区块链【各联盟链分析】

作者: 老鱼_chaimyu | 来源:发表于2020-04-29 11:18 被阅读0次

BSN

国家信息中心、中国移动通信集团设计院有限公司、中国移动通信有限公司政企客户分公司、中国银联股份有限公司、中移动金融科技有限公司、北京红枣科技有限公司。

BSN的直接参与方有三类：

一是云服务商，通过安装免费的区块链服务网络BSN公共城市节点软件，将其云服务资源（CPU、存储和带宽）接入BSN，并在BSN上进行销售；
二是区块链底层框架商（特指联盟链），根据BSN底层框架适配标准将框架进行适配后，可以部署到服务网络，供开发者选择使用；
三是门户商，可以在已有的云服务门户或开发者门户内，通过BSN快速并低成本地建立BaaS(Blockchain as a Service)平台，并向自己的客户提供基于BSN的区块链应用开发、部署和运行服务。

image

目前，BSN已经支持Hyperledger Fabric，正在适配的联盟链底层框架有Fabric国密、FISCO BCOS、CITA、XuperChain、梧桐链和 Brochain等。针对公链框架，目前支持以太坊和EOS等。

火币创始人李林曾表示，BSN网络最大的竞争优势之一就是价格成本十分低廉，因此能够触及到更多用户

CITA

Cryptape Inter-enterprise Trust Automation

CITA 将区块链节点的必要功能解耦为六个微服务：RPC，Auth，Consensus，Chain，Executor，Network。
各组件之间通过消息总线交换信息相互协作。

水平扩展性

在 CITA 的微服务架构中，“节点”是一个逻辑概念，有可能是一台服务器（一台服务器上面运行一组微服务），也有可能是一组服务器组成的集群，同时 CITA 还支持部署在云服务器上，充分利用了各种服务器硬件来提升处理能力。节点与节点之间通过 P2P 通信，节点内部各模块通过消息总线通信，这一点与 Fabric 仅仅在共识模块运用消息总线通信完全不同。

组件可插拔

松耦合的微服务架构，便于各组件将来平滑迁移至更好的算法（比如新的共识算法）或者更好的技术方案（比如新的 DB 或者新的隐私方案）；也有利于针对一些具体的业务场景，定制一些特定的功能。

高性能

微服务架构将 Chain 与 Executor 独立出来，Executor 仅负责计算和执行交易，Chain 负责存储交易，使得计算和存储分离，极大程度的提高了交易处理能力；编程语言采用 Rust，Rust 强调并秉持零开销抽象的理念在提供诸多高级语言特性的同时，没有引入额外的开销，性能可以媲美 C++。最新版本的交易性能已经可以达到 15,000+ TPS（数据来自 CITA 0.16 版本，在四台 32 核，64G 的云服务器上部署 4 个节点，每台服务器配置百兆带宽）

稳定可靠

CITA 提供快照工具来对区块链的数据进行备份，可在较短时间内恢复链数据。同时，Rust 借鉴了编程语言领域最新的研究成果，针对 C++中最头疼的内存问题（内存泄漏，野指针）进行编译器静态检查。只要代码编译通过，就可以保证没有以上问题，大大提高了应用运行阶段的可靠性。

兼容性

CITA 上支持使用 Solidity，Go 语言，Rust 开发智能合约，同时也支持以太坊的所有开发工具（Truffle，Zeppeling，Remix 等）。

链间互动

在区块链世界里，各种各样的链在不断的涌现出来。这些链如何互相配合形成区块链网络？ CITA 目前提供了一个简单的跨链协议来支持主链与侧链之间的通信。我们也正对跨链通信做更多的探索，旨在扩大在各种链上运行的应用程序的价值。

快速入门 https://docs.citahub.com/zh-CN/0.18/cita/chain/getting-started

共识

共识算法解决的是针对某个提案 (proposal)，系统中的节点达成一致的过程。在区块链系统中，共识算法确保所有正确节点的交易顺序是一致的。CITA 共识模块包括 Raft 和 CITA-BFT 的实现，共识模块负责接收交易并进行简单验证，然后打包出块。在 CITA 的实现中，共识以相对独立的形式存在，其他共识算法的实现可以很方便地集成到 CITA 中。

