当越来越多的区块链系统被部署在生产中时，有两个问题经常会出现：

1. 以高吞吐量和低延时实现共识

2. 在该共识的基础上建立一个分布式应用

可以解决这两个问题的一个系统是Cosmos。Cosmos使用的是Tendermint，一种高性能的BFT共识算法，以及Cosmos SDK，一个能使开发者在Tendermint之上启动自己的权益证明区块链的工具包。

其实Tendermint在很多年前就被设想出来了，这些年来，研究人员在BFT共识方面取得了巨大的进步。

我们Paradigm的许多人对使用有向无环图（DAG）的高吞吐量和低延迟共识的最新发展感到兴奋，特别是Narwhal mempool and the Tusk及Bullshark共识算法，以及其他。(查看这些博客文章，了解基于DAG的共识协议的更具体的介绍）。

Narwhal/Bullshark（N/B）承诺了更高的交易吞吐量和响应性（意味着N/B的确认延迟是实际网络延迟的函数，而不是最终同步下假设的网络延迟上限）。相比之下，Tendermint没有响应性，因此它的延迟被封闭的延迟约束所限制。由于mempool（Narwhal）和共识（Bullshark）之间的互动方式，N/B的性能也不会像其他基于领导者的共识协议那样，受到错误或恶意行为的影响，或受到网络故障的影响。

鉴于上述优势，我们想到一个问题：能不能用Narwhal & Bullshark (N/B)取代Tendermint，同时争取与Cosmos SDK stack兼容？

在最近为期两天的内部黑客马拉松中，我们建立了一个proof-of-concept（概念验证），居然就实现了这一目标。为此，我们在N/B的代码库中附加了一个小的shim，使其一方面可以 "说 "出Cosmos客户端的语言（API），另一方面可以说出Cosmos应用程序。这足以将Cosmos文档中给出的一些简单的去中心化应用代码实例移植到N/B上，而不是使用Tendermint。 

你可以在这里找到proof-of-concept（概念验证）的代码: 

  https://github.com/gakonst/narwhal-abci-evm 

Cosmos Stack是如何工作的？

为了了解我们到底做了什么，让我们看一下Cosmos节点的解剖结构：

一个Cosmos节点由Tendermint Core（TC）的一个实例和一个应用程序的实例组成，Tendermint Core（TC）负责与共识有关的一切，而应用程序的实例则由我们想要去中心化的有用逻辑组成。TC为终端用户客户提供RPC端点（例如，用于提交交易，或查询应用程序的状态）。

TC通过应用区块链接口（ABCI）与应用状态机的本地实例对话。为了ABCI的目的，TC作为一个客户端，发起请求，而应用程序作为一个服务器，以响应的方式回复。一个简单的请求/响应对是 "查询"。TC使用 "查询 "将通过RPC收到的关于应用程序状态的任何终端用户查询转发给应用程序。

其他重要的请求/响应对将已经达成共识的交易账本 "交付 "给应用程序，在那里被用作驱动应用程序状态机的输入。特别是，当一个新的区块在共识中被确认时，"BeginBlock "被调用，并带有区块元数据，随后是 "DeliverTx"，用于区块中的每个交易，"EndBlock "再次带有区块元数据，以及 "Commit "以保持所产生的状态。值得注意的是，由于所有的Tendermint实例都在交易账本上达成共识，从而在ABCI调用应用程序的序列上达成共识，应用程序的状态机在网络的所有节点上以锁步方式进行复制。

我们做了些什么？

与这个Stack挂钩的一个自然点是删除TC，并用N/B代替它，辅以一个shim，为客户提供一个RPC终端，并通过ABCI向应用程序提供共识分类帐：

事实上，经过大约两天的黑客攻击，我们能够运行一个简单的ABCI应用，包括N/B上面的EVM执行环境，我们可以通过TC RPC发布事务并查询其结果。

视频链接： https://asciinema.org/a/DP9RN2FzEtIyndGQdFxdkHXen 

演示的共识网络由四个节点运行（每个节点都在localhost上运行），其RPC端点可分别通过TCP端口3002、3009、3016和3023到达。有三个账户，Alice（初始为1.5ETH）、Bob（初始为0ETH）和Charlie（初始为0ETH）。Alice进行了一次双重消费，在两个不同的交易中分别向Bob和Charlie发送了1个ETH，分别输入到3009和3016端口的节点。请注意，只有一个交易可以做到这一点。最终，各节点就哪个交易在Foundry的EVM中被执行达成共识，应用程序的状态在所有节点上被同步更新。这个更新将反映在随后的余额查询中。

结论

我们建立了一个Cosmos/ABCI应用程序雏形，使用Narwhal/Bullshark作为共识算法而不是Tendermint。 

这个过程中，我们了解到ABCI是相当针对Tendermint的，尽管它的愿望是更加通用。例如，它假设了一个简单的区块链结构，在区块头中存在某些元数据（例如，前一个区块的状态根）。然而，最新的共识协议，无论它们是基于多个平行链还是DAG，都不再适合这个简单的套路。

为了超越proof-of-concept阶段，还需要做更多的工作：

对性能进行基准测试和优化。虽然我们实现了一个概念验证，成功地展示了EVM事务的交付和执行到/在应用程序中，但我们没有对系统进行全面的基准测试（即，提供EVM执行的TPS数字），或尽量减少开销，如在共识和应用程序之间的通信。这将会是我们未来的工作，希望也能支持优化，如EVM并行化以进一步提高吞吐量。

一个具有高性能共识、EVM执行和Ethereum JSON-RPC的testnet/L1交钥匙工程。我们建立的应用程序只使用Foundry的EVM，并不支持Ethereum JSON-RPC APIs。如果我们能将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 Stack类似，在这种串联中，所有的网络逻辑都由共识层提供，而Anvil可以只作为EVM的运行时间和状态持久层。

完整的Cosmos概念验证。我们建立了一个范围较小的ABCI应用，只支持ABCI共识信息传递。为了支持完整的Cosmos SDK并展示完整的端到端集成，需要实现ABCI的其余部分（可能还有ABCI++），这就需要扩展ABCI/RPC shim（以及潜在的N/B代码库）的功能，如验证器集的重新配置或轻型客户端支持。

对N/B实现本身的改进。例如，我们使用的研究代码库并没有提供Bullshark论文中描述的异步回退。

责编：Moon