把出厂代码存在链上：ERC-5202 蓝图合约格式

每部署一个合约都要把整段创建代码作为交易数据上传一次，链上重复的字节会永久占据区块空间。为省这一笔，工程师发展出“蓝图合约”：把某类合约的 initcode 本身存成一个链上合约，以后的工厂合约用一条指令读它再部署，不必重复搬运。ERC-5202 给这种合约定了格式，当前状态为 Final，创建于 2022 年 6 月 23 日，依赖 EIP-170。NFT 语境里它与“一个项目一个合约”的批量部署模式有关联，本文解释这层关系里的技术底座，不下任何价值判断。

部署合约时到底上传了什么

部署一个新合约走的交易携带的是 initcode——一段“执行一次、产出运行代码”的程序：它执行完毕后返回真正的合约运行代码。以太坊的规则是 initcode 本身不上账，只有产出被存进世界状态，于是每次部署都付一次数据费。蓝图模式改变分工：initcode 作为蓝图合约的“主体”在链上存一份，工厂合约部署时用 EXTCODECOPY 把蓝图主体的字节读进内存，紧跟一条 CREATE 或 CREATE2 完成实例化。批量部署多个结构相同的合约（多发行方复用同一套 NFT 合约模板属于此类场景）时，重复数据的成本从每单一次变成总共一次。

没有前缀的世界：误执行问题

蓝图 idea 早就有，标准要解决的是它的安全尾巴。规范动机部分说得很清楚：EVM 无法原生区分“可执行代码”与“其他字节”，把一段 initcode 原样存成合约主体，除非 initcode 自带访问控制，任何人都能调用这个合约、把 initcode 当普通运行代码执行——若其中写了存储写入、外部调用甚至 SELFDESTRUCT，后果从污染状态到蓝图被销毁不等。工具侧也有痛点：索引器靠字节码模式启发式猜“这是不是蓝图”，既难维护也不可靠。

前缀格式：一个 INVALID 开头的小协议

ERC-5202 的方案极简：蓝图合约的主体必须以 0xFE71 开头的 preamble 起始，其后是 6 位版本字段与 2 位长度编码字段，需要时再接长度字节与可选数据段。规范同时明确 initcode 的长度不写进前缀——想知道蓝图里存了多长的出厂代码，用一条 EXTCODESIZE 现场量取即可，这也是整套前缀能压缩到三个字节起步的底气。选择 0xFE 开头不是为了美观——INVALID 操作码会以异常终止结束执行，误直接调用蓝图合约的路径会被最硬的机制拦下；0x71 取自字符串 blueprint 哈希的末字节，纯粹做身份盐。规范要求蓝图至少携带一字节 initcode，空 initcode 被判违规，防的是低级配置错误。工具识别则从“猜”变成“查前缀”。

对 NFT 使用者的实际意义

蓝图与工厂模式是部署经济学，不是产品功能：它让部署方少花钱、少占空间，对买家的可感知影响通常只有两三个可验证事实。第一，你交易的合约可能只是某蓝图的实例，合约页看到的“验证源码”路径与其他经工厂部署的合约一致，用实例查模板是标准动作；第二，同一模板被多方批量部署时，同源代码、不同参数的合约可以长得几乎一样，蹭名仿冒在“代码相同”的掩护下更难被肉眼分辨——核对的唯一可靠路径仍是比对创建交易与模板蓝图；第三，这套机制本身不提安全性，蓝图只是部署的容器，合约逻辑有没有洞与它无关。

本文只做机制科普，不构成投资建议；格式细节以 ERC-5202 规范当前文本为准。