开源项目与联盟链平台

超级账本Fabric

超级账本项目是由IBM和Linux基金会领导的组织集团推出。该项目包括很多子项目，由众多全球领先组织创建。它是一个跨行业的开源合作项目，意在促进区块链在不同行业的应用。超级账本 Fabric是一个模块化企业区块链框架，由 IBM开发，为了帮助各行业迅速适应区块链开发的范式。来自 28个组织的159名工程师为项目做出了贡献，以期推动开放式区块链产品和服务的发展

Linux基金会于2015年12月启动了名为“超级账本”（Hyperledger）的开源项目，旨在推动各方协作，共同打造基于区块链的企业级分布式账本底层技术，用于构建支撑业务的行业应用和平台。超级账本将提供多种的区块链技术框架和代码，包含开放的协议和标准，不同的共识算法和存储模型，以及身份认证、访问控制和智能合约等服务。模块化、性能和可靠性是很重要的设计目标，用于支持各种各样的商业应用场景。

从创始成员看，参与超级账本项目的公司阵容相当强大，不仅有IBM、Intel、思科等科技巨头，还有摩根大通、富国银行、荷兰银行等金融大鳄，还有R3，ConsenSys等专注区块链的公司。截至2016年6月底，超级账本项目已经汇集了全球超过80家公司，声势之浩大是其他技术联盟或开源项目无法比拟的。不管是从代码数量还是从社区参与度来看，超级账本都是最大的区块链开源项目。和比特币、以太坊等由极客主导的公有链项目相比，超级账本则是由大企业领衔的商业化联盟链项目。

Fabric（编织品）项目的目标是实现一个通用的许可链的底层基础框架。为了适用于不同的场合，Fabric采用模块化架构提供可切换和可扩展的组件，包括共识算法、加密安全、数字资产、记录仓库、智能合约和身份鉴权等服务。Fabric克服了比特币等公有链项目的缺陷，如吞吐量低、交易公开无隐私性、无最终确定性以及共识算法低效等问题，使得用户能够方便地开发商业应用。

区块链的存储主要包含以文件形式存储的链式区块数据，以及在数据库保存的键值对（Key-Value Pair）状态数据。其中链式区块数据存放的是交易的原始数据区块，通过区块的哈希值形成防篡改的链式结构。状态数据库的作用主要是加速对数据的访问。因为区块链数据采用链式顺序存放，在读取数据时通常需要遍历整个链的数据块，采用数据库能够从索引迅速定位到所需数据。 Fabric中的智能合约称为“链码”（chain code）。链码部署在节点上，采用容器技术形成隔离的运行环境。链码的生命周期管理主要包括链码的安装、实例化、调用和终止等。

作为联盟链方案，Fabric包含管理成员身份的功能。参与区块链网络的成员身份必须是明确的，成员之间知道彼此组织身份信息，每个交易都有确定的参与方和背书方，这是绝大多数商用系统的需求。相比之下，许多公有链的用户身份是匿名的，参与方无须确认身份信息。

服务层利用核心层的基础功能，封装成服务的形式，提供给应用端来使用。账本服务和交易服务通过核心层的共识算法和区块链存储，实现基本的区块链数据操作能力。-链码服务提供智能合约的功能封装。事件服务则提供应用侦听系统事件并处理的功能。权限服务根据成员和用户的身份信息，对其操作权限进行控制，成为商业应用中安全管理的一部分。

接口层的目的是使Fabric的应用（客户端）能够方便地调用区块链的服务。接口主要以API的形式提供，能够完成通道、链码、交易等方面的操作。为了便于编程语言的调用，Fabric提供了绑定不同语言的SDK，如Node和Java等的SDK。此外，Fabric还提供了命令行接口CLI，可无须编程，通过命令直接调用Fabric的功能。

