吞吐量和延迟之间的权衡
有人将每秒处理交易数（TPS）作为衡量协议可拓展性的标准。TPS 是对吞吐量的度量，人们存在一个误解——以为对它单独优化就可以实现共识可拓展性。共识可拓展性的解决方案必须同时关注 吞吐量 和 确认时延 这两个因素。
通过 成批处理 来提高共识的吞吐量（但提高延迟）很简单：只需要一天一次，而不用每隔几秒一次，就可以让人们就被批处理的所有数据的哈希值达成共识。显然，由于一天只达成一次共识，成本会被分摊，仅就吞吐量而言，共识过程就不再是阻碍实现拓展性的瓶颈了。显然，批处理虽然能提高共识协议的吞吐量，但也会提高交易确认的时延，并不是什么扩展共识协议性能的万灵丹。
PBFT journal version 一文充分地讨论了 BFT 状态机复制的延迟和吞吐量。
对基于 Nakamoto Consensus 的协议而言，有很多协议都试图增加吞吐量及时延，如：Bitcoin-NG、 Fruitchains 和 Prism。
性能和安全性之间的权衡
有人建议在更小的状态机副本小组内达成共识，以优化共识过程的性能。降低验证状态机小组的规模的确可以提高性能，但这是以降低降低安全性为代价的。所以，真正的挑战在于不减少参与状态机的数量同时提高共识过程的性能。
提高 共识协议的复杂性 有望鱼和熊掌兼得，例如：减少轮数，或者说 改变消息传递的复杂度，使呈平方级增长的消息数量可以变为线性增长。本文讨论了一些部分同步中的协议改进和同步中的协议改进。
可拓展性和适应性之间的权衡
基于 PBFT 视图范式的共识协议容易受到攻击者的适应性攻击（adaptive attack）。共识协议的安全性不仅和攻击者的规模（由状态机副本总数决定）相关，而且和对手的适应性能力相关。
处理适应性对手的协议通常会导致更高的成本，也会在可拓展性上遇到更大的难题。Algorand 建议用基于轮次的密码抽样来拓展拜占庭共识，使其免受适应性攻击者的攻击。这种方法的模拟结果看起来很不错。适应性对手可以使用 拒绝服务攻击（Denial-of-Serivice attack）来阻止系统推进。HoneyBadger 提出了第一个实用的 异步 BFT 协议——该协议在不做任何时序假设的情况下，也能保证活性。
避免对所有命令进行全排序
如果所有指令都相互依赖，那么除了对所有指令进行全排序外，别无他选。但是在许多工作负载中，指令不会彼此依赖和彼此干扰。举个例子，在某些情况下，A 给 B 支付的指令和 C 给 D 支付的指令就不会相互干扰；在这种情况下，我们没有必要浪费昂贵的共识资源为这两笔指令进行 内部 排序，没有理由让它成为系统的瓶颈。在 epaxos 非拜占庭模型中就采用了这种（不在所有时候都搞全排序的）办法。像 Avalanche 和其他基于 DAG 的协议，会通过允许并发提交互不干扰的指令来增加共识的吞吐量。
分片
抽象一点来看，分片是对状态和状态机副本集合进行 分区。每一分片控制状态的某个部分，且共识过程是由验证状态机总体的某个部分来完成的。这当然也需要一些跨分片交互机制。
以太坊的 “Sharding FAQ” （编者注：中译本见文末）资源正是一个很全面的资源。
分片是并行化处理 数据、共识 和 执行 这三大瓶颈的方法。实现数据和执行并行化的关键在于工作负载的低 状态竞用（contention）。从共识的角度来看，分片本质上就是在性能和安全之间取舍：不是用所有状态机副本去保障一个状态，分片技术创建了多个分区，每个验证者副本会各自保护它们自己的分区。
（如果状态竞用程度较低）划分许多分区会显著地提高性能。但是，因为每一分区的验证状态机都变得更少，安全性自然就降低了。
想了解使用分片技术，请参阅 Omniledger 和 Ethereum 2.0 。以太坊 2.0 计划将每个分区的低安全性和全局链的高安全性结合起来。就像 Layer-2 方案一样，低安全性的分片可以定期上传自己的状态到高安全性的全局链上，并将状态更新确定下来。这也是在安全性和延迟之间取舍——想获得高安全性，就得等待全局链的周期性敲定。
版权申明：本内容来自于互联网，属第三方汇集推荐平台。本文的版权归原作者所有，文章言论不代表链门户的观点，链门户不承担任何法律责任。如有侵权请联系QQ：3341927519进行反馈。
