ERC-5018 合约文件系统：把网页装进合约需要哪几个函数

比特币那边把数据塞进见证字段刻铭文，以太坊这侧有人想了另一个问题：一个完整网页不止一张图，HTML 会引用相对路径下的样式、脚本和图片，合约里能不能干脆做一个文件系统？2022 年 4 月 18 日起草的 ERC-5018 给出的答案是一份目录接口，状态停在 Stagnant。它和 web3 网址翻译那套标准是一对搭档：对方负责把一个网址解析成对合约的调用，这份标准负责让被调用的合约长得像一个目录。

目录接口清单

接口按动作分三组。整文件读写：write 把二进制数据以文件名为键写进目录，read 返回内容与存在标志，size 返回大小与块数，remove 删除并返回移除了几块，返回 0 表示文件本来不存在。分块读写针对大文件：writeChunk 按块号写入，块号大于现有块数时拒绝——也就是只允许追加或覆盖已有块，防止跳过空洞；readChunk、chunkSize、removeChunk 按块读取、量尺寸与删除，countChunks 数块。收尾与校验：truncate 砍掉指定块号之后的内容，getChunkHash 返回某个块的哈希，给校验和增量比对用。目录还带一个 fallback，任何带斜杠前缀的名字直接当文件名读，网页里 src 属性的相对引用因此能被原样接住。

把一块块数据拼成文件的动机是现实的：以太坊区块有 Gas 上限，几十 KB 起步的静态资源单笔交易写不完，分块是唯一现实的写入方式；分块之后又引出完整性问题，getChunkHash 就是为此留的挂钩，浏览器端工具可以逐块比对缓存与链上内容。

和铭文路线的镜像关系

比特币铭文把数据切成 520 字节的段塞进脚本的不执行分支，网页类内容靠递归引用互相拼接，在沙箱里渲染；ERC-5018 这一侧数据进的是合约存储，引用靠网址翻译器把相对路径换算成合约调用。两条路线共同面对的问题其实一样：谁有写权限、拼出来的东西能不能变、渲染环境给不给执行脚本。合约文件系统的答案都写在部署里——write 与 writeChunk 要求调用方有写权限，这个权限模型是部署者自定的，标准不做规定；意味着这样一个链上页面完全可能继续被作者改写，也可能在部署时被刻意写死。

原文的 Rationale 里还留着一组诚实的工程权衡：分块让写入变成多笔交易，但读取可以回到单笔——借助 web3 网址，一次调用就能把整个文件取回，因为读函数在合约内把块拼接后整体返回。大文件的写入成本由此摊薄成几笔可负担的交易，代价是写入过程不再原子：中途放弃或只写一半的半成品文件会真实存在于目录里，读取方拿到的是残缺内容，要靠块哈希校验和 countChunks 与预期值的比对才能发现。这个细节对收藏判断有直接影响——一个分块写入的链上网页，在写入完成前的窗口期内本身就是不完整的，展示它的页面若不做校验提示，等于默认残缺版也可以被观看。

所以评估一个住在合约文件系统里的 NFT 页面或站点，顺序应该是：先用目录的读接口把每个被引用的文件拉下来，确认没有指向链下地址的外部资源；查合约所有权与模块，判断谁还握着写函数；用块哈希把当前内容和历史某一时点对一遍。文件系统把网页搬上了链，也把网页时代的所有信任问题原样搬了上来，只是每一层现在都多了一个可以直读的答案。本文为机制说明，不构成任何投资建议。