区块链研究笔记（二）-Hyperledger概览

%%一个小说明

%%把最近写的研究笔记分享给大家，请大家指教。为什么上来就是“研究笔记（二）”？因为此前写了一个科普性质的“研究笔记（一）”，作为公司内部科普读物，基本都是网络公开信息的整理，没什么原创内容，就不发了，从（二）开始发。

前言

研究区块链已经有一段时间，在参与了几次所谓对区块链的研讨会之后，有不少感触。

区块链作为一种新生技术，其上被贴了不少标签，也寄托了大家很多希望，然而我有一种感觉，目前我们看到的网络上，包括线下的一些探讨会，讨论的深度都是不够的。尤其对技术的理解不够到位。

对于区块链唱多和唱空的声音很多。唱空的文章常常都聚焦在ICO的乱象，大的逻辑不外乎是前面讲ICO很乱，有多少多少坐庄一夜暴富，多少人被坑去了钱等等，最后不外乎得出结论“贵圈真乱”。然而这样的文章可以说是毫无建设性可言。目前的ICO完全是一个无监管状态的早期金融市场，乱象丛生是必然的事，可以说目前虚拟货币市场发生的所有事都可以在早期华尔街和早期的中国A股找到对应，太阳底下没有新鲜事。

又例如，提到区块链就必然提到去中心化，那么所谓“去中心化”在技术上意味着什么？“去中心化”是否是绝对的？这些都需要对技术有更加深刻的认识。

而目前的现实情况是，大部分对于区块链的探讨，不如说是对于区块链上面衍生标签的探讨。

区块链技术目前处于发展早期，大部分公众对于其技术本身对理解不足非常正常，但是作为专业投资人也罢，技术人员也罢，在发表观点时要想立论扎实，就必须对区块链的技术细节有所掌握，避免“自己描个靶子出来打”的状态，多想想知乎名句“先说是不是，再问为什么”。

这就是我希望能够比较深入研究区块链技术的初衷，为了促使自己的研究更加系统和有所沉淀，因此采用“研究笔记”的形式，一边学习，一边输出，一方面迫使自己将学到的信息进行梳理、思辨，逐步形成自己的知识框架，另一方面也便于与大家交流，请诸君指出疏漏错误之处，共同进步。

那么首先，作为深入了解区块链技术的努力，我首先完成了一门由Linux基金会发布在edx上面的基础课程：

image

以此为契机，就将Hyperledger项目，这个目前看起来相对成熟的商业区块链开源项目进行一个梳理，希望可以管中窥豹，对区块链技术本身能够有更加深入的了解。

Hyperledger是什么？

Hyperledger，目前国内译作“超级账本”，是由Linux基金会主导的一个开源计划，由若干跨行业的分布式账本技术（Distributed ledger technologies, AKA DLT）开源技术框架项目组成。

该计划目前由Linux基金会主导运营，创立于2016年，由30个创始公司会员和一套技术和组织治理机构组成。

在Hyperledger的官方主页上，是这样描述创立Hyperledger的原因的：

为什么创立 Hyperledger?

自从互联网诞生以来，除了互联网本身，没有比区块链技术更广泛、更根本的革命性技术了。区块链是一种通过共识建立起来的、与“智能合约”系统和其他辅助技术相结合的对等分布式账本。这些技术可以一起用于构建新一代的交易应用。这些应用的核心是建立信任、责任和透明度，同时简化业务流程和法律限制。

可以把它看作是市场、数据共享网络、微型货币和分散的数字社区的操作系统。它有可能极大地降低在现实世界中完成工作的成本和复杂性。

只有开放源代码、协作式软件开发方法才能确保将区块链技术推向主流商业采用所需的透明度、寿命、互操作性和支持。这就是Hyperledger的目的 —— 由软件开发者社区构建区块链框架和平台。

Hyperledger的目标是：

• 创建企业级、开源、分布式账本框架和代码库，以支持商业交易

• 提供中立、开放和社区驱动的基础设施由技术和商业治理支持

• 建设技术社区，开发区块链和共享账本的概念验证（POC）、应用案例、实地跟踪和部署

• 教育公众关于区块链技术的市场机会

• 推广我们的社区，对许多平台和框架采用工具包方法

Hyperledger成立之初，其技术指导委员会接受了两个商业区块链框架代码库进行孵化，Hyperledger Fabric和Hyperledger Sawtooth。前者是Digital Asset、Blockstream的libconsensus、IBM的OpenBlockchain共同的作品，后者是由Intel的孵化小组所开发。

Apache软件基金会的共同发起人Brian Behlendorf于2016年5月被指定为Hyperledger治理委员会的执行总监，他曾在Hyperledger的官方博客[撰文]指出，经过Hyperledger的技术指导委员会（Technical Steering Committee，AKA TSC）的讨论，Hyperledger项目定义为由以下3部分组成：

1. 一组可辨认的的软件开发维护者。他们负责项目的开发进程、文化、总体技术方向以及与公开化。开发者可以投票选出新的成员，原成员可以退休。但所有的活跃项目都必须有至少一部分维护者来维持活跃度。

2. 一组具体工具，包括一个或数个Git库，一个bug追踪或问题数据库，一个维基页面（非维基百科，指软件开发的wiki页面），一组邮件列表以及其他开发者资源（例如论坛、邮件列表、IRC/Slack频道等等），这些共同构成某个特定项目的一部分。这些工具由广义的社区间接负责，由维护者直接负责保持更新和活跃。

3. 用于描述该项目及社区的Hyperledger中特定的空间，清晰地展示该项目与Hyperledger其他项目（或其他地方的项目）的联系与不同，并且声明所有的项目对Hyperledger都同等重要。

Hyperledger的参与方

Hyperledger最值得关注的一点在于，其成立后受到了业界的普遍关注，大量各行业的巨头加入该项目中，成为该项目的会员。

其高级会员包括：埃森哲、空客、美国运通、百度、思科、戴姆勒、富士通、日立、IBM、Intel、J.P.Morgan、NEC等等，如下图：

image

