同一个合约代码，第 N 次部署只要一点 Gas：ERC-1167 最小代理

多发行方场景里有个重复劳动问题：一套经过检验的 NFT 合约逻辑，每个项目方部署一遍就要完整上传一遍代码。ERC-1167（Minimal Proxy Contract）给出的答案是一段极简的壳合约：它自己几乎不带逻辑，收到的所有调用原样转发给一个共享的实现合约，整段运行代码只有几十字节。该提案为 Final 状态的标准，本文解释它与 NFT 合约评估相关的那一面——代理关系既是省钱的工程巧思，也是读链时最容易看走眼的结构。

一次调用如何穿过代理

代理合约的内部只回答一个问题：把调用者的数据、金额与调用者地址原封不动转发给实现合约，以 DELEGATECALL 方式执行，再把返回结果带回。DELEGATECALL 是关键中的关键：代码在实现合约里跑，但存储落在代理合约名下。于是一百个代理共享同一份实现代码，各自保有完全独立的所有者、持有人映射与铸造进度——“逻辑复用、状态隔离”就靠这一条语义成立。对 NFT 用户，这解释了一个常见现象：同一个链上可能存在一批“源码一模一样的 NFT 合约”，它们不是抄袭，而是同一实现的一百个克隆，真正的差异藏在各自的构造参数与状态里。

为什么它便宜到成为行业标准

普通代理方案（透明代理、通用可升级代理）运行时要解析逻辑地址、校验入口合法性，动辄几百字节代码。ERC-1167 把字节码压到极简的固定模板，只嵌入一个实现地址，成本优势直接兑换成部署费与铸造路径上的 Gas 节省。它还有更省钱的近亲：ERC-5202 蓝图格式解决 initcode 重复上传的问题，两者都属于“合约复用经济学”的组件——不同之处在于 1167 的代理与实现是两个独立已部署合约，代理里写死实现地址；这层写死既是特性也是局限。

用户必须补做的两步核验

第一步：验证代理时看到的源码只是转发模板，真正的逻辑在实现合约。只读代理页等于什么都没读——在区块浏览器记下实现地址，把实现合约当作真正的审计对象读它的函数、权限与事件。第二步：查实现合约的来源与状态。标准 1167 代理不做访问控制，理论上它会把调用转给实现里任何人可调的公开函数，因此实现合约自身是否带只读与权限防护、是否可能被自毁或留后门，决定了代理型 NFT 的真实安全水位。

与“可升级 NFT 合约”的关系要分清

常见误区是把 1167 与可升级合约混谈。可升级代理（如带管理存储槽的代理模式）的意义是“把实现地址做成可改的变量”，管理员换实现即换逻辑；而 1167 的最小代理把实现地址烙死在字节码里，按定义不升级。这带来一个对用户干净的结论：纯 1167 部署的 NFT 合约，其逻辑日后不会被“后台换掉”——当然前提是它确实是标准 1167 模板，而非带管理权壳子的仿制品。辨别方式仍然是同一句：看代理字节码形态，读实现合约代码与创建交易。

评估清单：确认代理形态（最小代理还是可升级代理）；实现合约源码是否开源验证与地址一致性；实现是否自毁、是否有 owner 特权函数；克隆家族的同源性判断——用创建交易回溯代理的构造参数，确认它写死的实现地址与你读过的实现一致；若委托给“看起来眼熟”的知名实现，务必逐字节比对源码而非只比名字，名字可以照抄，字节码不能。本文只做机制说明，不构成投资建议。