Permissioned Blockchains:Properties, Techniques and Applications翻译

Posted 2023-04-02 vincy_yeha

一些基础知识：

 翻译：

摘要：

区块链的独特功能，如不变性、透明度、来源性和真实性，已被许多大型数据管理系统用于部署广泛的分布式应用，包括供应链管理、医疗保健和在许可环境中进行众工。与无权限设置（例如比特币）不同，比特币是网络是公开的，任何人都可以在没有特定身份的情况下参与。区块链系统由一组已知的已识别节点组成，这些节点可能无法完全相互信任。虽然许可区块链的特点对各种大规模数据管理系统具有吸引力，但这些系统必须满足四个主要要求：保密性、可验证性、性能和可扩展性。工业界和学术界已开发出各种方法，以不同的假设和成本满足这些要求。本教程的重点是介绍许多这些技术，同时强调其中的权衡。我们通过展示三种不同的应用，即供应链管理、大型数据库和多平台众工环境，展示这些技术在现实生活中的实用性，并展示如何利用这些技术来满足此类应用的要求。

介绍：

区块链是一种分布式数据结构，用于记录由多个节点维护的交易，而没有中央授权。在区块链系统中，节点通过一个由不受信任的参与者组成的大型网络就共享状态达成一致。区块链最初是为比特币加密货币设计的，但是，最近的系统侧重于其独特的功能，如透明度、来源、容错性和真实性，以支持广泛的分布式应用。比特币和其他加密货币是无权限区块链系统。在未经许可的区块链中，网络是公开的，任何人都可以无特定身份参与。许多其他分布式应用程序（如供应链管理和医疗保健）被部署在经过许可的区块链系统上，这些系统由一组已知的已识别节点组成，这些节点可能仍不能完全相互信任。此教程的重点是支持跨协作企业分布式应用程序的许可区块链系统。然而，这些合作企业不一定相互信任。因此，我们解决了分布式应用程序的保密性、可验证性、性能和可扩展性要求方面的四个不同挑战，以便在现实生活中使允许的区块链系统切实可行。

许多协作分布式应用程序（例如供应链管理）都需要数据保密，其中多个企业根据服务级别协议 （SLAs） 进行协作以提供不同的服务。要在不同的协作企业中部署分布式应用程序，区块链系统需要支持每个企业的内部交易以及代表企业之间协作的跨企业交易。虽然跨企业交易访问的数据应对所有企业可见，但内部交易访问的每个企业的内部数据可能是保密的。

除了保密之外，在许多跨企业系统中，例如众工应用程序，参与者需要验证其他企业发起的交易，以确保满足整个系统上一些预先定义的全球限制。例如，根据公平劳动标准法案 1（FLSA），工人每周的总工作时间不得超过 40 小时。因此，如果一名工人为多个众工平台工作，例如为优步和 Lyft 工作的司机，验证此类全球限制需要访问其他企业拥有的数据。因此，系统需要支持可验证性，同时保持交易的机密性。

除了保密性和可验证性之外，分布式应用程序（例如财务申请）在吞吐量和延迟方面需要高性能，例如，Visa 支付服务每秒处理数千笔交易，而许可区块链的天真实施仅处理每秒数百笔交易。一般来说，"订单"和"执行"是许可链处理交易的两个主要阶段。已授权区块链需要在订单或执行阶段将不同交易的处理并行，以提高系统的整体性能。

最后，可扩展性是业务采用区块链系统的主要障碍之一。为了支持分布式应用程序，例如大型数据库，区块链系统应该能够通过向系统添加更多节点来高效扩展。将数据划分为多个由不同节点子集维护的碎片是增强数据库可扩展性的行之有效的方法。在这种方法中，数据库的性能与节点数目成线性地进行缩放。虽然数据库系统使用分片技术来提高数据库在仅崩溃节点网络中的可扩展性，但由于可能不可信的性质，区块链系统无法轻易地使用该技术网络中的节点。