普通会员中比较知名的包括：小米、博世、招商银行、民生银行、中信、德勤、华为、甲骨文、普华永道、三星、Redhat、Vmware等等，完整列表如下图：

image

除了会员机构，值得注意的是，在Hyperledger项目的领导层中，有不少华人面孔，其中比较值得注意的包括：

• 张旭阳，Hyperledger治理委员会成员，现任百度副总裁，分管百度金融体系下理财和资产管理业务，于2016年6月加入百度，此前在光大银行资产管理部担任总经理。

• 蔡栋（Charles Cai），Hyperledger治理委员会成员，万达科技集团首席架构师。

• 杨保华，Hyperledger技术指导委员会成员，甲骨文首席架构师。

Hyperledger下的各个技术框架及特点

Hyperledger目前包括5个技术框架，3+1个工具包（1个尚未发布）。

这5个技术框架分别是：

• Hyperledger Sawtooth

• Hyperledger Iroha

• Hyperledger Fabric

• Hyperledger Burrow

• Hyperledger Indy

3个工具包分别是：

• Hyperledger Cello

• Hyperledger Composer

• Hyperledger Explorer

还有一个尚未发布的工具包：Hyperledger Quilt

下文对这些技术框架做一下概要梳理（重点介绍Iroha、Sawtooth以及Fabric，出于简便，下文提到技术框架及工具包，一律省略前缀Hyperledger），让我们来看看区块链其上的“去中心化”等等标签在技术上具体意味着什么？我们针对这些标签的一些观点是否立得住脚。

Iroha

image

Iroha最初是由Soramitsu，Hitachi（日立），NTT Data以及Colu贡献的，它被设计为能够简单方便的整合到需要使用分布式账本技术（DLT）的基础项目中。Iroha的主要特点是简单的结构、现代并且领域驱动C++设计，强调移动应用的开发以及采用了YAC共识算法。

下图按层展示了组成Iroha的不同组件，一共包括四层：API, Peer Interaction, Chain Business Logic 以及Storage.

image

各个组件的作用涉及过多技术细节，后面涉及的时候顺带介绍，此处不再深入，因为目前我们主要要关注其区块链部分的运作逻辑。

在Iroha网络中，有3个主要参与者：

• 客户端可以：

1. 查询它们有权限查询的数据

2. 执行状态改变动作，或叫“交易”，这种动作由称为“命令”的基础操作构成。例如，在一个单笔交易中，一个用户可以将资金转给三个人（三个独立的命令）。但是，如果他/她转出的资金大于拥有的资金，那么整体交易（三笔转账是一个整体交易）会被拒绝。

• 节点维持现有的状态以及它们对于共享账本的自有拷贝。一个节点是网络中的一个实体，拥有地址、ID以及信任。Iroha设计成一个节点可以是一台计算机或者是一个集群（意味着多台不同的计算机备用做账本存储、索引、验证以及点对点逻辑）。

• 排序服务（Ordering Service）将交易排列成已知顺序。排序服务使用的算法有几个选项。

下面来看看Iroha的基础交易流程：

第一步：一个客户端创建一个交易，并将其发送到Torii门（Torii是Iroha的API层级的组件，为客户端提供输入输出接口），后者将这笔交易发送到负责执行无状态认证的节点。

image

第二步：在该节点执行了无状态认证后，这笔交易首先被送到排序门（ordering gate），后者负责选择适当的策略以连接到排序服务。

image

第三步：排序服务将交易排序并以提议（proposal）的形式将其发送给共识网络中的节点。一个提议（proposal）是由排序服务分享的未签名区块。它包含一批排好序的交易。只有当排序服务中积累了足够的交易之后或者在最后一次提议之后经过了一段特定的时间之后，提议（proposal）才会被发送，这避免了排序服务发送空的提议（proposal）。

image

第四步：每个节点在模拟器中验证提议的内容（有状态验证）并且创建仅包含被验证的交易的区块。这个区块被发送到共识门（consensus gate），后者负责执行YAC共识逻辑。

image

第五步：一个节点的有序列表被决定，并且基于YAC共识逻辑选择出一个领导节点（leader）。每个节点通过将其提名区块（proposed block）签名并发送到领导节点进行投票。

image

第六步：如果领导节点接收到了足够多的签名提名区块（例如，超过2/3的节点），那么它就开始发送提交信息（commit meassage）。该信息标示出该区块应当被应用到每个参与共识的节点所组成的链上。一旦提交信息被发出，提名区块就通过同步器（synchronizer）变成每个节点的链中的下一个区块。

image

%%Iroha目前执行的是一种称为YAC（Yet Another Consensus）的共识算法。该算法是基于对区块哈希值的投票。共识涉及在区块被验证后的接受，与其他区块合作以决定提交，在区块间传递提交。YAC共识实现两项功能：排序和共识。

%%排序负责将所有交易排序，打包为提议（proposals），并发送给网络中的节点。排序服务是设置交易序列以及以提议形式广播它们的终点。排序不负责执行交易的有状态验证。

%%共识负责基于相同的提议在区块上达成协议（agreement）。虽然验证与共识过程相分离，但是它是交易流中重要的部分。

Iroha最重要的特点就是聚焦于提供移动库（mobile libraries，即服务于在移动设备上开发的库）。Iroha的主要目标之一就是创造一个能够被应用轻松调用的分布式账本系统。为了实现这一点，Iroha为iOS，Android以及Javascript都提供了开源软件库。

Iroha未来的主要目标之一是减少不连续的项目，以及更多的库被作为组件共同使用。基于这样的远见，Iroha未来希望能最终提供以下C++组件供其他Hyperledger项目使用：

• YAC共识库

• Ed25519数字签名库

• SHA-3哈希库

• Iroha交易系列库

• P2P通信库

• iOS库

• Android库

• Javascript库

• 区块链浏览器（explorer）/数据可视化组件

Sawtooth

image

