BeeLab研究简报:深度解读Aptos

原文作者:Sybil Attack

原文来源:Twitter

Aptos最有意思的点,并不在于吹上天际的16万TPS的交易并行模式BlockSTM,而在于它的每个区块里没有交易的原始数据。 Aptos的出块者仅在区块头上标记出,这个Block内应当包含哪些交易,接收到Block的节点需要自己去本地的交易池里查找这些交易,然后把这批交易上链

Aptos

这样做有什么好处?答案是:节约带宽。 Nervos公链研究员张韧曾说:【带宽】实际上是区块链吞吐量的最大限制,TPS就是【带宽利用率】的游戏。 任何公链想要获得更高的TPS,都要先解决带宽消耗问题。 决定一个公链网络TPS的核心在于它每秒能对多少笔交易达成共识,这就要看网络带宽与数据传播速度。

Aptos

以太坊等传统公链的数据传输方式存在严重冗余,用户交易先在P2P网络里广播【一遍】,置入几乎所有节点的【交易池】,然后出块者会从自己的交易池里把交易【打包进区块】,再广播【一遍】。这样下来,一笔交易数据会在网络内广播【两遍】,造成了严重带宽浪费。 目前,以太坊每个区块包含的数据不能太多

Aptos

Solana为此做出了最极端的尝试,直接把交易池取消不要了,所有的用户交易 先发给指定的出块者Leader,再由Leader广播给其他节点。这样一来,每笔交易只需要在网络内广播【一遍】。代价是没了交易池,垃圾交易过滤能力大幅下降。

Aptos

Aptos

专门给比特币矿工同步区块的FIBRE则使用了接近于Aptos的方案。 出块者只向其他矿池节点发布最新区块的区块头(袖珍区块),里面会标记,这个区块里应该包含哪些交易数据。 接收到这个区块头的矿池节点,会去自己的交易池查找相关交易,把它们上链。若找不到,就去向发布区块头的出块者索取(fresh tx)

Aptos

Aptos的做法实质与FIBRE接近。出块者Leader发布的也是袖珍型区块,里面会标记一批交易的ID号,指定执行顺序和结果。收到袖珍区块的Validator,去自己的交易池里找对应的交易数据,按Leader在袖珍区块里标记好的顺序执行,然后再把它们上链。

Aptos

这样一来,真正限制Aptos吞吐量的,是节点们每秒能同步多少笔交易数据,而不在于出块者发布区块的速度、区块的数据容量。

因为Leader可以在一个袖珍区块里,把交易池剩余的交易全标记了,让Validator一次把交易池里的交易全执行完。以现在的电脑硬件水平,节点每秒处理几千笔交易是毫无压力的。

一般而言,Aptos 的共识节点时刻都会接收待处理的交易。每个共识节点Validator会把多笔待处理交易合并成一个批次Batch,广播给其他共识节点。 其他共识节点收到这个交易批次后,会把它放进交易池里,并反馈给发布者一个回执签名。

Aptos

比如:某个共识节点 V 在 2 秒内收到了 50 笔待处理交易,它验签后,把这50笔交易打包成了一个批次Batch,发送给其他共识节点。接收到Batch的节点也这么做,一传十十传百,这个交易批次最终装进了所有节点的交易池里。

每个接收者确认交易批次后,要给V发一个回执签名。

假设网络内有3f+1个共识节点,当 V 收到 2f+1 个回执后,就生成一个可用性证明 PoAv。

每个批次Batch对应的 PoAv,保证至少有 2f+1 个节点同步了这个交易批次(节点总数为 3f+1 个)。跟据拜占庭容错,可以认为所有节点最终都会收到这个交易批次。

其实这就相当于,网络节点对一个Batch完成了共识确认

Leader发布的袖珍区块中,会标记出一些生成了PoAv的交易批次Batch,叫接收者去自己的交易池里,找出这些已被同步给共识节点的交易Batch。 很显然,在这种模式下,实质制约网络吞吐量的,是网络每秒能对多少笔交易达成同步共识,也就是每秒能为多少笔交易生成PoAv可用性证明。

Aptos

这就有点像DAG公链一样,很多共识节点都可以发布一个区块,广播到网络中。但DAG的分叉选择算法只会选择一部分区块上链,因为这些区块可能包含冲突,比如包含某笔相同的交易。如果同时认可它们,就会造成双花。