在此教程中，我们的目标是向数据库社区介绍对设计高效的许可区块链系统的先进解决方案的深入了解。我们首先讨论了几个大型数据管理应用程序，这些应用促使对许可区块链作为基础设施的需求不断增加。然后，我们提供许可区块链模型及其基本加密和分布式系统组件的详细描述。鉴于不同应用的不同需求，我们详细描述了现有许可区块链系统设计背后的各种技术，这些技术可解决保密性、可验证性、性能和可扩展性等基本挑战。教程的每个部分将讨论所呈现的各种技术与实际系统在支持大型数据方面面临的挑战之间的权衡。

教程概述

保密性、可验证性、性能和可扩展性是需要通过许可区块链系统实现的大型数据管理应用程序的主要要求。虽然跨企业应用（如供应链管理和众工）需要保密性和可验证性（以维护企业数据的机密性，并验证其他企业发起的交易，同时保留其数据的机密性），但单企业申请和跨企业应用程序都需要性能和可扩展性。

在此部分，我们首先介绍了几个实际的大型数据管理应用程序，以激励已授权的区块链。接下来，我们将引入已授权的区块链，并介绍受许可区块链系统提出的不同技术，以满足大规模数据管理应用的要求。

应用

现在，我们简要讨论了几个大型数据管理应用程序，以激励已授权的区块链（许可链）。

供应链管理

各方之间缺乏信任是供应链管理中最重要的问题之一。为了解决此类问题，可以使用允许的区块链来监控协作过程的执行情况，并检查执行与 SLA 之间的一致性。使用的区块链系统需要支持内部和跨企业交易，与所有参与者可见的跨企业交易相比，每个企业的内部交易都是保密的，例如，制造商的内部交易演示了其生产制造商可能打算保密的产品的内部流程。最后，区块链系统也必须解决性能方面的问题。

大规模数据库

分片技术广泛应用于分布式数据库，如谷歌的斯潘纳和Facebook的陶，以解决可扩展性问题。此类系统主要采用崩溃故障模型，并依靠受信任的协调员处理跨碎片交易。在存在不受信任的基础设施（即 Byzan-tine 节点）的情况下，区块链系统可用于实现可扩展性，同时容忍恶意故障。如果需要数据碎片的机密性，可扩展性技术也则应与保密技术集成。

 多平台人群工作

人群工作使互联网上的公开协作成为可能。众工系统包括平台、请求者和工作人员，其中请求者提交任务，员工将针对特定任务的贡献发送到平台。因此，众工系统可能需要每秒执行数千次交易，因此必须具有高性能。此外，多平台群工作系统应随着平台、员工和请求者数量的增加而适当扩展。此外，该系统必须针对预先确定的全球限制提供交易的可核查性。例如，根据公平劳动标准法案 2 （FLSA） 或加利福尼亚州第 223 号提案，每周可能为多个人群工作平台工作的工人的总工作时间不得超过 40 小时，该提案对为健康福利工作的最小工时制定了自己的一套规定，例如，如果驾驶员每周至少工作 25 小时， 公司（即平台）必须提供医疗保健补贴。综上所述，多平台群工作系统需要所有四个保密性、可验证性、性能和可扩展性属性。

已许可区块链

 区块链系统是全球规模的点对点系统，集成了加密、分布式系统和数据库中的许多技术和协议。在区块链系统中，节点通过可能不受信任的参与者组成的大型网络就共享状态达成一致。比特币和其他加密货币是无权限区块链系统。无权限区块链系统是公共的，没有先验已知身份的计算节点可以随时连接或离开区块链网络。另一方面，已授权的区块链系统使用先验已知和已识别节点的网络来管理区块链。区块链系统中的主要基础数据结构是区块链分类账，这是一种仅附加的完全复制结构，在所有参与者之间共享，并保证系统中所有参与者对所有用户交易的一致视图。区块链分类账中的每个区块都包含一批交易，区块链分类账中的交易块总顺序由链块一起捕获，即每个区块都包含前一个区块的加密哈希。图 1 说明了一个由五个节点组成的权限区块链系统示例，每个节点都维护区块链分类账的副本。