在众多的分布式算法中，我们选择实现了非拜占庭容错的 Raft 算法和拜占庭容错的的 CITA-BFT 算法。

Chain

Chain 模块可以认为是一个 Append only 的 KV 数据库，它以块为单位，不断添加新的区块到链上，并存储交易以及交易执行后的状态到数据库。

VM Engine

智能合约是运行在可复制、共享的账本上的计算机程序，可以处理信息，接收、储存和发送价值。而合约引擎则为智能合约提供了一个简单、确定、高效、安全的执行环境。CITA 提供了多种形式的合约引擎，用户使用接口与 EVM 兼容：

EVM 合约引擎
原生合约引擎

交易处理

CITA 采用微服务架构，各个服务之间通过消息通道进行消息的传递，服务间的消息采用 Protobuf 格式进行编码。各个服务在收到消息后，根据实际情况将消息转化为服务内的结构，进行相应处理。

在 CITA 中交易的生命周期内，用户在客户端按照 Protobuf 结构进行交易构造，将 Protobuf 结构序列化为 bytes 结构，将消息以 JSON-RPC 格式发送到 RPC 模块。RPC 模块对消息进行简单验证，验证通过后将消息发送到 Auth 模块。Auth 模块进行签名验证等，将验证结果通过消息通道返回给 RPC 模块，与此同时，如果验证通过，会将消息插入交易池。最终共识模块打包交易，发送给 Chain&Auth 进行处理。

RPC

RPC(Remote Procedure Call Protocol) 即远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，不需要了解底层网络技术的协议，是基于可靠性、可控制 TCP 的应用层协议，从而保证了用户数据的传输完整。

在 CITA 内部专门提供了 RPC 模块，用于处理用户的 RPC 请求。其作用，一方面对用户的请求数据进行简单的校验，对不符合格式的数据进行友好错误状态返回，对于内部模块，过滤了部分杂乱请求，减少了共识模块等部分压力;

另一方面，从用户角度来说，它是唯一与 CITA 节点进行数据交互的模块，用户不需要关注其它模块的运行状态即可得到相应的服务，在一定程度保证了 CITA 其它模块的运行安全。

帐号

常见的视图状态模型有 UTXO 及账户两种。在 UTXO 模型中，由 UTXO 构成账本视图，每个交易在销毁旧有 UTXO 的同时创造新的 UTXO；在账户模型中，由账户构成世界状态视图，交易在处理过程中可以读写多个账户。账户模型相对更加简单，实现通用任务更有效率。在企业级应用中往往存在身份验证与授权的需要，这些服务所依赖的数据可以自然的与账户模型关联。CITA 默认支持账户模型。用户可以自定义包括 UTXO 在内的其他状态模型。

在 CITA 中存在两种账号：外部账号和合约账号。外部账号通常情况下代表用户的身份，用户可以通过外部账号来发送交易。与公链不同，CITA 具有用户准入机制。首先用户自行生成私钥和公钥，私钥由用户妥善保存；然后将公钥通过链外的方式提交给 CITA 系统中的 KYC 系统；通过申请之后，系统管理员将用户公钥通过操作账户管理合约，发送交易将用户加入 CITA 网络中。对于未准入的外部账户，无法向 CITA 发送交易。同时，CITA 内置了基于角色的权限管理，系统管理员（角色）可以根据实际情况灵活配置账户的权限。

存储

区块链本质上去中心化的分布式复制状态机，每个节点通过持久化的方式来保存自身的状态。CITA 使用 KV 持久化数据存储，支持 RocksDB、LevelDB。节点将 Block 结构，交易以及合约状态等持久化保存到 KV 数据库中。

