【英文】EIP-2935：通往无状态以太坊的关键一步

Chainfeeds 导读：

EIP-2935 代表着以太坊实现长期无状态性（statelessness）目标的重要一步。它通过在状态中部署专用合约来存储最近的 8192 个区块哈希，从根本上解决了当前设计中的一个核心限制 —— 即以太坊默认假设客户端始终可以访问最近的区块哈希。

文章来源：

https://research.2077.xyz/eip-2935-a-step-to-achieving-stateless-execution#conclusion

文章作者：

2077 Research

观点：

2077 Research：数据或历史过期指的是在一定时间后，从客户端中裁剪掉不再需要的数据。借助弱主观性检查点（weak subjectivity checkpoints），客户端可以从创世块开始同步并裁剪掉无用的历史数据。主观性指的是网络中的节点依赖社会性信息来就当前状态达成共识。在这个背景下，弱主观性意味着链可以在拥有一定社会性获取的初始信息的基础上客观地推进。但弱主观性检查点意味着网络上所有参与共识的节点都必须处于规范链上。这些检查点帮助以太坊 PoS 从受信源获取最近状态，以实现同步。EIP-4444 提供了一条实践路径，借由弱主观性实现数据的过期。该提案并不打算改变以太坊节点处理状态数据的方式，而是修改对历史数据的访问方式。另一方面，状态过期（State Expiry）旨在移除节点中长时间未被访问的状态数据。状态过期可以通过两种方式实现：按租金（rent）或时间进行终止。租金机制指的是对账户状态的长期存储施加额外费用；时间机制则是在账户长时间未活跃的情况下将其设为失效。这两种机制仍处于研究阶段。目前达成这些目标的途径主要依赖于集中式网络或提供方的协作。迄今为止，以太坊已部分实现了弱无状态性（weak statelessness）与状态过期的一些雏形。 无状态以太坊（Stateless Ethereum）为核心协议引入了新概念。理想情况下，无状态性并不意味着状态不再存在，而是客户端可以选择他们想要维护的状态。当客户端接收到已验证的区块时，他们还会接收到该区块对应的见证数据（witness），这些见证数据包含了执行区块中交易所需的所有信息。EIP-161 是以太坊在遭受拒绝服务攻击后提出的第一个减状态提案。此前，攻击者通过制造大量空账户扩展了以太坊的全局状态。EIP-161 提出移除 nonce 为零且余额为零的空账户，以清理冗余状态并防止此类攻击再现。另一个推动无状态的提案是 EIP-4788，旨在将信标链区块的根哈希暴露在 EVM 中，从而实现执行层与共识层的低信任连接。无状态性可分为弱无状态性和强无状态性。弱无状态性并不消除所有节点存储状态的需求，而是要求区块提议者（proposer）维护完整状态，其他验证节点仅需保存状态根哈希，并通过验证证明完成验证流程。这一模式依赖于提议者 - 构建者分离（PBS）和 Verkle Trie 的部署。相比之下，强无状态性则完全移除状态存储需求。所有交易和见证数据均由提议者聚合并提交，其他节点无需持有或检索任何状态数据即可完成验证。此模式仍处于构想阶段，尚需实现 EIP-2930（访问列表）等前提条件。EIP-2935 作为前 Verkle 阶段的方案，试图在无状态执行路径上提供进一步支持。、 EIP-2935 的目标是将历史区块哈希存储在区块链的状态中，借此支持无状态客户端执行。具体做法是将最多 8192 个历史区块的哈希值存储于系统合约中，这些数据存储在特殊地址中，以便客户端进行访问验证。这一提案解决了当前 EVM 假设客户端必须本地拥有最近区块哈希的问题，为未来无状态以太坊打下基础。提案引入了 4 个新参数：BLOCKHASH_SERVE_WINDOW（客户端需保留的历史哈希数量，默认 256）、HISTORY_SERVE_WINDOW（合约存储的区块数量，默认 8191）、SYSTEM_ADDRESS（写入区块哈希的调用者地址）以及 HISTORY_STORAGE_ADDRESS（实际合约部署地址）。提案规定这些哈希值以环形缓冲（ring buffer）的方式存储，使得每次写入都覆盖前一个旧数据，从而节省存储空间。系统合约提供两个操作接口：set () 和 get ()。当调用者为 SYSTEM_ADDRESS 且参数合法时，触发 set () 操作，将哈希存入指定槽位。否则，默认执行 get () 操作，根据请求的区块号返回对应哈希值或回退。为避免安全问题，该合约还设计了无法被非系统地址写入的逻辑，防止分支污染攻击。【原文为英文】