作者:IttaiAbraham
翻译&校对:ViloaH&阿剑
来源：以太坊爱好者
如果有人很直接地问你：怎样才能拓展状态机复制系统呢？
你应该反问：你系统遇到的瓶颈是什么？数据？共识？还是执行？
1、数据：数据是将所有指令传输给所有状态机副本的载体。举个例子，如果一个区块包含1MB的指令，那么你就需要把1MB的数据发送给所有负责验证的副本。显然，这种情况下，系统的通道容量是系统可拓展的瓶颈。
2、共识：指令到达本地之后，状态机们就会参与共识协议。举个例子，如果一个共识协议需要两次消息往返，而参与验证的状态机分布在全球各地，那么，这里明显的瓶颈在——由光速和地球大小而导致的延迟。
3、执行：指令到达、共识在指令排序上达成共识后，副本需要执行指令。执行引擎是一个接受旧状态并应用指令来计算新状态的函数。又举个例子，如果执行需要许多密码学计算，那么很明显啦，这里的瓶颈就是副本要重复执行的密码学计算。
需要注意的是，这三个瓶颈不是追求一种折衷，也不是两难的困境，也不是三难困境。它们是彼此独立的。所有状态机复制系统的可拓展能力都受到这三种因素的限制。本文将介绍一些解决这些瓶颈的方案。
安全团队：0xDc4d开头EOA地址上有可疑活动，请及时撤销代币访问权限:5月12日消息，据CertiK监测，EOA地址（0xDc4d51D732a7C8E90727eb3628c89Ef655a25EC5）上发生可疑活动。如果用户无意中授予EOA访问代币权限，请及时撤销。[2023/5/12 14:59:14]
1.从数据上提高可拓展性
更好的网络解决方案
对比特币等密码学货币而言，扩展吞吐量的能力取决于减少延迟——因为某个矿工挖出的区块需要经过一定的延迟才能传播给所有其他矿工。像FIBRE、Falcon、bloXroute这些系统会通过使用专用通道来降低延迟，并使用前向纠错码来传播区块。提高数据可拓展性的另一个办法是通过内容可寻址网址来发现对等节点并访问内容。具体可参考Kademlia，它不仅启发了以太坊的RLPx编码规范，并在libp2p上得到了推广。
把数据迁移到layer-2
另一种思路是，既然瓶颈源于需要复制所有指令到所有状态机，那我不复制不就完啦！像Lightning、Plasma和其他Layer-2解决方方案都是如此——把中间命令传播给一个较小的半公开团体以减少数据复制、定期向整个系统报告总结。自然而然地，这种方法的不足在于：不复制所有数据会造成数据的可用性问题。而安全性依赖于每个拥有数据的半公开团体内至少有一个诚实参与者能及时地作出反应。
巴拉圭参议院批准一项加密货币法案，或利好当地加密矿企:7月15日消息，巴拉圭参议院通过了一项加密货币法案，目前仍需总统批准。该法案将允许加密矿工以有竞争力的价格使用产生的多余能源，并且在巴拉圭运营的加密公司将免除增值税。（Portal do Bitcoin）[2022/7/15 2:16:29]
2.从共识上提高可拓展性
吞吐量和延迟之间的权衡
有人将每秒处理交易数作为衡量协议可拓展性的标准。TPS是对吞吐量的度量，人们存在一个误解——以为对它单独优化就可以实现共识可拓展性。共识可拓展性的解决方案必须同时关注吞吐量和确认时延这两个因素。
通过成批处理来提高共识的吞吐量很简单：只需要一天一次，而不用每隔几秒一次，就可以让人们就被批处理的所有数据的哈希值达成共识。显然，由于一天只达成一次共识，成本会被分摊，仅就吞吐量而言，共识过程就不再是阻碍实现拓展性的瓶颈了。显然，批处理虽然能提高共识协议的吞吐量，但也会提高交易确认的时延，并不是什么扩展共识协议性能的万灵丹。
PBFTjournalversion一文充分地讨论了BFT状态机复制的延迟和吞吐量。
对基于NakamotoConsensus的协议而言，有很多协议都试图增加吞吐量及时延，如：Bitcoin-NG、Fruitchains和Prism。
性能和安全性之间的权衡
有人建议在更小的状态机副本小组内达成共识，以优化共识过程的性能。降低验证状态机小组的规模的确可以提高性能，但这是以降低降低安全性为代价的。所以，真正的挑战在于不减少参与状态机的数量同时提高共识过程的性能。
提高共识协议的复杂性有望鱼和熊掌兼得，例如：减少轮数，或者说改变消息传递的复杂度，使呈平方级增长的消息数量可以变为线性增长。本文讨论了一些部分同步中的协议改进和同步中的协议改进。
可拓展性和适应性之间的权衡
基于PBFT视图范式的共识协议容易受到攻击者的适应性攻击。共识协议的安全性不仅和攻击者的规模相关，而且和对手的适应性能力相关。
处理适应性对手的协议通常会导致更高的成本，也会在可拓展性上遇到更大的难题。Algorand建议用基于轮次的密码抽样来拓展拜占庭共识，使其免受适应性攻击者的攻击。这种方法的模拟结果看起来很不错。适应性对手可以使用拒绝服务攻击来阻止系统推进。HoneyBadger提出了第一个实用的异步BFT协议——该协议在不做任何时序假设的情况下，也能保证活性。
避免对所有命令进行全排序
如果所有指令都相互依赖，那么除了对所有指令进行全排序外，别无他选。但是在许多工作负载中，指令不会彼此依赖和彼此干扰。举个例子，在某些情况下，A给B支付的指令和C给D支付的指令就不会相互干扰；在这种情况下，我们没有必要浪费昂贵的共识资源为这两笔指令进行内部排序，没有理由让它成为系统的瓶颈。在epaxos非拜占庭模型中就采用了这种办法。像Avalanche和其他基于DAG的协议，会通过允许并发提交互不干扰的指令来增加共识的吞吐量。
分片
抽象一点来看，分片是对状态和状态机副本集合进行分区。每一分片控制状态的某个部分，且共识过程是由验证状态机总体的某个部分来完成的。这当然也需要一些跨分片交互机制。以太坊的“ShardingFAQ”资源正是一个很全面的资源。
分片是并行化处理数据、共识和执行这三大瓶颈的方法。实现数据和执行并行化的关键在于工作负载的低状态竞用。从共识的角度来看，分片本质上就是在性能和安全之间取舍：不是用所有状态机副本去保障一个状态，分片技术创建了多个分区，每个验证者副本会各自保护它们自己的分区。
划分许多分区会显著地提高性能。但是，因为每一分区的验证状态机都变得更少，安全性自然就降低了。
想了解使用分片技术，请参阅Omniledger和Ethereum2.0。以太坊2.0计划将每个分区的低安全性和全局链的高安全性结合起来。就像Layer-2方案一样，低安全性的分片可以定期上传自己的状态到高安全性的全局链上，并将状态更新确定下来。这也是在安全性和延迟之间取舍——想获得高安全性，就得等待全局链的周期性敲定。
3.从执行上提高可拓展性
共识和执行的分离是状态机复制系统的基本架构设计之一。分离的好处可参见Yinetal2003。在传统的状态机复制系统中，命令不仅要复制并传播到所有副本，还得在所有副本上执行。
在很多系统中，可拓展性的瓶颈是执行指令的成本。对SMR系统的一种主要拒绝服务攻击工段是发出合法的命令，让整个系统浪费时间在执行上。很多系统通过设计领域专用语言来避免攻击。比特币用比特币脚本，小心翼翼地限制每笔交易的计算复杂性。以太坊用gas机制来限制执行的复杂性，并用效率来激励人们对Gas的使用。
并行化执行
让状态机并行化执行也是一种提高执行能力的方法。当在区块中的大部分命令无状态竞用的情况下，这个方法是有效的。它的主要思想是设想一种在无竞用的条件下并行执行、在有竞用时维护安全性的协议，用该协议模拟出连续执行的结果。详情请参看Eve2012、Dickerson、Gazzillo、Herlihy、Koskinen2017和Saraph和Herlihy2019。
不在SMR内执行，使用经济激励和错误性证明来验证
在这类解决方案中，指令作为数据提交到SMR内，但是执行不是由验证状态机副本完成的。状态机副本仅充当数据可用性层。
不用副本来执行指令，而用经济激励机制——玩家可以通过发布债券来成为执行者。锁定了保证金的执行者都可以提交执行结果，而其他人可以通过提交错误性证明来举报执行人提交了不正确的执行结果。如果这份错误性证明是正确的，执行者将受到惩罚，而提交者将得到部分奖励。如果挑战者在错误性证明上说谎，那他的保证金就会大幅罚没。
实现高效挑战的协议起源于FeigeKilian2000，而Canetti,Riva,Rothblum2011沿着这条道路推进，最终演化成采用链上激励的TrueBitTeutsch,Reitwie?ner2017和Buterin’sOff-ChainOracles。如今，这种方法在名为optimisticrollups的方案中中得到进一步发扬。
不在SMR内执行、用简洁的证明来验证
在本方案中，指令同样作为数据提交到SMR中，执行同样不关验证状态机副本的事。副本只是作为指令的数据可用性层。
不同于用挑战游戏和错误性证明来验证执行结果，利用简洁的非交互式证明也是可以的。这些密码学技术允许验证者生成非常短的证明，同时对这些证明的验证在密码学上具有高度的可靠性和完整性。执行只能由同一实体完成。有了简洁证明后，验证状态机副本只需要验证简洁证明，而不需要重新执行长交易。Zexe用这个方法来建构了基于nano-kernel的证明系统，人们因此可以在UTXO中实现隐私交易。
Buterin论述zk-roll-up的文章和Ben-Sasson的podcast强调了这种拓展交易处理量的方法。详情请查看Buterin的视频，进一步去了解如何将隐私添加到简洁的证明中中。
这种简洁的证明有很多好处：验证证据正确性的成本非常低。而短处在于构造指令执行的证明通常比单单去执行指令的成本要高得多。还有一个坏处在于这些协议增加了大量的复杂性。此外，某些协议还需要繁复的受信任初始设置仪式。
需要注意的是，以上介绍的方法意在克服执行可拓展性的瓶颈，而不在改变数据可拓展性的瓶颈。
感谢
我们想借此机会感谢LingRen、KartikNayak、AlinTomescu、PratyushMishra、LouisGuthmann和JohnAdler。感谢他们给本文提供了富有教益的反馈。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。