大文件如何走 web3://：ERC-7617 用分块头绕过 RPC 的 Gas 上限

完全链上的作品有个物理天花板：合约函数返回多大数据，受限于单次调用的 Gas 上限。网页服务可以流式吐出几十兆文件，链上调用不行。ERC-7617 专门处理这个矛盾：在 web3:// 协议的 ERC-5219 解析模式（也就是 ERC-6944 定义的 resolve 模式）里，让合约可以一次只交一小块，再用一个头部告诉客户端下一块去哪取。标准创建于 2024 年 2 月 8 日，仓库记录状态为 Draft，与 ERC-7087 出自同一对作者。

一个头部引发的循环

机制浓缩成一句话：ERC-6944 的 request() 返回一个 headers 键值数组，本标准为它新增可选成员 web3-next-chunk，值是一条完整或相对的 web3:// URL，指向资源数据的下一个分块。协议处理首次调用结果时，立刻把状态码、头部和正文交给客户端；若发现 next-chunk 头，就解析那条 URL——URL 非法，或目标合约没有使用 ERC-6944 解析模式，流式传输就地报错终止；一切正常则对那条 URL 再调 request()，忽略返回里的 statusCode，把 body 作为下一块数据续上，若再带 next-chunk 就继续循环，直到某个响应不再携带该头。块与块的顺序完全由这条链决定，没有索引字段。

设计取向与盲区

Rationale 解释了这个方案为什么便宜：它不改 ERC-6944 的接口一行代码，只在响应头做文章；用 web3:// URL 而非裸函数调用当指针，则给下一块的来源留了灵活性——可以是同一合约另一函数，也可以是另一合约。值得留意的是安全考量一栏原文写着未发现安全考量：协议作者认为本机制只是数据搬运的编排，不引入新的信任问题。这提示读者把注意力放回顾问对象上：谁决定块的顺序并不重要，重要的是每一块都来自解析过的合约调用；同时整条链的完整性没有任何校验，中间块被合约逻辑改动只能靠合约自身保证。

和链上艺术的关系

和传统网页的分块对照着看更容易理解这套设计的成色。HTTP 的 chunked 传输由协议层自动分帧，客户端不用懂内容；这里的分块却把切块责任推回给合约作者——资源要切成几段、每段挂哪个函数、顺序怎么保证，全由合约逻辑说了算。好处是合约可以按需组合：一段返回 HTML 头、一段返回正文、一段按请求者的参数返回动态片段；坏处是没有任何协议级校验保证块不漏、不重、不乱序，合约内部逻辑错了，客户端只会默默少拿到一块。规范对相对 URL 的允许也给链上站点开了组合空间：一个作品的分块指针可以指向同合约另一入口，也可以指向另一合约——读一个复杂 web3:// 页面时，浏览器状态栏里跳来跳去的地址不是卡顿，是分块接力在可见化。

顺带厘清分块与压缩的关系：同一份资源可以同时用两条机制——先按 ERC-7618 声明压缩编码，再按本条分块传输，下一块指针指向同一压缩流的后半段，协议端在拼齐之后再解压交付，两条规则互不冲突。这个组合透露了协议族的分工哲学：分块管体积传输、压缩管存储成本、MIME 管语义渲染，各管一段、互不越界。对搭建链上站点的作者，值得先设计好切块边界再谈其余：把标题段、正文段、动态段分开挂函数，比事后在巨型函数里临时切返回数组更不容易留下对不上的指针。

对把 SVG 或分页渲染逻辑放进合约的作品，分块意味着体积策略从一次性返回改成多函数协作，合约要为每块数据安排可独立调用的入口。对普通浏览者，一条 web3:// 长链背后可能是十几次合约调用的接力，加载时快时慢并不奇怪；如果作品只加载出上半部分就停住，更可能是某个分块指针指向的合约不符合要求，而非网络波动。理解这一层，你就不会把协议层面的取数失败误读成作品被篡改的证据——先取到的是哈希可验的链上字节，后卡住的是取数编排。本文为机制说明，不构成任何投资建议。