一种状态保质期和无状态性的路线图

一种状态保质期和无状态性的路线图
2021年06月23日 19:11 金色财经

以太坊的状态的规模正迅速增长。当前仅存储状态大概是 35 GB,如果加上默克尔证明就是 100 GB 了;而且现在预计每年都要增长这个数字的一半。此外,状态存储也是以太坊经济模型的一个短板:在这个机制中,用户只需付费一次就可以给共识节点施加永久的负担。为了保持以太坊的可扩展性和可持续性,我们需要一些解决方案。

有两种路径,而且都已经存在很长时间了:“弱无状态性” 和 “状态保质期”:

状态保质期:从状态中移除近期(比如,去年)无人访问的状态对象,并要求在复活状态对象时提供见证数据(witness)。可以将每个节点都需要存储的状态数据减少到扁平的约 20 ~ 50 GB。

弱无状态性:仅要求区块提议者存储状态,其他节点都可无状态验证区块。在实践中,需要把状态共识形式(从默克尔树)切换到 “Verkle Tree”,以缩减见证数据的规模。

本文提出了一种多阶段的方案,来同时实现这两种方案。因为,可以证明,这会比按顺序实现这两个(无论什么顺序)容易很多。如果不实现 Verkle 树,状态保质期方案下就需要非常大的见证数据来证明一个旧状态;如果不实现状态保质期,切换到 Verkle 树就需要一个一步到位的切换流程(例如 EIP 2584),这几乎跟只实现状态保质期一样复杂。如果合二为一,同时进行,它们就解决了彼此面临的挑战:状态保质期方案包含了每年创建一棵新状态树的机制,因此 Verkle 树可以分阶段逐步建构,而无需一个一步到位的切换流程,而 Verkle 树也解决了见证数据规模的问题。

无状态客户端的概念,于 2017 年始发于 ethresear.ch 论坛:https://ethresear.ch/t/the-stateless-client-concept/172(亦可见 EthHub)

状态租金(状态保质期的前身),始发于 2015 年:https://github.com/ethereum/EIPs/issues/35

ReGenesis(Alexey Akhunov 的提议,可以认为是 状态保质期 + 历史过期 的一种形式):https://medium.com/@mandrigin/regenesis-explained-97540f457807 

Verkle 树:https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw

(演讲)约束见证数据的大小:https://www.youtube.com/watch?v=qQpvkxKso2E

一种状态规模管理理论(2021 年 2 月):https://hackmd.io/@vbuterin/state_size_management

最小化复活冲突的状态约束方案:https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739

实现无状态性和状态保质期的路径:https://hackmd.io/@vbuterin/state_expiry_paths

这里所描述的是此提案的机制。

核心想法是,每个周期(比如以一年为一个周期)都会有一棵状态树,每当一个周期开始时,就初始化一棵空状态树,所有的状态更新都写到这颗状态树上。在一个周期内,所有的写入都会发生在最新的状态树上(所以新树和老树可能会存储同样的信息,也可能会发生冲突;那么总是以更新的树为优先)。

- 注意:我之前曾把这个约长一年的状态保质期周期称为 “epoch”,现在都称为 “period”,以免与信标链的术语相混淆 -

两个关键原则是:

只能修改最新的那棵树(也即对应于当前周期的树)。所有更老的树都不能再修改;更老的树上的对象只能在更新的树上创建副本,而且这些副本会取代更老的副本。

可以预期全节点(包括区块提议者)只会保存最近的两棵树,所以只有最近的两棵树上的对象才能不需要 witness 就能读取。读取更老的对象就需要提供见证数据了。

“见证数据” 就是一个简短的证据,证明某个值(或者某一组值)存在于某棵树的某个位置上,而且验证的一方只需具有树根即可。举个例子,可以制作 一个 witness 来证明账户 0x124f...89ab 的存储空档 123 处在某时的状态下,包含的值为 50;任何人都只需要这棵状态树的根值就可以验证这个证据。

状态保质期产生了一种混合的状态机制:共识节点需要保存最近被人访问和修改过的状态,但可以使用基于见证消息的无状态客户端方法来验证更老的状态。也就是说,也可以维护一个 “归档节点”,存储所有历史状态树,或者 一个完全无状态的节点,使用见证数据来验证哪怕是最新的状态。不过,gas 消耗量的结构和默认的网络格式,都要围绕 “节点会存储最近的两棵状态树” 来开发。

迁移将按阶段来实现:

周期 1 硬分叉:需要一个硬分叉来开启第一个周期(此前的则都算是第 0 个周期)。分叉之后,就会出现两棵状态树:十六叉的帕特里夏树(已冻结,不可再编辑)以及一棵新的 Verkle 树(包含所有新的状态 编辑/增加,还有旧状态的副本)

EIP 草案:https://notes.ethereum.org/@vbuterin/verkle_tree_eip

地址扩张周期:地址从 20 字节扩充到 32 字节,而新地址的格式包含一个 “地址周期” 的概念(曾用名 “地址空间(address space)”)。这样新合约就可以无需提供见证数据而直接写入新的存储空档。这一步什么时候做都可以,只需要在最终状态保质期转型完成之前就可以了,在周期 1 分叉之前或之后都可以。

VB 的方案 :https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485

Ipsilon 团队的方案:https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

周期 2 硬分叉:需要一个硬分叉来开启周期 2,并安排未来周期的时点。周期 0 的十六叉的帕特里夏树将被一棵 Verkle 树替换,客户端仅存储其状态根。从这时开始,周期 0 的状态将需要见证数据来访问。并且,状态保质期方案也算是完整实现了。

EIP 草案:https://notes.ethereum.org/@vbuterin/state_expiry_eip

原文链接:

https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal

作者: Vitalik

翻译: 阿剑

财经自媒体联盟更多自媒体作者

新浪首页 语音播报 相关新闻 返回顶部