Sawtooth是一个潜在应用方向为物联网、生产、金融以及企业的区块链框架。Sawtooth支持多种需求，包括许可和非许可部署（permission and permission less deployments），以及一种可插拔（pluggable）共识算法。该框架也提供了一种革命性的共识算法，流逝时间证明（Proof of Elapsed Time，PoET）。这种算法使得对多种解决方案的多功能性以及规模化称为可能。

Sawtooth支持很多不同的基础架构需求，比如：

• 许可和非许可基础架构

• 模块化区块链架构

• 规模化能力。因为具备更高的吞吐量，这对大型区块链网络很重要。

• 用于交易逻辑的多种语言

Sawtooth框架中有这样一些概念需要了解：

交易验证者（transaction validators）验证交易。

交易家族(transaction families)是Sawtooth中的智能协议。他们定义了可以应用于交易的操作。交易家族由交易处理器（transaction processors，服务器端逻辑，the server-side logic）以及客户端（通过网页或移动app使用）组成。

交易处理器（transaction processors）是对网络资产进行操作的服务器端业务逻辑。

交易批次（transaction batches）是交易群（clusters of transactions），这些交易或者全部同时提交到状态或者全部不提交到状态。（即一个交易批次中的交易同时被认可或者同时不被认可）。

网络层（the network layer）负责Sawtooth网络中验证者之间的沟通，包括执行最初的连接，对等发现（peer dicovery）以及消息处理。

全局状态（global state）包括账本的当前状态以及一个交易调用链。所有交易家族的状态被在每个验证者上表达。在每个验证者上区块验证的过程保证了同样的交易带来同样的状态变化，最终的数据对于网络中的所有参与者都是相同的。

下面以一个金枪鱼的溯源案例来看sawtooth的现实应用。

image

1. Sarah捕捞到一条金枪鱼，并用app的用户界面将捕获的详情都录入账本。一整网金枪鱼可以被当作一个交易批次，每一条独立的金枪鱼作为批当中的一个交易。

2. 在这次捕获的细节被存储到账本上，并且金枪鱼在供应链上继续传递之后，金枪鱼加工厂可以使用他们自己的应用来查询账本上某个特定的捕获的细节，比如重量。然后加工厂可以添加细节，反映加工日期和时间，以及其他的相关信息。

3. 在金枪鱼在供应链上传递的同时，监管者也可以使用他们相应的应用来在账本上查询特定捕获的细节信息，比如所有者以及捕获地点，来验证其合法性。

4. 最后，当这网金枪鱼到达Miriam的餐馆，Miriam可以使用她的应用来查询账本，核查并确认Sarah对于其每条鱼的来源是可信的。

在任何区块链网络中，改变全局状态（global state）要求创造和应用交易。在Sawtooth中，验证者应用引起状态改变的区块。更具体的，验证者验证交易区块，并且确保交易导致的状态改变在整个网络中的参与者中是一致的。

一个用户创建一个交易批次并且通过一个客户端和REST API将其提交给一个验证者。然后改验证者核对该交易批次，如果它是有效的，就应用它，使得状态发生改变。在我们展示的场景中，渔民Sarah创建了一个交易批次来记录关于一组金枪鱼捕获的信息。验证者接着应用这些交易，然后如果所有的适当的属性都存在的话，就状态更新，这些属性包括：一个独特的ID数，位置以及捕获时间，重量以及鱼的捕获者。如果以上任何元素缺失，批中的交易就不会被应用，状态就不会更新。

image

Sawtooth组织运行一个与Sawtooth网络交互的节点。每个节点运行着至少三样东西：

• 主验证者进程

• 监听请求（可能是交易发布或者状态查询）的REST服务

• 一个或多个交易进程

每个进入Sawtooth网络的组织至少运行一个节点，并接收兄弟节点提交的交易。

image

Sawtooth网络中最常用的共识算法是流逝时间证明（PoET）。PoET使用一个抽奖函数从许多不同的分布节点中选出一个领导者的方式来公正地决定谁来提交一个交易的状态。Sawtooth的PoET算法与比特币区块链的工作量证明（PoW）算法不同。后者依赖于巨量的能源，而PoET能够确保信任和推选领导者的随机性，又不消耗高额的电力。PoET使得增大规模和增加参与方成为可能。因为网络中的每个节点都有在链上创造下一个区块的公平机会。

首先，每个网络中的验证者从一个enclave或者一个受信任的函数请求得到一个等待时间。这里“流逝时间”就发挥作用了。对于某个特定区块有最短等待时间的验证者被指定为领导者，然后创建将要被提交给账本的区块。结果就是，领导者的选择完全是随机的，你所拥有的能源或者硬件类型并不能给你带来优势。使用简单的函数，通过证明它在获得领导者位置前拥有最短的等待时间，网络可以验证获胜的验证者是真的“获胜”了。

PoET使用一个抽奖机制来获得分布式共识的能力是革命性的。这不仅是的网络内核实变得简化而且公平，而且还有难以置信的规模化能力。Sawtooth的一个主要优势就是它允许网络的规模扩张。也就是说，Sawtooth在支持的网络体量方面几乎是无穷的。

但是，虽然PoET有很多优点并且极大地帮助了规模化能力，他也有缺点。那就是分叉的问题。PoET算法可能带来分叉，导致两个“胜者”提交区块。每个分叉都必须靠验证者来解决，这导致在网络中达成一致上的延迟。

Fabric

Fabric是一个许可网络，这意味着仅仅那些获得许可的参与者才能接入网络。为了处理网络成员资格以及身份，成员资格服务提供者（membership service providers, AKA MSP）管理用户ID，并且认证网络中的所有参与者。一个Fabric区块链网络可以被一个或多个MSP管理。这提供了成员资格操作的模块化以及在不同的成员资格标准和架构之间的跨领域操作性。

Fabric中涉及的概念包括：

• Chaincode（智能协议）同时包括资产定义以及修改这些资产的业务逻辑（或者说交易）。交易调用导致账本的改变。

• 账本包括现在的网络全局状态以及一个交易调用链。一个共享的许可的账本是一个记录的仅可追加系统，是真实的唯一来源。