区块链架构由异步大分布系统中的一组节点组成。系统中的节点可能会崩溃，即当节点发生故障时，它完全停止处理，或者可能恶意行为，即当节点发生故障时，它可能任意行为，通常称为拜占庭故障模型。为了确保不同节点上复制的数据之间的一致性，区块链系统使用状态机器复制 （SMR） 算法（其中节点就传入交易的订购达成一致），以确保分布式分类账的副本相同。SMR 对不同节点上客户交易的确定性执行进行监管，使每个无故障节点以相同的顺序执行每笔交易。在已授权的区块链系统中，节点就使用异步耐错协议（如 Paxos 或 PBFT）将交易附加到区块链分类账中这一独特顺序达成共识。

技术

在过去的几年中，许可区块链系统提出了各种技术来解决大规模数据管理系统的四个主要要求。在本节中，我们将详细讨论这些技术，并介绍利用这些技术满足四个主要要求的系统：机密性、可验证性、性能和可伸缩性。

2.3.1机密性

在许多协作分布式应用程序中，数据需要保密性，例如，供应链管理，其中多个企业按照服务水平协议（SLA）进行协作以提供不同的服务。为了在不同的协作企业中部署分布式应用程序，区块链系统需要支持每个企业的内部事务以及代表企业之间协作的跨企业事务。虽然跨企业事务访问的数据应对所有企业可见，但每个企业的内部数据（由内部事务访问）可能是机密的。特别是，在协作分布式应用程序中，每个企业都可以维护自己独立的脱节区块链，并使用原子跨链交易或Interledger协议等技术来支持跨企业协作。这些技术通常成本高昂，复杂，主要是为无许可区块链设计的。另一方面，支持单个区块链上的协作企业的技术要么不支持导致数据集成问题的企业内部交易，要么遭受机密性问题，因为整个分类账对所有企业都是可见的，例如，单通道Fabric。

为了实现机密性，已经提出了加密和基于视图（即基于分片）的技术。在加密技术中，数据被加密或散列，因此，不相关的各方无法访问数据。或者，基于视图的技术已被用于实现机密性，其中每一方（即一个企业或一组企业）仅维护自己的数据视图（包括该方可访问的记录），因此，没有必要使用加密技术。我们介绍了Caper，多渠道Hyperledger Fabric

和私有数据收集（在Hyperledger Fabric的每个渠道中使用）。

基于视图的方法。我们首先讨论基于视图的方法。在Caper中，每个企业都维护两种类型的私有和公共数据，系统支持内部和跨企业交易，其中内部交易由单个企业执行，而跨企业交易由所有企业执行。在Caper中，每个企业都在本地订购和执行其内部交易，而跨企业交易是公开的，并且对每个企业都是可见的。此外，Caper的区块链账本是一个有向无环图，包括每个企业的内部交易和所有跨企业交易。尽管如此，为了保密起见，区块链分类账不由任何节点维护。事实上，每个企业都维护自己的本地分类账视图，包括其内部和所有跨企业事务。由于订购跨企业交易需要所有企业之间的全球协议，因此Caper引入了不同的共识协议来对跨企业交易进行全球排序。

Hyperledger Fabric引入了保持机密性的渠道。多渠道超级账本结构由多个渠道组成，每个渠道都有自己的一组企业。在一个通道中，每个企业都有自己的一组执行者（即背书者）节点，其中企业的交易由其背书者节点执行。因此，在其智能合约中实现的企业逻辑是其他企业私有的。但是，通道内的企业共享相同的区块链分类账和区块链状态（即数据存储），因此，通道中的任何交易都将复制到所有通道成员（即企业）的分类账上。另一方面，不同的通道是完全分开的，既无法访问区块链分类账，也无法访问其他渠道的区块链状态。不同的通道仍可能共享同一组订单节点集。订货商就通道的交易顺序达成共识。由于订购者能够访问交易数据，因此所有渠道成员都应信任他们。还应该注意的是，企业可能是不同渠道的成员，例如，参与不同供应链管理方案的制造商。此外，处理两个通道之间的（公共）事务需要在参与者之间使用受信任的通道或原子提交协议。