Aptos面对的问题也在于这,如果两个交易Batch包含同一笔交易,那么有一个Batch必定被废弃。

如果Aptos在这方面好好优化,相信可以解决此类问题。 至于其一贯鼓吹的BlockSTM并行执行模式,无外乎就是允许节点同时执行多笔交易。 以太坊是串行执行,同一时刻只能执行1笔交易。但按照 @chenxingdotli 李辰星博士的看法,CPU单个核心每秒最多可以串行执行约5万笔基础转账,换做SWAP大概可以跑5000笔

Aptos

但每秒最高可以执行5000笔SWAP的以太坊节点,平均每秒只能对10几笔交易达成共识。显然,串行还是并行与否,不是限制Layer1公链效率的最大问题。况且,Aptos的BlockSTM(乐观执行)在理想状态下,也只是比以太坊提高了8-16倍的交易处理速度,这比Solana的Sealevel低了不知道多少。

值得注意的是,Aptos的节点带宽要求和Solana一样,都是1Gbit/s,换成网速就是125MB/s。这其实就说明了,它最后还是要以高配节点的方式,走纵向扩容之路。既然有了Solana作为前车之鉴,想必也不必对Aptos的效率抱以太大期望。

Aptos

Aptos最大的亮点还是在于MOVE这门开发语言。如果MOVE可以展现出Solidity不具备的业务建模能力,那么Aptos还是会有很大的崛起可能。外加Multicoin和FTX、a16z 等一众资本巨头入局,即便是在开盘就被Paradigm某工程师低级黑的情况下,还是会有很强的后劲。

毕竟市场本身就充满了不确定性,没人能预知未来。

在此感谢 @Huobi_Research @jiangmengchu11 @XResearchDAO 的研报对我的启发,并且感谢unipass开发人员 @xcshuan@NervosNetwork 的资料素材。

这里面第二段的表述有些问题,应该是在带宽有限的情况下,改善了利用方式。Aptos的做法类似于Rollup,每个区块只包含交易数据的摘要,而不是完整的交易数据。这样一个区块就可以映射几千上万笔交易,而不像以太那样只有几百笔。

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

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

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

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2022年10月19日 上午1:36
下一篇 2022年10月19日 上午1:37

相关推荐

BeeLab研究简报:深度解读Aptos

星期三 2022-10-19 1:37:20

Aptos最有意思的点,并不在于吹上天际的16万TPS的交易并行模式BlockSTM,而在于它的每个区块里没有交易的原始数据。 Aptos的出块者仅在区块头上标记出,这个Block内应当包含哪些交易,接收到Block的节点需要自己去本地的交易池里查找这些交易,然后把这批交易上链

Aptos

这样做有什么好处?答案是:节约带宽。 Nervos公链研究员张韧曾说:【带宽】实际上是区块链吞吐量的最大限制,TPS就是【带宽利用率】的游戏。 任何公链想要获得更高的TPS,都要先解决带宽消耗问题。 决定一个公链网络TPS的核心在于它每秒能对多少笔交易达成共识,这就要看网络带宽与数据传播速度。

Aptos

以太坊等传统公链的数据传输方式存在严重冗余,用户交易先在P2P网络里广播【一遍】,置入几乎所有节点的【交易池】,然后出块者会从自己的交易池里把交易【打包进区块】,再广播【一遍】。这样下来,一笔交易数据会在网络内广播【两遍】,造成了严重带宽浪费。 目前,以太坊每个区块包含的数据不能太多

Aptos

Solana为此做出了最极端的尝试,直接把交易池取消不要了,所有的用户交易 先发给指定的出块者Leader,再由Leader广播给其他节点。这样一来,每笔交易只需要在网络内广播【一遍】。代价是没了交易池,垃圾交易过滤能力大幅下降。

Aptos

Aptos

专门给比特币矿工同步区块的FIBRE则使用了接近于Aptos的方案。 出块者只向其他矿池节点发布最新区块的区块头(袖珍区块),里面会标记,这个区块里应该包含哪些交易数据。 接收到这个区块头的矿池节点,会去自己的交易池查找相关交易,把它们上链。若找不到,就去向发布区块头的出块者索取(fresh tx)

Aptos