• 网络是构成区块链网络的数据处理节点的集合。网络负责维护一个一致的复制账本。

• 排序服务（ordering service）是一个将交易在区块中排序的节点集合。

• 全局状态（world state）反映关于网络中的所有资产的现有数据。这些数据存储在一个数据库中便于高效地访问。现在支持的数据库包括LevelDB以及CouchDB。

• 成员资格服务提供者（membership service provider, AKA MSP）管理身份以及客户端及点的许可访问。

现在我们来假设一个金枪鱼溯源场景：

1. Sarah抓住一条金枪鱼并且使用供应链应用的用户接口记录关于此次捕获的所有的细节到账本上。在这些到达账本之前，这笔交易被传送到网络中的背书节点（endorsing peers）。在背书节点这些交易获得背书。获得背书后的交易被发送到排序服务，被排序进入一个区块。这个区块然后被送到网络中的提交节点（committing peers），在那里区块被验证后就被提交。

2. 随着金枪鱼在供应链上传送，监管者可以使用他们自己的应用来在账本上查询对于某个特定捕获的细节（不包括价格，因为他们没有权限访问价格相关的chaincode）。

3. Sarah可以与一个餐馆Carl达成协议，同意$80/镑的价格。他们为规定$80/磅的chaincode合约使用蓝色的频道。蓝色频道的账本更新一个包含这笔交易的区块。

4. 在一个不同的商业合约中，Sarah和Miriam同意一个特殊的价格，$50/磅。他们为规定$50/磅的chaincode合约使用红色频道。红色频道的账本更新一个包含此笔交易的合约。

image

在我们假设的场景中（同Sawtooth，也是一个金枪鱼溯源场景），应当仅有监管者、认证的渔民、认证的餐馆被允许买入网络。为了做到这一点，一个MSP被定义来为这条供应链上的所有成员提供成员资格。在配置该MSP时，证书以及成员身份被创造。然后政策（policies）被定义为表述一个频道的读/写政策，或者一个chaincode的背书政策。

我们的场景中有两种独立的chaincode，运行在三种独立的频道上。这两种chaincode是：一个用于渔民和餐馆间的价格合约，一个用于金枪鱼的转移。三种频道是：一个用于Sarah和Miriam之间的价格合约；一个用于Sarah和Carl之间的价格合约；一个用于金枪鱼的转移。这个网络中的每个成员都知道彼此以及彼此都身份。这些频道提供私密性以及交易的机密性。

在Fabric中，MSP也允许动态的成员资格添加或者移除，以此来维持供应链的完整以及运作。例如，如果Sarah被发现她的鱼是非法捕捞的，她的成员资格就会被吊销，而不会危及网络的其他部分。这个特点是关键的，特别对于企业应用。因为在企业应用中商业关系虽时间变化。

Fabric中比较特别的设定是频道（channels）。

频道允许组织使用同一个网络，同时维持不同区块链之间的独立性。只有一个在其上执行相应交易的频道的成员可以看到这比交易相应的细节。换句话说，频道将网络分隔开，以允许仅对交易利益相关方的可见性。这种机制通过将交易分配给不同的账本来实现。只有一个频道的成员参与共识，而网络中的其他成员看不到频道上的交易。

image

上面的图展示了3个不同的频道——蓝、橙、灰。每个频道有自己的应用、账本以及节点。

节点可以属于不同的网络或者频道。参与多个频道的节点模拟和提交交易到不同的账本。排序服务在任何网络和频道上是一样的。

需要记住的几点：

• 网络设置允许创造频道；

• 同样的chaincode逻辑可以被应用于多个频道；

• 一个给定的用户可以参与多个频道。

Fabric网络中有3种不同的角色：

• 客户端是执行代表一个人向网络提议交易的应用。

• 节点（peer）维持网络的状态以及账本的拷贝。有两种不同类型的节点：背书（endorsing）以及提交（committing）节点。但是，在背书以及提交节点之间是有重合的，即，背书节点是一种特殊种类的提交节点。所有的节点都向分布式账本提交区块。

• 排序服务接收背书后的交易，将他们排序进入一个区块，并且将这些区块发送给提交节点。

Fabric作为一个面向许可链的技术架构，还有一个特别的组件就是成员资格服务提供器（以下简称MSP）。

MSP是一个组件，它定义这样一些规则，即那些身份是有效的，真实的，并且允许使用网络。MSP管理用户ID以及认证那些想要加入网络的客户端。这包括为这些客户端提供提议交易的证书。MSP使用一个证书颁发机构。这是一个基于确认的身份验证和吊销用户证书可插拔接口。用于MSP的默认接口是Fabric-CA API，但是机构可以植入他们选择的外部证书颁发机构。这是Fabric另一个模块化的特点。Fabric支持许多证书架构，这样就可以使用许多种类的外部证书颁发机构接口。因此，一个单一的Fabric网络可以被多个MSP控制，每个机构都可以选择自己最喜欢的。

在分布式账本系统中，共识是在下一组将要添加到账本中的交易上达成一致的过程。在Fabric中，共识由三个清晰的步骤组成：

• 交易背书

• 排序

• 认证以及提交

这三个步骤保证网络的政策被维持住。下面我们通过探索交易流来看看这些步骤如何执行的。

交易流（步骤一）

在Fabric网络中，交易始于客户端应用发送交易提议，或者，向背书节点提交一个交易。

image

客户端应用通常被称为应用或者客户端。它使得人们可以与区块链网络交流。应用开发者可以通过应用的SDK来利用Fabric网络。

交易流（步骤二）

每个背书节点模拟提交的交易，而不更新账本。背书节点会刻画读写数据组，成为RW Sets。这些RW sets在模拟交易时刻画什么被从当前的全局状态读出，同时也刻画当交易被执行后，什么会被写入当前的全局状态。这些RW sets接下来被背书节点签署然后返回到客户端应用，以便于在交易流的未来步骤中使用。

image

背书节点必须持有智能协议，以模拟交易提议。

%%交易背书