加密技术。当在跨企业应用程序中，一部分企业希望进行机密交易并保持交易数据的私密性时，可以使用加密技术。特别是在Hyperledger Fabric中，如果一个通道上的一部分企业需要对同一通道上的其他企业的数据保密，他们可以选择创建一个新通道，该通道仅包含需要访问数据的企业。但是，创建单独的通道会导致额外的管理开销和数据完整性（在公共数据和私有数据之间）问题。Hyperledger Fabric提出了私有数据收集，以管理单个渠道上的两个或多个企业希望与同一渠道上的其他企业保密的机密数据。私有数据收集使用哈希，这是一种加密技术。通过定义私有数据收集，通道上的企业子集将其机密数据存储在每个授权对等体上复制的私有数据库中。私有数据的哈希值仍会附加到通道上每个对等节点的区块链分类账中。哈希用作事务的证据，并用于状态验证。使用哈希，其他企业仍然能够在验证阶段检查读写冲突。企业可能涉及不同的私有数据收集，其中每个集合在其对等体上复制一个私有数据库。

讨论。总而言之，基于视图的技术在管理视图中成本高昂，例如，在Hyperledger Fabric中配置通道。此外，处理公开交易要求在所有有关意见（例如，企业、渠道）之间建立共识。与Hyperledger Fabric相比，Caper在企业层面保留了机密性（逻辑和数据）。另一方面，加密技术虽然降低了管理视图的成本，但但却导致维护不相关企业的区块链分类账和区块链状态中的数据的开销。

2.3.2可验证性

在许多跨企业系统中，企业需要验证由其他企业发起的跨部门行为，以确保以保护隐私的方式满足全球约束。这可能发生在众包工作环境中，在这个环境中，多个互不信任的平台需要共同执行全球法规，例如，一名工人每周最多可以工作40个小时。因此，区块链系统需要采用可验证性技术，同时保护参与者的隐私。在具有增强隐私的加密货币中也需要可验证性，例如Zcash，其中交易数据是机密的，节点需要在不知道发送者，接收者或交易金额的情况下验证交易。

为了实现可验证性，已经提出了加密技术（零知识证明）。在密码学中，零知识证明是一种方法，通过这种方法，一方（证明者）可以向另一方（验证者）证明他们知道值x，除了他们知道值x之外，没有传达任何信息。还可以使用基于令牌的技术实现可验证性，其中集中式实体根据全局约束生成可验证的令牌并将其分发给相应的参与者。我们介绍 Quorum 和 Separ，并讨论如何在这两个系统中解决可验证性问题。

加密技术。Quorum作为基于以太坊的许可区块链引入了两种共识协议：基于Raft的崩溃容错协议和称为伊斯坦布尔BFT的拜占庭容错协议。Quorum支持公共和私有事务，其中公共和私有事务都使用相同的共识协议进行排序。Quorum使用零知识证明技术来确保私有事务的可验证性。零知识证明允许在分布式账本上转移数字资产，而不会泄露有关发送方，接收方或资产数量的任何信息，同时确保：发送方有权转移资产的所有权，资产以前未花费过（双重支出），交易输入等于其输出（质量守恒）。零知识证明也被用于众工平台，例如ZebraLancer，ZKCrowd和Prio，以在单一平台环境中提供可验证性。

基于令牌的技术。Separ是一个基于区块链的多平台众工系统，它使用基于令牌的技术来确保可验证性。在Separ中，一个集中的可信机构使用匿名令牌对全球法规进行建模，并将其分发给参与者。例如，如果全局约束声明工作人员每周的总工作时间不得超过 40 小时才能遵循 FLSA，则权限将为每个工作人员分配 40 个令牌，每当工作人员参与任务时，工作人员都可以使用这些令牌。Separ由一个基于隐私保护令牌的系统组成，该系统位于跨平台共享的区块链分类账之上，其中使用分布式共识协议在众工平台之间管理系统的全局状态。