为了更高效的检索和更新数据，区块链一般会在内存中维护某种数据结构的视图模型。对于传统的区块链，如 Bitcoin 采用了 Merkle Tree 来保存交易；Ethereum 采用了 Merkle Patricia Tree，一种改进的 Merkle Tree 来保存状态和交易。 CITA 采用了一种更高效的 AVL 来保存账户状态，并且采用了 Simple Merkle Tree 来保存交易列表和交易回执。

XuperChain

第一，提供多组件、可实现定制化开发。
智能合约、共识机制等能力被拆解成单个模块，开发者根据场景应用需求进行灵活调用，让区块链应用搭建更加高效。

第二，支持全球部署，可在高效的广域网数据交换。

第三，性能行业领先，采用独创的链内并行技术，实现单链6.5万TPS，整体网络20万TPS。

第四，提供了多私钥保护的账户体系，且账户系统是内置在账本，实现了去中心化的权限校验，权限模型支持权重累计、集合运算等灵活的策略。

除此之外，百度自建区块链社区，提供完善、周全的开发者服务，保证开发者快速、便捷搭建应用。

官网
https://xchain.baidu.com/

Github
https://github.com/xuperchain/xuperchain

梧桐链

同济大学联合海航科技、欧冶金融、上海银行、中国银联等企业，共同发起了梧桐链

梧桐链的技术架构如下图所示，由底层平台和基于底层平台的对外应用模块构成。底层平台由网络服务、数据存储、权限管理、安全机制、共识机制、智能合约等部分构成。对外应用模块可针对不同的应用场景进行系统化定制和提供开发API等。

image

1.1. 网络服务

梧桐链基于TCP/UDP的通讯协议，支持点对点P2P通讯。节点角色可根据使用情况定制扩展，分离出不参加共识而只存储或读取数据的节点，分担主网络的查询负担。

各个节点采用P2P网络技术组织网络，支持多节点的动态加入和退出。节点的加入和退出由权限管理控制，新加入的节点需要经过已经存在的节点一致同意才能够成功。

1.2.数据存储

梧桐链在运行期的数据保存在节点的内存中，当需要记录一个新的区块的时候，可以对于不同的数据，选择与其相适应的持久化方案来保存区块，包括但不限于关系型数据库、NoSQL、文件系统等。

目前梧桐链已实现使用LevelDB存储数据，并支持扩展到使用公有云存储。

1.3.权限管理

权限管理负责所有参与梧桐链的节点权限的管理，对不同节点分别授予不同的权限。此外对于梧桐链的访问和读写权限也有权限管理模块负责，链上数据只有获得授权的用户才能够访问。

基于数据在节点间匿名验证的考虑，梧桐链研发团队正在开发零知识正明和环签名算法，将在后续的版本中上线。

1.4.安全机制

梧桐链的设计上需要充分考虑企业级的安全性要求，采用符合国家和国际标准的加密机制，在服务器实施部署上也有相应的安全性保障措施。区块和链式结构，哈希算法、非对称加密和签名算法均支持国密算法。

梧桐链基于PKI的证书体系做节点身份认证，CA服务器管理证书的发行和销毁，节点使用数字证书进行验证和加解密，防止出现节点证书重复使用、节点重复登录、节点退出等事件引起的安全问题。

1.5.共识机制

共识算法是使梧桐链中各个节点达成- - 致的策略和方法。梧桐链采用模块化的设计，共识算法模块为可插拔设计，内置多种共识算法模块，用户可根据系统类型和应用场景进行手动选择或动态调整。此外，梧桐链预留共识模块的接口，用户可根据自己的需求编写并替换共识模块。

梧桐链已经实现Raft和PBFT共识算法。

Raft是在Paxos基础上实现的一种分布式- 致性算法，结构简单且具有与Paxos一样的功能与性能，在联盟链的场景下，梧桐链对Raft进行了适配区块链的修改和实现，能够在半数节点出现故障的情况下保证系统的一致性。

PBFT是一- 种拜占庭容错算法，能够在节点数量不小于n=3f+1的情况下，容忍f个拜占庭节点，但由于其通讯效率较低，后续会在此基础上进行改进。