主要组件 Fabric的组件包括客户端（Client）、网络节点（Peer）、CA（Certificate Authority）节点和排序节点（Orderer）。 客户端的主要作用是和Fabric系统交互，实现对区块链系统的操作。这些操作分为管理类和链码类。管理类操作包括启停节点和配置网络等；链码类操作主要是链码的生命周期管理，如安装、实例化以及调用链码。最常用的客户端是命令行客户端（CLI），此外是用Fabric SDK开发的应用客户端。用户可以通过不同的客户端使用Fabric系统的功能。 网络节点（Peer）是区块链去中心化网络中的对等节点，按照功能主要分为背书节点（Endorser）和确认节点（Committer）。背书节点主要对交易预案进行校验、模拟执行和背书。确认节点主要负责检验交易的合法性，并更新和维护区块链数据与账本状态。在实际部署中，背书节点和确认节点既可以部署在同一物理节点上，也可以分开部署。 排序节点（Orderer）的主要职责是对各个节点发来的交易进行排序。在并发的情况下，各个节点交易的先后时序需要通过排序节点来确定并达成共识。排序节点按照一定规则确定交易顺序之后，发给各个节点把交易持久化到区块链的账本中。排序节点支持互相隔离的多个通道，使得交易只发送给相关的节点（Peer）。 CA节点主要给Fabric网络中的成员提供基于数字证书的身份信息，可以生成或取消成员的身份证书（certificate）。在成员身份明确的基础上，Fabric可以实现权限控制的管理。 Fabric网络的组件往往归属于不同的组织，在组织之间形成对等的去中心化网络。每个组织通常拥有自己的客户端、网络节点和CA节点，并且可以根据需要创建一个或多个不同的类型节点。排序节点不属于某个组织的实体，属于组织共同维护的组件。各个组件的相互关系如图9-2所示。

P2P网络 Fabric的节点组成了一个P2P的网络。P2P网络的节点可以通过直接交换来共享资源和服务。节点彼此之间处于对等的地位，并不依赖于集中的服务节点来进行资源调度。网络中的每一个节点既能充当网络服务的请求者，又能响应其他节点的请求，提供网络资源和服务，以达到资源共享的目的。 在Fabric中，P2P技术主要用于网络节点之间的健康检测和账本同步。节点间的P2P网络由Gossip协议实现，在通道中的各个节点会持续广播和接收Gossip消息。Gossip的内容包含节点的状态、账本数据以及通道数据等信息，由于Gossip消息需要发送者的签名，因此伪造的消息很容易被识别。此外，还可以基于消息的签名对信息进行隔离。通过Gossip协议，受延迟、网络分区或其他因素而导致账本没有同步的节点，最终都会同步到最新的账本状态。

通道 商业应用的一个重要需求是私密性交易，为此Fabric设计了通道（Channel）来提供成员之间的隐私保护。通道是部分网络成员之间拥有独立的通信渠道，在通道中发送的交易只有属于通道的成员才可见，因此通道可以看作是Fabric的网络中部分成员的私有通信“子网”。 通道由排序服务管理。在创建通道的时候，需要定义它的成员、组织、锚节点（anchor peer）和排序服务的节点。一条和通道对应的区块链结构也同时生成，用于记录账本的交易。通道的初始配置信息记录在区块链的创世块（第一个区块）中。通道的配置信息可以用增加一个新的配置区块来更改。 每个组织可有多个节点加入同一个通道。这些节点中可以指定一个锚节点（或多个锚节点做备份）。锚节点代表本组织与其他组织的节点交互，从而发现通道中的所有节点。另外，同一组织的节点会选举或指定主导节点（leading peer）。主导节点负责接收从排序服务发来的区块，然后转发给本组织的其他节点。主导节点可以通过特定的算法选出，因此保证了在节点数量不断变动的情况下仍能维持整个网络的稳定性。 在Fabric的网络中，可能同时存在多个彼此隔离的通道，每个通道包含一条私有的区块链和一个私有账本，通道中可以实例化一个或多个链码，以操作区块链上的数据。由此可见，Fabric是以通道为基础的多链多账本系统。

分布式账本 Fabric里的数据以分布式账本的形式存储。账本由一系列有顺序和防篡改的记录组成，记录包含着数据的全部状态改变。账本中的数据项以键值对的形式存放，账本中所有的键值对构成了账本的状态，也称为“世界状态”（World State）。每个通道中有唯一的账本，由通道中所有成员共同维护。每个确认节点上都保存了它所属通道的账本的一个副本，因而是分布式账本。对账本的访问需要通过链码实现对账本键值对的增加、删除、更新和查询等操作。 账本由区块链和状态数据库2部分组成。 区块链是一组不可更改的、有序的区块（数据块），记录着全部交易的日志。每个区块中包含若干个交易的数据，不同区块包含的交易数量可以不同。区块之间用哈希链（Hashed-link）关联：每个区块头包含该区块所有交易的哈希值，以及上一个区块头的哈希值。这样的链式架构可以确保每个区块的数据不可更改，以及每个区块之间的顺序关系不可更改。这个特点决定了区块链的区块只可以添加在链的尾部。 状态数据库记录了账本中所有键值对的当前值，相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态，从状态数据库可以迅速获取键值的最新状态。如果没有状态数据库，要获得某个键值时，需要遍历整个区块链中和该键值相关的交易，效率非常低。因此，读取状态数据库可以认为是快速定位和访问某个键值的方法。另外，当状态数据库出现故障的时候，可以通过遍历账本重新生成。当一个区块附加到区块链尾部的时候，如果区块中的有效交易修改了键值对，则会在状态数据库中做相应的更新，这样区块链和状态数据库就能始终保持一致。 区块链的数据块以文件形式保存在各个节点中。状态数据库原理上可以是各种键值数据库，Fabric缺省使用的是LevelDB，它也支持CouchDB的选项。CouchDB除了支持键值数据之外，也支持JSON格式的文档模型，能够做复杂的查询。