%%一个交易背书是模拟交易后的结果的一个签署的回应。交易背书的方法依赖于背书政策。后者是当chaincode部署时明确的。一个背书政策的例子是“大部分的背书节点必须背书这笔交易”。因为一个背书政策是为一个特定的chaincode明确的，不同的频道可以有不同的背书政策。

交易流（步骤三）

接下来，应用将背书后的交易及RW sets提交给排序服务。排序在整个网络上发生，与其他应用提交的背书后的交易及RW sets平行。

image

交易流（步骤四）

排序服务接受背书后的交易以及RW sets，将这些信息排序进入一个区块，然后将这个区块发送给所有的提交节点。

image

排序服务，由排序器群组成。排序服务并不处理交易、智能合约或者维护共享账本。排序服务接受背书后的交易并且明确这些交易未来提交到账本的顺序。Fabric v1.0架构设计为特定“排序”（Solo，Kafka，BFT）的执行称为一个可插拔的组件。Fabric的默认排序服务是Kafka。因此，排序服务是Fabric的一个模块化组件。

%%排序

%%在一个时间框架内的交易被整理到一个区块中并且以一个序列顺序提交。在区块链网络中，交易必须被以一个连续的顺序写入共享账本。交易的顺序必须被建立，以保证当他们被提交到网络中时全局状态的更新是有效的。比特币区块链中排序通过解决一个密码学难题，或者叫“挖矿”来进行。与其不同，Fabric允许运行网络的组织选择最适合其网络的排序机制。这种模块化以及灵活性使得Fabric在企业应用有难以置信的优势。

%%Fabric提供了三种排序机制：SOLO，Kafka，以及Simplified Byzantine Fault Tolerance（SBFT），其中SBFT尚未在Fabric v1.0中使用。

%% - SOLO是开发者试验Fabric网络时最常用的排序机制。SOLO涉及一个单独的排序节点。

%% - Kafka是推荐用于生产用途的排序机制。这种排序机制使用Apache Kafka，一种开源流处理平台。后者提供了一个用于处理实时数据源的统一的、高吞吐、低延迟的平台。

%% - SBFT 可以在存在恶意或者失效节点的情况下依然达成一致。Fabric社区尚未植入该机制，但这在他们的路线图上。

%% 这三种排序机制为交易的排序达成一致提供了可供选择的方法。

交易流（步骤五）

提交节点通过核实验证交易，以保证RW sets依然与当前的全局状态匹配。特别的，当背书者模拟交易时存在的读取数据与当前全局状态完全相同。当提交节点验证交易时，交易被写入账本，全局状态被RW set中的写入数据更新。

image

如果交易失败，即，如果提交节点发现RW set与当前的全局状态不符，那么区块中的交易依然会被包含在区块中，但是它会被标记为无效的，同时全局状态也不会更新。

提交节点负责给共享账本添加交易区块并且更新全局状态。他们可以持有智能合约，但并非必须。

交易流（步骤六）

最后，提交节点异步（asynchronously）通知客户端应用交易的成功或失败。应用会得到每个提交节点的提醒。

image

交易流总结

注意到网络的状态时通过节点维护的，而不是被排序服务或者客户端维护的。这很重要。通常，你会这样设计你的系统，网络中的不同的机器扮演不同的角色。也就是说，作为排序服务的一部分的机器不应当被设置为同时背书或者提交交易，反之亦然。但是，在系统中的背书和提交节点之间是有重合的。背书节点在扮演提交节点的角色之外，必须可使用并且持有智能合约。背书节点确实提交区块，但提交节点却不背书交易。

背书节点证实客户端签名，然后执行一个chaincode函数来模拟这笔交易。输出是chaincode结果，一组从chaincode（Read set）读出的键/值版本。这些提议回应被发送给排序器以排序。排序器接下来将交易排序进入区块，然后将区块发送给背书和提交节点。RW sets被用来认证在账本的内容和全局状态更新之前交易依然是有效的。最后，节点异步通知客户端应用交易的成功或失败。

其他框架及工具包

Burrow

Burrow最初由Monax贡献，同时由Intel联合赞助。Burrow提供了一个模块化的带有许可智能协议解释器的区块链客户端，部分是根据乙太虚拟机开发的。

目前Burrow尚在孵化中。

Indy

Indy是一个用于去中心化身份的分布式账本。它提供了工具、库以及可服用的组件，用于创造和使用基于区块链或者其他分布式账本的独立数字身份，从而使他们可以实现跨领域/跨应用进行操作。

Cello

Cello是一个区块链模块工具。Cello目标是为区块链生态带来按需的“作为服务”（as-a-service）部署模型。Cello最初由IBM贡献，其他赞助者包括Soramitsu，华为和Intel。

Composer

Composer是一组建造区块链商业网络的协作工具。它使得业主和开发者可以简单快速的创造智能合约和区块链应用来解决商业问题。Composer本身用Javascript写成，还是用了现代化工具包括node.js，npm，CLI以及流行的编辑器。

Explorer

Explorer是一个区块链模块，目标是创造一个用户友好的网页应用。Explorer可以查看、调用、部署或者查询区块、交易以及相关数据、网络信息（名字、状态、节点列表）、链代码、交易家族以及任何其他存储在账本中的相关信息。Explorer最初由IBM、Intel以及DTCC贡献。

小结

简单的总结一下，从上文Iroha、Sawtooth以及Fabric的技术细节来看，我们可以找到不少共通之处，得到以下一些初步的印象：

• 一笔完整的交易流程包括：某个节点（客户端）提交交易->某些节点认证交易->排序->通过某种共识算法决定由哪个节点进行区块提交以及提交的内容的有效性->提交区块，所有节点更新账本；

• 为了提高效率，通常都引入了批次的概念，将一批交易一次性处理，而不是每产生一笔交易就进行处理；

• 许可链中存在着对身份的认证以及不同的频道的概念。

根据这些初步印象，我们可以来探讨一下一些关于区块链的常见观点：

观点一：区块链用于溯源，如果供应链上的参与方自己造假，在中途将实物替换掉，区块链宣称的不可更改不就无效了吗？

