博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
翻译Monoxide: Scale out Blockchains with Asynchronous Consensus Zones
阅读量:3726 次
发布时间:2019-05-22

本文共 15715 字,大约阅读时间需要 52 分钟。

 

摘要

虚拟货币为我们提供了一个有前景的匿名的在线支付系统,然而,低吞吐量显著阻碍了加密货币系统的可扩展性和应对井喷式增加的用户和交易数量时的可用性。另一个实现可扩展性的障碍是每个节点需要备份整个网络的通信,存储和状态。

本文介绍一种可呈线性提升区块链系统性能,又不影响其去中心化程度以及安全性的扩容方案,称为异步共识组。我们通过运行多个平行且独立的单链共识系统(称之为共识组)来实现上述特性,共识在每个单独的共识组内部通过最小化通信来进行。

具体的,Monoxide将区块链系统划分为若干个“异步共识组”,共识组是由多个同质的、功能上完全一致、地位上也完全平等,并逻辑上尽量隔离的独立共识系统的实例所构成;它们并行工作,分摊全网的吞吐、计算、存储的压力,也分摊全网状态的维护工作。其次,Monoxide利用“最终原子性”去确保跨组交易可以高效无误的完成,而无需两阶段提交协议的开销,保证 Monoxide系统中交易原子性在所有接力交易确认和执行之后可以得到满足。

此外,Monoxide本文提出了一种名为“连弩挖矿”的挖矿机制,通过协议层调整,放大网络有效算力,保证每个分区的挖矿算力与整个网络一样,从而避免因分散挖矿能力导致分区易被攻击的问题。实验结果证明了此方案的有效性:在拥有48000个节点的测试平台上,此系统相较比特币、以太坊网络在吞吐量上高出了1000 倍,容量上扩大了2000倍。

自从2008年《the peer-to-peer electronic cash system》发表之后,分布式的共识系统持续扩大应用范围,并对社会产生了更大的影响。然而,较低的交易确认吞吐量(以每秒交易的次数TPS来衡量)严重阻碍了该系统应对如此爆发增长的用户以及交易量的可用性。除去网络延时,根本的原因是区块需要顺序创建产生,在区块链网络中,按顺序创建区块需要足够的时间,无论在该网络有多少个全节点和矿工,都会限定一个较低且固定的TPS。

此外,例如在比特币和以太网中,每个全节点需要复制整个网络的通信,存储和状态表达(内存),这将使得共识系统难以扩大规模。即使已经实现了高吞吐量,也需要足够快的网络通信,充足的存储容量和足够的算力,这些也为节点设置了一个很高的参与门槛,与此同时又严重阻碍了去中心化的实现。因此,可扩展的区块链系统需要在保持去中心化和安全性的同时,从共识协议的层面考虑其可扩展性,包括通信资源的使用、存储、计算和状态表达(内存)等等。在此之前,以太坊社区已经对区块链系统中的分片进行了研究[39](更多内容见第8节),该研究的动机与本文的许多考虑因素一致,包括备份现有交易数据、低准入门槛、高效跨片交易的重要性以及分片后可能降低的挖矿能力导致的安全性问题。

我们需要一个可扩展性良好的区块链系统,以便支持将来因特网规模的应用程序。VisaNet支付和结算[46]大约平均需要4kTPS,支付宝移动支付在2017年的高峰流量超过256kTPS [3],区块链[44]上数字应用程序的快速增长也显示出对可扩展性良好区块链系统的巨大需求,这样的系统具有高吞吐量和足够大的容量,可以支持游戏和分布式的交换。

这些需求激励我们展开本文工作。

异步共识组是本文的主要思想,旨在设计一个可扩展性良好的区块链系统,同时又不减弱去中心化和安全性。通过在多个独立和并行的共识组中隔离地处理工作,实现区块链系统的扩展。整个网络被分割为多个共识组,每个共识组负责自己的部分。核心数据结构,例如区块和交易信息,是每个组不同的,并且这些信息只在它们自己的共识组内备份和存储。竞争挖矿、链的增长、交易验证都是独立且异步地在每个共识组中实现。

共识组通过具有与共识组总数成比例的存储量、计算能力和状态表达(内存),展现了线性增长的可扩展性。设计这样一个区块链系统有两个主要的挑战:(1)在处理跨共识组交易时,应确保以可扩展性的方式进行来保证高吞吐量;(2)随着各共识组区块链的独立增长,诚实挖矿者的比例减少,应加强安全保障。

跨共识组原子性对区块链系统的准确性和鲁棒性至关重要。在共识组中,交易可能涉及不同共识组中的多个参与者,由于这些参与者的状态更新是在不同的共识组内独立进行的,因此,保证原子性具有一定挑战性。如何高效地处理这种情况,是扩大吞吐量和整个系统性能的关键。我们提出最终原子性来确保跨共识组的交易原子性,通过该方案,所有操作都将完成,并最终实现正确的结束状态,而不是像两阶段确认协议[27]那样序列化交易。为保持共识组的并行和充分利用,最终原子性允许以异步和无锁的方式进行交叉交易,最终原子性将一个跨共识组交易分解,将其分成多个步骤(relay transactions接力交易),每个都发生在一个单独的共识组内。这些步骤由矿工在不同共识组中接力和执行。我们的制度不能保证矿工安全处理所有的接力交易,就像在比特币或以太币中不能保证交易处理一样。相反,通过处理接力交易并确保最终原子性,可以激励每个共识组内的矿工完成每个步骤。

