没有 Tendermint 的Cosmos，了解 Narwhal/Bullshark 如何实现更高的交易吞吐量
原文：Paradigm
随着越来越多的区块链系统部署到生产环境中，经常会遇到两个问题：
如何以高吞吐量和低延迟达成共识
如何在该共识之上构建分布式应用程序
解决这两个问题的一个系统是 Cosmos。 Cosmos 使用高性能 BFT 共识算法 Tendermint 和 Cosmos SDK 工具包，使开发人员能够在 Tendermint 之上启动自己的权益证明（PoS）区块链。
然而，Tendermint 是多年前构想出来的，从那时起，研究人员在 BFT 共识方面取得了长足的进步。
Paradigm 的许多人都对使用有向无环图 (DAG) 的高吞吐量和低延迟共识的最新发展感到兴奋，特别是 Narwhal 内存池，以及 Tusk 和 Bullshark 共识算法，等等。 （查看这些博客文章，更温和地介绍基于 DAG 的共识协议。）
Narwhal/Bullshark (N/B) 承诺更高的交易吞吐量和响应能力（意味着 N/B 的确认延迟是实际网络延迟的函数，而不是最终同步下假设的网络延迟上限）。相比之下，Tendermint 没有响应，因此它的延迟受到悲观延迟限制的瓶颈。由于内存池 (Narwhal) 和共识 (Bullshark) 之间的交互如何工作，N/B 的性能也不会像其他基于领导者的共识协议那样受到错误或恶意行为或网络故障的影响。
鉴于上述优势，我们想到：我们能否将 Tendermint 替换为 Narwhal & Bullshark (N/B)，同时以与 Cosmos SDK 堆栈的兼容性为目标？
在最近为期两天的内部黑客马拉松中，我们构建了一个概念验证来实现这一目标！为此，我们在 N/B 代码库上附加了一个小 shim，它一方面允许它“说语言”（API），一方面是 Cosmos 客户端，另一方面是 Cosmos 应用程序。这足以移植 Cosmos 文档中给出的一些简单的去中心化应用程序代码示例，以使用 N/B 而不是 Tendermint。
您可以在此处找到概念验证代码：https://github.com/gakonst/narwhal-abci-evm
Cosmos 堆栈如何工作？
要了解我们到底做了什么，让我们看一下 Cosmos 节点的解剖结构：
Cosmos 节点由一个 Tendermint Core (TC) 实例组成，用于与共识相关的所有内容，以及一个应用程序实例，该实例由我们想要去中心化其执行的有用逻辑组成。 TC 为最终用户客户端提供 RPC 端点（例如，用于提交事务，或用于查询应用程序的状态）。
TC 通过应用程序区块链接口 (ABCI) 与应用程序状态机的本地实例进行对话。就 ABCI 而言，TC 充当发起请求的客户端，而应用程序充当响应响应的服务器。一个简单的请求/响应对是“查询”。 TC 使用“查询”将任何最终用户关于通过 RPC 接收到的应用程序状态的查询转发给应用程序。
其他重要的请求/响应对将已达成共识的交易账本“交付”到应用程序，在那里它们被用作驱动应用程序状态机的输入。特别是，当一个新的区块以共识方式被确认时，“BeginBlock”被调用，带有区块元数据，然后是“DeliverTx”，用于区块中的每个事务，“EndBlock”再次带有区块元数据，“Commit”来持久化结果状态.请注意，由于所有 Tendermint 实例都在交易账本上达成共识，从而在对应用程序的 ABCI 调用序列上达成共识，因此应用程序状态机在网络的所有节点上同步复制。
我们做了什么
因此，挂钩到这个堆栈的一个自然点是删除 TC，并用 N/B 替换它，并增加一个 shim，它既向客户端提供 RPC 端点，又通过 ABCI 将共识分类帐传递给应用程序：
事实上，经过大约两天的黑客攻击，我们能够在 N/B 之上运行一个简单的 ABCI 应用程序，该应用程序由一个 EVM 执行环境组成，我们可以在其中发出交易并通过 TC RPC 查询其结果：
https://asciinema.org/a/DP9RN2FzEtIyndGQdFxdkHXen
这个演示共识网络由四个节点运行（每个节点都在 localhost 上运行），其 RPC 端点分别可通过 TCP 端口 3002、3009、3016 和 3023 访问。共有三个账户，Alice（初始 1.5 ETH）、Bob（初始 0 ETH）和 Charlie（初始 0 ETH）。 Alice 执行一笔双花，在两个不同的交易中分别向 Bob 和 Charlie 发送 1 ETH，这些交易分别获得端口 3009 和 3016 的节点的输入。请注意，只有一笔交易可以完成。最终，节点就在 Foundry 的 EVM 中执行哪个交易达成共识，并且应用程序状态在所有节点之间同步更新。更新反映在后续余额查询中。
结论
我们构建了一个原型 Cosmos/ABCI 应用程序，使用 Narwhal/Bullshark 作为共识算法而不是 Tendermint。
在这个过程中，我们了解到 ABCI 是非常特定于 Tendermint 的，尽管它希望更加通用。例如，它假设一个简单的区块链结构，在区块头中存在某些元数据（例如，前一个区块的状态根）。然而，最新的共识协议，无论是基于多个平行链还是 DAG，都不再适合这种简单的结构。
要超越概念验证阶段，还需要做更多工作：
基准测试和优化性能。虽然我们实现了一个概念证明，它成功地展示了 EVM 交易在应用程序中的交付和执行，但我们并没有对系统进行完全基准测试（即提供 EVM 执行的 TPS 数量），或者最大限度地减少开销，例如之间的通信共识和应用。我们将其留作未来的工作，希望还支持诸如 EVM 并行化之类的优化，以进一步提高吞吐量。
具有高性能共识、EVM 执行和以太坊 JSON-RPC 的交钥匙测试网/L1。我们构建的应用程序只使用了 Foundry 的 EVM，不支持 Ethereum JSON-RPC API。如果我们可以将 N/B 与 Foundry 的 Anvil 集成，那就太好了。
具体来说，RPC shim 会将新交易重定向到 N/B 以进行排序，并将所有剩余的 RPC 调用代理到 Anvil 的 Ethereum JSON-RPC。来自 N/B 的有序交易序列将被馈送到 Anvil（例如通过 ABCI 的 BeginBlock/DeliverTx/EndBlock/Commit），以在 Anvil 中驱动（修改为确定性的）锁步区块生产，复制 Anvil 的状态和它在所有参与者中的 EVM。结果可能是一个简单的交钥匙高性能测试网/L1，具有 N/B 的强大共识和 Anvil/Ethereum/EVM 的富有表现力的 RPC 和执行。与前面看到的 Cosmos 堆栈类似，在这个串联中，所有的网络逻辑都由共识层提供，而 Anvil 可以充当 EVM 运行时和状态持久层。
完整的 Cosmos 概念验证。我们构建了一个缩小范围的 ABCI 应用程序，我们只支持 ABCI 共识消息传递。为了支持完整的 Cosmos SDK 并展示完整的端到端集成，需要实现 ABCI 的其余部分（可能还有 ABCI++），需要扩展 ABCI/RPC shim（可能还有 N/B 代码库）的功能例如验证器集重新配置或轻客户端支持。
N/B 实现本身的改进。例如，我们使用的研究代码库没有提供 Bullshark 论文中描述的异步回退。
特别感谢 Zaki Manian、Lefteris Kokoris-Kogias、Matt Huang 和 Dan Robinson 对本文早期草稿的富有成果的讨论和评论，并感谢 Achal Srinivasan 提供的精美图表。