• 这是一个非常常见的观点。我甚至听到过对区块链研究颇久的人将此观点摆出来，作为区块链的缺点之一。这是对区块链本质理解有误带来的典型问题，是一个非常好的问题，驱使我们去思考区块链的本质是什么。

• 区块链是对信息传递的变革，对线上信息组织方式的变革，它和现有的其他互联网技术一样，可以对线下赋能，但不能指望它解决一切。换一种思考方式，现有的中心化溯源机制（依赖某个组织进行认证）同样解决不了“调包”问题。同样的，在初期淘宝也无法前置的解决假货问题，到今天也只是通过后发的处罚部分解决，而如果站在十年前、二十年前，因此就说淘宝没有未来，在今天看来必然是可笑的。

• 那么区块链溯源究竟改变了什么呢？或者说去中心化的溯源机制相对于目前中心化的溯源机制本质的区别在哪里呢？我想，其根本在于从“相信某个机构”转变为“相信某种机制或制度”，从而杜绝了某个中心机构“犯错/被攻击”的可能性。

观点二：区块链的挖矿浪费大量能源，是低效的机制。

• 这是把区块链与比特币网络混为一谈而得出的结论。并非所有的区块链网络都是采用PoW（Proof of Work，即工作量证明）共识机制。实际上，稍有了解的人都知道，从以太坊的PoS机制，到从上文的Sawtooth、Iroha、Fabric的共识机制都可以看到，并非所有区块链的共识都依赖于算力（本质是资源和能源）。进一步的，我们还可以想到，既然并非所有的共识都需要大量消耗能源，所以作为奖励机制的“挖矿奖励”在区块链网络或者说DLT技术中并非是必须的。更进一步，token（即，币）并非是必须的。也就是说，并非所有与区块链相关生态都需要存在token，都可以ICO。笔者目前认为，ICO的成立意味着其生态体系至少存在着可交易的资源，此时token才有价值。当然，这是另外一个大命题了。

• 但是另一方面，区块链因为共识机制的存在，因为分布式账本的存在，其效率方面确实难以和倾注巨量资源的中心化的机构匹敌。其本质是拿效率换信任，所以在这个方面“低效”的结论倒不是全错。

• 更进一步的思考，区块链的应用领域，如果在共识机制的效率上短期没有革命性的突破，就要主要考虑非高频的领域了。

观点三：区块链是一场去中心化的革命，所以其必然颠覆当前的中心化机构！/所以其必然受到中心化机构狙击而失败！

• 一个“去中心化”的标签可以演化出截然不同的两个标签真的是非常有意思的结果。

• 事实上，在笔者最初接触区块链的时候，第一感觉也是“‘去中心化’？这不是天生反骨吗？”。然而在上文中我们看到，以许可链作为自己特点的Fabric，其基础架构中存在MSP这样的机制。更进一步的，在许可链或者联盟链中，因为有身份的认证之说，也就意味着存在掌控整条链或者说整个账本的一个/群中心化组织，这就是“去中心化”的技术与“中心化”的现实世界融合之处。

• 那么我们就应当问一个问题，这样的话，区块链还有什么可取之处？

• 事实上，当共有链变成私有链/许可链/联盟链之后，其去中心化的属性就已经被大大的限制了。此时，其链中依然存在着分布式账本，但整条链中的节点已经不对等了，或者说链存在一个/群至高无上的管理者，他们掌握着链的身份认证，虽然让渡了账本的记账权（分布式账本依然存在），但是同时获得了链中交易的可追溯性和不可篡改性。打个比方，就是将原来在一个黑盒中操作的账本开放出来，人手一份，通过共识机制来协调，这种开放是双向透明的（可以通过技术手段对于信息获取的权限进行限制，例如Fabric中的channel），中心机构无法作假，同样，其他节点也一样。所以，更直白的说，分布式账本增加了整个网络中的双向信息透明，这就减弱了整个网络中造假的可能性，其结果很可能是原来组织的中心节点的控制大大的强化，而非弱化！

• 所以，我们就不难理解为何央行一直在大力组织研究区块链。事实上，从Hyperledger的会员机构就可以看出，一个号称要“颠覆中心化大机构”的技术，却有大量产业巨头热衷于投入力量资金资源，恐怕就是因为许可链/联盟链不仅是一种增信措施，更可以大大加强中心机构对于整个网络的控制力。

• 事实上，这顺道也回答了另外一个区块链相关的问题，就是“区块链既然是增强信任的，那么在一个已经有强力的中心机构的网络中，我信任中心机构就好了（比如支付宝），还要区块链干什么？”。实际上，如果对于网络中非中心节点的行为没有追踪诉求，这样的组织架构已经非常完美了，而如果有前述诉求（比如大部分的供应链中），那么中心节点就是有动力推动许可链/联盟链的部署的。

• 所以，同样一种技术，在作为“公有链”的时候是被作为打破寡头垄断的革命性武器，而作为“私有链/联盟链/许可链”的时候确实加强控制力的有力机制，真的是一件很有意思的事情。

在做了这么多分析之后，我们发现，在整个区块链或者说DLT技术中，账本是“去中心化”的不假，但是整个技术路径的结果是否是去中心化恐怕还言之尚早。分布式的账本双向提升了网络中的透明度，不仅中心节点更透明了，其他节点也是如此，整个网络中的一举一动都可溯源、可追溯、可监控，这些分布在众多节点上的账本，监视和记录着整个网络中每个细微的动作。

当然，最终还要回到笔者的本行，区块链的投资价值在哪里？其商业应用在哪里？

那么在to B端，我觉得Hyperledger自己的总结已经非常到位了，下面将我在《区块链研究笔记（一）》中已经翻译过的Hyperledger对于适用DLT技术的商业场景的条件再引用一遍：

区块链对于满足以下一条或多条需要的商业应用最适合：

• 有共享通用数据库的需要；

• 流程设计的参与方存在激励冲突，或者在参与方之间没有信任；

• 一个数据库有多方参与或者有多个写入者；