为加强共识组的安全,引入了Effective Mining Power Amplification,区块链系统依靠战局多数算力来抵御攻击者袭击。然而,当挖矿被分布到不同共识组时,攻击者可以针对单个的共识组聚集算力进行攻击,很可能去超过单个共识组内的51%的算力阈值。

为解决这一问题,我们提出连弩挖矿机制来保证每个共识组的安全性。使用连弩挖矿机制,矿工可以通过解决一个工作证明谜题,在不同的共识组创建多个块,大大增强了将算力平均分布到不同共识组的诚实矿工的有效算力。另一方面,这种放大对攻击者没有用处,因为放大后的算力被迫均匀地分布在多个共识组,而不能集中到一个共识组。这样,每个共识组的有效算力将与整个网络的物理算力处于同一水平,使得攻击单个共识组与攻击整个网络一样困难。

 

本文的贡献包括:

  1. 一种可扩展的区块链系统,它将用于通信、计算、存储和状态表达(内存)的工作负载划分为独立的和并行的共识组。尽管网络吞吐量持续增长,我们的系统中单个全节点的负担保持在较低的水平。
  2. 最终原子性方案,用于有效地处理跨共识组交易,确保异步工作的共识组的准确性和鲁棒性。
  3. 连弩挖矿机制,一种新型的工作量证明pow方案,它可以防止算力分散到多个共识组时,攻击门槛的境地。

为了证明我们的系统的有效性,我们在一个包括全球1200台虚拟机的测试台上进行了一系列的实验,使用了来自以太坊网络的ERC20支付历史数据,在这些实验中,我们的系统实现了比特币和以太坊网络吞吐量的1000倍扩大和2000倍扩容。

 

背景