讨论。总之，加密技术是真正分散的，因此，不需要受信任的实体。然而，零知识证明具有相当大的开销。使用此类技术，尤其是在大多数事务可能是本地事务的环境中，由于其开销而无益。另一方面，基于令牌的技术需要集中的权限来生成令牌。集中的权威必须得到所有参与者的信任。但是，无需复制每个节点上的所有事务，从而提高性能。

2.3.3性能

许多大型数据管理应用程序在吞吐量和延迟方面需要高性能，例如财务应用程序。许可的区块链系统使用乐观或悲观的方法处理交易。这些方法根据事务之间争用和冲突的程度和频率在性能上提供了权衡。在乐观方法中，节点在不运行共识协议的情况下执行事务以明确建立排序，而在悲观方法中，事务首先被排序然后执行。

从架构的角度来看，已经为许可的区块链系统提出了三种主要架构。订单执行 （OX） 和订单并行执行 （OXII） 架构遵循悲观方法，而执行-订单验证 （XOV） 架构遵循乐观方法。我们展示了Tendermint、ParBlocckhain、Hyperledger Fabric、Fast Fabric、Fabric++、FabricSharp和XOX Fabric如何应对许可区块链系统的性能挑战。

悲观的态度。在OX许可链中，一组节点（即排序者）使用容错协议在传入交易的唯一顺序上建立协议。根据节点的故障模型，可以使用拜占庭式，例如PBFT，Hotstuff，崩溃，例如Paxos，Raft，甚至是混合，例如SeeMoRe，UpRight，容错协议。然后，排序器节点生成块并将其多播到其他节点（即执行器）。执行器节点以相同的顺序按顺序执行区块的交易，将交易追加到区块链分类账，并更新区块链状态（即数据存储）。订单执行架构（OX）广泛用于不同的许可区块链系统，如Tendermint ，Quorum，Multichain，Chain Core，Hyperledger Iroha和Corda。特别是，Tendermint使用基于PBFT的共识协议，该协议在几个方面与原始PBFT不同。首先，只有一部分节点，称为验证者，参与共识协议，要成为验证者，节点需要锁定其硬币。其次，Tendermint使用领导者旋转技术，并在每个回合（即每次尝试构建一个块）后以循环方式切换领导者。第三，Tendermint实现了权益证明共识机制。事实上，在Tendermint中，验证者在共识协议中没有相同的"权重"，验证者的投票权对应于其有界硬币的数量。结果，三分之一或三分之二的验证者是根据总投票权的比例而不是验证者的数量来定义的。

订单并行执行 （OXII） 架构类似于订单并行架构，遵循悲观的方法。在OXII架构中，一组不相交的节点（排序器）在传入交易的顺序上建立协议并构建块。一旦构建了一个区块，排序器节点就会为区块内的交易生成一个依赖关系图。依赖关系图根据事务之间的冲突给出部分顺序，并允许并行执行非冲突事务。然后，事务由执行器节点按照生成的依赖项图执行。ParBlockchain遵循 OXII 架构，能够支持多企业系统。在多企业系统中，每个企业都有自己的一组执行器节点，其中每个企业的交易由相应的执行器节点执行。

乐观的方法。最后，Hyperledger Fabric通过切换”订单“和”执行“阶段的顺序，提出了乐观的XOV架构（由Eve在拜占庭容错SMR的上下文中首次引入）。在 Fabric 中，不同企业的交易首先由每个企业的执行者节点（即背书人）并行执行。然后，交易通过共识协议（目前是基于Raft的协议）进行排序，并多播到所有背书节点。然后，背书人验证交易并将其附加到分类帐中。