• 现在有一个受信任的第三方参与流程，以促进其他多方之间的交互，这些其他方必须相信这个第三方。这就包括：托管服务、数据提供服务、发放牌照的权威以及公证人；

• 密码学正在被使用或者应当被使用。密码学促进数据保密，数据完整性，权威性以及不可复制性。

• 一个商业流程的数据在整个流程中被导入许多不同的数据库。该数据在不同的实体间是连续的，并且/或者对于该过程的数码化是需要的。

• 系统中的参与者受到统一的规则制约；

• 各方的决策是透明的而不是保密的；

• 有对客观、不可更改的历史或者对各方指定的事实的日志的需求；

• 交易频次不超过10,000次/秒。

下图是一张对于一个商业是否要使用区块链技术的决策图：

image

刘晟西

2018年3月5日于北京

附：

Hyperledger Project Charter

The Linux Foundation

Effective 22 January 2016

1. Mission of Hyperledger Project (“HLP”).
   

The mission of HLP is to:

a. create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.

b. create an open source, technical community to benefit the ecosystem of HLP solution providers and users, focused on blockchain and shared ledger use cases that will work across a variety of industry solutions;

c. promote participation of leading members of the ecosystem, including developers, service and solution providers and end users; and

d. host the infrastructure for HLP, establishing a neutral home for community infrastructure, meetings, events and collaborative discussions and providing structure around the business and technical governance of HLP.

2. Membership.
   

a. HLP shall be composed of Premier, General and Associate Members. All Premier and General Members must be current corporate members of The Linux Foundation (at any level) to participate in HLP as a member. Anyone may propose a contribution to HLP’s technical codebase regardless of membership status. All participants in HLP, including Associate Members, enjoy the privileges and undertake the obligations described in this Hyperledger Project Charter, as from time to time amended by the Governing Board with the approval of The Linux Foundation (“LF”). During the term of their membership, all members will comply with all such policies as the LF Board of Directors and/or the HLP may from time to time adopt with notice to members.

b. The Associate Member category of membership is limited to non-profits, open source projects, and Government entities, and requires approval by the Governing Board of HLP (“Governing Board”), or, if the Governing Board sets criteria for joining as an Associate Member, the meeting of such criteria. If the Associate Member is a membership organization, Associate Membership in HLP does not confer any benefits or rights to the members of the Associate Member.

c. Premier Members shall be entitled to appoint a representative to the Governing Board, the Marketing Committee and any other committees established by the Governing Board.

d. General Members shall be entitled to annually elect one representative to the Governing Board for every ten (10) General Members, up to a maximum of two (2) representatives, provided that there shall always be at least one (1) General Member representative, even if there are less than ten (10) General Members. The election process shall be determined by the Governing Board.

e. Premier Members, General Members and Associate Members shall be entitled to:

i. participate in Project general meetings, initiatives, events and any other activities; and

ii. identify themselves as members of, or participants in, HLP.

3. Governing Board
   

a. Composition – the Governing Board voting members shall consist of:

i. Up to twenty-one (21) Premier Members with one representative appointed by each Premier Member;

ii. elected General Member representative(s) per Section 2.d.;

iii. one representative elected by the End User Technical Advisory Board, as defined in Section 6 below; and

iv. the Chair elected by the TSC, as defined in Section 4 below.

b. Conduct of Meetings

i. Governing Board meetings shall be limited to the Governing Board representatives and follow the requirements for quorum and voting outlined in this Charter. The Governing Board may decide whether to allow one named representative to attend as an alternate.

ii. The Governing Board meetings shall be confidential unless approved by the Governing Board. The Governing Board may invite guests to participate in consideration of specific Governing Board topics (but such guest may not participate in any vote on any matter before the Governing Board). The Governing Board should encourage transparency, including the public publication of public minutes within a reasonable time following their approval by the Governing Board.

c. Responsibilities – the Governing Board shall be responsible for:

i. approving a budget directing the use of funds raised by HLP from all sources of revenue;

ii. electing a Chair of HLP to preside over Governing Board meetings, authorize expenditures approved by the budget and manage any day-to-day operations;

iii. overseeing all Project business and marketing matters;

iv. adopt and maintain policies or rules and procedures for HLP (subject to LF approval) including but not limited to a Code of Conduct, a trademark policy and any compliance or certification policies;

v. working with the TSC on defining and administering any programs for certification, including any Project certification or processes for HLP;

vi. coordinating with the EU-TAB (as defined in Section 6 below) to enable End User adoption, inclusion in technical community conversations and overall participation in HLP;

vii. approving procedures for the nomination and election of (1) General Member representatives to the Governing Board, and (2) any officer or other positions created by the Governing Board.

viii. voting on all decisions or matters coming before the Governing Board.

4. Technical Steering Committee (“TSC”)
   

a. Composition

i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.

ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

b. TSC projects generally will involve Maintainers and Contributors:

i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.

c. Participation in HLP through becoming a Contributor and/or Maintainer is open to anyone. The TSC may:

i. establish work flows and procedures for the submission, approval and closure or archiving of projects,

ii. establish criteria and processes for the promotion of Contributors to Maintainer status, and

iii. amend, adjust and refine the roles of Contributors and Maintainers listed in Section 4.b., create new roles and publicly document responsibilities and expectations for such roles, as it sees fit.

d. The TSC shall elect a TSC Chair, who will also serve as a voting member of the Governing Board, and is expected to act as a liaison between the Governing Board and technical leadership of HLP.

e. Responsibilities: The TSC is responsible for:

i. coordinating the technical direction of HLP;

ii. approving project proposals (including, but not limited to, incubation, deprecation and changes to a project’s charter or scope) in accordance with a project lifecycle document to be developed, approved and maintained by the TSC;

iii. designating Top Level Projects;

iv. creating sub-committees or working groups to focus on cross-project technical issues or opportunities;

v. coordinate technical community engagement with the End User (as defined in Section 6 below) community and with any End User SIGs (as defined in Section 6 below) with respect to requirements, architecture, implementation, use cases, etc.;

vi. communicating with external and industry organizations concerning Project technical matters;

