不再生成地址也能收款：ERC-2876 的八字节身份与三段校验

交易所给你生成一个“专属充值地址”，听起来很专属，链上真相是：那只是交易所主合约内部记账的一个编号，除非有人给它转过账，区块链上根本没有这个地址存在的痕迹。ERC-2876 想把这件事讲得更诚实，同时把收款基础设施做便宜。摘要的定义是：兼容的收款系统接受多方以太币存款而无需管理多个密钥或使用热钱包；兼容的钱包应用发送以太币时，收款系统能凭标准规定的八字节 id 区分每一笔付款。文档创建于 2020 年 8 月 13 日，仓库记录状态为 Stagnant，属于长期无人推进的归档方案。

被点名批评的三种旧方案

动机部分把当时的收款模式逼到了墙角。每个用户或每张发票新建一个账户的话：若是外部账户，充值账户全是热钱包，安全风险陡增，或者冷钱包团队要为几千个账户逐一手动画扫线；若是合约账户，一个简单的代理合约部署就要至少六万 gas，成本直接劝退。三选一的结果要么高风险、要么高人力、要么高部署费，而提案诞生的背景正是 gas 价格上涨的时期，越来越多服务被迫滑向热钱包收款。省钱的账它也算好了：全部存款先由一个转发合约代收再归集，一笔简单转发交易接近三万 gas，而两笔直接价值转账要四万二——身份变成数据而不是账户，钱就省在部署与归集两端。

八字节怎么拼出来

新格式的关键是把用户身份塞进八个字节。规范拆成三段：整个八字节叫 id，前五个字节（最高有效位）叫 nonce，后三个字节叫校验段。校验段的算法原文写得精确：取二十字节的账户地址与 id 的前五字节共二十五个字节拼接，做 keccak256 哈希，取结果的前三个字节。合约侧的核对逻辑因此一目了然：收到带 id 的调用，用 abi.encodePacked(address(this), bytes5(id)) 重算哈希，比对后三字节，不匹配即视为无效。参考实现里还有一个细节：这个校验以 address(this) 参与拼接——同一组八字节在不同部署合约上校验结果不同，id 天然锁死在特定合约实例上，不能跨系统挪用。

deposit 函数与部分付款

合约接口只有一条核心函数：function deposit(bytes8 id) external payable returns (bool)。返回值语义是这份设计里最容易读错的部分，规范规定：当合约需要保留收到的价值、但以父应用（交易所后台或商户系统）的口径这笔充值尚未完成时，必须返回 false——原文举的例子正好是部分付款：发票五以太币，先转三个返回 false，补转两个返回 true。也就是说返回 false 不等于钱丢了，也不等于转账失败，它说的是业务意义上的“还欠着”。钱包侧要能解析这份语义，否则用户会被一个 false 吓得以为丢币。

归档方案照出的两个今天

这份标准没被采用，但它戳中的两个问题至今每天都在发生。第一，链上可验证性和链上所有权是两回事：八字节 id 有校验段，校验的是“这个 id 和这个主地址在数学上配对”，而不是“这个 id 拥有任何资产”——校验通过、记账出错、归集卡单，全在接口之外。第二，“专属充值地址”的展示方式值得每个用户多问一句：交易所给你看的那串 0x 地址，在链上可能只有它第一次被使用的那笔转账可见，扫块浏览器查不到任何注册记录，这类地址和 ERC-2876 的 id 属于同一种思路的两种包装。实操核对清单：给交易所地址充值大额资产前，先向官方渠道确认到账确认规则与部分付款处理；发现充值页面展示的“专属地址”在多个平台复用同一组字节前缀的，基本可以确定它是记账派生而非链上实体，一切风险以该平台的托管能力为准。本文为机制说明，不构成任何投资建议。