无状态客户端中的见证数据

以太坊爱好者 閱讀 35917 2020-7-18 17:39
分享至
微信掃一掃,打開網頁後點擊屏幕右上角分享按鈕

编者注:本文为 Vitalik Buterin 为 “无状态客户端见证数据” 撰写的介绍性幻灯片,介绍了无状态客户端的范式,也讨论了多种可能采用的实现无状态性的方法。

无状态客户端简介

这一部分介绍了以太坊协议当前的范式和无状态范式,还介绍了无状态范式的好处。

在当前的以太坊协议中,状态转变函数需要状态作为输入,但交易(区块)发送者并不提供这部分状态,而是默认接收并验证区块的人在本地维护了状态;因此,想要验证以太坊区块的节点就必须在本地保存全局状态的副本。而无状态范式改变了这一点,把 “状态” 输入替换成了 “状态根 + witness”,此处的 witness,就是为了让区块验证者能够验证区块而附加的状态数据(或者状态证明),有了这部分数据,验证的一方就不再需要在本地维护全局状态了。无状态范式能大幅提高节点同步区块链的时间并降低节点的运行负担(大量减少了硬盘的 I/O 需求)。

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

实现无状态客户端的困难所在

该部分介绍了实现无状态客户端的困难所在。一方面,witness 的数据规模较大,安装此处的估算,每个区块会产生 600 KB 的区块 witness 数据(当前的以太坊区块本身的数据量平均在 30~35 KB 左右)。另一方面,则是因为 EVM 操作码的 Gas 消耗量都是根据操作的计算量来决定的,根本不适合无状态范式以带宽消耗为主的情况。所以,总的来说,实现无状态性的挑战一方面在于要降低 witness 的大小,另一方面是制定出一套与之相适应的 Gas 消耗量方案。

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

可能采取的方案

此处介绍了可能采用的实现无状态性的方案,包括多项式承诺、Verkle Tree 和 SNARKing Merkle Tree。作者从对多项式承诺方案的分析给出了一个 “直觉”:为便于在状态更新后更新 witness,可能我们仍逃不出要使用树状数据结构。

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

无状态客户端中的见证数据

btcfans公众号

微信掃描關注公眾號,及時掌握新動向

來源鏈接:https://ethfans.org/
免責聲明:
2.本文版權歸屬原作所有,僅代表作者本人觀點,不代表比特範的觀點或立場
2.本文版權歸屬原作所有,僅代表作者本人觀點,不代表比特範的觀點或立場
上一篇:原阿里高管朱烨出任火币新CTO 火币高管全员首度曝光 下一篇:快速突破市值前十的Link,站在DeFi舞台中央

相關資訊