EIP-7775 BURN 操作码在 EVM 中标准化的原生 ETH 销毁方案【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7775 提出在 EVM 中引入一个全新的BURN操作码0xFC用于直接销毁当前执行上下文地址上的原生以太native ether从协议层终结“把 ETH 转到不可花费地址”这一历史遗留的销毁手段。本文基于 EIPS/eip-7775.md 的完整规范结合本仓库内其他 EIP如 EIP-6780、EIP-7503、EIP-1559的销毁语义与调用上下文规则逐条解析BURN的操作数栈行为、余额校验与回滚规则、DELEGATECALL/CALLCODE/STATICCALL下的语境语义、100 动态 gas 计费模型及官方 Python 伪代码。读完本文你将掌握该操作码的完整规范细节、gas 计算方式、与现有销毁手段的异同以及它在 L2 跨链回桥、链上销毁记账等场景中的设计意图。提案背景与动机为什么需要一个专门的销毁操作码历史销毁方式的缺陷在以太坊历史上销毁原生 ETH 一直依赖“把资金转移到不可恢复的地址”这一间接手段常见做法包括转给零地址0x0资金被永久锁定无法被任何人再次动用转给没有提款能力的合约例如 BeaconDepositContract 这类只有存款路径、没有取款路径的合约存入后资金在该地址上变得不可恢复。EIP-7775 的动机章节明确指出这种“看似销毁、实则只是不可恢复地转移”的方式存在两个核心问题语义不清晰从状态账本的角度看资金仍然存在于某个地址的余额字段中只是“无法取出”。这既让索引器indexer和追踪代币流动的工具产生困惑也让审计者难以区分“真实销毁”与“普通转账”存在被误恢复的风险被标记为“已销毁”的原生代币如果因为合约逻辑漏洞或其他原因被意外恢复可能成为智能合约攻击面的一部分。因此该提案希望提供一个明确、标准化、在协议层直接生效的销毁原语BURN操作码在执行时直接从当前地址的余额中扣减指定数额销毁动作对状态变更一目了然不再依赖“转入死地址”的旁路技巧。目标使用场景提案动机中列举了两类主要受益场景Ethereum L2 向 L1 回桥转账当 L2 需要把原生 ETH 桥回 L1 时往往需要在 L2 侧销毁相应数量的 ETH以维持跨链代币总量守恒。一个标准化的BURN操作码能让这一过程在 EVM 内部直接完成而不是依赖约定俗成的“烧毁地址”其他 EVM L1 链的代币经济学凡是需要在链上实现原生代币通缩、销毁机制的 EVM 兼容链都可以复用该操作码作为统一销毁入口。规范BURN 操作码的行为定义本文档中的关键措辞 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、OPTIONAL 均按 RFC 2119 与 RFC 8174 解释。操作码标识与执行步骤BURN操作码的编码值为0xFC其行为规范如下出栈取数从栈顶弹出一个 32 字节的 word将其解释为uint256类型的待销毁原生以太数量单位 wei定位当前地址从 EVM 执行上下文中取出当前执行地址current address读取余额查询该地址的当前余额余额不足即回滚若待销毁数量大于当前地址余额操作码MUST回滚revert零值不回滚若待销毁数量为 0执行MUST NOT回滚扣减余额从当前地址的原生以太余额中减去该数量。值得注意的细节是第 5 条与其他许多操作码不同BURN 0是一个完全合法且无副作用仅消耗基础 gas的调用不会被当作异常处理这为“条件式销毁”的合约逻辑提供了便利。不同调用上下文下的语义EIP-7775 对操作码的语义随调用上下文而变化的情况做了明确规定DELEGATECALL / CALLCODE 上下文BURN操作码实际扣减余额的对象是发起 DELEGATECALL 或 CALLCODE 指令的那个合约而不是被调用代码所在合约。这是因为 delegate 类调用共享调用者的存储、余额与地址语境见下文源码佐证STATICCALL 上下文在静态调用中执行BURNMUST 回滚。这与静态调用禁止一切状态写入的共识规则一致——销毁余额属于状态修改操作在 static 模式下必须被拒绝。这些规则与仓库中现有 EIP 对调用指令语义的描述一脉相承。例如 EIP-7069 Revamped CALL instructions 在定义EXTSTATICCALL时同样要求“若当前帧处于 static-mode 且 value 非零则异常失败”而DELEGATECALL共享调用者地址与余额的语义也与其沿用 EIP-150、EIP-211 等既有调用语义的定位一致。Gas 成本BURN的 gas 成本由基础成本 动态成本两部分组成组成部分数值触发条件基础成本100 gas每次执行必收动态成本0 gas销毁数量为 0动态成本0 gas账户不存在或账户余额为 0动态成本2800 gas其余情况账户存在且余额非零总成本 基础成本100 动态成本0 或 2800。这套计费模型与 EIP-2929 引入的冷/热账户访问定价思想一脉相承2800 的增量对应一次“冷账户访问”cold account access级别的成本而销毁零值或对不存在的账户操作则免费避免无意义的状态触碰。从下文伪代码可以看出2800 的动态成本被注释为 “warm” gas即假设经过前面的余额读取后账户已被视为热访问按热路径计费。官方伪代码逐行解析EIP-7775 提供了一段 Python 风格的伪代码是理解其实现语义最直接的入口完整代码见 EIPS/eip-7775.mddef op_burn(pc, interpreter, scope): # Consume the base gas cost interpreter.consume_gas(100) # Pop the value to be burned from the stack value_to_burn scope.stack.pop() # If the value to be burned is 0, do not revert if value_to_burn 0: return None # Retrieve the current address from the EVM execution context current_address scope.contract.address() # Check the balance of the current address balance interpreter.evm.state_db.get_balance(current_address) # If the value to be burned is greater than the balance, revert if value_to_burn balance: return ErrInsufficientBalance # If the account balance is 0, return. if balance 0: return None # Subtract the value from the current addresss balance interpreter.evm.state_db.sub_balance(current_address, value_to_burn) # The account is known to exist at this point, thus we consume warm gas. interpreter.consume_gas(2800) return None这段伪代码揭示了几个实现层面的关键点gas 消费顺序基础 100 gas 在栈操作前就先行扣除2800 的动态成本在余额扣减成功后才消费且此时已确认账户存在因此按 “warm” 热路径计费错误传播机制余额不足时返回ErrInsufficientBalance错误标识由解释器interpreter层负责转换为 EVM 回滚revert符合典型解释器“返回错误码、由执行引擎统一处理”的设计状态接口抽象state_db.get_balance与state_db.sub_balance两个接口反映了状态数据库层对“读余额”与“扣余额”的原子性要求——注意这里用的是sub_balance扣减而非“转移”即销毁不产生任何接收方资金直接从供应量中消失零值短路value_to_burn 0与balance 0两个分支都直接返回避免无意义的存储访问这也正是动态 gas 归零的代码体现。从调用链看scope.contract.address()获取的是当前执行上下文即scope中合约的地址。在 DELEGATECALL/CALLCODE 场景下该地址即为发起 delegate 调用的合约地址从而在代码层面落实了“销毁的是委托调用方余额”这一规范语义。设计动机Rationale清理历史遗留的怪异语义EIP-7775 的设计动机Rationale章节直言其目标是清理以太坊中一块历史遗留的怪异语义weird semantics。传统销毁方式把 ETH 转入零地址或无提款能力的合约这在账本上制造了大量“看似有余额、实则不可动用”的幽灵资金对索引器与资金追踪工具极不友好。提案总结的潜在优点Pros与缺点Cons如下优点为智能合约提供清晰、标准化的原生以太销毁方法支持智能合约内对原生代币进行更好的记账accounting实践降低因“被标记为已销毁的原生代币被意外恢复”而引发的智能合约漏洞风险。缺点无法清理已经滞留在现有合约中不可恢复的以太客户端需要新增代码实现黄皮书Yellow Paper需要引入新概念。与仓库中其他销毁相关 EIP 的横向对照本仓库中还有多个与“销毁burn”语义直接相关的 EIP可与 EIP-7775 对照阅读以理解销毁语义在以太坊协议中的演进脉络EIP-1559 Fee market changeFinalEIP-1559 中每区块的基础费base fee由协议直接销毁是当前以太坊主网最主要的 ETH 通缩来源。它是协议层自动销毁与 EIP-7775 的合约内显式销毁形成互补——前者发生在交易费用层面后者是面向合约逻辑的编程原语EIP-6780 SELFDESTRUCT only in same transactionFinalEIP-6780 改变了SELFDESTRUCT的语义规定除合约创建同一笔交易内调用外SELFDESTRUCT不再删除账户同时明确“以自身为受益人的 SELFDESTRUCT 只有在创建同交易内才会销毁 ETH”。这实际上堵住了用 SELFDESTRUCT 作为非正式销毁通道的路径进一步凸显了 EIP-7775 提供显式销毁原语的必要性EIP-7503 Zero-Knowledge WormholesStagnant提出“把 ETH 发送到不可花费地址”后可基于 ZK 证明重新铸造其前提恰恰就是“发送到不可花费地址”这种销毁方式的存在。若 EIP-7775 成为标准销毁将不再产生可验证的“不可花费地址”这类方案的技术前提也需相应演进。需要说明的是EIP-7775 自身在仓库中的状态为Stagnant停滞且其 Test Cases 与 Reference Implementation 章节目前仍为 TODO 占位见 EIPS/eip-7775.md说明该提案尚未形成测试套件与参考实现属于早期设计阶段的规范草案。向后兼容性与激活方式EIP-7775 在 Backwards Compatibility 章节明确指出由于引入了全新的操作码必须通过一次排期硬分叉scheduled hardfork来激活。新增操作码对既有合约完全向后兼容——已部署合约不引用0xFC就不会受到任何影响这与仓库中其他新增操作码类 EIP 的激活方式一致例如 EIP-1109 PRECOMPILEDCALL 同样要求block.number XXXXX时按区块号启用。安全考量DELEGATECALL 的滥用面Security Considerations 章节明确指出一个潜在风险DELEGATECALL 场景下可能被滥用。由于在 DELEGATECALL/CALLCODE 语境中BURN扣减的是发起 delegate 调用方合约的余额若一个合约在设计上允许外部任意调用其内部使用BURN的函数例如通过 delegatecall 代理模式则调用者可能诱导该合约销毁自己的余额造成资金损失。典型场景是代理合约proxy模式若代理逻辑中包含未加权限控制的BURN调用路径任何能触发该逻辑的执行者都可能烧毁代理地址上的 ETH。该章节目前标注为 “Needs discussion”说明提案作者将其视为开放问题期望社区进一步讨论防护模式如要求权限校验、与代理升级模式协同等。总结EIP-7775 通过引入0xFCBURN操作码为 EVM 提供了第一个协议级的原生以太销毁原语从栈上弹出销毁数量、校验当前地址余额、余额不足回滚、零值安全放行并在 DELEGATECALL/CALLCODE 下作用于委托调用方、在 STATICCALL 下强制回滚gas 采用“100 基础 0/2800 动态”的模型。作为 Stagnant 状态的标准跟踪提案它目前尚缺测试用例与参考实现但其对“显式销毁 vs 不可恢复转移”的语义清理思路与 EIP-1559 的协议级销毁、EIP-6780 对 SELFDESTRUCT 销毁路径的限制形成了完整的演进叙事对 L2 跨链回桥与 EVM 链代币经济学设计具有直接参考价值。本文内容基于 EIPS/eip-7775.md 全文规范撰写相关对照资料可继续查阅 EIPS/eip-1559.md、EIPS/eip-6780.md、EIPS/eip-7503.md 与 EIPS/eip-7069.md。版权遵循 CC0见 LICENSE.md。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7775 BURN 操作码：在 EVM 中标准化的原生 ETH 销毁方案
EIP-7775 BURN 操作码在 EVM 中标准化的原生 ETH 销毁方案【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7775 提出在 EVM 中引入一个全新的BURN操作码0xFC用于直接销毁当前执行上下文地址上的原生以太native ether从协议层终结“把 ETH 转到不可花费地址”这一历史遗留的销毁手段。本文基于 EIPS/eip-7775.md 的完整规范结合本仓库内其他 EIP如 EIP-6780、EIP-7503、EIP-1559的销毁语义与调用上下文规则逐条解析BURN的操作数栈行为、余额校验与回滚规则、DELEGATECALL/CALLCODE/STATICCALL下的语境语义、100 动态 gas 计费模型及官方 Python 伪代码。读完本文你将掌握该操作码的完整规范细节、gas 计算方式、与现有销毁手段的异同以及它在 L2 跨链回桥、链上销毁记账等场景中的设计意图。提案背景与动机为什么需要一个专门的销毁操作码历史销毁方式的缺陷在以太坊历史上销毁原生 ETH 一直依赖“把资金转移到不可恢复的地址”这一间接手段常见做法包括转给零地址0x0资金被永久锁定无法被任何人再次动用转给没有提款能力的合约例如 BeaconDepositContract 这类只有存款路径、没有取款路径的合约存入后资金在该地址上变得不可恢复。EIP-7775 的动机章节明确指出这种“看似销毁、实则只是不可恢复地转移”的方式存在两个核心问题语义不清晰从状态账本的角度看资金仍然存在于某个地址的余额字段中只是“无法取出”。这既让索引器indexer和追踪代币流动的工具产生困惑也让审计者难以区分“真实销毁”与“普通转账”存在被误恢复的风险被标记为“已销毁”的原生代币如果因为合约逻辑漏洞或其他原因被意外恢复可能成为智能合约攻击面的一部分。因此该提案希望提供一个明确、标准化、在协议层直接生效的销毁原语BURN操作码在执行时直接从当前地址的余额中扣减指定数额销毁动作对状态变更一目了然不再依赖“转入死地址”的旁路技巧。目标使用场景提案动机中列举了两类主要受益场景Ethereum L2 向 L1 回桥转账当 L2 需要把原生 ETH 桥回 L1 时往往需要在 L2 侧销毁相应数量的 ETH以维持跨链代币总量守恒。一个标准化的BURN操作码能让这一过程在 EVM 内部直接完成而不是依赖约定俗成的“烧毁地址”其他 EVM L1 链的代币经济学凡是需要在链上实现原生代币通缩、销毁机制的 EVM 兼容链都可以复用该操作码作为统一销毁入口。规范BURN 操作码的行为定义本文档中的关键措辞 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、OPTIONAL 均按 RFC 2119 与 RFC 8174 解释。操作码标识与执行步骤BURN操作码的编码值为0xFC其行为规范如下出栈取数从栈顶弹出一个 32 字节的 word将其解释为uint256类型的待销毁原生以太数量单位 wei定位当前地址从 EVM 执行上下文中取出当前执行地址current address读取余额查询该地址的当前余额余额不足即回滚若待销毁数量大于当前地址余额操作码MUST回滚revert零值不回滚若待销毁数量为 0执行MUST NOT回滚扣减余额从当前地址的原生以太余额中减去该数量。值得注意的细节是第 5 条与其他许多操作码不同BURN 0是一个完全合法且无副作用仅消耗基础 gas的调用不会被当作异常处理这为“条件式销毁”的合约逻辑提供了便利。不同调用上下文下的语义EIP-7775 对操作码的语义随调用上下文而变化的情况做了明确规定DELEGATECALL / CALLCODE 上下文BURN操作码实际扣减余额的对象是发起 DELEGATECALL 或 CALLCODE 指令的那个合约而不是被调用代码所在合约。这是因为 delegate 类调用共享调用者的存储、余额与地址语境见下文源码佐证STATICCALL 上下文在静态调用中执行BURNMUST 回滚。这与静态调用禁止一切状态写入的共识规则一致——销毁余额属于状态修改操作在 static 模式下必须被拒绝。这些规则与仓库中现有 EIP 对调用指令语义的描述一脉相承。例如 EIP-7069 Revamped CALL instructions 在定义EXTSTATICCALL时同样要求“若当前帧处于 static-mode 且 value 非零则异常失败”而DELEGATECALL共享调用者地址与余额的语义也与其沿用 EIP-150、EIP-211 等既有调用语义的定位一致。Gas 成本BURN的 gas 成本由基础成本 动态成本两部分组成组成部分数值触发条件基础成本100 gas每次执行必收动态成本0 gas销毁数量为 0动态成本0 gas账户不存在或账户余额为 0动态成本2800 gas其余情况账户存在且余额非零总成本 基础成本100 动态成本0 或 2800。这套计费模型与 EIP-2929 引入的冷/热账户访问定价思想一脉相承2800 的增量对应一次“冷账户访问”cold account access级别的成本而销毁零值或对不存在的账户操作则免费避免无意义的状态触碰。从下文伪代码可以看出2800 的动态成本被注释为 “warm” gas即假设经过前面的余额读取后账户已被视为热访问按热路径计费。官方伪代码逐行解析EIP-7775 提供了一段 Python 风格的伪代码是理解其实现语义最直接的入口完整代码见 EIPS/eip-7775.mddef op_burn(pc, interpreter, scope): # Consume the base gas cost interpreter.consume_gas(100) # Pop the value to be burned from the stack value_to_burn scope.stack.pop() # If the value to be burned is 0, do not revert if value_to_burn 0: return None # Retrieve the current address from the EVM execution context current_address scope.contract.address() # Check the balance of the current address balance interpreter.evm.state_db.get_balance(current_address) # If the value to be burned is greater than the balance, revert if value_to_burn balance: return ErrInsufficientBalance # If the account balance is 0, return. if balance 0: return None # Subtract the value from the current addresss balance interpreter.evm.state_db.sub_balance(current_address, value_to_burn) # The account is known to exist at this point, thus we consume warm gas. interpreter.consume_gas(2800) return None这段伪代码揭示了几个实现层面的关键点gas 消费顺序基础 100 gas 在栈操作前就先行扣除2800 的动态成本在余额扣减成功后才消费且此时已确认账户存在因此按 “warm” 热路径计费错误传播机制余额不足时返回ErrInsufficientBalance错误标识由解释器interpreter层负责转换为 EVM 回滚revert符合典型解释器“返回错误码、由执行引擎统一处理”的设计状态接口抽象state_db.get_balance与state_db.sub_balance两个接口反映了状态数据库层对“读余额”与“扣余额”的原子性要求——注意这里用的是sub_balance扣减而非“转移”即销毁不产生任何接收方资金直接从供应量中消失零值短路value_to_burn 0与balance 0两个分支都直接返回避免无意义的存储访问这也正是动态 gas 归零的代码体现。从调用链看scope.contract.address()获取的是当前执行上下文即scope中合约的地址。在 DELEGATECALL/CALLCODE 场景下该地址即为发起 delegate 调用的合约地址从而在代码层面落实了“销毁的是委托调用方余额”这一规范语义。设计动机Rationale清理历史遗留的怪异语义EIP-7775 的设计动机Rationale章节直言其目标是清理以太坊中一块历史遗留的怪异语义weird semantics。传统销毁方式把 ETH 转入零地址或无提款能力的合约这在账本上制造了大量“看似有余额、实则不可动用”的幽灵资金对索引器与资金追踪工具极不友好。提案总结的潜在优点Pros与缺点Cons如下优点为智能合约提供清晰、标准化的原生以太销毁方法支持智能合约内对原生代币进行更好的记账accounting实践降低因“被标记为已销毁的原生代币被意外恢复”而引发的智能合约漏洞风险。缺点无法清理已经滞留在现有合约中不可恢复的以太客户端需要新增代码实现黄皮书Yellow Paper需要引入新概念。与仓库中其他销毁相关 EIP 的横向对照本仓库中还有多个与“销毁burn”语义直接相关的 EIP可与 EIP-7775 对照阅读以理解销毁语义在以太坊协议中的演进脉络EIP-1559 Fee market changeFinalEIP-1559 中每区块的基础费base fee由协议直接销毁是当前以太坊主网最主要的 ETH 通缩来源。它是协议层自动销毁与 EIP-7775 的合约内显式销毁形成互补——前者发生在交易费用层面后者是面向合约逻辑的编程原语EIP-6780 SELFDESTRUCT only in same transactionFinalEIP-6780 改变了SELFDESTRUCT的语义规定除合约创建同一笔交易内调用外SELFDESTRUCT不再删除账户同时明确“以自身为受益人的 SELFDESTRUCT 只有在创建同交易内才会销毁 ETH”。这实际上堵住了用 SELFDESTRUCT 作为非正式销毁通道的路径进一步凸显了 EIP-7775 提供显式销毁原语的必要性EIP-7503 Zero-Knowledge WormholesStagnant提出“把 ETH 发送到不可花费地址”后可基于 ZK 证明重新铸造其前提恰恰就是“发送到不可花费地址”这种销毁方式的存在。若 EIP-7775 成为标准销毁将不再产生可验证的“不可花费地址”这类方案的技术前提也需相应演进。需要说明的是EIP-7775 自身在仓库中的状态为Stagnant停滞且其 Test Cases 与 Reference Implementation 章节目前仍为 TODO 占位见 EIPS/eip-7775.md说明该提案尚未形成测试套件与参考实现属于早期设计阶段的规范草案。向后兼容性与激活方式EIP-7775 在 Backwards Compatibility 章节明确指出由于引入了全新的操作码必须通过一次排期硬分叉scheduled hardfork来激活。新增操作码对既有合约完全向后兼容——已部署合约不引用0xFC就不会受到任何影响这与仓库中其他新增操作码类 EIP 的激活方式一致例如 EIP-1109 PRECOMPILEDCALL 同样要求block.number XXXXX时按区块号启用。安全考量DELEGATECALL 的滥用面Security Considerations 章节明确指出一个潜在风险DELEGATECALL 场景下可能被滥用。由于在 DELEGATECALL/CALLCODE 语境中BURN扣减的是发起 delegate 调用方合约的余额若一个合约在设计上允许外部任意调用其内部使用BURN的函数例如通过 delegatecall 代理模式则调用者可能诱导该合约销毁自己的余额造成资金损失。典型场景是代理合约proxy模式若代理逻辑中包含未加权限控制的BURN调用路径任何能触发该逻辑的执行者都可能烧毁代理地址上的 ETH。该章节目前标注为 “Needs discussion”说明提案作者将其视为开放问题期望社区进一步讨论防护模式如要求权限校验、与代理升级模式协同等。总结EIP-7775 通过引入0xFCBURN操作码为 EVM 提供了第一个协议级的原生以太销毁原语从栈上弹出销毁数量、校验当前地址余额、余额不足回滚、零值安全放行并在 DELEGATECALL/CALLCODE 下作用于委托调用方、在 STATICCALL 下强制回滚gas 采用“100 基础 0/2800 动态”的模型。作为 Stagnant 状态的标准跟踪提案它目前尚缺测试用例与参考实现但其对“显式销毁 vs 不可恢复转移”的语义清理思路与 EIP-1559 的协议级销毁、EIP-6780 对 SELFDESTRUCT 销毁路径的限制形成了完整的演进叙事对 L2 跨链回桥与 EVM 链代币经济学设计具有直接参考价值。本文内容基于 EIPS/eip-7775.md 全文规范撰写相关对照资料可继续查阅 EIPS/eip-1559.md、EIPS/eip-6780.md、EIPS/eip-7503.md 与 EIPS/eip-7069.md。版权遵循 CC0见 LICENSE.md。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考