此外，梧桐链研究团队正在研究一种可扩展的拜占庭容错算法，能够根据网络环境和安全情况动态调整算法，并可通过多节点并行，在不降低容错的情况下提高tps。

1.6.智能合约

梧桐链采用Docker容器方案来提供隔离安全环境，智能合约运行在Docker容器中，能与链系统隔离，保证了合约执行的安全性。用户可根据梧桐链技术文档，使用G0语言编写智能合约。Docker容器方案可提供良好的系统兼容性。

梧桐链将实现自定义轻量级虚拟机方案，智能合约在虚拟机中执行，确保和链上数据的隔离，避免安全风险。同时相比Docker容器方案更加高效，支持受控的I0，内置丰富的微服务接口。

依托于研究院测试平台，在设计和开发过程中，梧桐链将引入智能合约安全测试体系，提供测试工具来检测智能合约中的安全漏洞，帮助用户发现并解决合约中的安全问题。

1.7.应用网关及SDK

SDK为开发者提供区块信息写入、查询、读取等操作，使得接入梧桐链的难度大大降低。目前梧桐链提供G0语言版本的SDK，更多语言的SDK正在开发中。同时提供HTTP Restfu1的应用网关，使得应用系统的接入更加简单、灵活。

官网
https://www.wutongchain.com/

Fabric

hyperledger

超级账本（hyperledger）是Linux基金会于2015年发起的推进区块链数字技术和交易验证的开源项目，加入的成员包括金融、制造、航运物流、咨询等各行业的巨头。该项目的愿景是打造一个透明、安全、去中心化的企业级区块链解决方案。让更多企业能用上区块链，用好区块链。

Hyper Ledger和fabric的关系

Fabric是Hyper Ledger的一个子项目。它是作为企业级联盟链的基础设施而存在的。

节点

比特币、以太坊这种公有链上的节点只有两种，全节点（全部区块的历史数据）和轻节点（只和自己有关的数据），每个角色间是平等的，不含特殊功能。而Fabric的角色成员至少分为三种：主节点、背书节点、记账节点和排序节点。其中主节点、背书节点、记账节点属于组织内节点，排序节点属于组织外节点。Fabric的节点扮演的是不同的角色。

作为公链，比特币、以太坊的节点必须全部连入公网，否则无法参与到网络交易中。而Fabric只需要把组织外节点（即排序节点）部署在公网中，而每一个参与其中的企业主体，只暴露一个主节点就可以了。这种巧妙的设计可以帮助企业不用大动干戈就可以用上区块链，同时还保证企业内网的安全。

架构

Fabric的架构包括四种：1、客户端。2、Peer。3、Orderer。4、CA

特点

Fabric采用X.509数字证书验证使用者身份和角色。不同于公链，联盟链的成员相互了解并存在合作关系，每个成员具有明确的身份，每次操作都有据可查。身份会带来监管和安全，一旦成员进行恶意操作，立刻会被其它成员发现并对其进行惩罚。
Fabric取消了矿工和激励机制，这是因为联盟链中各成员有天然的动力部署自己的节点来保证数据安全，联盟链成员既是系统的使用者也是系统节点的提供者。从本质上消除了矿工和激励机制，也解决了始终困扰公链的资源竞争问题。
基于身份机制，Fabric支持权限控制，系统可以授予读写数据、调用部署合约等权限给不同的成员或角色。Fabric还支持数据隐私保护，成员只能访问所属通道的数据，同一通道中也通过私有数据功能保护数据只被指定成员使用。
Fabric创造性地将合约执行和出块上链分离。公链系统中，合约执行必须和出块在一起，这是因为公链的节点间并缺乏信任，无法赋予部分节点特殊角色例如出块。而联盟链的节点具有身份和高信任度，能够分化出具有不同角色的节点来提高系统的整体性能。Fabric中peer节点负责数据保存和合约执行，orderer节点负责将事务执行结果打包出块同步给peer节点。这样一来，peer节点可以执行复杂的合约调用而不会影响出块，orderer节点专注于出块从而提高TPS。
还是基于身份机制，Fabric采用更简单高效的共识机制。联盟链的共识机制主要解决由于网络环境导致的数据不一致问题，而不用关心公链共识机制的难点欺诈问题。Fabric提供单节点出块以及kafka集群出块两种方式。在此基础上，有望实现商用级出块速度。
Fabric支持企业级应用开发，主要体现在一下几点，

