LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 新闻观点 > 无状态客户端中的见证数据

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

2020-07-19 以太坊爱好者 来源:火星财经
文中幻灯片介绍了无状态客户端的范式,也讨论了多种可能采用的实现无状态性的方法。

00:0000:00

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

无状态客户端简介


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

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


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


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


可能采取的方案


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

(完)

(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)

原文链接:

https://vitalik.ca/files/misc_files/stateless_client_witnesses.pdf

作者:Vitalik Buterin

你可能还喜欢:

观点 | 无状态以太坊:二进制状态树实验

观点 | 通过 EVM 代码默克尔化缩减见证数据大小

引介 | 以太坊 2.0 得自以太坊 1.0 升级的灵感

本文来源:以太坊爱好者
原文标题:无状态客户端中的见证数据

—-

编译者/作者:以太坊爱好者

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...