Aptos的做法实质与FIBRE接近。出块者Leader发布的也是袖珍型区块,里面会标记一批交易的ID号,指定执行顺序和结果。收到袖珍区块的Validator,去自己的交易池里找对应的交易数据,按Leader在袖珍区块里标记好的顺序执行,然后再把它们上链。

Aptos

这样一来,真正限制Aptos吞吐量的,是节点们每秒能同步多少笔交易数据,而不在于出块者发布区块的速度、区块的数据容量。

因为Leader可以在一个袖珍区块里,把交易池剩余的交易全标记了,让Validator一次把交易池里的交易全执行完。以现在的电脑硬件水平,节点每秒处理几千笔交易是毫无压力的。

一般而言,Aptos 的共识节点时刻都会接收待处理的交易。每个共识节点Validator会把多笔待处理交易合并成一个批次Batch,广播给其他共识节点。 其他共识节点收到这个交易批次后,会把它放进交易池里,并反馈给发布者一个回执签名。

Aptos

比如:某个共识节点 V 在 2 秒内收到了 50 笔待处理交易,它验签后,把这50笔交易打包成了一个批次Batch,发送给其他共识节点。接收到Batch的节点也这么做,一传十十传百,这个交易批次最终装进了所有节点的交易池里。

每个接收者确认交易批次后,要给V发一个回执签名。

假设网络内有3f+1个共识节点,当 V 收到 2f+1 个回执后,就生成一个可用性证明 PoAv。

每个批次Batch对应的 PoAv,保证至少有 2f+1 个节点同步了这个交易批次(节点总数为 3f+1 个)。跟据拜占庭容错,可以认为所有节点最终都会收到这个交易批次。

其实这就相当于,网络节点对一个Batch完成了共识确认

Leader发布的袖珍区块中,会标记出一些生成了PoAv的交易批次Batch,叫接收者去自己的交易池里,找出这些已被同步给共识节点的交易Batch。 很显然,在这种模式下,实质制约网络吞吐量的,是网络每秒能对多少笔交易达成同步共识,也就是每秒能为多少笔交易生成PoAv可用性证明。

Aptos

这就有点像DAG公链一样,很多共识节点都可以发布一个区块,广播到网络中。但DAG的分叉选择算法只会选择一部分区块上链,因为这些区块可能包含冲突,比如包含某笔相同的交易。如果同时认可它们,就会造成双花。

Aptos面对的问题也在于这,如果两个交易Batch包含同一笔交易,那么有一个Batch必定被废弃。

如果Aptos在这方面好好优化,相信可以解决此类问题。 至于其一贯鼓吹的BlockSTM并行执行模式,无外乎就是允许节点同时执行多笔交易。 以太坊是串行执行,同一时刻只能执行1笔交易。但按照 @chenxingdotli 李辰星博士的看法,CPU单个核心每秒最多可以串行执行约5万笔基础转账,换做SWAP大概可以跑5000笔

Aptos

但每秒最高可以执行5000笔SWAP的以太坊节点,平均每秒只能对10几笔交易达成共识。显然,串行还是并行与否,不是限制Layer1公链效率的最大问题。况且,Aptos的BlockSTM(乐观执行)在理想状态下,也只是比以太坊提高了8-16倍的交易处理速度,这比Solana的Sealevel低了不知道多少。

值得注意的是,Aptos的节点带宽要求和Solana一样,都是1Gbit/s,换成网速就是125MB/s。这其实就说明了,它最后还是要以高配节点的方式,走纵向扩容之路。既然有了Solana作为前车之鉴,想必也不必对Aptos的效率抱以太大期望。

Aptos

Aptos最大的亮点还是在于MOVE这门开发语言。如果MOVE可以展现出Solidity不具备的业务建模能力,那么Aptos还是会有很大的崛起可能。外加Multicoin和FTX、a16z 等一众资本巨头入局,即便是在开盘就被Paradigm某工程师低级黑的情况下,还是会有很强的后劲。

毕竟市场本身就充满了不确定性,没人能预知未来。

在此感谢 @Huobi_Research @jiangmengchu11 @XResearchDAO 的研报对我的启发,并且感谢unipass开发人员 @xcshuan@NervosNetwork 的资料素材。

这里面第二段的表述有些问题,应该是在带宽有限的情况下,改善了利用方式。Aptos的做法类似于Rollup,每个区块只包含交易数据的摘要,而不是完整的交易数据。这样一个区块就可以映射几千上万笔交易,而不像以太那样只有几百笔。