EIP-7819 详解用 SETDELEGATE 指令在协议层实现可升级的智能账户克隆【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7819 提出在 EVM 中新增一条SETDELEGATE指令操作码0xf6允许智能合约像部署 ERC-1167 克隆一样在协议层直接创建与 EIP-7702 完全一致的委托指示器delegation indicator。本文以 eip-7819.md 为骨架结合 EIP-7702、EIP-2929、EIP-7523、EIP-3541 等关联规范完整拆解其设计动机、指令行为、地址推导、Gas 成本、向后兼容性与安全边界。读完本文你将理解 SETDELEGATE 与克隆/代理的差异、如何在工厂合约中用它部署可升级或不可升级的智能账户以及它为何能显著压缩区块链状态占用。背景为什么需要一种新的克隆方式克隆与代理的固有取舍链上大量应用尤其是账户抽象方案需要在不同地址部署同一份代码的多个实例。当前主流手段有两类最小克隆如 ERC-1167将实现地址直接编码进字节码极其轻量但无法升级可升级代理如 ERC-1967实现地址存放在存储槽中灵活可升级但每次调用都要从存储读取实现地址成本更高。无论哪种方式用 EVM 代码做调用转发都存在两个结构性缺点Calldata 必须先从交易数据复制到内存再执行 delegate call如果未来启用 EOFEVM 对象格式用 EOF 编写的克隆/代理无法向 legacy EVM 代码的实现做委托导致实现被锁定在 legacy 形态阻碍生态演进。EIP-7702 委托指示器带来的新可能EIP-7702Final 状态为 EOA 引入了一种新对象——委托指示器一段恰好 23 字节的代码0xef0100 || address执行类指令CALL、DELEGATECALL等遇到它时自动跟随指针加载目标地址的代码。EIP-7819 观察到同样的对象完全可以复用于合约场景——由合约调用SETDELEGATE创建委托账户从而把调用重定向从用户空间userspace搬到协议层既获得升级能力又省掉存储查询。链上数据佐证EIP-7819 引用了 Geth 团队在 EthCC 上的研究Not all state is equal约 5000 万已部署合约中97.1% 对应的是被多次部署的代码且28.6% 的独有字节码小于 1 KiB——克隆与代理大概率占其中很大比例。将这类合约迁移到仅 23 字节的委托指示器对用户交互成本下降和网络状态增长放缓都是正向收益。典型应用场景文档列出的目标场景包括Safe 一类的传统智能合约钱包账户ERC-4337 兼容的智能账户需要随 EntryPoint 新版本升级EIP-8141Frame Transaction等走向抗量子账户的提案所隐含的大量新部署。账户抽象视角从二选一到三者皆可智能账户由一个或多个密钥拥有、用于替代 EOA 的合约常用克隆或代理指向单例实现被迫在可升级与不可升级之间二选一不可升级代码有 bug 或功能受限时会被困住可升级每次调用都要付出读取存储地址的成本。SETDELEGATE让工厂合约可以部署可升级变体不增加查找成本部署不可升级变体复用同一 salt 即失败选择性锁定部分账户的升级能力。升级机制与选择性锁定都在工厂层完成账户自身无需实现任何升级逻辑。同时把调用重定向从用户空间移到协议层意味着更少的 EVM 操作、更低的 Gas 消耗——不仅影响签名验证和 user operation 执行也包括带回调的资产转账如 ERC-721、ERC-1155 代币。可扩展性23 字节 vs 708 字节文档给出的量化对比非常直观OpenZeppelin 的 ERC-1967 代理约708 字节而 EIP-7702 委托指示器仅23 字节。大规模部署下状态占用可被显著压缩同时转发逻辑从执行期搬到协议层节省的 Gas 与区块空间可以用于合约的实际执行。规范SETDELEGATE 指令SETDELEGATE的新操作码为0xf6执行过程如下扣除EMPTY_ACCOUNT_COSTGas若当前帧处于static-mode立即停机Halt从操作数栈弹出salt与target计算location keccak256(DESIGNATOR address salt)[12:]将location加入accessed_addresses按 EIP-2929 定义若location处的代码非空且不以0xEF0100开头即既非空、也非委托指示器立即停机若location已存在于状态树中向全局退款计数器refund counter添加EMPTY_ACCOUNT_COST - BASE_COSTGas将location的代码设为DESIGNATOR target与 EIP-7702 的委托流程一致若target为0x0不写入指示器而是清除代码并将 code hash 重置为空哈希0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470若location账户的 nonce 为 0将其递增为 1将location压入操作数栈。关于 target 的字节约束第 8 步中target必须恰好为 20 字节从栈中取出的值不足 20 字节按大端序左补零超过 20 字节截断最高位字节。最终写入location的代码必须恰好 23 字节0xef0100 20 字节地址与 EIP-7702 完全一致。即时生效与行为等价性委托在操作完成时立即生效——从下一操作开始对该地址的调用就会执行新委托的代码。由SETDELEGATE创建的委托指示器与 EIP-7702 创建的是同一类对象因此 EIP-7702 中记录的所有行为细节同样适用包括CODESIZE/CODECOPY作用于实际执行的代码而非指示器本身EIP-7702 中明确委托账户的EXTCODESIZE返回 23而CODESIZE返回目标地址代码的大小目标为预编译地址时视为空代码调用以空代码成功返回委托链/环不解析客户端只取第一层代码不再继续跟随未来的任何 EIP 若修改 EIP-7702 委托指示器的行为也应同样作用于SETDELEGATE创建的指示器。与 SELFDESTRUCT 和空账户的关系委托指示器不是合约即使在同一交易中SELFDESTRUCT触发了账户创建也无法通过SELFDESTRUCT删除。委托的销毁只应由创建它的同一调用者以相同 salt、零 target 再次执行SETDELEGATE来实现。第 9 步的 nonce 递增确保即使余额为零、从未写入状态、代码又被零 target 的SETDELEGATE移除账户因 nonce ≥ 1 而永远不会退回空账户状态——这正是 EIP-7523Last Call禁止 post-merge 网络出现空账户的要求。参数表EIP-7819 直接复用 EIP-7702 的参数ConstantValueDESIGNATOR0xef0100EMPTY_ACCOUNT_COST25000BASE_COST12500对照 EIP-7702 的常量表PER_AUTH_BASE_COST 12500、PER_EMPTY_ACCOUNT_COST 25000可见二者完全同源。EIP-7702 的12500由其影响评估得出101 字节 calldata1616 签名恢复3000 读取 nonce 与代码2600 已热账户写入200 部署 23 字节代码4600≈ 12016向上取整为 12500。设计动机Rationale深度解析Gas 成本为何可以比 EIP-7702 更便宜与 EIP-7702 授权元组处理相比SETDELEGATE的执行少了三个环节无签名恢复ecrecover无专用 calldata——除交易层面已支付的成本外无需额外计费无 nonce 更新第 9 步的初始置 1 除外。因此其执行成本本可以低于 EIP-7702但文档选择直接复用 EIP-7702 的数值以求简洁。即便如此25000仍低于CREATE/CREATE2的成本足以在目标场景中保持竞争力。地址推导确定性且防碰撞location由keccak256(DESIGNATOR address salt)[12:]推导镜像了CREATE2的确定性寻址但预映像长度为 55 字节与现有地址推导方案刻意区分详见下文向后兼容性。其中address是调用者地址salt由调用者选择——这与CREATE2中部署者 salt的语义一一对应也意味着同一调用者用相同 salt 只能管理同一 location。向后兼容性地址碰撞分析文档用严密的预映像长度论证排除了碰撞风险与 CREATE2 的碰撞CREATE2 地址由85 字节预映像推导而 SETDELEGATE 是 55 字节长度不同从根本上排除预映像碰撞与 CREATE 的碰撞CREATE 地址由RLP([address, nonce])推导。要让其预映像达到 55 字节nonce 需为 32 字节此时 RLP 编码为0xf694addressa0nonce不以0xef0100开头nonce 更小时预映像虽可能以0xef开头但会短于 55 字节且前缀为0xef940x94编码 20 字节地址对象仍与 SETDELEGATE 的预映像前缀不同。与 EIP-3541 的关系委托指示器复用了被 EIP-3541Final禁用的0xef前缀字节。EIP-3541 禁止新部署的合约代码以0xEF开头该字节代表 EOF magic而 EIP-7702 / EIP-7819 的委托指示器恰好借助这一保留字节区分为特殊对象0xef0100是 EIP-7702 选定的 magic 前缀客户端据此识别委托而不将其当作普通可执行代码。两套规范在此形成互补而非冲突。安全考量委托的升级与删除由工厂控制由于复用了 EIP-7702 的零 target 即清除代码行为工厂合约可以加检查禁止复用已用 salt→ 委托指示器不可变immutable允许受限升级但禁止删除→ 可升级且可追溯。无论如何委托生命周期的一切保证都来自调用它的合约而非协议本身。工厂需要根据自己的信任模型显式设计这些约束。委托链与环与 EIP-7702 一致委托链/环不会被解析这一点与克隆不同但开发者对此并不陌生——代理链同样可能产生无限委托循环等意外。工厂可主动校验target自身是否含委托指示器来规避此类风险。初始化前插Front-Running免疫EIP-7702 的签名可被放入任意交易若实现不校验初始化参数的真实性就可能遭遇初始化抢跑。而SETDELEGATE由智能合约执行可以在同一原子交易内、委托创建后立即完成初始化逻辑——这正是开发者熟悉的创建克隆/代理后立即初始化模式天然免疫该攻击。单交易内多次委托变更若合约在同一交易中以相同 salt 不同 target 多次执行SETDELEGATE同时对相应地址发起调用则在无 revert 的情况下一个地址会在交易内关联多个先后不同的代码值其中两个或更多会被实际执行包括委托被反复移除/重置。文档明确指出这在传统可升级合约中早已可能修改某个存储槽即改变实现地址因此不是新引入的风险。与其他 EIP 的关系一览关联规范作用EIP-7702委托指示器的定义与全部行为细节必读前置requires: 7702EIP-2929accessed_addresses集合与冷/热账户定价第 5 步引用EIP-7523空账户禁令第 9 步 nonce 置 1 的直接依据EIP-35410xef前缀保留委托指示器识别基础ERC-1167 / ERC-1967被对比的克隆 / 可升级代理方案ERC-4337 / EIP-8141智能账户与抗量子账户等目标应用场景实施视角的注意事项EIP-7819 当前状态为Draft属于 Standards Track / Core 类别创建于 2024-11-18依赖 EIP-7702。阅读与实施时请注意所有行为语义CODESIZE/CODECOPY、预编译目标、委托链、跨 EIP 行为同步以 EIP-7702 为准两者必须一并实现客户端实现应复用 EIP-7702 已有的委托解析与accessed_addresses记账逻辑避免出现行为分叉工厂合约设计者应自行落实 salt 复用策略、target 校验防链与升级权限控制协议层不提供任何默认保证。小结EIP-7819 用一条指令把 EIP-7702 的委托机制从EOA 专用推广为通用部署原语它让合约在协议层创建仅 23 字节、可升级、可锁定、可清除的克隆同时规避了 calldata 复制、存储查询与 EOF/legacy 委托不兼容等经典痛点。对账户抽象生态Safe 类钱包、ERC-4337 智能账户、抗量子账户迁移而言这是一个既能压缩状态、又能降低每笔交互 Gas 的方向性提案其后续演进值得持续关注。本文内容基于 EIPS/eip-7819.md 及其在仓库中的关联规范整理版权声明见 LICENSE.mdCC0。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7819 详解：用 SETDELEGATE 指令在协议层实现可升级的智能账户克隆
EIP-7819 详解用 SETDELEGATE 指令在协议层实现可升级的智能账户克隆【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7819 提出在 EVM 中新增一条SETDELEGATE指令操作码0xf6允许智能合约像部署 ERC-1167 克隆一样在协议层直接创建与 EIP-7702 完全一致的委托指示器delegation indicator。本文以 eip-7819.md 为骨架结合 EIP-7702、EIP-2929、EIP-7523、EIP-3541 等关联规范完整拆解其设计动机、指令行为、地址推导、Gas 成本、向后兼容性与安全边界。读完本文你将理解 SETDELEGATE 与克隆/代理的差异、如何在工厂合约中用它部署可升级或不可升级的智能账户以及它为何能显著压缩区块链状态占用。背景为什么需要一种新的克隆方式克隆与代理的固有取舍链上大量应用尤其是账户抽象方案需要在不同地址部署同一份代码的多个实例。当前主流手段有两类最小克隆如 ERC-1167将实现地址直接编码进字节码极其轻量但无法升级可升级代理如 ERC-1967实现地址存放在存储槽中灵活可升级但每次调用都要从存储读取实现地址成本更高。无论哪种方式用 EVM 代码做调用转发都存在两个结构性缺点Calldata 必须先从交易数据复制到内存再执行 delegate call如果未来启用 EOFEVM 对象格式用 EOF 编写的克隆/代理无法向 legacy EVM 代码的实现做委托导致实现被锁定在 legacy 形态阻碍生态演进。EIP-7702 委托指示器带来的新可能EIP-7702Final 状态为 EOA 引入了一种新对象——委托指示器一段恰好 23 字节的代码0xef0100 || address执行类指令CALL、DELEGATECALL等遇到它时自动跟随指针加载目标地址的代码。EIP-7819 观察到同样的对象完全可以复用于合约场景——由合约调用SETDELEGATE创建委托账户从而把调用重定向从用户空间userspace搬到协议层既获得升级能力又省掉存储查询。链上数据佐证EIP-7819 引用了 Geth 团队在 EthCC 上的研究Not all state is equal约 5000 万已部署合约中97.1% 对应的是被多次部署的代码且28.6% 的独有字节码小于 1 KiB——克隆与代理大概率占其中很大比例。将这类合约迁移到仅 23 字节的委托指示器对用户交互成本下降和网络状态增长放缓都是正向收益。典型应用场景文档列出的目标场景包括Safe 一类的传统智能合约钱包账户ERC-4337 兼容的智能账户需要随 EntryPoint 新版本升级EIP-8141Frame Transaction等走向抗量子账户的提案所隐含的大量新部署。账户抽象视角从二选一到三者皆可智能账户由一个或多个密钥拥有、用于替代 EOA 的合约常用克隆或代理指向单例实现被迫在可升级与不可升级之间二选一不可升级代码有 bug 或功能受限时会被困住可升级每次调用都要付出读取存储地址的成本。SETDELEGATE让工厂合约可以部署可升级变体不增加查找成本部署不可升级变体复用同一 salt 即失败选择性锁定部分账户的升级能力。升级机制与选择性锁定都在工厂层完成账户自身无需实现任何升级逻辑。同时把调用重定向从用户空间移到协议层意味着更少的 EVM 操作、更低的 Gas 消耗——不仅影响签名验证和 user operation 执行也包括带回调的资产转账如 ERC-721、ERC-1155 代币。可扩展性23 字节 vs 708 字节文档给出的量化对比非常直观OpenZeppelin 的 ERC-1967 代理约708 字节而 EIP-7702 委托指示器仅23 字节。大规模部署下状态占用可被显著压缩同时转发逻辑从执行期搬到协议层节省的 Gas 与区块空间可以用于合约的实际执行。规范SETDELEGATE 指令SETDELEGATE的新操作码为0xf6执行过程如下扣除EMPTY_ACCOUNT_COSTGas若当前帧处于static-mode立即停机Halt从操作数栈弹出salt与target计算location keccak256(DESIGNATOR address salt)[12:]将location加入accessed_addresses按 EIP-2929 定义若location处的代码非空且不以0xEF0100开头即既非空、也非委托指示器立即停机若location已存在于状态树中向全局退款计数器refund counter添加EMPTY_ACCOUNT_COST - BASE_COSTGas将location的代码设为DESIGNATOR target与 EIP-7702 的委托流程一致若target为0x0不写入指示器而是清除代码并将 code hash 重置为空哈希0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470若location账户的 nonce 为 0将其递增为 1将location压入操作数栈。关于 target 的字节约束第 8 步中target必须恰好为 20 字节从栈中取出的值不足 20 字节按大端序左补零超过 20 字节截断最高位字节。最终写入location的代码必须恰好 23 字节0xef0100 20 字节地址与 EIP-7702 完全一致。即时生效与行为等价性委托在操作完成时立即生效——从下一操作开始对该地址的调用就会执行新委托的代码。由SETDELEGATE创建的委托指示器与 EIP-7702 创建的是同一类对象因此 EIP-7702 中记录的所有行为细节同样适用包括CODESIZE/CODECOPY作用于实际执行的代码而非指示器本身EIP-7702 中明确委托账户的EXTCODESIZE返回 23而CODESIZE返回目标地址代码的大小目标为预编译地址时视为空代码调用以空代码成功返回委托链/环不解析客户端只取第一层代码不再继续跟随未来的任何 EIP 若修改 EIP-7702 委托指示器的行为也应同样作用于SETDELEGATE创建的指示器。与 SELFDESTRUCT 和空账户的关系委托指示器不是合约即使在同一交易中SELFDESTRUCT触发了账户创建也无法通过SELFDESTRUCT删除。委托的销毁只应由创建它的同一调用者以相同 salt、零 target 再次执行SETDELEGATE来实现。第 9 步的 nonce 递增确保即使余额为零、从未写入状态、代码又被零 target 的SETDELEGATE移除账户因 nonce ≥ 1 而永远不会退回空账户状态——这正是 EIP-7523Last Call禁止 post-merge 网络出现空账户的要求。参数表EIP-7819 直接复用 EIP-7702 的参数ConstantValueDESIGNATOR0xef0100EMPTY_ACCOUNT_COST25000BASE_COST12500对照 EIP-7702 的常量表PER_AUTH_BASE_COST 12500、PER_EMPTY_ACCOUNT_COST 25000可见二者完全同源。EIP-7702 的12500由其影响评估得出101 字节 calldata1616 签名恢复3000 读取 nonce 与代码2600 已热账户写入200 部署 23 字节代码4600≈ 12016向上取整为 12500。设计动机Rationale深度解析Gas 成本为何可以比 EIP-7702 更便宜与 EIP-7702 授权元组处理相比SETDELEGATE的执行少了三个环节无签名恢复ecrecover无专用 calldata——除交易层面已支付的成本外无需额外计费无 nonce 更新第 9 步的初始置 1 除外。因此其执行成本本可以低于 EIP-7702但文档选择直接复用 EIP-7702 的数值以求简洁。即便如此25000仍低于CREATE/CREATE2的成本足以在目标场景中保持竞争力。地址推导确定性且防碰撞location由keccak256(DESIGNATOR address salt)[12:]推导镜像了CREATE2的确定性寻址但预映像长度为 55 字节与现有地址推导方案刻意区分详见下文向后兼容性。其中address是调用者地址salt由调用者选择——这与CREATE2中部署者 salt的语义一一对应也意味着同一调用者用相同 salt 只能管理同一 location。向后兼容性地址碰撞分析文档用严密的预映像长度论证排除了碰撞风险与 CREATE2 的碰撞CREATE2 地址由85 字节预映像推导而 SETDELEGATE 是 55 字节长度不同从根本上排除预映像碰撞与 CREATE 的碰撞CREATE 地址由RLP([address, nonce])推导。要让其预映像达到 55 字节nonce 需为 32 字节此时 RLP 编码为0xf694addressa0nonce不以0xef0100开头nonce 更小时预映像虽可能以0xef开头但会短于 55 字节且前缀为0xef940x94编码 20 字节地址对象仍与 SETDELEGATE 的预映像前缀不同。与 EIP-3541 的关系委托指示器复用了被 EIP-3541Final禁用的0xef前缀字节。EIP-3541 禁止新部署的合约代码以0xEF开头该字节代表 EOF magic而 EIP-7702 / EIP-7819 的委托指示器恰好借助这一保留字节区分为特殊对象0xef0100是 EIP-7702 选定的 magic 前缀客户端据此识别委托而不将其当作普通可执行代码。两套规范在此形成互补而非冲突。安全考量委托的升级与删除由工厂控制由于复用了 EIP-7702 的零 target 即清除代码行为工厂合约可以加检查禁止复用已用 salt→ 委托指示器不可变immutable允许受限升级但禁止删除→ 可升级且可追溯。无论如何委托生命周期的一切保证都来自调用它的合约而非协议本身。工厂需要根据自己的信任模型显式设计这些约束。委托链与环与 EIP-7702 一致委托链/环不会被解析这一点与克隆不同但开发者对此并不陌生——代理链同样可能产生无限委托循环等意外。工厂可主动校验target自身是否含委托指示器来规避此类风险。初始化前插Front-Running免疫EIP-7702 的签名可被放入任意交易若实现不校验初始化参数的真实性就可能遭遇初始化抢跑。而SETDELEGATE由智能合约执行可以在同一原子交易内、委托创建后立即完成初始化逻辑——这正是开发者熟悉的创建克隆/代理后立即初始化模式天然免疫该攻击。单交易内多次委托变更若合约在同一交易中以相同 salt 不同 target 多次执行SETDELEGATE同时对相应地址发起调用则在无 revert 的情况下一个地址会在交易内关联多个先后不同的代码值其中两个或更多会被实际执行包括委托被反复移除/重置。文档明确指出这在传统可升级合约中早已可能修改某个存储槽即改变实现地址因此不是新引入的风险。与其他 EIP 的关系一览关联规范作用EIP-7702委托指示器的定义与全部行为细节必读前置requires: 7702EIP-2929accessed_addresses集合与冷/热账户定价第 5 步引用EIP-7523空账户禁令第 9 步 nonce 置 1 的直接依据EIP-35410xef前缀保留委托指示器识别基础ERC-1167 / ERC-1967被对比的克隆 / 可升级代理方案ERC-4337 / EIP-8141智能账户与抗量子账户等目标应用场景实施视角的注意事项EIP-7819 当前状态为Draft属于 Standards Track / Core 类别创建于 2024-11-18依赖 EIP-7702。阅读与实施时请注意所有行为语义CODESIZE/CODECOPY、预编译目标、委托链、跨 EIP 行为同步以 EIP-7702 为准两者必须一并实现客户端实现应复用 EIP-7702 已有的委托解析与accessed_addresses记账逻辑避免出现行为分叉工厂合约设计者应自行落实 salt 复用策略、target 校验防链与升级权限控制协议层不提供任何默认保证。小结EIP-7819 用一条指令把 EIP-7702 的委托机制从EOA 专用推广为通用部署原语它让合约在协议层创建仅 23 字节、可升级、可锁定、可清除的克隆同时规避了 calldata 复制、存储查询与 EOF/legacy 委托不兼容等经典痛点。对账户抽象生态Safe 类钱包、ERC-4337 智能账户、抗量子账户迁移而言这是一个既能压缩状态、又能降低每笔交互 Gas 的方向性提案其后续演进值得持续关注。本文内容基于 EIPS/eip-7819.md 及其在仓库中的关联规范整理版权声明见 LICENSE.mdCC0。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考