合约壳子也能瘦身：ERC-7760 最小可升级代理的三种写法

很多人以为”可升级合约”必然占一大段字节码，其实壳子可以小到接近极限。ERC-7760（Minimal Upgradeable Proxies）给出的答案是：把 ERC-1967 代理压到几条指令，同时保留透明代理、UUPS、信标三种模式的完整语义。按以太坊 ercs 仓库记录，该提案状态为 Draft，创建于 2024 年 8 月 19 日。它解决的问题很实际：一个项目动辄部署成百上千个代理合约，每个壳子省下的字节，最后都是部署者与用户实打实付出去的 gas。

三种壳子各管什么

标准的第一个维度是按”谁能升级”分三种代理。透明代理把升级权限留在代理自己身上：普通账户的调用一律转发给实现合约，只有管理员调用升级函数才在代理层处理。这种模式要求代理自己识别”这功能是管理用还是业务用”，代价是字节码稍长。UUPS 反过来，把升级逻辑写进实现合约，代理只负责转发和指向，壳子最薄，但代价是：如果实现合约里忘了保留升级函数，合约将永久无法升级。信标代理则连”实现地址存在哪”都外包：每个代理实例只存一个信标地址，成千上万个实例共用同一份信标登记，升级时改一处、全体生效，适合同一套逻辑批量部署大量实例的场景。

第二个维度：构造参数放哪里

同一标准还处理了初始化参数的存放策略。最省字节的做法是把参数作为不可变数据接在运行字节码尾部，构造函数里只留 deploy 与 upgrade 两段内部逻辑：先用汇编拼出初始化码流，create 出实例，再调用 upgrade 挂上实现合约。参数烤进字节码意味着同一份创建逻辑为每个实例生成略有差异的运行时码；另一组变体则支持链上查询实现，代理不存实现地址而是每次去指定合约问，进一步压缩实例存储。标准还为 14 字节与 20 字节工厂地址分别准备了 initCode 变体，说明它对接的是确定性工厂这类批量部署基础设施。

对 NFT 合约的意义与体检要点

一次 NFT 合集部署的字节账

把三种模式放进一个具体决策里看更清楚。假设一个团队要在六条链各部署一个合集合约，再加一万枚确定性派生的子账户代理：信标模式在每条链只需要维护一个信标合约，一万个实例每个薄到极限，日后升级六次信标即可全量生效，是批量场景下 gas 与维护次数的双赢解，代价是全部实例的逻辑命运绑在同一根线上。透明或 UUPS 模式则每份代理自带实现指针，各合约可以独立升级，权限结构更分散，字节账也更大，适合数量少、彼此需要隔离风险的旗舰合约。标准给出的工厂 initCode 变体还有另一层含义：壳子越小，同一个工厂在相同 gas 上限下能塞进的批量越大，确定性地址方案的实操吞吐也随之上升。选型的正确姿势不是问”哪种最省”，而是先回答”我能否接受全部藏品共用一次升级”——这个答案决定模式，模式再决定字节账。

NFT 项目常用代理部署合集合约，代理壳子的模式选择直接影响持有人的风险结构。透明代理的问题在于合约被迫区分调用者，很多合集干脆避开它；UUPS 要盯实现合约是否保留了升级入口与 ERC-1967 自毁防护；信标模式下，一个信标地址背后可能挂着一整个系列的合集，信标被换意味着整个系列的逻辑一夜改写。体检路径不变：先按 ERC-1967 的公开槽位算法读出实现地址，确认壳子属于哪一种模式；再查升级权限在代理、实现还是信标手里，权限变更有没有事件可查。字节码更薄不等于更安全，瘦的是壳，管住升级钥匙的仍然是壳后面的那把 owner 权限。本文为机制说明，不构成任何投资建议。