EIP-161 详解State Trie Clearing 与以太坊空账户清算机制【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-161State trie clearing, invariant-preserving alternative是以太坊第四次硬分叉 Spurious Dragon 的核心协议改动之一于区块高度 2,675,000 在主网激活。它定义了「空账户」empty account的判定与清除规则从协议层面彻底解决了 2016 年秋季因低价状态写入而造成的状态树膨胀问题同时避免了早期方案 EIP-158 对既有协议不变量invariant的破坏。阅读本文后你将完整掌握 EIP-161 的四条规范、touched/empty/dead 三个关键概念的精确语义、它与 EIP-158 的演进关系以及它在后续 EIP如 EIP-684、EIP-7610、EIP-7523中的长期技术遗产。背景为什么要进行状态树清算在以太坊早期版本中协议存在一个明显的缺陷任何人都能以极低的成本向状态树中写入大量空账户。EIP-158State clearingVitalik Buterin 提出的 Rationale 明确指出这一缺陷源于早期协议版本的漏洞导致主网状态中积累了海量空账户造成状态大小急剧膨胀增加了全节点客户端的磁盘负载快速同步fast sync耗时变长同步需要处理的状态对象数量庞大协议长期复杂度上升空账户与不存在的账户在语义上产生歧义客户端必须为空和不存在维护两套逻辑。EIP-161 正是为解决这一问题而提出的最终方案并随 Spurious Dragon 硬分叉元提案 EIP-607 在主网区块 2,675,000Morden 测试网为 1,885,000正式激活。该分叉共包含四个 EIPEIP-155简单重放攻击保护、EIP-160EXP 费用上调、EIP-161状态树清算与 EIP-170合约代码大小上限。EIP-161 与 EIP-158两个方案的演进关系EIP-161 的完整标题是 State trie clearing (invariant-preserving alternative)即保持不变量invariant-preserving的替代方案。它由 Gavin Wood 撰写与 EIP-158 针对同一问题提出了不同的解决路径EIP-158 的核心思路在任意导致账户变为空的状态变更发生时直接删除该账户并将空与不存在在 EVM 语义中等价化。EIP-158 还提出了按sha3(address)排序每块删除 1000 个空账户的渐进清理方案Specification 1c。EIP-161 的改进如文档 Rationale 所述EIP-161 与 EIP-158 except that several edge cases are avoided since we do not break invariants——通过保留两条关键协议不变量来规避边界情况一个账户在执行交易中途不能从有代码和存储变为无代码无存储文档中已更正此条新建账户在其代码部署完成之前不能被删除。正是这两条不变量的保留使 EIP-161 成为最终被采纳进 Spurious Dragon 的方案。EIP-158 的动机与背景分析则在仓库中得以完整保留作为理解 EIP-161 设计意图的最佳对照材料。EIP-161 规范精读EIP-161 的规范包含四条核心规则a–d全部以 RFC 2119 风格的关键词SHALL表述具有强制的协议约束力。规则 a创建类操作的非ce预递增Account creation transactions and theCREATEoperation SHALL, prior to the execution of the initialisation code,incrementthenonceover and above its normal starting value byone.在初始化代码执行之前账户创建交易与CREATE操作必须在正常起始 nonce 的基础上再额外递增 1。对于正常网络新账户的起始 nonce 为 0因此创建后的 nonce 即为 1但对于起始 nonce 非零的测试网实际值会相应变化。这一设计的 Rationale 是CREATE通过使 nonce 非零避免新建账户在创建中途被回收reaped的怪异情形。换言之一旦账户通过CREATE被创建其 nonce 立即为 1账户就不再是空账户空账户要求 zero nonce从而在创建过程中不会被状态清算逻辑误删。规则 b25,000 Gas 账户创建费的新触发条件WhereasCALLandSUICIDEwould charge 25,000 gas when the destination is non-existent, now the charge SHALLonlybe levied if the operation transfersmore than zero valueand the destination account isdead.在旧协议中当CALL或SUICIDE的目标账户不存在时总是收取 25,000 gas 的账户创建费用。新规则下这笔费用仅在同时满足两个条件时才征收操作转移了大于零的价值目标账户是dead不存在或为空的。这意味着零值调用zero-value call与零值自杀zero-value suicide在任何情况下都不再消耗 25,000 gas——这是 EIP-161 对攻击面收窄的关键一环攻击者无法再通过大量零值操作制造高额状态写入而只付出极低 gas 成本。规则 c禁止从不存在变为存在但为空No account maychange statefrom non-existent to existent-but-empty. If an operation would do this, the account SHALL instead remain non-existent.任何操作都不得让账户从不存在变为存在但为空。如果某个操作会导致这种转变那么该账户应当保持不存在。这条规则从源头杜绝了新空账户的产生与规则 d 的存量清理形成存量增量的完整闭环。规则 d交易结束时清算被触碰的空账户At the end of the transaction, any accounttouchedby the execution of that transaction which is nowemptySHALL instead become non-existent (i.e.deleted).在交易结束时任何被该交易执行过程touched触碰且当前为empty空的账户都应被删除变为不存在。需要特别注意时间点的定义At the end of the transaction是指自杀列表suicide list执行完毕之后、为收据receipt填充而计算状态树根state trie root之前的时刻。这一精确的时间点界定确保了删除动作发生在状态根计算的最后一刻是区块共识验证可复现的基础。三个关键概念的精确定义EIP-161 引入了三个相互关联的协议概念是理解整个规范的核心概念定义touched被触碰账户参与了任何潜在改变状态的操作。包括但不限于作为零值转账的接收方。empty空账户没有代码no code、nonce 为零、余额为零。dead死亡账户不存在或者账户是empty的。三者关系可概括为dead non-existent ∪ empty而规则 b 判定是否收取账户创建费时只需检查目标是否 dead规则 d 清算的对象则是被触碰且为空的账户。什么构成状态变更changes state规范进一步枚举了账户改变状态的四种情形即触发触碰判定的操作全集作为SUICIDE操作的目标或退款接收方无论转账价值为零或更多作为CALL操作或消息调用交易message-call transaction的来源或目的地无论转账价值为零或更多作为CREATE操作或合约创建交易的来源或创建目标无论 endowment 为零或更多作为区块作者miner作为区块奖励或交易费的接收方无论价值为零或更多。值得注意的是这四种场景都明确包含了零或更多的表述——即零值操作同样构成状态变更这正是触碰定义不限于零值转账在操作层面的完整展开。Notes当前协议中仅存的四种空账户产生上下文EIP-161 的 Notes 部分指出一个重要的工程事实在当前以太坊协议中最终能导致交易执行后账户为空的状态变更场景极少实现者实际只需追踪以下四种上下文一个空账户通过CALL被转入零值一个空账户通过SUICIDE被转入零值一个空账户通过消息调用交易被转入零值一个空账户通过零 gas 价格的费用转账获得零值。这一枚举大大降低了客户端实现的复杂度——节点不需要泛化地处理任意状态变更而只需在这四类具体场景中检查账户是否变为空并执行删除。这也是 EIP-161 相比任意状态变更即检查删除的朴素实现更可落地的原因。Addendum2016-11-24 共识 Bug 与规范修订EIP-161 文档末尾的补充说明Addendum, 2017-08-15记录了一次重要的共识事故On 2016-11-24, a consensus bug occurred due to two implementations having different behavior in the case of state reverts.2016 年 11 月 24 日由于两个客户端实现在**状态回滚state revert**场景下的行为不一致爆发了一次共识 bug。根据文档引用的官方安全通告细节Geth 的缺陷当导致空账户删除的交易以out-of-gas 异常结束时Geth 未能回滚空账户的删除操作涉及 Geth v1.4.19 与 v1.5.2Parity 的缺陷Parity 客户端在一组更有限的场景中错误地未能回滚空账户删除这些场景涉及对预编译合约precompiled contracts的 out-of-gas 调用最终裁定新的 Geth 行为与 Parity 一致即空账户的删除在状态回滚时必须一并回滚规范据此修订明确empty account deletions are reverted when the state is reverted。文档还预测随着清算过程完成空账户问题将在一周左右后基本从主网消失。这一 Addendum 是理解 EIP-161 规范语义闭环的关键补充——删除动作不是无条件执行的它必须遵循交易回滚的原子性。Spurious Dragon 分叉全景EIP-161 的部署上下文EIP-161 并非孤立生效它属于 EIP-607 Hardfork Meta: Spurious Dragon 的一部分。该元提案明确了分叉代号 Spurious Dragon别名 State-clearing及激活参数主网区块 2,675,000Morden 测试网区块 1,885,000。同期激活的其余三个 EIP 与 EIP-161 形成互补EIP主题与 EIP-161 的关联EIP-155简单重放攻击保护引入CHAIN_ID进入交易签名哈希参数同为FORK_BLKNUM 2,675,000、CHAIN_ID 1EIP-160EXP 费用上调将 EXP 从 10 10/字节 提高至 10 50/字节缓解 DoS 攻击的定价失衡EIP-170合约代码大小上限初始化返回超过0x60002**14 2**13字节时创建失败封堵二次复杂度攻击从攻击面治理的角度看这四个 EIP 共同构成了一次针对 2016 年 DoS 攻击的系统性修复EIP-161 清空账户、EIP-160 修复被低估的 EXP 定价、EIP-170 限制超长代码、EIP-155 提供重放保护。EIP-161 在其中承担了状态膨胀治理的核心职责。长期技术遗产EIP-161 对后续协议演进的深远影响EIP-161 定义的空账户语义已成为以太坊协议的基础设施后续多个核心 EIP 直接以它为锚点EIP-1014CREATE2CREATE2 的规范文本中直接引用了 EIP-161其确定性地址推导与 EIP-161 的 nonce/空账户规则共同构成了现代合约创建语义。EIP-684创建碰撞回滚规定目标地址已有非零 nonce 或非零代码长度时创建必须回滚。其 Rationale 指出了一个历史遗留问题在 EIP-161 生效之前新建合约的 nonce 保持为零因此完全可能部署出nonce 为零、代码为空但存储非空的合约——主网上现存 28 个此类合约。EIP-7610非空存储创建回滚在 EIP-684 的基础上追加存储必须为空的部署条件直接动机正是弥补 EIP-161 之前时代遗留的上述 28 个异常合约该 EIP 的 Abstract 明确声明其规范建立在 EIP-161 的账户语义之上。EIP-7523空账户弃用作为requires: 161的后续提案它规定 post-merge 网络的任何状态都不得包含空账户。其 Motivation 直言尽管主网空账户已于区块14049881交易0xf955834b...全部清除EIP-161 的 touch 规则仍持续带来技术债务——新边界情况不断出现需要反复讨论、实现、测试与文档化。EIP-7523 通过显式禁止空账户解放了未来客户端实现者无需仅为通过测试套件而实现空账户支持。从 EIP-158 的初步构想到 EIP-161 的正式落地再到 EIP-7523 的最终弃用这一系列提案展示了以太坊治理中问题识别 → 方案竞争 → 共识采纳 → 技术债务清偿的完整演化链条而 EIP-161 正是这条链条上承上启下的核心环节。小结EIP-161 通过四条精确的规范规则——创建 nonce 预递增、25,000 gas 费用的新触发条件、禁止不存在→存在但为空的状态转变、交易结束时清算被触碰的空账户——以保持协议不变量的方式完成了以太坊状态树的清理。它的 touched/empty/dead 概念体系为后续十余年的协议演进提供了稳定的语义地基其对回滚原子性的修订Addendum则成为客户端共识实现的重要教训。无论是研究以太坊协议历史、实现客户端状态管理还是理解现代 EIP 的依赖关系EIP-161 都是必须精读的基石性文档。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