共识机制 Fabric的网络节点本质上是互相复制的状态机，节点之间需要保持相同的账本状态。为了实现这个目的，各个节点需要通过共识（consensus）过程，对账本状态的变化达成一致性的认同。因为账本记录的是系统中发生的交易，共识机制实际上就是要确保各个节点看到相同的交易顺序和交易内容，从而保证各个节点都处于相同的状态。 Fabric的共识过程包括3个阶段：背书、排序和校验。 1.背书 在背书（endorsement）阶段，背书节点对客户端发来的交易预案进行合法性检验，然后模拟执行链码得到交易结果，最后根据设定的背书逻辑判断是否支持该交易预案。如果背书逻辑决定支持交易预案，它将把预案签名后发回给客户端。缺省情况下，背书节点的背书逻辑是直接支持预案并签名。但是节点也可以依照业务规则设定背书逻辑，从而仅对符合业务需求的交易进行背书。如果背书节点判定不支持交易，则给客户端返回错误信息。 客户端通常需要根据链码的背书策略，向一个或者多个成员的背书节点发出背书请求。背书策略会定义需要哪些节点背书交易才有效，例如需要5个成员的背书节点中至少3个同意，或者某个特殊身份的成员支持等。客户端只有在收集满足背书策略的支持之后，广播出去的交易才能被视为有效。 2.排序 排序（ordering）阶段就是由排序服务对交易进行排序，确定交易之间的时序关系。排序服务把一段时间内收到的交易进行排序，然后把排序后的交易打包成区块，再把区块广播给通道中的成员。采用这种方式，各个成员收到的是一组发生顺序相同的交易，从而保证了所有节点数据的一致性。 Fabric 1.0中的排序服务支持可插拔的架构。除了提供的SOLO和Kafka模式外，用户还可以添加第三方的排序服务。SOLO是单机确认模式，仅适合开发测试中使用。Kafka模式是基于Kafka开源的分布式数据流平台，具有高扩展性和容错能力，适合用在生产系统。需要注意的是，Kafka只提供了CFT类型的容错能力，即仅可对节点的一般故障失效容错，缺乏对节点故意作恶行为进行容错的能力。因此，需要第三方的容错方案来支持BFT。 排序服务是共识机制中重要的一环，所有交易都要通过排序服务的排序才可以达成全网共识，因此排序服务要避免成为网络上的性能瓶颈。为此，排序服务采用轻量级设计，只完成确定交易顺序的功能，不参与其他操作。 3.校验 校验（validation）阶段是确认节点对排序后的交易进行一系列的检验，包括交易数据的完整性检查、是否重复交易、背书签名是否符合背书策略的要求、交易的读写集是否符合多版本并发控制MVCC（Multiversion Concurrency Control）的校验等。当交易通过了所有校验之后，将被标注为合法并写入账本中。因为所有的确认节点都按照相同的顺序检验交易，并且把合法的交易依次写入账本中，所以它们的状态能够始终保持一致。 更多的共识机制的介绍参见9.1.9节。

智能合约（链码） “智能合约”的概念最早出现在1996年，由密码学家尼克·萨博（Nick Szabo）首次提出。他对智能合约的定义为：“智能合约是一套以数字形式定义的承诺（promises），包括合约参与方可以在上面执行这些承诺的协议。” 智能合约能够部署和运行在区块链环境中，由一段代码来描述相关的业务逻辑。部署后的智能合约在区块链中无法修改。智能合约的执行完全由代码决定，不受人为因素的干扰。一般来说，参与方通过智能合约规定各自的权利和义务、触发合约的条件以及结果，一旦该智能合约在区块链环境中运行就可以得出客观、准确的结果。 在Fabric中，智能合约也称链码（chaincode），分为用户链码和系统链码2种，通常所说的链码指的是用户链码。链码是访问账本的基本方法，一般是用Go等高级语言编写的、实现规定接口的代码。上层应用可以通过调用链码来初始化和管理账本的状态。只要有适当的权限，链码之间也可以互相调用。 链码安装在背书节点上，需要在某个通道上实例化并且定义相应背书策略后才能运行。链码部署后不可更改，但是可以通过升级来发布新的功能或修复问题。在Fabric的设计中，链码运行在一个安全的Docker容器沙盒内。该容器由背书节点创建和管理，以便隔离背书节点和链码的运行环境。

