原文链接:https://medium.com/@chaisomsri96/statelessness-series-part1-state-expiry-history-expiry-2bbd5835b329 译者:AI 翻译官[1],校对:翻译小组[2] 本文永久链接:learnblockchain.cn/article…[3]
在区块链研究中,区块链三难困境是一个众所周知的概念,它表明主链追求的三个目标——去中心化、安全性和可扩展性——彼此之间存在权衡关系,使得同时实现这三个目标变得困难。以太坊社区将去中心化作为其最重要的价值,并考虑了各种方法来提高可扩展性而不牺牲去中心化和安全性,甚至为这些计划发布了路线图。
以太坊团队关注的两个主题,MEV(矿工可提取价值)和无状态,可能看起来不相关,但它们都有一个共同的目标,即增强以太坊的去中心化。例如,使区块生产对所有人开放的想法,防止 MEV 成为只有一些中心化节点才能获得的利益,是防止强大节点中心化的一种运动。
此外,随着以太坊链的规模增长,提高操作链的最低硬件要求,使链尽可能轻量化以避免集中于少数节点的努力也被视为去中心化的努力。尽管最近在以太坊研究论坛上的讨论更多集中在 MEV 上而不是无状态,但显然链规模的增加也是一个必须最终解决的问题。
操作以太坊全节点和存档节点的硬件要求(来源:https://blog.woodstockfund.com/2022/04/21/deep-dive-into-eip-4444 )
在本文中,我们将讨论状态过期和历史过期,这些方法被提及为减少节点操作所需硬件要求的方法。
简而言之,状态过期涉及定期删除由全节点维护的状态树的一部分,以防止树的大小无限增加。另一方面,历史过期涉及常规以太坊全节点完全删除非常旧的过去区块数据。
为了了解更大的图景,让我们重新审视无状态的概念。当以太坊链上创建一个新块并在此块中包含新交易时,全节点执行这些交易以验证其有效性。要确定交易是否有效,需要当前的状态树。这个状态树存储了当前所有账户的状态,允许验证当前状态在执行特定交易时是否有任何问题。例如,如果地址 A 广播一笔交易将 1 ETH 转移给 B,但 A 的当前余额少于 1 ETH,那么这笔交易将被视为无效。
状态树包含了从以太坊创世块到现在超过 1600 万个块中出现的所有账户的状态。状态树的大小接近 50GB,并且还在不断增长,不仅在存储方面,还在搜索和修改所需的资源方面。人们还认为这是低效的,因为超过 90% 的这些账户已经很长时间没有使用,但它们仍然被存储。
无状态的概念是减少以太坊全节点持有的状态树的大小,它可以分为两个方向:1)弱无状态和 2)状态过期。
首先,弱无状态的想法是只有区块提议者应该存储状态,而验证交易的其他节点不应维护状态树。目前,区块提议者(Block Proposer)只广播包含交易的区块。然而,如果区块提议者也能广播交易以及证明(见证)这些交易有效的证据,那么其他验证节点就不需要持有整个状态树。虽然弱无状态可以减轻许多验证节点的负担,但它对区块提议者节点生成见证的要求更高,这可能加速中心化。因此,仅靠弱无状态是不够的,还需要状态过期。
状态过期的想法是定期删除和重建由以太坊全节点维护的状态树。
目前讨论的周期是一年,这意味着通过每年重置状态树并重新创建它,节点自然不需要存储很少使用的账户(休眠账户)的状态,从而减少树的大小并防止其无限增长。然而,不加区分地删除树显然会导致无法验证新交易的情况,如果发起交易的账户不在状态树中。为了防止这种情况,需要一种方法来恢复旧状态树中存在的账户的状态。
来源:https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal
在 **ethresear.ch** 的讨论中,状态过期的结构[4]是每年重置状态树,只存储前一个周期的状态树,并仅保留超过两个周期的状态树的根值。如果当前周期称为 T 周期 ,则有 (T-1) 和 (T) 状态树,只有_(T)_状态树可以更改。
此外,为了存储账户访问所属的周期(以下简称 Epoch),使用了 扩展地址方案 ,而不是当前的地址系统。这里的“年”表示为一个 Epoch,这与以太坊的共识算法 Gasper 中的 Epoch 不同(1 Epoch=32 个槽)。在扩展地址方案中,当前以太坊地址前面附加 Epoch 编号,表示为 **(e,s)**。
**(e,s)**:e 是 Epoch,s 是以太坊中使用的当前 160 位地址。
(e,s) 是对应于 Epoch e 的地址,因此如果当前 Epoch 小于 e,则无法访问 **(e,s)**。为了更容易理解,我们将 Epoch e 的状态树表示为 S_e。状态树被引用的情况可以分为四种场景。我们将检查在每种场景中正确加载状态所需的信息。
(1) 如果 (e,s) 的状态在 Epoch e 期间发生变化
全节点可以访问和修改 Epoch e 的状态树 S_e,因此情况类似于以太坊全节点当前访问状态树的方式。全节点拥有 Epoch e 的状态树,因此可以读取 (e,s) 的当前状态并执行交易以修改状态。
(2) 如果 (e,s) 的状态在 Epoch e+1 期间发生变化
S_{e+1}不包含 (e,s) ,当前全节点拥有前一个和当前的状态树,S_e 和 S_{e+1}。读取前一个状态树 S_e,并在 S_{e+1}中新增或更改 (e+1,s)。
(3) 如果 (e,s) 的状态在 Epoch f > e+1 期间发生变化
全节点只存储 S_f 和 S_{f-1}。如果 (e,s) 是 S_f 和 S_{f-1} 的一部分,这意味着 (e,s) 在 f-1 或 f 被调用,并且可以按照 (1) 或 (2) 的方式进行修改。
然而,如果 (e,s) 不包含在 S_f 和 S_{f-1} 中,想要更改 (e,s) 的实体必须广播一个证明 (e,s) 存在于 S_e 的见证,以及一个证明 (e,s) 未包含在 S_{e+1}, …, S_{f-2} 中的缺失证明。
总之,通过状态过期,全节点只存储最近 1-2 年的状态 Trie,仅保留之前时期状态 Trie 的根。要从之前的时期检索账户状态,账户所有者需要提交一个证明其状态在最近点的见证和一个证明其在某个时期之前未被使用的缺失证明。该方案防止状态 Trie 的大小无限增长。
节点存储从创世区块到当前区块(大约 1600 万)的所有区块数据、交易数据和一些收据数据,总计约 500GB。历史过期指的是全节点删除某个过去时间点之前的所有区块和交易数据,只保留最近的区块。被称为 EIP-4444[5](历史过期),讨论的存储期约为一年。
历史数据的用途包括 1) 同步,2) 维护 dAPP 等。当第一次运行像 Geth 这样的以太坊客户端时,它会连接到对等节点以请求和接收区块数据,执行从创世区块到当前区块的所有区块和交易数据。
然而,如果全球所有以太坊节点都删除了一年前的所有区块数据,新节点将无法直接从创世区块执行所有交易。因此,可以定期更改特定检查点并像创世区块一样使用它们,这样只接收检查点之后的区块和交易数据。尝试重新同步的节点将不得不信任它们收到的第一个检查点。提案还包括将删除的历史数据存储在像 IPFS 或 torrent 这样的分布式服务器上。
此外,如果 dAPP 需要非常旧区块中的交易信息,向其他节点请求这些数据可能会变得困难。dAPP 将不得不自己存储交易和收据数据,或依赖于持有从创世区块以来所有交易数据的少数存档节点。
历史过期不是以太坊协议层面的变化,而是客户端层面的变化。这不是为以太坊创建新规则,而是像 Geth 或 Erigon 这样的客户端默认删除一年前的数据。删除旧区块数据乍一看似乎有风险,但并不会显著影响安全性。
事实上,Geth 客户端已经允许用户从他们的计算机中删除过去的区块数据。没有义务向请求同步的其他节点提供区块数据;这是出于善意而为。存储过去的区块数据不是全节点的强制责任。理论上,或者在最坏的情况下,将客户端默认设置更改为不存储过去的数据似乎无关紧要。然而,实际上,客户端的默认设置控制了大多数不修改客户端的全节点的行为,可能会影响整个以太坊网络。
更改数据存储的默认设置似乎有风险,仿佛区块链正在放弃其功能。然而,以太坊是一个状态机;它的存在不是为了保存历史数据,而是为了执行新交易并通过对当前状态的共识达到新状态。如果检查点可以被信任,那么在检查点之后接收并直接执行交易以同步到当前状态没有问题,信任一个检查点与信任创世区块没有太大区别。
本文讨论了状态过期和历史过期,这是无状态以太坊路线图的一部分。总之,目的是防止状态 Trie 大小无限增长,并删除节点长期存储的旧区块数据以减轻客户端负担。状态过期中的地址空间扩展(ASE)系统未在本文中详细讨论,将在下一篇文章中讨论。
参考资料
State Expiry eip[6]
Deep Dive into EIP – 4444[7]
A state expiry and statelessness roadmap[8]
EIP-4444: Bound Historical Data in Execution Clients[9]
我是 AI 翻译官[10],为大家转译优秀英文文章,如有翻译不通的地方,在这里[11]修改,还请包涵~
AI 翻译官: https://learnblockchain.cn/people/19584
[2]翻译小组: https://learnblockchain.cn/people/412
[3]learnblockchain.cn/article…: https://learnblockchain.cn/article/8509
[4]在ethresear.ch的讨论中,状态过期的结构: https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739
[5]EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
[6]State Expiry eip: https://notes.ethereum.org/@vbuterin/state_expiry_eip
[7]Deep Dive into EIP – 4444: https://blog.woodstockfund.com/2022/04/21/deep-dive-into-eip-4444/?source=post_page-----2bbd5835b329--------------------------------
[8]A state expiry and statelessness roadmap: https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal?source=post_page-----2bbd5835b329--------------------------------
[9]EIP-4444: Bound Historical Data in Execution Clients: https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450
[10]AI 翻译官: https://learnblockchain.cn/people/19584
[11]这里: https://github.com/lbc-team/Pioneer/blob/master/translations/8509.md
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。