链上存压缩包：ERC-7618 让 web3:// 客户端解压再显示

链上存储贵是写死在所有设计题面前的大前提。同样一张可渲染的矢量图，原始 JSON 与 gzip 后的字节可能要差一个数量级——把压缩后的数据存进合约、需要时再还原，是自然不过的省钱思路。ERC-7618 干的就是给这个思路定规矩：合约照旧返回压缩字节，由协议层负责解压，标准创建于 2024 年 2 月 8 日，仓库记录状态为 Draft，和 ERC-7617 是同一对作者围绕 web3:// 写的一对姊妹提案。

为什么不照搬 HTTP 的协商

HTTP 世界处理压缩的方式是协商：客户端用 Accept-Encoding 报出支持清单，服务器从清单里挑一种算法返回，并用 Content-Encoding 声明。这份标准明确说，在 web3:// 上照搬这套不划算——区块链的存储和计算都受限，合约没有立场根据每个客户端的清单动态选算法。可行的替代是：数据固定以某一种压缩形态存链，解压的活交给协议端。但直接固定 Content-Encoding 头也有坑：HTTP 客户端可能根本不带对方那套压缩库，收到压缩字节却解不开。于是分工变成——协议先看请求头里的 Accept-Encoding，若声明的算法客户端不支持或客户端压根没声明，就在协议内完成解码；协议自身必须支持 gzip 和 brotli 两种编码。

规则的边角

规范用 MUST 措辞钉死了三个细节。其一，若协议要替客户端解码，且声明的 Content-Encoding 不在必须支持列表里，必须向客户端返回不支持的内容编码错误，而不是硬着头皮转发。其二，一旦协议完成了解码，Content-Encoding 头不得再随响应转发给客户端——否则下游会对着已解压的数据二次解压。其三，解码后的明文才是交给客户端的正文。整套规则刻意复用 Content-Encoding 这个 HTTP 老熟人，而不是发明新头，理由是尽量贴近标准 HTTP 语义。

对读者意味着什么

成本这本账可以算得更具体些。链上存储在 Gas 价高的时段以每字节数千 Gas 计，一张未压缩的生成艺术 SVG 与它 gzip 后的形态，部署费差距可能达到数倍——这直接决定了不少项目把压缩存链当成默认选项，而不是优化项。brotli 与 gzip 并列进必须支持清单也值得一提：前者通常比 gzip 再省一至两成，代价是并非所有客户端都自带解压器，于是协议端解压成了弥合手段。把整条规则链合起来读，合约作者真正要守的是两端：字节确实以声明的算法压缩、声明的算法必须落在 gzip 或 brotli 之列；中间的网络路径不需要聪明，只需要规矩。顺带一提，标准的安全考量一栏原文写着未发现安全考量——不是没有问题，而是压缩解压本身不引入新信任面，这个措辞本身就是给读者的提示：这一层没有攻击面，也没有保护，数据的真伪仍要回到内容哈希与合约出处去核。

把两条姊妹标准并排读，能看清 web3:// 协议族的拼图顺序：ERC-7617 让大资源能传完，ERC-7618 让大资源能存小，两者都刻意不动 ERC-6944 的接口本身，只在响应头与字节形态上做增量——这套只改约定不改签名的小步演进，是协议在链上约束下迭代的典型样本。给普通读者的操作提示同样朴素：如果某个链上作品显示空白或乱码，先在另一台支持 brotli 与 gzip 的浏览器或网关重试一次，再怀疑合约坏了；显示正常但体积可疑（比如一张本该几百 KB 的图渲染得异常粗糙），则不妨直接读它的 request 返回声明的 Content-Encoding 与实际字节长度，用字节和哈希说话。

对作品侧，这条标准给了链上生成艺术一个现实的体积策略：存压缩字节、由网关解压，费用换存储。对浏览侧，它解释了为什么有些 web3:// 作品页对压缩支持好的现代网关显示正常、对老工具则干脆报错——报错往往正是标准要求的正确行为，而不是故障。顺带一个防坑直觉：遇到要求你在本地自行解压链上数据再查看的第三方工具，优先选按标准声明编码格式的一方，因为解压这一步没有密码学证明，拿到的明文对不对，最终仍要回到内容哈希和合约出处去核。本文为机制说明，不构成任何投资建议。