成员服务提供者 Fabric与其他公有链系统的重要区别在于，Fabric具有成员身份和权限管理的能力。成员服务提供者MSP（Membership Service Provider）抽象地描述了参与者在网络中的身份，成员服务是成员服务提供者的具体实现。参与者在网络中的身份由参与者的成员服务描述，成员服务最重要的一个部件是参与者所持有的身份证书。该证书由特定CA签发，当若干参与者的身份证书可追溯到同一个根CA时，则认为这些参与者处于同一个信任链中，这些参与者也称该信任链的成员（member），这些成员可用组织（organization）来代表。组织中的成员可以分为普通成员和管理员2种角色，管理员角色拥有对组织配置进行修改的权限。 在实际运行中，参与者通过成员服务可对其他参与者进行身份认证、授权访问权限等操作以管理区块链网络，从而对账本数据的访问控制可以在更广泛的网络和通道层面上进行操控，有助于实现数据的授权访问和隐私保护。例如：可以允许特定参与者调用链码应用程序，但阻止他们部署新的链码；制定规则以拒绝验证由某些参与者签名的交易等。

交易流程 1）应用端首先构建交易的预案，预案的作用是调用通道中的链码来读取或者写入账本的数据。应用端使用Fabric的SDK打包交易预案，并使用用户的私钥对预案进行签名。应用打包完交易预案后，接着把预案提交给通道中的背书节点。通道的背书策略定义了哪些节点背书后交易才能有效。应用端根据背书策略选择相应的背书节点，并向它们提交交易预案。 2）背书节点收到交易预案后，首先校验交易的签名是否合法，然后根据签名者的身份，确认其是否具有权限进行相关交易。此外，背书节点还需要检查交易预案的格式是否正确以及之前是否提交过（防止重放攻击）。在所有合法性校验通过后，背书节点按照交易预案调用链码。链码执行时，读取的数据（键值对）是节点中本地的状态数据库。需要指出的是，链码在背书节点中是模拟执行，即对数据库的写操作并不会对账本造成改变，所有的写操作将归总到一个写入的集合（Write Set）中记录下来。如果在链码中对某个数据项写完之后再读取，得到的数据是在链码执行前的旧值，因为新值并没有实际写入账本中。在链码执行完成后，将返回链码读取过的数据集（Read Set）和链码写入的数据集（Write Set）。读集和写集将在确认节点中用于确定交易是否最终写入账本。 3）背书节点把链码模拟执行后得到的读写集（Read-Write Set）等信息签名后发回给预案提交方（应用端）。 4）应用端在收到背书响应之后，检查背书节点的签名和比较不同节点背书的结果是否一致。如果预案是查询账本的请求，则应用端无须提交交易给排序节点。如果是更新账本的请求，应用端在收集到满足背书策略的背书响应数量之后（例如，背书策略规定的至少5个背书节点中的4个背书响应），把背书预案中得到的读写集、所有背书节点的签名和通道号发给排序节点。 5）排序节点在收到各个节点发来的交易后，并不检查交易的全部内容，而是按照交易中的通道号对交易进行分类排序，然后把相同通道的交易打包成数据块（blob）。 6）排序节点把打包好的数据块广播给通道中的所有成员。数据块的广播有2种触发条件：一种是当通道的交易数量达到某个预设的阈值；另一种是在交易数量没有超过阈值但距离上次广播的时间超过某个特定阈值时，也可触发广播数据块。两种方式相结合，使得排序过的交易可以及时广播出去。 7）确认节点收到排序节点发来的交易数据块后，逐笔检查区块中的交易。先检查交易的合法性以及该交易是否曾经出现过。然后调用VSCC（Validation System Chaincode）的系统链码检验交易的背书签名是否合法，以及背书的数量是否满足背书策略的要求。接下来进行多版本并发控制MVCC的检查，即校验交易的读集（Read Set）是否和当前账本中的版本一致（即没有变化）。如果没有改变，说明交易写集（Write Set）中对数据的修改有效，把该交易标注为有效，将交易的写集更新到状态数据库中。如果当前账本的数据和读集版本不一致，则该交易被标注为无效，不更新状态数据库。数据块中的交易数据在标注成“有效”或“无效”后封装成区块（block）写入账本的区块链中。 上述的交易流程中，Fabric分离了背书节点和确认节点的职责，增加了系统的吞吐量，使系统更具可扩展性。在交易的确认过程中，采用了MVCC的乐观锁（optimistic locking）模型，提高了系统的并发能力。