虽然 Fabric 通过并行执行事务来提高性能，并支持事务的非确定性执行，但在工作负载中存在任何争用（即冲突事务）的情况下（这在分布式应用程序中很常见），它必须忽略冲突事务的影响，这些事务会对区块链的性能产生负面影响。发生这种情况是因为 Fabric 在第一步中执行事务，并在最后一步中验证它们，因此，如果同一块的事务之间存在任何读写依赖关系，则直到最后一步才会检测到它。已经提出了不同的技术来提高Fabric的性能，同时仍然遵循其XOV架构。

FastFabric 使用不同的数据结构和缓存技术，并行化事务验证管道，以提高 Fabric 对无冲突事务工作负载的吞吐量。Fabric++ 采用来自数据库的并发控制技术来提前中止事务或在排序阶段之后对事务进行重新排序，以协调潜在的冲突。FabricSharp 更进一步，提供了一种算法，用于早期筛选出永远无法重新排序的事务，还提供了一种重新排序技术，可消除不必要的中止（这是由于 Fabric++ 的强大可序列化性保证，而 Fabric 需要可序列化保证）。最后，XOX Fabric 模型由一个预购和一个订后执行步骤组成，其中在验证步骤之后添加订单后续执行，以重新执行由于读写冲突而失效的交易。

讨论。总而言之，由于所有事务的顺序执行，OX体系结构的性能较低，而OXII和XOV体系结构都能够并行执行事务。OXII 还通过检测订单阶段的冲突事务并生成依赖关系图来支持有争议的工作负载，而 XOV 则验证读写冲突，最后导致性能不佳。另一方面，XOV通过首先执行事务并在早期检测任何不一致来支持事务的非确定性执行，而在OXII中，事务在最后一步执行，因此，如果结果不一致，中止事务将代价高昂。

2.3.4可扩展性

可扩展性是企业采用区块链系统的主要障碍之一，特别是在金融和大型数据库系统中。许可区块链系统主要使用集群来提高可扩展性。在集群方法中，例如Blockplane，节点被划分为容错集群，其中每个集群处理（或至少排序）一组不相交的交易。许可区块链系统使用单分类账或分片分类账技术来增强可扩展性。在单分类账技术中，整个分类账在所有集群上复制，所有节点执行每笔交易。另一方面，在分片账本技术中，账本被划分为由不同集群维护的多个分片。分片账本许可区块链系统处理分片内和跨分片交易两种类型。跨分片事务可以使用基于协调器的方法以集中方式处理，也可以使用扁平化方法以分散方式处理。我们详细讨论了 ResilientDB、AHL、SharPer、Saguaro 和多通道 Fabric。

单分类帐方法。ResilientDB 使用拓扑感知群集方法，并将网络分区为本地容错群集，以最大限度地降低全局通信的成本。但是，所有集群在每个节点上复制整个分类账，并且在每一轮中，每个集群都会在本地建立单个事务的共识，然后将本地复制的事务多播到其他集群。然后，所有群集，以预定顺序执行该轮的所有交易。由于所有事务都由所有集群执行，因此 ResilientDB 中没有分片内和跨分片事务的概念。

分片账本方法。AHL 使用分片技术来增强可扩展性。在AHL中，类似于无许可区块链Elastico，OmniLedger和Rapidchain，节点被随机分配给集群（称为委员会）。为了确保高概率的安全性，每个委员会必须包含至少80个节点（而不是OmniLedger中的600个节点）。为了减少每个委员会中所需节点的数量，AHL 采用受信任的硬件（其中提供的技术）来限制节点的恶意行为。使用可信硬件，恶意节点不能将不一致的消息多播，例如，序列号不一致的消息发送到不同的节点，AHL通过依靠一组额外的节点（称为参考委员会）来充当协调者的角色，以集中的方式处理跨分片交易。参考委员会使用经典的两阶段提交 （2PC） 和两阶段锁定 （2PL） 协议处理相关集群的跨分片事务。

SharPer是另一个分片许可的区块链系统，其中系统由一组容错集群组成，每个集群维护区块链分类账的分片。与AHL相比，SharPer通过考虑预先确定的容错集群或假设节点数远大于故障数来提供确定性安全保证。SharPer 使用分散的扁平共识协议在所涉及的集群中以分散的方式处理跨分片交易（不需要参考委员会）。

