ERC-3561：给合约升级加一段“零信任等待期”

可升级合约的经典困境：逻辑可以改是优点，能被立刻改成恶意版本是威胁。EIP-1967 定义了代理壳与逻辑分离的主流写法，但管理权限在手的人理论上随时可以换掉代码。ERC-3561 在 2021 年 5 月 9 日提出一个补丁式方案：在透明代理旁边再加三个存储槽，规定任何被指定的新逻辑必须等满一段“零信任期”才能真正上岗。按 ercs 仓库记录，这份提案状态为 Stagnant，动机段落罕见地聚焦一个人群——需要保持匿名又想赢得信任的开发者。

六个存储槽的分工

提案在 EIP-1967 的管理槽与实现槽之外新增四个槽位，每个槽的哈希算法都写明了推导式。候选逻辑槽存放“下一任”地址；升级区块槽记录最早可转正的区块高度；提议区块槽记录“何时才开始接受提议”，管理员可以调一个远期数字把提议权封存，甚至设成极大值彻底焊死代码；零信任期槽存放等待的区块数，且只允许调高不允许调低——这是整个方案的信用锚，规则若是可以双向改，等待期就名存实亡。所有管理员动作必须触发事件，必须挂在权限修饰语后面。

提议、等待、转正三步

流程由三个函数串起来。proposeTo 指定候选逻辑并发出 NextLogicDefined 事件，事件里带上最早生效区块，让围观者可以提前算出日子；等实际区块追上升级区块槽，管理员调用 upgrade 把候选转正并初始化；在转正发生之前，cancelUpgrade 随时可以撤销候选并发出 NextLogicCanceled。零信任期还在默认值 0 时，这份代理的行为与标准透明代理完全一致，一旦设定，整套约束立即生效。这套设计的好处是向前兼容：项目可以公开承诺某个周期数值，用链上数据代替一份免责声明。

匿名开发者与信任数学

原文动机写得坦白：使用升级代理的匿名开发者很难赢得社区信任，而完全禁止升级又会牺牲修错能力，折中办法是让“恶意升级在数学上需要提前公示”。把这段翻回普通读者的视角，它给出一个可操作的合约体检法。检查一个标榜可升级的合约（包括发行藏品的合约），在 EIP-1967 槽之外还可以扫一眼提案定义的几个额外槽位：有没有下一任逻辑被暗中提名、它的最早生效区块是哪天、零信任期参数被设成了多少。即便合约没实现这份标准，同样的读法也适用于任何把“提名到生效”拆成两步的升级设计——重点永远是中间那段等待是否被写死、缩短它需要什么权力。

提案没有解决的事

诚实的边界同样要说：等待期防的是突袭式换逻辑，防不了逻辑本身被预埋后门，也防不了管理员在合法升级里夹带有害但“合规”的改动；它把信任从“相信管理人不变坏”降级成“相信等待期公告与区块计数”，信任没有消失，只是换了位置。作为 Stagnant 提案，它更像一份给代理标准社区的思想实验，但它提出的那笔账——哪些承诺可以完全交给代码计时器——至今仍是评估任何托管、锁仓、升级合约时的核心一问。

与常见代理写法的相处方式

普通读者几乎不会直接实现这份提案，但会频繁路过它服务的场景——藏品合约、市场合约、金库合约的升级按钮。读法可以统一成三步：先在区块浏览器的存储槽页面确认项目是不是代理壳，EIP-1967 的实现槽与管理槽是常规第一站；再查管理地址是个人钱包、多签还是时间锁，这决定升级动议从哪扇门进来；最后找项目方对升级公示期的公开承诺，能给出链上可验证数字的承诺，比任何路线图都硬。即便项目没实现 ERC-3561，同样的提问框架照样成立：提名与生效之间隔了多久、谁能缩短、缩短时事件是否可查。这份 Stagnant 提案的全部遗产可以压缩成一句话——可升级不是罪，说不清升级节奏才是问题；把节奏变成区块计数器的想法，值得写进每一份合约体检清单的首页。

本文为机制说明，不构成任何投资建议。