应用场景 超级账本有个重要的设计原则是按照“用例驱动”（use case driven）的方式来实现的，所有功能都应该有对应的用例需求。鉴于超级账本是个通用型框架，无法预先确定将来所有的应用场景，因此，定义出部分典型的用例，可使超级账本先满足这部分代表性的区块链应用需求，然后再用可替换模块来满足其他需求。目前，Fabric项目主要针对下面几种用例：金融资产管存、公司行为、供应链、主数据管理以及分享经济。需要指出的是，这些用例并非一成不变，随着项目的推进，可能会有所调整和增减。 （1）金融资产管存 金融行业最关心的区块链应用估计是资产的分布式管存，因为把资产（如证券）数据存放在区块链网络后，资产的利益相关人可以直接访问资产数据，而无需经过传统的中间人，可大幅度提高效率和节约成本。资产的交易可准实时地完成，交易的人员也能近乎实时地查询到相关资产信息。资产利益人可赋予资产自动执行的业务规则，从而进一步降低运营成本。与公有区块链应用的较大区别是，金融资产及其相关的交易、业务规则通常是保密的，例如，资产的余额只有持有人才能知道，其他人无法查看。 （2）公司行为 公司行为通常是上市公司发起的有关公司证券的事件，一般和股东有关，有时需要股东做适时的回应，例如要约收购、分红扩股、收购合并等。不管有多少中间机构在处理的流程当中，公司需要及时地把事件的完整信息递交给所有股东。当股东作出某项决定后，该结果会实时处理或清算（如发行新股等）。在整个事件处理过程中，应该保护股东的隐私，以确保投资者所作决定不受外界因素的左右。 （3）供应链 在供应链中，所有的参与者都通过区块链记录、追踪和共享各种数据，例如原材料来源、零部件检测结果以及货物的出处等。这些数据记录在区块链里，并贯穿于货物的生产、运输和销售等环节，从而提供深度回溯查询等核心功能。 （4）主数据管理 在很多的行业里，不同的组织之间往往共享一些主数据（Master Data）。例如，不同的移动运营商之间，需要共同维护一份发射机站地理位置的数据。虽然主数据不是交易类型的商业信息，但是作为各组织间唯一的全局性数据，采用分布式的区块链来保证数据的质量和完整性具有非常重要的意义。 （5）分享经济 分享经济是指将闲置或没有被充分利用的实物资源分享出来，有偿地供陌生人暂时使用的一种商业模式。这种崭新的模式已经延伸到日常生活的多个领域，包括交通、住宿、保健、零售、教育等行业。在分享经济的模式下，最需要解决的就是陌生人之间的信任问题，即资源的提供方和资源的租用者，如何在缺乏信任的基础上安全地完成交易。目前主要的手段是通过分享经济平台来确保信任度。分布式区块链将是全新的一种去信任的方式，它不使用任何中间平台，便可达到各方参与者可靠交易的目的。

部署方式 Fabric的网络由几类节点组成：身份服务节点、验证节点（validating node）、非验证节点（Non-validating node）和若干个应用节点， ·身份服务节点：负责发放和管理用户及组织的身份，具体来说就是在注册、交易、传输过程中使用的各类数字证书，以及区块链相关的密钥。 ·验证节点：创建和校验交易，并且维护智能合约的状态。在执行交易时，一般需要和其他多数的验证节点达成共识（取决于共识算法），然后才能更新本地的账本数据。每个验证节点在本地都保存一份账本的副本。 ·非验证节点：主要是接收客户端的请求，组装交易，并发往验证节点处理，从这个角度看，非验证节点像交易预处理器，并不负责交易的实际执行。为了加速客户端的查询响应速度，非验证节点在本地也保留一份账本数据的拷贝。 ·应用节点：主要提供用户端（例如浏览器或移动设备）的后台服务，在收到请求后，把交易请求直接发往（或经由非验证节点转发）验证节点处理。

Fabric的部署方式按照实际需要可有多种形式。由于Fabric是联盟链，组成网络的节点分别属于不同的联盟成员，只要这些节点可通过网络互相连接，每个成员能够选择自己节点的部署方式：既可把节点部署在自有的数据中心，也可把节点部署到公有云中。如果在云端部署节点，需要更强的加密手段来防止公网潜在的恶意攻击。由于Fabric节点部署的多样性，规划的时候应该把通信延迟、网络故障、节点失效、网络恢复等因素综合考虑在内，以符合应用的要求。

R3 Corda

