Paradigm:更换Cosmos共识算法——抛弃Tendermint采用Narwhal/Bullshark

原文标题:Cosmos without Tendermint: Exploring Narwhal and Bullshark

原文作者:Joachim Neu,Georgios Konstantopoulos,Andrew Kirillov

原文来源:Paradigm

编译:Nicole,MarsBit Intern

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

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

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

声明:图文来源于网络,如有侵权请联系删除

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2022年8月8日 下午7:25
下一篇 2022年8月9日 上午9:46

相关推荐