支持Node，Go，Java等主流开发语言，方便大多数开发者开发。
支持部署复杂结构合约（多文件项目）以及合约升级。
合约数据保存在状态中，升级合约不影响状态数据，并可将状态数据存入数据库中，方便查询。

https://www.jianshu.com/p/c3755b7094b3

Github
https://github.com/hyperledger

使用Hyper Ledger Fabric实现企业级联盟链
https://www.jianshu.com/p/5a98425cefcf

https://www.jianshu.com/p/64281ff8de13

https://www.hyperledger.org/projects/fabric

FISCO BCOS

FISCO BCOS平台是金融区块链合作联盟（深圳）（以下简称：金链盟）开源工作组以金融业务实践为参考样本，在BCOS开源平台基础上进行模块升级与功能重塑，深度定制的安全可控、适用于金融行业且完全开源的区块链底层平台。金链盟开源工作组的首批成员包括以下单位：微众银行、深证通、腾讯、华为、神州数码、四方精创、博彦科技、越秀金科、亦笔科技等9家单位。

FISCO BCOS 最初源自以太坊C++版本

特点

FICO BCOS 平台对以太坊的众多功能删繁就简，保留了区块链最核心的特性。熟悉Solidity和以太坊的开发人员可以迅速的搭建起联盟链和开发智能合约，并可以参考和使用大量的用于以太坊的成熟框架和库，加快开发速度。
去掉了代币逻辑，在生成区块时不会发行和奖励代币。由于去除了代币，gas的消耗不和代币挂钩。FISCO BCOS保留了智能合约引擎的gas控制逻辑，以保障计算安全，针对每个区块里的每个交易能消耗多少gas，在系统的设置里可以配置。
FISCO BCOS 平台对于交易量适中，权限管理简单的联盟链应用来说，提供了良好的经济性。例如已经在使用该平台的司法存证系统和盲拍应用。一方面，节点的搭建和扩容步骤简单，合约的开发和维护容易，大大减少了集成链上链下应用的成本。另一方面，在PBFT或RAFT共识机制的支持下，可以实现秒级出块，单链可以满足100tps的交易量。
针对中国市场的需求，特别加入了对国家密码局认定的商用密码的支持。实现了国密加解密、签名、验签、哈希算法、国密SSL通信协议。对于一些对加密有特殊要求的应用场景，FISCO BCOS是为数不多满足需求的平台。

缺点

Solidity和EVM目前的功能还无法充分满足各种复杂业务场景的需求。为了保证可升级性，合约里保存的数据和功能不能太复杂。常规业务调整导致的合约升级也会带来比较大的挑战。FISCO BCOS 平台提供的不少特有功能目前完成度很低，还达不到商用的水平，无法形成相对其他联盟链平台的独创性。
版本演进变化极大，版本间无法向后兼容。迁移业务到新版的成本极高。FISCO BCOS平台仅提供了官方Java SDK来开发应用，对其他开发语言支持的比较差

https://www.jianshu.com/p/2b3976a54bf5

官网
https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/index.html

Corda

Corda 是由 R3CEV 推出的一款分布式账本平台，其借鉴了区块链的部分特性，例如 UTXO 模型以及智能合约，但它在本质上又不同于区块链，并非所有人都可以使用这种平台，其面向的是银行间或银行与其商业用户之间的互操作场景。

关于Corda是什么，我们有三句话：首先，Corda是一个分布式账本；第二，Corda是一个去中心化数据库；第三，Corda是一个“受区块链启发的”技术平台。

UTXO模型