· 它是开源的，网络由R3所有。 · 最初是为金融业设计的，但是也可以应用于其他行业，如保险业、零售业等。 · 采用的是分布式账本技术（DLT），而非区块链。 · 能够让组织机构将区块链技术和他们目前数据库的便利结合起来，减轻因为新技术范式迁移而引起的诸多不便。 R3 Corda的主要特色如下。 1.它在很多方面与传统的应用开发类似，使用的都是Java 和Kotlin语言。 2.具备许可网络能力。 3.可以创建和转移任何数字资产。 4.采用被称为“状态”的技术，具有最新的数据。具有虽有带查询特色的交易历史。 5.具备能够验证交易独特性的“公证人”。 6.能够与RDBMS数据库集成，以便存储和检索数据。 7.能够与RPC协议互动，其中的“流动”改变能够创造和展开交易。 8.利用Kotlin或Java来编写智能合约。 9.可轻易扩展，提供新的代码。 10.为解释功能和优秀文档的项目提供模板。 11.合作方：R3联盟、保险联盟。

Quorum

· Quorum是一个以太坊的企业版本。 · 提供了许可网络和专门针对金融领域使用的案例设计的交易能力。 · 由JP Morgan开发。 Quorum的主要特点如下。 1.它包含以太坊的所有特征。 2.利用星座网络的概念增强交易的隐私属性。 3.安全性高，能够利用Solidity开发出任何去中心化应用程序。 4.具备自己的共识机制——Quorum共识，能够提升交易产出，因为以太坊本身的交易产出比较低。 Quorum链是一个基于时间的多数表决算法，利用智能合约来管理共识以及参与共识的人。交易通过网络来宣传投票，用以太坊的签名验证来自制定者和投票者节点的签名。 Quorum链提供一个简单的链式基础结构，整个节点都承载相同的账本，但是只能获取与他们相关的信息。Quorum链采用一种能够加密信息的独特结构，使信息无法被无关节点看到。

Chain

· 它是开源的。 · 主要用于金融组织。 · 任何金融资产都可以被点对点转移。 · 它是可扩展的、安全的、稳健的。 Chain采用链协议，该协议可用于资产注册和无缝转移区块链网络 Chain的主要特色如下。 1.原生数字资产——货币、证券。 2.许可网络——网络内基于角色的许可。 3.不可变的账本。 4.多重签名账户——企业、机构。 5.全栈安全性——HSM集成、可加密、可审计。 6.智能合约——编写商业规则程序。 7.交易隐私——仅针对责任方。 8.参考数据——资产定义、符合性数据、注释。 它拥有构建网络的链核心。

MultiChain

这是一个开源的私有链开发平台，可在区块链平台上创建和追踪资产。主要目的是帮助各种组织机构迅速建立基于区块链的自有资产追踪方案。 MultiChain的主要特点如下。 1.快速开发——只需两步即可创建网络，第三步实现与现有网络相连。 2.无限资产——在平台层面创建资产，可以实现原子式、多方参与、多资产的交易。 3.创建多个键值以安全地共享数据。 4.许可——被许可方能够连接、发送、接收交易。 5.开发友好型。 它具备开启网络的多链节点。 目前，Multi Chain是世界上最受欢迎的私有链开发平台之一。其客户包括Visa,NASDAQ,First Capital,Fiserv,MUFG,State Street,Fidelity等。

Open Chain

Open Chain是一种开源分布式账本技术。它适用于希望以稳健、安全、可扩展的方式发行和管理数字资产的组织机构。 Open Chain的主要特色如下。 1.即时确认交易。 2.无挖矿费用。 3.极高的可扩展性。 4.通过数字签名进行安全保障。 5.不可变性：在比特币区块链中建立锚点，受益于工作量证明的不可逆性。 6.向用户分配别名，而不是使用Base 58的地址。 7.多重控制： · 参与者能够以匿名方式加入的完全开放式账本； · 参与者必须得到管理员的批准才可以加入闭环账本； · OpenChain混合使用上述技术，被授权的用户比匿名用户享受更多的权利。 8.分级账户系统能够在任何层次上设置许可。 9.交易的透明性和可审核性。 10.处理损失或私钥被盗都不会给终端用户带来任何损失。 11.能够让多个开放链案例彼此复制。 OpenChain允许私人组织进行以下活动。 · 利用现有的数据库迁移进入区块链。 · 在一种模式下创建自己的区块链，在适当时候变成管理员，并添加参与者。 · 允许建立一个验证集群和多个参与集群的发行人/订阅人模型。 · OpenChain与NoSQL和Cassandra数据库配合良好，在很多情况下能够在特定组织中保持良好的运行。 BigchainDB 由于存储在所有节点的数据复制，区块链领域的数据集迅速增长，各个组织越来越难以一种可扩展和有效的方式，在不同使用案例和多种去中心化组织中进行交易。很多交易都是在链外完成的，为了保证数据的完整性，BigchainDB提出一种方案，它能够完成海量级别的大数据交易。在运行 Ascribe.io（一个为全球艺术家和创作者提供所有权和市场证明服务的区块链）时，其发起人发现了这一问题，感到有必要建立一个这样的平台，并在NoSQL数据库平台上创建的BigchainDB（即Rethink DB）中找到了一个解决方案。