在Saguaro中，节点按照从边缘设备到边缘，雾和云服务器的广域网基础架构以分层结构进行组织，其中每个级别的节点进一步聚类到容错群集中。在较低级别，类似于SharPer的Saguaro在每个集群上维护区块链分类账的分片。然而，Saguaro在处理跨分片交易时受益于网络的分层结构。对于每个跨分片事务，选择与相关集群具有最小总距离的内部集群，即所有参与集群中最低的共同祖先，作为协调器，从而降低延迟。

最后，在多通道 Fabric 中，引入通道主要是为了增强机密性，但它们也可用于对系统和数据进行分片。通道实际上是整个系统的分片，由一组（逻辑上）独立的节点自主管理，但仍然知道它所属的更大系统。使用通道，Fabric 使用容错协议高效地处理分片内事务。多通道 Fabric 中的跨分片事务以集中方式处理，并且需要参与者之间存在受信任的通道来扮演协调器角色或原子提交协议。

讨论。分片账本方法的主要区别在于它们如何处理跨分片交易。跨碎片事务的集中处理更简单，更接近传统的两阶段提交，即，需要一个协调器集群来容忍拜占庭式故障，而不是单个协调器节点，但是，需要大量的内部和跨集群通信阶段。另一方面，分散式方法不需要一组额外的节点，在所涉及的集群中以较少的阶段数处理事务，并且能够并行处理具有非重叠集群的跨分片交易。但是，如果涉及的集群距离较远，则在需要多轮消息传递的相关集群之间建立跨分片共识会导致高延迟。另一方面，单账本方法（例如 ResilientDB）不会受到通过在每个集群上复制整个数据来处理跨分片交易的延迟。但是，对于每个事务，在所有集群之间交换消息仍然会导致高延迟。

教程信息

这是一个三小时的教程，面向对许可区块链及其在大规模数据管理系统中的应用感兴趣的研究人员，设计师和从业者。具有区块链和分布式系统基本背景的目标受众应该从本教程中受益最多。对于普通观众和新手，本教程解释了大规模数据管理系统中许可区块链的设计空间。

本教程与以前在数据库会议中讨论同一主题的教程不同。Maiyya等人在VLDB 2018上提供的教程主要是关于无许可区块链的，涵盖了比特币，PoW共识的细节以及几种比特币替代方案，以提高比特币的吞吐量。然后，该教程介绍了原子交换和闪电网络等解决方案，以解决多个区块链系统兴起带来的挑战。该教程的下一个版本在SIGMOD 2019上发布[44]，部分涵盖了许可区块链，其中Hyperledger Fabric，ParBlockhain和Caper等几个系统仅作为许可区块链的示例呈现。然而，在本教程中，介绍了20多个许可的区块链及其基础技术，以满足大规模数据管理系统的要求，并讨论了各种技术之间的不同权衡。本教程也不同于C. Mohan在VLDB 2017和ICDE 2018 [46]上的教程，他明确指出他的教程的范围"本质上是通用的，没有深入研究加密算法或分布式共识协议的

细节"。最后，本教程与Gupta等人在VLDB 2020上提供的教程不同，该教程的重点是探索许可区块链的高吞吐量共识协议。

Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains学习总结

学习背景

Fabric作为一个不同于之前区块链的一种面向企业开发的区块链框架，虽然是在2018年发布的这篇文章，而且其官方文档内容也已经在不断更新，但是初学区块链，尤其是联盟链相关知识时，这篇文章可以起到一定的引导作用。其官方文档链接如下：A Blockchain Platform for the Enterprise — hyperledger-fabricdocs main documentationhttps://hyperledger-fabric.readthedocs.io/en/latest/

文章主要贡献 

我总结了这篇文章的几个主要贡献点：

·Fabric是第一个在排序阶段即共识阶段提供一个可插拔的接口给共识协议，在此之前不管是公链还是联盟链都是提供已经提前规定的共识协议。

