ERC-875 一次转一批：早期 NFT 标准的批量与索引设计

今天绝大多数 NFT 都长在 ERC-721 上，一枚一枚地铸造、授权、转移。但在 2018 年 2 月，一份编号 ERC-875 的提案曾试图给不可同质代币定另一条路：用数组一次转一批，还把原子交换写进接口本身。按 ercs 仓库记录，这份提案的最终状态是 Withdrawn（已撤回），创建时间为 2018 年 2 月 8 日。它没有变成基础设施，但它提出的问题——批量太贵、换货要信任中间人——恰好是后来大量 NFT 标准反复修补的方向。理解它，是理解 ERC-721 为什么长成现在这样的一个好切口。

接口长什么样：数组就是钱包

ERC-875 的合约有 name 与 symbol 两个描述函数，但它对不可同质代币的处理和 ERC-721 很不一样。balanceOf 直接返回一个 uint256 数组，也就是这个地址持有的全部代币编号列表；transfer 的第二个参数同样是一个数组，一条交易就能把多枚代币转给对方，提案原文强调这正是相对早期逐枚转账的省费点。transferFrom 允许被授权方按数组批量代转。合约另有可选的 totalSupply 与 ownerOf：提案作者认为有些资产是随时增发的，总量未必固定，所以把总量查询列为可选而不是必选。

一个关键设计是：代币本身没有链上元数据字段。一枚代币就是合约内账本上的一个索引号，图片、属性、名称都不在标准管辖范围内。这省下大量存储，代价是市场、钱包和索引器必须各自去链下找一份”编号到内容”的对照表，对照表一旦对不齐，不同平台对同一编号显示的东西就可能不同。

原生原子交换：trade 函数

ERC-875 独有的部分是 trade 函数：把一组编号连同接收地址一起提交，用于同一合约内多枚代币的以物换物式记账。这种设计瞄准的是收藏卡类场景——我有三张你缺的卡，你有两张我缺的，一笔交易里同时完成，不存在一方转了另一方不转的信任缺口。后来的 ERC-721 生态要靠 Seaport 这类订单合约才能做的事，ERC-875 想直接在代币合约里解决。

为什么被放弃

撤回提案没有写明唯一原因，但从机制上能看到几条张力。其一，代币只是索引号，没有标准挂点承载元数据，恰好与后来”链上编号加链下内容”的主流叙事相反；其二，按数组记账意味着每次查询持有人都要拖出整个数组，与 ERC-721 的映射加事件相比，索引方式完全不同，工具生态难以两头兼容；其三，2018 年初 CryptoKitties 带火了 ERC-721，同一时期再造一套不兼容接口的网络效应门槛极高。它的批量思路并没有消失：ERC-1155 用批量接口解决了一次签多笔的问题，ERC-5216 给 1155 补上按数量授权，都是同一条问题线上的后续答案。

从账本结构再看一层，ERC-875 与 ERC-721 的分野是”清单优先”还是”映射优先”。875 把每个地址的持币清单当作一等公民，一次读出全部编号；721 把每个编号的归属当作一等公民，查询单枚归属只读一个映射槽。前者的读接口对钱包极友好，写接口却要在每次转移时增删数组元素，Gas 随清单长度浮动；后者单笔操作成本稳定，代价是列出全部持仓要么遍历海量事件，要么依赖 ERC-721A 与 ERC-2309 这类后补的批量与连续记账方案。当年 875 赌的是读多写少的收藏场景，后来生态用事件索引器解决了读端问题，于是写端成本稳定的 721 胜出。这也解释了为什么今天批量转账的省费方案全部长在同一方向：不是改变账本形状，而是在不动映射的前提下把多笔事件压进同一次执行，例如 1155 的批量接口与 4521 为 721 补的兼容通道。

对今天的持有人意味着什么

现在几乎不会再有新的 ERC-875 部署，但极早期藏品里偶有类似”合约内索引即资产”的结构。遇到这类合约时，先确认市场与钱包用的是哪份编号对照，再核对链上 Transfer 类事件与显示内容是否一致；编号对不上的展示错误，与资产丢失是两回事。批量操作在今天的正确姿势仍是优先找合约原生批量接口，而不是逐枚连发多笔交易。本文为机制说明，不构成任何投资建议。