Fluree

对于那些希望融入区块链生态系统的组织来说，Fluree是另一个重要的阵营。Fluree允许组织在不同类型的结构化、非结构化数据上工作，省去很多中心化和去中心化应用，将数据以无缝的方式迁移进区块链，启动数据库，并提供逐一查询这些数据的功能。 FlureeDB以理想的交易特征为基础，支持很多区块链共识。低共识需求（内部交易）处理非常快，而高共识需求需要利用去中心化、公共记录、验证等功能。FlureeDB的查询功能允许加入不同数据库，因此可以将不同共识的数据库作为单个数据库系统来查询。 Fluree的内部许可数据库能够实现完全的隐私功能，具备单数字微妙查询和不变的交易数据区块，这种层次的共识能够实现完全控制。很快，组织就能够选举出预定网络，预定网络可以验证共享数据库账本中的交易。这样的话，能够实现交易实体间的信任和交易过程的透明，不用担心公共泄露问题。 在未来，FlureeDB计划升级自己的平台，让应用程序能够执行透明但是安全的交易，充分利用公有链的优势。公共数据库账本能够实现去中心化、不变的、透明的记录。

Factom

Factom是一个有趣的项目，能够为一个组织内的所有原稿和其他文件提供一个安全的存储和审查平台。 组织内所有需要保护和追踪的数据都以安全和易检索的方式上传到Factom的数据层，采用适当的文档分享和索引。 Factom会定期编排平台上的所有数据，并将这些数据的散列存储到比特币和以太坊的区块链中，弹性地对抗单点故障。

IBM ADEPT

IBM与三星、以太坊一起合作实施了ADEPT（自治去中心化点对点遥测技术）项目，保护物联网设备不受那些可能引起分布式拒绝服务攻击或其他类型的设备误用的恶意软件操纵。ADEPT现在是一个开源项目，很多公司都热情地参与其中，几乎覆盖了物联网中的所有设备。 IBM提供了相应的技术平台，将设备与云端的区块链连接起来，还为设备提供必要的鉴定、分析支持、智能服务。该项目在提供智能合约功能的以太坊区块链上实施，能够让各种设备彼此以安全的点对点的方式进行交易。

微软的COCO框架

从很多方面来看，微软的 COCO框架算是全世界都在期待的一个解决方案。Coco这个名字代表机密联盟（confidential consortium） 并且，摩根大通（该领域的早期创新者，开发了自己的以太坊区块链Quorum）、英特尔、由多家银行组成的分布式账本集团R3和供应链公司Mojix（拥有用于零售和供应链行业的区块链技术）都在支持这个项目。

Coco Framework可以说是企业区块链的黑科技，它是第一个能够在企业级区块链上同时解决性能、隐私和组织管理问题的框架。对于企业级用户来说，直接应用已有的区块链（公链）技术无法达到企业级别对系统性能和安全性的要求，即使经过复杂的应用开发流程和网络部署管理，甚至很多系统需要根本架构的改变，也很难达到期望目标。

Coco Framework的设计就是为了降低企业级区块链集成和使用的门槛，解决企业商用的需求——系统的性能、隐私和联盟组织管理。它集成了最先进的软件架构、密码学、一致性算法以及可信计算的技术（如Intel的SGX、Hypervisor的VSM）。有了Coco Framework的技术加成，企业可以放心地开发更多样、更复杂的区块链应用，进而让区块链技术可以真正地在这场数字化革命中得以施展和绽放。

Coco Framework：兼顾解决三大“顽疾”

近年来，区块链技术备受关注。特别是2017年，几乎每个行业都在积极地探索区块链技术，渴望从中挖掘出新的运营模式和商机。然而，在推进区块链技术应用的过程中，企业级用户意识到现有的公链的区块链协议并不能满足他们的业务需求，最直接面临的就是性能、隐私和组织管理这三大“顽固问题”。

