ERC-7827 带版本的 JSON 合约：链上档案的每一行都有前世今生

NFT 合约的链上配置常是一种尴尬的存在：改一次值，旧值就从状态里蒸发，只有翻历史区块才能找回；而大多数工具只读最新值。ERC-7827（JSON Contract with Value Version Control）给这类“链上 JSON 文档”定了个最小接口，特点只有一个——每一次写入都自动留下键级别的版本链，读取方能对任何一个键问出“它以前都是什么”。按以太坊 ercs 仓库的记录，提案状态为 Draft，创建于 2024 年 11 月 7 日。

三个函数的分工：全量读、历史读、批量写

接口面小到了极限。json() 返回当前完整 JSON 字符串，是日常查询的主入口；version(key) 按键返回一个 JSON 数组，按时间顺序排列该键的全部历史值——最早版本在零号位，最新值在数组末尾，换句话说，某个字段的全部修改史不需要解析器去挖区块，一次调用直接给出；write(keys, values, replace) 是唯一的写入口，keys 与 values 两个数组按下标配对，replace 参数决定冲突行为：为真时覆盖既有键，为假时若键已存在则整笔交易回退，给“只新增、不覆盖”的登记场景一个保险栓。三个函数全部围绕一份文档对象，没有权限模型、没有并发协议，标准把治理留在了实现层。

这种结构适合什么，什么时候别用

标准把成本问题挑得很明：JSON 上链天生费 gas，规范选择用最朴素的办法控制复杂度——所有值一律按字符串存，编码效率交给客户端库；同时给合约留了一条硬提醒，必须防住无上限的数组写入，否则一次恶意的 write 就能让之后每次读写都贵到难以承受，这是典型的存储型拒绝服务路径。落到使用侧的翻译：这类合约合理的用途是目录页而不是仓库，长文本与二进制留在内容寻址存储里，链上只放短字段和指针；version 数组的长度也值得盯，一个被高频改写的键会把读取成本一路推高，必要时得迁移到新合约给历史封箱。

与内容寻址路线对照，这条链上 JSON 路线的分工很清楚：文件级内容归 IPFS 与 Arweave，靠哈希保证内容不可改；配置级键值归这类合约，靠版本数组保证变化可追。一个成熟的项目常常两者并用——图片与长文进内容存储，链上 JSON 只存指针、开关与期限，version 函数记录的恰是指针换过哪些版本，等于给元数据生命周期装上行车记录仪。尽调时这个组合比任何单独方案都更能回答“项目方悄悄改过什么”这个高频问题。

权限模型留白还带来一个提示：同一份接口既可以是透明档案也可以是不透明的权力工具，区别全在谁能调 write。看到链上 JSON 合约时先查它的访问控制——无限制开放写入的，读来当参考即可；写入绑定了角色或时间锁的，其内容才具备与承诺近似的数据地位。

它的甜点位在中低频、小体量的配置与档案：项目参数表、合集的公开设置、需要历史可追的活动说明。版本链把“配置什么时候变成这样”从取证问题降级成查询问题，审计与争议回溯的成本显著下降。但容量账要算在前面：键值以字符串形式存进合约存储并逐版保留，JSON 里塞大对象（整段 SVG、长列表）会让读写 gas 快速膨胀，历史数组更是单调增长，某键改得越频繁、查询返回越大。因此合理的用法是把这份 JSON 当作目录页而非仓库——正文放内容寻址存储，链上键值只放指针与短字段，版本链管的就只是“指针换过哪些地址”。权限设计也不能省略：write 谁能调、要不要时间锁，标准不规定，实现必须自己补上并写进文档。读一份这类合约时，先看 json() 里的字段是否全是指针与短值，再看 version 的数组长度是否异常，最后确认写权限归属。标准仍是草案，细节以仓库当前文本为准。本文为机制说明，不构成任何投资建议。