本文现在展开对这项工作的必要背景介绍,包括区块链系统和两种共识机制(即工作量证明(PoW)及权益机制证明(PoS)的细节。最后,我们讨论了UTXO和帐户/余额交易模型之间的异同。

区块链系统

像比特币[37]和以太坊这样的区块链系统包含许多计算节点,如矿工节点和全节点。交易本质上是状态的逐渐更新,由区块进行确认和携带,而区块由矿工创造。区块的验证涉及到一个数学难题(也称为 (proo-of-work, PoW)),它在计算时比较困难,但是很容易在网络中验证。矿工们互相竞争,第一个解开谜题的矿工将获得奖励和创建一个新区块的权利。在创建下一个区块之前,新创建的区块必须在矿工和全节点之间充分传播。由于网络延迟,其他矿工可能仍然在不同的块上工作,并且在链上添加新区块而将链分散到不同的路径。链的分散称为叉,不在主链中的区块称为孤立块。增大区块大小(更高的传播延时)或减少出块间隔,可能导致更多的孤立块,甚至在极端情况下(例如孤立块比例率> 50%)会阻止系统收敛到单个最长的链。我们将在第8节详细讨论相关研究。

我们总结了使用共识协议影响区块链系统整体性能的其他方面:

共识:共识协议需要的顺序的区块创建和验证是可扩展性的主要挑战,这受限于上面分析的吞吐量。

  • 通信:需要通信的信息包括未确认的交易和新创建的区块,这些信息在所有矿工和全节点之间交换,并且会受到本地带宽的限制。
  • 存储:链中所有已接受的区块都需要持久地存储在每个矿工和全节点中,它们与本地磁盘空间有关。
  • 状态:整个网络的全局状态,例如每个地址的余额和智能合约状态,由每个矿工和全节点维护。它们受主机内存大小的限制。

 可扩展的区块链设计必须考虑所有四个方面。

 

和PoS

如上所述,在比特币和以太坊等主要加密货币中,为保持每个区块的一致性,PoW要求矿工进行高强度运算的验证。这易操作产生了巨大的电力消耗,但它为加密货币设定了基本的相应的现实世界价值。

相反,PoS以通常依赖于节点的利害关系(财富)的确定性方式选择区块的创建者。现有PoS系统采用不同的方法产生领导人选举的随机性,以保证权力分散和安全[22,7,45,18]。虽然在本文中使用PoW,但是我们的方案与每个共识组使用的实际协共识机制是无关的。关于PoW和PoS的最新研究的详细讨论请参阅第8节。

和账户/余额

加密货币中有两种主要的交易模型。前者是未使用交易支出(Unspent Transaction Output, UTXO)模型,其中交易使用以前交易的输出,并生成可以在未来交易中使用的新输出。在utxobbased系统中,用户或帐户可能有多个UTXOs。当用户想花钱时,她使用一个或多个UTXOs来支付话费,并可能得到一些零钱作为新的返回的UTXOs,比特币和许多区块链系统都使用这种模型[11,32,23]。后者是账户/余额模型,类似于银行账户。在批准交易之前,银行需要检查账户余额是否能支付成本。以太坊使用了该模型,因为该模型被认为比UTXO更好地支持智能合约[6]。

本系统基于简便性使用账户/余额模型,使得一个付款帐户和一个收款帐户可以执行任意金额的交易(而不是在双方都使用多个UTXO)。此外,可以将余额扩展到更复杂的状态,以支持可编程的应用程序逻辑。账户/余额模型的另一个重要好处是,交易可以任意携带状态的逐步更新,而UTXO交易只能携带完整的状态。这大大节省了token不可替代、(例如以太坊的ERC-721 token)状态是一组独特标识符的应用程序的交易大小。

系统设计

在深入讨论细节之前,让我们首先检查一下系统的高层架构,该架构用于处理涉及来自不同共识组的两个用户的交易,即共识组A和B,如图1所示。

在这种情况下,取款操作ρ只与共识组A有关,由共识组A的矿工所处理。如果账户余额满足取款操作,相应的t+1区块上的交易将被矿工打包创建,并且仅仅添加在共识组A中的链上。在这之后,进行接力交易的存款操作Φ从共识组A前递到共识组B。不管目标共识组B内账户余额有多少,这个只与B状态有关的存款操作Φ将一直被执行。一旦该接力交易被共识组B中的另外一个矿工拾起打包,该操作Φ将会被执行,结束整个完整的交易过程。

分片与命名

在我们的系统中,帐户或用户通过其地址表示,即,其公钥的固定大小哈希值。我们的系统将用户地址空间以固定的、确定的方式统一划分为个共识组,每个共识组由分片大小k和共识组索引{0,1,…,2k-1}uploading.4e448015.gif正在上传…来标识。

给定分片大小k,用户的共识组索引可以很容易地导出,即,计算其地址的前k位。发起交易的共识组索引由付款人的地址决定,而接力交易的共识组索引由收款人的地址决定,每个区块由<s,k,h>唯一指定,h是链的高度,分片大小k定义了共识组的数量,进而决定了整个网络的吞吐量和算力。为了简单起见,下面的讨论在一个假设固定的k下进行。。

在本系统中,全节点加入swarm来广播新的交易,并从其他全节点(包括矿工)接收区块,swarm是参与备份相同数据集的一组节点。在比特币或以太坊中,只有一个swarm,每个全节点复制相同的数据集,包括所有区块和交易。在我们的系统中,为了不同的目的建立了多个群。一个分布式哈希表(DHT)用于swarm寻址和swarm中节点的发现。细节将在第7节中描述

我们的系统有一个用于备份所有共识组的最少公共信息,由所有全节点组成的全局swarm。另一方面,大多数通信发生在由属于特定共识组的全节点组成的共识组特定swarm中。在每个swarm中,参与的全节点是稀疏连接的,并使用gossip协议广播消息。与共识组相似,共识组特定swarm也可以通过共识组索引s和分片大小k来识别。

孤立的识组内工作负载

一个全节点,或者一个矿工,将有一个永久的随机初始化的标识符,它决定节点所进行工作的特定共识组。通过地址空间划分,在每个共识组内分别建立一个区块链,矿工通过PoW与同一共识组的其他矿工竞争,并验证来自自己共识组内的交易。全节点将忽略接收到的不属于其共识组的任何区块或交易,尽管这些区块或交易不太可能接收的到。因此,与交易验证和产生链相关的计算和存储在共识组之间是独立的:(1)一个矿工只对他选择参与的共识组内发生的交易负责;(2)任何全节点只记录自己共识组内用户的余额。随着整个网络的增长,更多的共识组将会创建,从而确保单个节点上的计算和存储负担始终处于合理的水平。对于一个全节点,网络中低门槛的准入机制和操作难度,对于保持区块链系统的去中心化和鲁棒性是至关重要的。

跨共识组开销的最小化

在区块链系统中,大多数通信用于备份未经确认的交易和广播携带已确认交易的新块。在我们的系统中,这种通信只在共识组内的节点之间执行。我们的系统在每个节点上维护一个分布式哈希表(DHT),在得到一个未经确认交易的共识组索引或一个前递区块时,系统基于本地DHT路由表选择拥有相同共识组索引的节点,并通过gossip协议(使用于比特币和以太坊)给这些节点发送交易和区块,这孤立了每个共识组内大多数的通信。对于跨共识组交易,我们的系统只将接力交易发送到目标共识组而不是整个网络中。此外,除实际确认的交易外,用于产生链的最少数据将在所有共识组中备份。我们将在下一节中讨论这个问题。

 

高效的跨区域原子性

我们将每个区块分为两部分: chaining-block,用于记录链的基本信息以及确认pow, transaction-block携带已经确认的交易信息。

如图2,一个chaining-block,携带区块的(metadata)元数据,包括pow计算出的nonce值,一个指向前驱区块的指针,一个记录已确认交易信息的merkle tree的根。除此之外, chaining-block把所有本区块中初始交易所产生的的接力交易列表提供给树根,这将被用于接力交易在其他共识组的确认。

Transaction-block记录交易列表,只会在共识组的全节点中复制和储存(如比特币、以太坊这些已经存在的系统)。与交易需要的上百kb信息对比,chanining-block只有一个固定大小为100b的数据结构,无论在交流还是存储中,都只是一笔微不足道的开支。

对于一个包含付款者a的取款操作以及存款者b的存款操作的初始交易,当ab来自同一个共识组的时候,操作将会很快完成。当ab来自不同的共识组时,我们介绍一对两阶段操作机制,将包含向目标共识组存款的接力交易产生、前递。图2展示的跨共识组支付时,数据结构层面上的操作情况。

 

A共识组的交易确认和前递:

  1. 当矿工在付款者a的共识组构建一个区块时,未确认的交易<ρ,a,Φ,b>被拾起
  2. 如果a的余额不比转账数量小,初始交易被确认。如果余额不够,交易会标记为无效,标记交易终止并且被写入区块中。
  3. 除此之外,chaining-block和transaction-block构建,拥有包含a到b这一笔交易在内的一些列已确认的交易。
  4.  矿工基于这些已确认的交易寻找pow问题的解。
  5. 当pow问题找到解,chaining-block向全局进行广播,同时transaction-block在当前共识组中广播。
  6. 入组的交易被执行并且结算。
  7.  执行跨共识组的取款交易。
  8. 每个跨共识组交易产生一个将要被发往目标共识组(如收款者b的共识组B)的出组接力交易Ψ:=<Φ,b,γ>.

 

B共识组对接力交易的处理:

  1. 当矿工在收款者b的共识组构建一个区块时,未确认的入组交易Ψ:=<Φ,b,γ>被拾起
  2. 矿工将入组交易对比其产生区块进行验证。如果无效,则跳过后续操作。
  3. 矿工构造新的chaining-block和transaction-block,包括了入组接力交易<Φ,b,γ>
  4. 当pow问题的解被找到时。
  5. 执行存款操作Φ,结束交易<ρ,a,Φ,b>

如图2所示,transaction-block只在本共识组中复制和存储,正如在A、B两组中。接力交易Ψ在产生共识组A中生成,并且只被发送到,目标共识组B。每个只有大概100比特的chaining-block将会在所有共识组中备份。

 

检验

交易的检验

当共识组b的矿工接收了一个来自共识组a的接力交易,为规避恶意攻击,他需要进行确认。如图2所示,一个前递的交易Ψ:=<Φ,b, γ>,包含确认数据γ:Υ≔ <s,k,t,p,{h_q}>uploading.4e448015.gif转存失败,位置指针p表示了在产生区块的跨界接力交易列表中的位置,merkle树路径hq表示所有从根到入口的路径上兄弟节点的哈希值,此外用共识组标签s,分片规模k,高度t来确认原始区块。

矿工将基于merkle tree路径hq和交易信息<Φ,b>本身重新计算Merkle树的根,如果重新计算的merkle树根与产生区块匹配,且产生区块在zoneA的链上,则说明验证成功。需要注意的是,{hq}中没有兄弟节点间的关系,这些需要从指针p中推出。

 

区块的验证

在接受一个已经全网广播的区块时,一个全节点需要验证区块以抵御恶意攻击。在我们的系统中,一个全节点需要验证三种交易。

  1. 在各自共识组中确认了的初始交易
  2. 从其他共识组来的入组接力交易
  3. 前往其他共识组的接力交易

为节省全节点的存储空间,前两种交易被嵌在transaction 区块中,同时可以从确认的初始交易列表中获得出组接力交易信息。

节点通过将已确认交易与目前用户状态比对来进行验证,拒绝任何包含非法交易或无法配对的初始/接力交易的区块。入组接力交易将会通过与产生区块信息比对来验证,如4.1节所示,这一过程也会通过两次验证所有出组接力交易列表的merkle树根,来验证所有的出组交易是否如预期那样创建,这里面假设出组接力交易和已确认的初始交易是严格有序的。。注意,chaining-block中只记载了merkle树根,而不是出组接力交易本身

 

最终原子性

一个涉及支出和存款两部分的交易操作,可以原子性的保证全局账本的正确性。在存在的区块链系统中,例如RSCoin [11] and OmniLedger,两阶段有着已知的有锁/无锁交易费用的确认操作被用来保证操作的原子性。

在我们系统的跨共识组交易中,允许取款操作与其他交易交叠先进行,而相应的存款操作晚一些执行,以此来达到当取款操作确认后,存款操作再最终执行的效果。这样的原子性,我们叫做最终原子性。我们乐观的估计,接力交易带来的取款操作,等到有想要赚取交易费用的良好表现矿工出现时才终于被拾起。我们的设计保证通过合理充足的交易费用划分,接力交易不会被区别对待。

理论上,存在创造不确认任何正常交易或者接力交易的空区块的不良表现矿工,这样的情况下,通量将会受损,且直到一个良好表现的矿工赢得了创造区块的机会,最终原子性不会被履行。在比特币和以太坊的历史上中,创造空区块是存在的,尽管很少。

新产生的出组接力交易被在产生共识组中创造区块的矿工,自动地前递到他们的目的共识组中,当接力交易在目的共识组中得以备份时,在被矿工捡起之前是不会过期的,除非他的初始交易被确认无效,例如成为分叉情况下的孤块(这一部分我们稍后讨论)。

如果一个接力交易被极其偶然的遗失,可以由产生共识组中的任何全节点基于产生它的区块重新构造。在重新开始备份重构造的接力交易时,不需要额外的验证或者共识。

在存在的区块链系统中,一个支付交易在被打包上链时就对收款者可见(首次确认),它将在添加n-1个连续的区块后被再次确认。相反的,本系统中,当一个接力交易被前递给收款者的共识组并且产生区块可知时,它将对收款者可见时,一个跨共识组交易可以被收款者看见。根据最终原子性,当初始交易被确认n次,接力交易获得第一个确认时,交易被认为最终确保安全。因为两个共识组的矿工分开工作,初始交易的n个确认与延时交易前递和第一次确认会重叠。这样,最终原子性没有额外的延时,在本文7.3也会介绍这一部分。理论上,当接力交易等待矿工拾起的时间过长时,额外的延时也会发生,换而言之,这种延时会在等待拾起的时间比初始交易的n次确认更久时发生。

 

分叉的解决方案

在pow的共识网络中,矿工很有可能在同一高度创造两个甚至更多的区块,这就是分叉现象。在成功的分叉解决方案中,最终一次会只接受其中一个区块,剩余的被当做孤块舍弃掉。在比特币网络中应用最长链原则解决分叉,以太坊中则使用幽灵协议。我们选择在共识组中使用幽灵协议,是因为其在分叉率很高时依然非常可靠。

在每个共识组中,分叉方案如之前的单链共识系统中一样被单独使用,一个区块可能存在下面三种状态:

  1. 可靠的:无分叉,且区块在被使用的路径上。
  2. 解决的:区块在一条处于竞争状态的路径上。
  3. 孤块:区块位于被舍弃的路径上。

当多个区块被挖掘和添加时,解决分叉是一个连续的操作,一个先前可靠的区块可能接下来变成孤块或未解决的,反之亦然,一个未解决的或者孤块也有可能后期变成可靠的块

根据最终原子性,一个共识组的分叉解决方案的结果,将会影响前递到其他共识组中确认的接力交易的有效性。接力交易的确认与原生区块的证明密切相关。如果原生区块在分叉解决后不再可靠,它的验证将会失效,并且反过来它产生的接力交易也会无效化。

 

事前确认

一个未确认的接力交易直到它的原生区块成为可靠状态时,才会被纳入新产生区块的考虑在此之前,它都会停留在未确认交易集中。

事后确认

如图3共识组a所示,区块a开始时可靠,然后变成未解决状态或孤块,同时不幸的是,a产生的接力交易x已经在共识组B的区块b中确认。这种情况下,b不会被无效,只有接力交易x被无效。共识组 B的账本状态需要跳过所有无效的接力交易,通过执行创世区块后的历史区块上的交易来重构。实际上,状态重构会被状态检查点加速,只有附近区块上的操作会被重新执行。

 

更复杂的交易无效情况

在接力交易x失效后,有一种更加严重的情景:一系列以接力交易x的状态更新为基础的确认交易失效了,如图3 的例子,接力操作x把u个token放在区块b,此时零钱变成+u。随后一个交易y在区块c中被确认,并且取出v个token。

如果接力交易x是无效的,交易y是一个跨共识组的交易,区块C将会被无效化,且其后面的区块也会被抛弃,为避免这一情况,矿工将会把入界交易信息延迟接力λ块再进行验证、执行。

这样,交易y直到区块a之后已经收到了至少λ个确认的区块d才完成确认,这将有效避免上述情况。

假设新的区块是b,正常状况s是通过完成所有创世区块到b的操作创建的,对于矿工,创建一个执行所有从创世区块到b-λ区块中操作的,以及b-λ+1到b区块非存款操作的状态,当要把未确认的跨组交易放入区块b+1时,要必须对两种状态都有效。

 

保护每个共识组安全性

在早些阶段,挖矿都是个人行为,并且算力很小。在这种情况下,随机的基于本地地址的划分共识组是安全的,因为此时没有矿工拥有超过百分之五十的算力。专业的矿场通过占有更多的算力,以及支付稳定、频繁的费用联合个人算力,逐渐主导挖矿算力。在有n个共识组的本系统中,理性的矿工会理想化的将所有算力分散到不同的共识组中,使得收益最大化。最终,这将使得全网H算力的倾向于在所有共识组中平均分布,每个共识组中的算力将会是H/n,当一个恶意的挖矿设备聚集T算力在某一个共识组上时,只有T>H/N*50%时会成功,显然在n很大时在,该阈值会低的无法接受。

为解决这一问题,我们提出连弩挖矿机制,使得一个矿工可以通过解决一个pow问题,在多个共识组中创造更多的区块。这保证每个组中的有效算力接近等于全网中的物理算力,当多数矿工接受连弩挖矿机制时,每个组中的攻击阈值将会提升到接近50%。

除此之外,连弩可以节省解决pow问题上的资源,使得区块的产生更有效率。但是,正如pow机制本身,连弩机制的安全性由互相竞争挖矿决定,如果攻击者控制了全网百分之五十以上的算力,安全性将难以保证。归根到底,防御能力由有多少算力参与pow求解决定。

 

连弩挖矿协议

连弩挖矿允许矿工使用一个pow的解在不同共识组里创造多个区块,但是每个共识组中不多于一个。这种情况下,图4的batch-chaining-block会取代chaining-block,并且在所有共识组中如图2备份,矿工可从根据IT资源的容量,从序号b开始的n个组,或所有组中开始连弩挖矿,

矿工将在所有涉及到的n个共识组中,收集n个区块头ai进行交易验证。没有连弩机制时,如在比特币和以太坊系统中,一个矿工需要找到n个随机数,每个都满足hash(<Ai,  η_i>)uploading.4e448015.gif转存失败 ,τ代表pow的目标,决定了挖矿的难度,<通过将哈希值看做一个足够大的整数进行比较大小,通过连弩挖矿,矿工只需要找到一个单独的随机数,满足hash<h0,C,  ηb><τuploading.4e448015.gif转存失败 ,C是batch的规模(图4中C),h0是这一个batch中所有下列区块头生成的merkle树的根:<A0,A1,…,A_{n-1}>uploading.4e448015.gif转存失败这里假设pow的目标在所有涉及的共识组中是一样的,我们将在下一节讨论他们都不同的情况。

每当这个随机数找到,各个共识组独特的batch-chaining-block将会构建,并且发送到相关的共识组中。正如图4中所示,每个共识组中, batch-chaining-block都会带着一个区块头(A)。它的merkle树的路径{hj}(B),batch的规模(C),以及找到的pow解,这些参数恰好可以重新计算式子3,验证pow。我们的系统不会清晰的记录merkle树路径上的兄弟节点,但是可以从s-b的batch列表中推出这些关系。在这种方法下,共识组的标签s与batch中区块列表的偏移互相结合,保证矿工一次只能在batch中涉及到的一个共识组中,创造一个区块。

在每个共识组中,全节点和矿工们在接受新区块时,平等对待batchchaining-blocks和chaining-blocks。他们选用相同的方法发现和解决4.3中提到的分叉,一个共识组中的链在不同高度下可包含batch-chaining-blocks和chaining-blocks

连弩挖矿与合并挖矿有相同的内核,都是可以解决一个pow问题挖出多个块,但是合并挖矿为不同的目的设计,主要为了在较小的算力下也能保证区块链的安全性。连弩挖矿主要用于当算力在不同共识组分散时,能够放大有效算力,并且其以相同的角色和相等的算力在不同链上作用,而不是一条父链和辅助链。连弩挖矿强行保证每个共识组出一个块,导致了不同的数据结构和履行。

 

共识组内的独立确认

当已找到随机数值的batch-chaining-block在每个共识组中不同,并且被分开发送后,连弩挖矿已经为batch中的区块头解决了pow问题。每个共识组的batch-chaining-block将会被确认并且独立接收。一个区块可以成为孤块或者失效,但是这不会影响其他块的接受和确认。

因为验证是独立进行的,系统中允许一个batch中混杂着多个pow目标。batch-chaining-block 的构造和5.1中一样,但是它允许在每个区块头中有不同的pow目标。在计算batch pow的随机数,可能一些有着较容易pow目标的区块已经满足条件,但是其他还没有。这些已满足条件的共识组的batch-chaining-block会马上组建,无论其他共识组的求解情况如何,batch-chaining-block会立刻发送到自己的共识组中,。被满足的区块会被从chaining-block的列表中剔除,用接下来的其他候选区块替代。Batch pow的随机数解谜问题将会随着等式3中h0的更新变成一个新问题,因为寻找不同共识组中满足条件的随机数是独立且随机的,这些更替不会减少挖矿的效率。

 

配挖矿算力的重新分配

这一节将说明,为什么对于连弩挖矿,攻击一个共识组和攻击全网一样困难,本系统将和比特币以太坊拥有相同的攻击阈值。

我们用哈希速率去描述对于产生新块的速度是很重要的算力,在一个有个共识组的网络中,是所有参与连弩挖矿的矿工们的物理哈希速率,是不参与的矿工们的物理哈希速率。则每个共识组中有效的哈希速率可以计算得到:

等式5

如果一个恶意节点可以在任何共识组中获得超过/2的哈希速率,他可以控制这一共识组,因此,每个共识组中的攻击阈值,可以由一个恶意节点获得的哈希速率比上全网哈希速率得到:

等式6

当挖矿设备主导了全部的哈希速率时,这一比例将会收敛到50%。例如,在一个挖矿设备贡献99%的哈希速率的256共识组的网络中,,一次成功的攻击需要全网中49.5%的物理哈希速率。在目前比特币的网络中,100%哈希速率由挖矿设备贡献。

为最大化单个pow解的奖励,,专业的挖矿设备将参与到所有共识组中寻找随机数,并且希望从所有组中获得报酬。连弩挖矿实际上因为一个矿工参与到了多个共识组中,从而放大了矿工的算力,放大的算力被平均分到了所有涉及到的组中,这样一个有效的算力放大帮助诚实的矿工将算力分布到所有共识组中,但是不会对以单个共识组为目标的攻击者产生帮助。

 

规模化的挖矿系统

比特币或者以太坊的挖矿系统是分散式系统,并且有成百上千的由gpu asic联合起来着眼于哈希解谜的挖矿设备,此外还有少数的pc服务于真实的交易确认和区块建造。

在本系统中,一个挖矿系统希望可以同时监视多个共识组。网络中的分割方案自然的给了同时观察大量共识组的挖矿设备一个规模化的解决方案。如图5所示,除了pow联合挖矿的群组,此外,还有独立发现新区块、确认交易、构建候选区块头ai的全节点组成的群组。当ai在任何共识组i中更新了,ai将会被发送到图5中的mining coordinator。区块头列表组成的merkle树将会被mining coordinator重新计算,更新后的树根h0将会被在所有pow联合挖矿中广播。这样的设计提供了一个示例,并且说明,一个规模化的挖矿系统如何在专业的挖矿设施中实行和操作。

 

讨论

热点单地址

某一个地址包含了大量的交易这种情况是很有可能的,比如说一个大的加密货币交易所的存款地址。第7部分讨论的工作负载中,地址0x3f5CE5FBFe3E9af3971dD833D26bA9b5C936f0bE 作为收款方,其交易量超过总交易量的2% , 这个地址是Binance(一个顶级加密货币交易所)中的一个存款地址。因为在我们的划分方案中,单个地址是最细粒度的单位,目前,我们的系统无法将这样的工作负载进一步划分到多个组当中。

实际上,这种 “热点单地址” 问题可以通过联合上层的应用设计就很容易的解决。比如,应用或者用户可以在不同的组中分配多个存款地址,从而实现负载均衡。机构运营商可以公布一些存款地址的列表,钱包应用程序自动选择一个随机地址,如果可以的话,甚至可以是一个组内的地址,用来转账。因此,可以利用多个组的交易吞吐量。

激励和费用

我们遵循了比特币的激励模式,在每个组中按阶段减少奖励矿工的 coinbase,最终的加密货币总供应量保持固定。交易费作为一个参数,由发出交易方设置,它通常基于最近确认交易的平均费用。矿工一般会基于交易费去优先处理未确认的交易。

对于跨组交易,我们引入了费用分摊机制,这将同时激励初始步骤和接力步骤中对交易进行处理的矿工,以便接力交易和普通交易一样,在交易费上有同等的优先级。对于一笔简单的交易,交易费可以等分。对于有可编程交易逻辑的复杂交易来说,交易费的划分可以基于每步中工作负载的估值,类似于以太坊中gas的计算。

对于跨组交易广播,我们没有引入额外的费用。乐观的是,我们希望这样的任务由整个网络的所有全节点和矿工自愿完成,因为在比特币和以太坊网络中,自愿传播组内交易都工作的很好。对于跨组交易,在构造区块时会比组内交易花费更高。我们建议跨组交易的发送方设置两倍或甚至三倍的交易费。

我们鼓励连弩挖矿,对于使用或者不使用连弩挖矿生成的区块提供相等的coinbase奖励。这样一来,给定固定的物理算力,连弩挖矿的收益和矿工参与挖矿的组数是成正比的。专业的矿工可以同时在所有组上挖矿,这样可以提高了整个网络的安全性。

我们没有对生态系统的中的激励机制和经济效益进行定量分析,因为这超出了本文讨论的范围。

支付以外的泛化

到目前为止,我们的讨论都是基于存取款的范例,这可以很好的服务以支付为中心的场景,比如比特币。然而,为了处理复杂交易逻辑,和以支付为中心以外的应用,很有必要去扩展交易模型。为了这个目的,首要的挑战就是正确处理普遍存在的接力交易,并保证原子性。我们将存取款范例扩展到一个更通用的带有可编程交易逻辑的模型,如附录所示。

我们提出的可编程交易逻辑支持加密货币的可编程发行和转账,以及用户定义的有形和无形令牌,类似于以太坊上ERC20/ERC721令牌。它也支持其他一些更复杂的应用,比如域名注册系统。我们的方法要求跨组的交易可以在单个组中被验证,并在一步不可被取消的接力交易中被完成,不支持多对多支付的应用。可以被扩展为不可取消的接力交易和多步接力,这些改进将作为我们未来的工作。

实验结果

我们的系统使用C++实现。加密算法基于Botan cryptography library (v1.11)和Intel IPP Cryptography library (v7.1) 实现。使用RocksDB (v4.11) 存储归档区块和交易。我们实现了Mainline DHT和swarm formation facilities peer discovery ,前者用于P2P路由,后者用于全局swarm和每组的swarm。

我们通过全网重放 Ethereum 中,从头至区块高度5867279的完整 ERC20 历史交易记录,对该系统进行了评估,其中包括1650万个唯一地址和7580万笔交易。我们的系统部署在包含1200个虚拟机的分布式环境中,每个虚拟机都为8核和32GB内存。这些机器被均匀地分布在15个可用组中,用于测试真实世界中的跨国家延迟。在测试网络中,我们将端到端峰值带宽限制为30Mbps,测量的端到端平均延迟为102.48 msec。每组中,我们将块大小限制为32KB,目标设置为15秒创建块的间隔,在一对一的令牌转账中,大约为15.6 TPS。每组中的平均孤块率是8.3‰,这与组的个数相互独立。在这样一个测试实验平台上,我们的系统支持48000个区块链节点。

可伸缩性

我们首先评估3.1节中介绍的划分机制是否能够平衡组之间的支付数量。我们改变分片规模 k 去生成不同数量的组,例如,设置 k 为4,5,8,分别得到16,32,256个组。图 7说明了在不同分片规模 k 下,每组中处理的交易数量是平衡的。然而对于存在的热点单地址,可以进一步按照6.1节中讨论的进行优化。

我们通过使用不同数量的组来测量系统的实际吞吐量,从而评估可扩展性。当增加组数量时,我们固定每组中的节点数,比如24个节点,平均每个组中有12个矿工。图6 表明测量的TPS随着组数量的增加而扩大。该系统具有线性可扩展性,在2048个组的情况下,可以达到11694.89 TPS。唯一的例外是将组数量从一个增加到两个。由于接力交易的开销,使用两个组相对于一个组的性能提高为1.88×。

开销

尽管随着组数量的增加,我们系统的吞吐量呈线性扩展,但跨组的接力交易实际上会引入开销,放大了交易的数量,以及需要被存储和复制的数据总量。图8表明随着组数增加,跨组的交易占比也会增加。当我们的实验中有超过64个组时,几乎所有的交易都会产生一个接力交易。这种放大使得交易总量最多增加两倍,不会减弱吞吐量的可扩展性。如图6所示,当多于64个组时,吞吐量会持续增加。

图9显示了整个网络中数据复制和存储的放大大小。首先,当增加组数量时,几乎所有的交易都会导致一个接力交易,比如这里描述的超过64个组时。交易被放入块中,并在原始组中进行持久存储;接力交易在目的组中存储,从而使得交易数量加倍。其次,与一个块中的交易(需要数百个千字节)相比,具有数十字节的chaining-block的重要性要小得多。然而,因为 chaining-block被复制到所有的组上,它们在整个网络中存储的总大小将随着组数量的增加而增加。如图所示,2048个组中,它们的总大小达到十千字节,占交易总大小的6.2%,这在现实中是可以接受的。

确认时延

每个节点的平均连接数会影响网络中的数据传播速度,进而影响区块链的确认时延。图10显示了经过的时间和到达的节点数的累积分布函数。我们将每个节点的平均连接数配置为16、32、64、128,并观察到连接数为128时能达到最快的传播速度。我们的实验中,每个全节点平均连接68.5个节点。

如4.2节中提出的,当区块在网络中被节点间复制时,其包含的交易第一次被确认;n个区块以后,交易被确认安全。比特币中n设置为6,区块生成的间隔为10分钟,需要1个小时去确认交易安全。我们的系统中,在原始交易到达n个确认之前,接力交易肯定已经上链,因此没有额外的确认时延。图11展示了接力交易第一次确认的时间。当组数大于30时(几乎所有的交易都有接力交易),时延在13到21秒之间。因为我们将出块时间配置为15秒的间隔,原始交易在90秒(n=6,和比特币一样)后被确认安全,这个时间足以包含接力交易的确认时延。

吞吐量和孤块率

我们还评估了本系统在不同块大小和出块间隔下的TPS和孤块率,如图12。在本次实验中,我们把组的数量固定为256个。正如预期,当我们的系统增加区块大小或者减小出块间隔,几乎都还是会产生线性的TPS,因为我们系统对于每个组中实际配置的中本聪共识实例都是中立的。然而更大的区块大小或者更小的出块间隔都会导致更高的孤块率,致使区块被浪费。在一些典型的情况下,为了产生高TPS和低孤块率,我们都配置为合理的区块大小和出块间隔,比如32KB,15s。

转载地址:http://erqnn.baihongyu.com/

你可能感兴趣的文章
SSM项目整合——05商品页面编辑与更新功能实现
查看>>
SSM项目整合——06文件上传功能实现
查看>>
Form表单提交后获取下载文件到服务器以及获取文件之外的参数数据
查看>>
SSM项目整合——07OSCache缓存讲解
查看>>
SSM项目整合——08页面展示缓存使用
查看>>
SSM项目整合——09freemarker讲解
查看>>
SSM项目整合——10SpringMVC拦截器
查看>>
SpringMVC异常处理
查看>>
写给初学者的Maven教程——01Mave安装与概念
查看>>
写给初学者的Maven教程——02Maven常用命令
查看>>
写给初学者的Maven教程——03从一个项目引用另外一个项目
查看>>
写给初学者的Maven教程——04Maven坐标讲解
查看>>
写给初学者的Maven教程——05依赖管理
查看>>
写给初学者的Maven教程——06Maven创建web项目
查看>>
写给初学者的Maven教程——07用Tomcat插件来跑web项目
查看>>
写给初学者的Maven教程——08使用jetty
查看>>
写给初学者的Maven教程——09Maven的继承
查看>>
写给初学者的Maven教程——10聚合项目
查看>>
入门使用Git
查看>>
Maven入门教程目录
查看>>