为什么这三个问题很难从系统角度解决呢？这是因为在公链区块链系统的设计中，主要考虑的是如何让不同节点达成共识，而不同节点所处的环境通常是匿名的、不可信任的、潜在敌对的环境。因此，为防止恶意行为，交易一般都用“明文”（非加密）对所有人可见以监督验证，并应用拜占庭容错类算法来达成共识。然而，这就使得公链中的“保障”技术、性能和隐私保护形成了一个“顾此失彼”的关系，运用“保障”技术就意味着无法兼顾性能优化和隐私保护，但这些恰恰是企业业务的需求。至于隐私问题，我们曾在之前的文章“一文读懂区块链上的隐私与监管问题”中剖析过，相关解决方案一般仅适用于特定的系统中，很有局限性，并且通常会带来性能的损失。

因此，如何设计解决方案来兼顾公链中的“保障”技术和性能、隐私保护等成为技术研究领域的一大挑战。Coco Framework的出现则一举击中行业痛点，让我们看到了可行性。

隐私烦恼“去无踪”：TEE环境和区块链高度集成

用Coco Framework部署的区块链网络具有高度可扩展和隐私保护的特性。它可以满足所有企业联盟链的关键需求，从而加快区块链技术在企业中的广泛应用。Coco Framework不是独立的块链协议，它提供了一个信任的基础，可以整合现有的块链协议（如Ethereum，Quorum或Corda等）提供完整的企业级区块链解决方案。

Coco Framework充分利用可信计算环境TEE （Trusted Execution Environment），如 Intel SGX 和Windows 虚拟安全模式(VSM) ，创建了可信的网络。TEE环境既可以证明放入代码的正确性，又能保证运行时内部数据对外界不可见以及不被篡改，进而可以确保保障区块链协议关键代码和数据的机密性、完整性，使得区块链的应用可以在完全受信任的成员节点上高效运行。

TEE环境从技术上实现了隐私性能的大幅提升：第一，网络中物理节点之间信任的建立无须节点拥有者之间的相互信任；第二，能够在保证区块链状态保密的情况下处理各种用户请求。事实上，已经有不少的区块链项目采用TEE来达到隐私或者性能方面的要求，例如Hawk[中就用TEE来完成智能合约中对私密信息的处理，而非代码本身以及用户查询请求的隐私性；Hybster 则用TEE实现了高效的BFT协议等等。与它们不同的是，Coco Framework将区块链和TEE高度集成，达到了更高的隐私性以及灵活性。

Coco Framework的运行原理

Coco Framework搭建的网络中的节点，通过证书的验证（如Intel背书）而成为可信节点VN（Trusted Validating Nodes）。每个节点运行Coco Framework和某个区块链的协议（比如以太坊），并根据所选取的一致性协议系统选取lead来处理应用中的交易事务。

类比来说，成为lead的VN就像以太坊里面的矿工，但不同的是Coco Framework里面的每个VN都可以通过TEE attestation 验证其他节点执行时候所用的代码哈希值（恶意行为将直接被发现），而不需要像以太坊一样通过重新计算交易来验证。VN之间通过TEE可以互相验证身份和代码从而建立可信的连接。更为重要的是，Coco Framework包含了一套密钥及权限管理机制，可保证只有在TEE中才能处理加密后的交易，并且只有拥有相应权限的用户才能查看相关状态。

正是由于可信网络的建立，让Coco Framework 搭建企业级区块链网络的优点十分突出：

吞吐量和交易响应时间接近数据库的速度。通过使用TEE，Coco Framework可以简化一致性协议，从而提高了交易的速度和延迟但不会影响安全性。

支持更丰富、更灵活的隐私保护模型。有了TEE的加成，Coco Framework通过使用数据访问控制方案来实现复杂的隐私保护模型。交易的执行，智能合约代码和状态都只能通过应用定义的接口返回给有权限的人。

提供可编程的管理模型来支持任意的分布式管理策略。

支持非确定性（Non-deterministic）的交易和运算。在绝大多数的区块链系统里，交易的运行结果必须是确定的，任何纯随机的运算都会导致无法有效重现和验证。然而在Coco Framework里因为有了TEE，节点间的运算结果无需验证，所以可以支持非确定性的计算。更加灵活的是，交易可以根据应用的需要和外界系统进行交互。这极大的丰富了应用的语义和场景。

已有的区块链协议通过与Coco Framework的整合能够直接解决隐私、性能和管理三大问题。例如，一个企业正在使用以太坊开发应用，那么与Coco Framework整合之后，关键问题一并解决，且不需要对已经开发的应用做修改。

同时，Coco Framework并非必须要和云服务绑定，它可以被部署到云上（如Microsoft Azure），也可以部署在企业自己的服务器上。正因为此，Coco Framework在短时间内就迎来了广泛企业和区块链团队的欢迎和拥抱。