设计联盟链的思考
整理了一些联盟链（私有链）的设计，非原创，不可转载
整理时间为2018年年末
BCOS与Fabric等国外底层的若干比较，介绍下双方的区别，并提出一些对国产联盟链发展方向的思考。
共识方面
共识的发展方向目前主要是BFT（拜占庭类）和非BFT两类，前者考虑节点“作恶”问题，即网络具有一定抗欺诈能力，后者则以考虑通讯故障为主，不考虑抗欺诈问题。
BCOS目前同时支持两种共识方式：PBFT和RAFT。PBFT是BFT类共识，这使得网络具有支持弱信任环境的能力。BCOS平台对PBFT共识过程进行了优化，尽量让所有节点在每个阶段的计算都是并行发生，不需要互相等待，以充分提高共识效率。RAFT方面BCOS平台采用的是标准RAFT协议，并进行了针对极端网络环境的优化。此外，BCOS平台中的RAFT结合智能合约（BCOS的节点管理、权限管理可以通过智能合约设置）可以支持节点动态增加和退出网络，这点是平台的一个优势。
Fabric曾在0.6版中使用PBFT共识协议，在1.0版，转而采用Kafka方式实现共识，效率获得了较大提升。与Fabric不同，摩根大通主推的Quorum平台可以支持IBFT和RAFT两类协议的，微软的Coco采用的则是Paxos和Caesar，Ripple采用的是波纹协议共识算法（RPCA）。应该说国内外在共识方面都有多元化的倾向，这也是联盟链发展的一个特点。
从共识角度来讲，其实所有联盟链设计都应该考虑“联盟”的含义和性质，是高度可信的联盟还是松散、弱信任的联盟，不同的联盟类型确实需要不同的共识协议，提高对共识类型的支持能力，以更好地适应联盟环境是非常必要的。除此之外，也应当考虑共识范围，这么说可能有点儿“离经叛道”，但是现在联盟链都有支持数据有限可见范围的发展倾向，在这种条件下，所谓的共识究竟是什么含义？共识的方式和参与共识的节点范围，都应当做新的思考，而非继续沿用公链或者仅从数据库共识的角度考虑问题。
扩展性方面
参加到联盟链中的机构，最好能够具备独立的节点，这样可以减少网络中的“代理”行为，从而提高节点平等自主的参与能力，才能有利于实现更加真实的、由较多主体参与的多中心、弱中心生态环境。但这样就带来一个扩展性问题，需要联盟链架构能够支持更多的节点数。
联盟链解决扩展性问题目前主要是两种思路：提升单链性能和采用多链并行。在2014年，V神的以太坊社区曾经讨论过“中心轮辐链模型”，这是多链结构应用在扩展性方面的早期想法
Fabric在设计上有“多链”的影子。其通道机制原本在白皮书中希望用于实现多种业务网络之间的连接，每个通道都有一个账本，实际上有多链的意思，应该也可以用于支持扩展性，但是实际操作中更多是被用于数据隔离了。
其实在1.2版引入“私有数据”概念后，数据隔离问题已经可以通过“私有数据”方式加以解决，可以考虑将“多链”用于解决扩展问题，增强对通道机制的改进。
在1.1版支持了账本加密，1.2版增加了私有数据概念，在最新的1.3版中，支持了使用Identity Mixer实现MSP(零知识身份证明) 最新版本1.4于 Dec/20/2018上线
BCOS是并行多链结构，设计思路是在一个区块链网络中设置多个分组，每个组是一个完整的区块链网络，有独立的软件模块和硬件资源，可独立完成机构间共识，有独立的数据存储。根据可定制的路由规则，网络中的所有机构、用户及不同类型的交易，都可以接入到不同的分组里，可以较为容易地增加分组，并在路由策略中进行设定，应用上也可以实现基于路由的跨链操作。
在扩展性方面，一些基于公链设计的联盟链较好地回避了节点数限制问题，考虑到平台生态的延展性和对更强大的行业覆盖能力的要求，节点扩展及由此带来的考验是联盟链平台设计必须关注的，以避免由于联盟链扩展能力的局限而产生一个个新的数据孤岛。
隐私与安全
BCOS在安全方面可以支持第三方认证CA，并定期检查证书有效性，这对国内应用而言是非常实在的。可以支持内置反洗钱名单，满足金融行业的KYC要求。
隐私方面，最重要的是BCOS支持国密算法，这对国内金融机构而言非常重要。交互方面，设计了AMOP协议，以提供机构间的点对点通信，通信信息属于链下信息，不在全网共享，链上部分在引入中央对手方提供信用背书的情况下，数据也仅在交易方和中央对手方之间共享。此外，BCOS还支持了群签名、环签名、同态加密、零知识证明等保护手段。
数据挖掘方面
在这方面，BCOS为区块链设置了一个准实时的数据ETL（Extract-Transform-Load），及时将链上新区块包含的交易列表、交易明细、交易结果、智能合约状态数据、链上配置信息等全部导入到链外的数据仓库里。数据仓库的数据只增不减，写入后不允许再发生变化，并随时可以和链上数据源进行对比验证，以保证其完整性和不可篡改性。通过数据仓库实现数据的查询、分析和挖掘，以对区块链上产生的数据进行复杂的整合和加工，满足更多应用上的需要。
Fabric的数据库是账本数据库加状态数据库，状态数据库是基于账本数据进行的状态提取和更新，可以是LevelDB或者CouchDB，后者支持富查询，但是效率比前者要低。但是二者仅限于对状态的存储，更多的数据加工还是要自行设计。多数国外联盟链平台都没有考虑数据加工问题，这应该是设计思路上的差别。
从设计角度来讲，联盟链首重的是联盟的构建和内部效率的提升，因此，在通过区块链技术构建可信连接的基础上，增加对应用便利性的支持是非常必要的，现有的联盟链多数在部署上都比较复杂，也缺少工具性支持，这点BCOS做的相对好些。无论从应用还是竞争的角度来讲，国产联盟链确实需要多加强这方面的工作。
开发主体方面
联盟链平台开发难度较高，但是区块链技术发展却比较快，所以，新技术手段的加入、平台升级、开发支持、运维支持都离不开平台提供者，这是联盟链与公链的一大显著区别，联盟链是有“主儿”的，而且离开了“主儿”的支持，在应用方面的确是挺艰难的。
国内涌现了不少联盟链平台，参考了一下Hyperchain，它只公布了文档，却迟迟未发布代码
验证节点授权机制
Hyperchain通过 CA认证授权实现联盟链准入机制。当一个新成员被准许加入联盟时，他将自己的公钥以及必要的身份标识信息发送给证书签证机构 CA。然后，CA 根据这些信息，为其颁发证书，作为加入联盟的许可认证，证书实际是由 CA 签发的对用户的公钥的认证。新成员发送消息时，需要附带自己的身份信息，其他节点收到该成员的消息时，对其身份进行认证，如果认证失败，则无法参与记账。所以，只有通过 CA 授权的成员，才会被联盟中的其他节点承认。
为解决 Internet 的安全问题，Hyperchain 采用 PKI 体系结构采用证书管理公钥，通过第三方的可信机构 CA，把节点的公钥和节点的其他标识信息捆绑在一起，在网络中验证节点的身份，将节点分为验证节点（参与共识记账）、非验证节点（参与部分区域记账）监管节点（参与全网记账）。PKI 体系结构把公钥密码和对称密码结合起来，实现密钥的自动管理，保证网上数据的机密性、完整性、有效性。
传输层加密
Hyperchain 采用了可插拔的加密机制，首先实现了椭圆曲线数字签名算法（ECDSA）对交易进行签名，防止消息被恶意篡改；其次通过 ECDH 密钥协商技术对传输层数据加密，保证交换双方可以在不共享任何秘密的情况下协商出一个密钥，然后根据该密钥对称加密进行安全的网络数据传输通信；最后通过Hyper－key 对数据进行加密存储，保证了原始数据本身的加密。
国密支持
Namespace分区
Hyperchain 设计基于Namespace的分区共识机制通过区块链账本的分区维护，交易的分区共识实现了敏感交易数据的存储和执行空间的隔离。
Namespace机制允许部分区块链节点创建属于它们的 Namespace，这些Namespace成员之间的数据交易以及存储对其他Namespace中节点不可见。Namespace中允许授权节点的动态加入和退出，单个 Hyperchain节点支持授权加入任意数量的Namespace。
Hyperchain通过Namespace(名字空间)机制实现区块链网络内部交易的分区共识。Hyperchain平台的使用者可以按照名字空间进行业务交易划分，同一个Hyperchain联盟链网络中的节点按照其所参与的业务组成以名字空间为粒度的子区块链网络。名字空间通过业务的交易共识、分发以及存储的物理级别隔离实现业务级别的隐私保护。
共识的节点动态增减
- 动态成员管理与权限控制（DMPC）：Hyperchain 共识模块实现了在区块链网络中动态增删节点机制，使得整个网络在不宕机的前提下准入或删除节点。同时，通过CA证书的方式区分不同节点，达到节点之间的权限控制功能。
- 动态数据失效恢复机制（ARCM）：共识模块在原有机制上，新增了Recovery机制。节点重启时，Recovery机制能自动检测节点并自主更新，同时也是动态增删的基础。当一个节点发生 ViewChange 而无响应时，Recovery机制进行自我恢复。Recovery机制的存在大大地增强了共识模块的可用性。
参考文档 hyperchain.git
https://github.com/hyperchain/hyperchain/tree/master/docs/zh_CN
CA manager的概述
https://github.com/hyperchain/hyperchain/blob/master/docs/zh_CN/ca_manager.rst
namespace分区的概述
https://github.com/hyperchain/hyperchain/blob/master/docs/zh_CN/namespace.rst
在链上有CA，CA manager对应到P2P网络时，又有对应的peer manager
peer主要用于处理逻辑上的消息发送请求。其主要工作就是对消息进行加密，然后调用Hypernet Client的对应的消息发送方法，并且消息中需要附着namespace信息。