Corda采用了比特币的UTXO模型而不是以太坊的“账户-余额模型”，这一点是值得赞许的。UTXO模型与账户-余额模型最大的不同点，就是它直接记载原始事实，而不是根据原始事实推断出来的余额。不错，余额往往直接可用，但余额与原始事实毕竟隔了一层甚至多层。从以太坊的经验看，仅凭余额状态的日志，有时不足以完整解释余额状态何以发生。所以，以注重原始单据合法合规性的银行应用为背景的Corda，选择UTXO模型来组织基础数据，是完全可以理解的。

Graph

图谱（Graph），在Corda中起着核心的作用。它的作用，用大白话说就是“自带证据、自证清白”。

因为没了统一总账，没了“所有人见证所有交易”的机制，发起交易并主张预期交易结果的人必须有相应的替代机制去推进交易的达成，具体落地就体现为“图谱”。图谱把需要自带的证据组织成有向无环图（DAG）结构，交易对手方或流程下游的主体可沿着图谱的走向一一验证。理论上，要想验证一笔交易，不仅要验证直接证据，还要验证产生直接证据的各层间接证据，乃至一直追溯到源头。

公证人

公证人（Notary），是Corda区别于其他分布式账本平台的最大不同点，某种意义上可以认为是一笔特定交易的交易双方共同认可的可信第三方。这在传统银行业务中本不是问题，但是在分布式账本平台当中，确实显得另类。有人批评说公证人的引入使得本来从技术上可以完全去除可信第三方的区块链技术又倒退回了必须依赖可信第三方的中心化局面，这话听上去不无道理。但是，Corda中的公证人和传统意义上的可信第三方，还是有很大不同的。

智能合约

Corda中的智能合约，是为验证输入状态（单据）是否有效和输出状态（单据）签发条件是否为真而设定的程序代码，在Corda里统一命名为verify()函数。这种智能合约程序代码在Corda中被转译为字节码，在特定的JAVA虚拟机上运行。

隐私保护

一是抽离（Tear-off）部分敏感内容的类盲签名技术。该技术采用把敏感字段和非敏感字段分组哈希，再分层构建Merkel树的方式，使得去掉敏感字段后，剩余的Merkel树仍然具有树状结构和针对非敏感字段的验证价值，可在其基础上达到类似盲签名的效果。同时一旦发生法律纠纷，如已去除的敏感字段内容被伪造，该Merkel树还可用作鉴别证据真伪之用。

二是复合签名技术。该技术使用感知机模型，对多个签名主体赋权，并设置加权求和阈值。一旦一个指定群体中签名的主体所占加权和超过阈值，则复合签名生效。这个模型可以实现一组签名的“与/或”逻辑组合，但在涉及“异或”这样的逻辑组合时失效。

监管和运营控制

监管介入，体现在Corda的如下一些技术环节：

（1）许可环节，可提出实名制要求、设置准入条件、通过证书和名字服务将监管要求落地；

（2）运营环节，可赋予监管节点访问一切节点上本地数据库的权限，获取全部交易数据，达到“看穿式”效果；

（3）应急处置环节，可赋予特定节点进行应急处置操作的特权，包括但不限于暂停交易、纠正错误交易等。

私钥安全

在Corda中，任何一个“节点”都是和“身份”绑定的，而“身份”在数字世界的具体代表就是证书及私钥。在这样一个联盟链中，私钥和节点之间的关系是至关重要的。按照某些国家和地区的信息安全法律法规，核心金融机构的私钥可能必须采用独立于节点设备的物理介质（类似U盾）的形式，采用指定的密码学算法标准并且禁止私钥在规定物理介质之外存储。人和私钥在物理场景中的分离，私钥信息在无人看管的节点机内存储，这都是私钥安全的大忌。

即便如此，也会提出一旦私钥丢失，应该如何应对的问题。这个问题还可以进一步分解为“如何防止该用的人不能用”和“如何防止不该用的人试图用”两个子问题。在Corda中，前一个问题可以通过复合密钥来解决（在主用私钥和备用私钥之间设置“或”逻辑），而后一个问题是否可以仅通过网络访问控制措施来解决，还是一个疑问。

联盟链可能应用领域

供应链金融
共享出行
司法存证
追踪溯源
文化版权
...