·智能合约在Fabric之前只能由非标准、特定领域的语言进行编写，但在fabric里智能合约（链码）可以由c++、go、Java语言进行编写。

·Fabric提供了一个新的区块链架构，即execute-order-validate，之前的区块链都是Order-Execute架构

·不需要所有peer节点执行智能合约，只需要有满足背书策略的节点执行，之后把状态更新gossip给其他节点

注意：在这篇论文中没有联盟链的概念，只是许可链，当然这两者是等价关系的 

Order-Execute架构 

 

 在fabric之前所有的区块链都是order-execute架构，这也就是交易来临时，先进行排序共识，然后peer进行顺序执行交易。这种架构虽然由于简单因而应用广泛，但是存在着一些限制缺陷。

本篇论文中从三个方面介绍了其限制：

·顺序执行

因为在这个架构中所有peer节点会顺序执行交易，而且智能合约是所有人都可以编写的，不管你是否有恶意，这个时候如果有一个恶意的需要很长时间执行的智能合约被引入执行，就会极大的降低区块链的性能，这种恶意行为也就是DOS（denial of service）攻击。

当然，公链对此并不是说毫无对策。公链为了解决可能出现的这种问题，提出并实施了一个执行交易的花费。比如说在以太坊上，提出了一个gas费用的概念，并面向交易的提出者进行收费。这是主要面向有本地加密货币的公链的解决方案，也就是说没法解决没有本地加密货币的区块链。

·非确定性编码

 对于order-execute架构来说达成共识或者说排序后的执行的操作必须是确定性的，在之前区块链是通过使用特定领域语言编写区块链以此解决问题，但是因为特定领域语言学习需要开发人员的额外学习，不如通用的编程语言如go，c++，Java方便，但是如果使用通用编程语言就无法确保操作的确定性。

·机密执行

在过去，执行智能合约需要在所有的peer节点上进行，但是这样就无法保证有些时候一些交易的数据的机密性。

除此之外，之前的区块链的共识协议都是一刀切似的，无法根据具体情形需求来更换适合的共识协议，比较死板。例如，BFT协议在部署在潜在对抗环境时，性能差异很大。具有“链”通信模式的协议在具有对称和同构链路的局域网集群上显示出可证明的最优吞吐量，但在广域异构网络上性能严重下降。

 Execute-order-validate架构

 

 在本文中Fabric提出的execute-order-validate架构如其名字一样分为三个阶段，分别是执行阶段，排序阶段以及验证阶段。

其执行交易的流程大致是这样的：

·客户端从CA获取合法的身份证书来加入到网络中

·客户端把交易的提案发送给配置文件中指定的背书节点，背书节点会检验请求签名，是否满足ACL，然后模拟执行后对结果进行签名

·背书节点会响应请求给客户端，客户端会验证响应签名，然后对比多个背书节点的回复结果，最后检查是否收集足够的endorsement

·客户端、背书节点会把交易提交给排序节点，排序节点会对交易进行排序，之后构造区块，发送给验证提交节点

·验证节点会检查区块中交易完整性，签名是否重复，交易是否满足endorsement策略，检查读写集中版本与账本是否一致，最后会执行区块中合法交易，更新账本状态

节点类型

在fabric中节点主要有两种，分别是Peer与Orderer 

·Orderer节点主要是提供共识服务的节点，对所有的合法交易进行排序，再对排序后的交易按批次组合为区块结构

·Peer节点在网络中有两种角色，即Committer和Endorser。Committer角色的peer节点负责维护区块链和账本。该节点定期从Orderer节点中获取排序好的交易区块结构，对这些交易景兴最后的检查确认。Endorser角色的节点主要是为交易背书，检查其是否合法。通过则模拟运行交易，对交易执行导致的状态变化作背书，并返回给客户端。

注意：同一个Peer节点可以仅为Committer角色运行，也可同时担任Endorser与Committer角色

论文链接Hyperledger fabric | Proceedings of the Thirteenth EuroSys Conference