vii. appointing representatives to work with other open source or standards communities;

viii. establishing community norms, workflows or policies for releases;

ix. discussing, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and

x. establishing election processes for Maintainers or other leadership roles in the technical community that are not within the scope of any single project.

5. Marketing Committee
   

a. Composition: the Marketing Committee shall consist of:

i. one appointed voting representative from each Premier Member;

ii. non-voting representative(s), appointed by members of any other class of membership; and

iii. any non-voting Maintainer appointed by the TSC.

b. Responsibilities: The Marketing Committee shall be responsible for designing, developing and executing marketing efforts on behalf of the Governing Board. The Marketing Committee is expected to coordinate closely with the Governing Board, End User and technical communities to maximize the outreach and visibility of HLP throughout the industry.

6.  End User Technical Advisory Board (EU-TAB)
   

a. An End User is defined as any company running or intending to run an application or service as part of an industry solution that incorporates the technology produced by the HLP, who do not offer that application or service for sale to others.

b. The EU-TAB shall be composed of members of HLP who are End Users. The EU-TAB shall approve new End User members. The Governing Board will approve an initial set of End User members sufficient to setup an EU-TAB.

c. The EU-TAB shall coordinate the efforts of End Users through meetings, mailing lists, or creation of Special Interest Groups (SIGs).

d. The EU-TAB may decide whether any meeting, SIG, or other End User activity shall be limited to members or open to non-member participants.

7. Voting
   

a. While it is the goal of HLP to operate as a consensus based community, if any decision requires a vote to move forward, the representatives of the Governing Board, TSC, Marketing Committee or EU-TAB, as applicable, shall vote on a one vote per voting representative basis.

b. Quorum for Governing Board, TSC, Marketing Committee or EU-TAB meetings shall require two-thirds of the voting representatives. The Governing Board, TSC, Marketing Committee or EU-TAB may continue to meet if quorum is not met, but shall be prevented from making any decisions at the meeting.

c. Except as provided in Section 13.d. and 14.a., decisions by vote at a meeting shall require a majority vote, provided quorum is met. Except as provided in Section 13.d. and 14.a., decisions by electronic vote without a meeting shall require a majority of all voting representatives.

d. In the event of a tied vote with respect to an action that cannot be resolved by the Governing Board, the chair shall be entitled to refer the matter to the LF for assistance in reaching a decision. For all decisions in the TSC, Marketing Committee or other committee created by the Governing Board, if there is a tie vote, the matter shall be referred to the Governing Board.

e. All resolutions proposed for adoption by the Governing Board at a meeting, excluding resolutions to adopt minutes, shall be circulated in draft form to the members of the Governing Board at least two business days prior to the date of the meeting, and the text of such draft votes may be altered at such meeting.

8. Antitrust Guidelines
   

a. All members shall abide by The Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy.

b. All members shall encourage open participation from any organization able to meet the membership requirements, regardless of competitive interests. Put another way, the Governing Board shall not seek to exclude any member based on any criteria, requirements or reasons other than those that are reasonable and applied on a non-discriminatory basis to all members.

9. Code of Conduct
   

a. The Governing Board shall adopt a specific Project code of conduct, with approval from the LF.

10. Budget

a. The Governing Board shall approve an annual budget and never commit to spend in excess of funds raised. The budget and the purposes to which it is applied shall be consistent with the non-profit mission of The Linux Foundation.

b. The Linux Foundation shall provide the Governing Board with regular reports of spend levels against the budget. In no event will The Linux Foundation have any obligation to undertake any action on behalf of HLP or otherwise related to HLP that will not be covered in full by funds raised by HLP.

c. In the event any unbudgeted or otherwise unfunded obligation arises related to HLP, The Linux Foundation will coordinate with the Governing Board to address gap funding requirements.

11. General & Administrative Expenses

a. The Linux Foundation shall have custody of and final authority over the usage of any fees, funds and other cash receipts.

b. A General & Administrative (G&A) fee will be applied by the Linux Foundation to funds raised to cover Finance, Accounting, and operations. The G&A fee shall equal 9% of HLP’s first $1,000,000 of gross receipts and 6% of HLP’s gross receipts over $1,000,000.

c. Under no circumstances shall The Linux Foundation be expected or required to undertake any action on behalf of HLP that is inconsistent with the tax exempt purpose of The Linux Foundation.

12. General Rules and Operations. The HLP project shall be conducted so as to:

a. engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of The Linux Foundation in the open source software community;

b. respect the rights of all trademark owners, including any branding and usage guidelines;

c. engage The Linux Foundation for all HLP press and analyst relations activities;

d. upon request, provide information regarding Project participation, including information regarding attendance at Project-sponsored events, to The Linux Foundation;

e. coordinate with The Linux Foundation in relation to any websites created directly for HLP; and

f. operate under such rules and procedures as may from time to time be approved by the Governing Board and confirmed by The Linux Foundation.

13. Intellectual Property Policy

a. Members agree that all new inbound code contributions to HLP shall be made under the Apache License, Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0). All contributions shall be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org) that is submitted through a Governing Board and LF-approved contribution process. Such contribution process will include steps to also bind non-Member Contributors and, if not self-employed, their employer, to the licenses expressly granted in the Apache License, Version 2.0 with respect to such contribution.

b. All outbound code will be made available under the Apache License, Version 2.0.

c. All documentation will be contributed to and made available by HLP under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/).

d. If an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project or is otherwise required to achieve HLP’s mission, the Governing Board may approve the use of an alternative license for specific inbound or outbound contributions on an exception basis. Any exceptions must be approved by a two-thirds vote of the entire Governing Board and the LF and must be limited in scope to what is required for such purpose. Please email legal@hyperledger.org to obtain exception approval.

e. Subject to available Project funds, HLP may engage The Linux Foundation to determine the availability of, and register, trademarks, service marks, and certification marks, which shall be owned by the LF.

14. Amendments

a. This charter may be amended by a two-thirds vote of the entire Governing Board, subject to approval by The Linux Foundation.