ERC-205 创建于 2017 年 2 月 6 日,仓库记录状态为 Stagnant。它提议把合约 ABI 存进 ENS 解析器:调用方报上名字和可接受的编码格式位图,解析器返回 JSON、zlib 压缩 JSON、CBOR 或一个外部 URI 四种形态之一的接口定义。本文按原文拆解四种编码常量、ABI 查询方法签名与先正向后反向的查询顺序,并说明为什么这条发现路径和 NFT 市场连合约时的接口问题有关,以及停滞后今天该用什么替代。
ERC-205 创建于 2017 年 2 月 6 日,仓库记录状态为 Stagnant。它提议把合约 ABI 存进 ENS 解析器:调用方报上名字和可接受的编码格式位图,解析器返回 JSON、zlib 压缩 JSON、CBOR 或一个外部 URI 四种形态之一的接口定义。本文按原文拆解四种编码常量、ABI 查询方法签名与先正向后反向的查询顺序,并说明为什么这条发现路径和 NFT 市场连合约时的接口问题有关,以及停滞后今天该用什么替代。
ERC-2525 创建于 2020 年 2 月 19 日,仓库记录状态为 Stagnant。它设想用用户自己的 ENS 域名当登录入口:应用解析名字,读出 enslogin 文本记录指向的钱包代码地址,下载并执行实例化函数,得到 EIP-1193 提供者。本文拆解两步文本回退、SLIP 44 后缀和配置对象,并说明一个钱包要接入所有应用不必再经谁批准的同时,供应链信任被交给了谁。
ERC-838 创建于 2020 年 8 月 20 日,仓库记录状态为 Draft。它提议给合约 ABI 增加 error 声明,把 REVERT 原因字符串从自由文本升级成带选择器、带参数的结构化错误,让钱包和应用能把失败原因翻译成可读信息。本文拆解 ABI 里错误对象的字段、选择器计算方式、零前缀的兼容设计与 NatSpec 扩展,并说明它和铸造失败排查的关系,以及这条思路后来以什么形态落了地。
ERC-7087 创建于 2023 年 5 月 28 日,仓库记录状态为 Draft。它扩展 ERC-6860 的 web3:// 协议:对没有主动适配协议的合约(自动模式),返回数据的 MIME 类型原本要么隐式要么藏在 data URL 里,本标准要求用 mime.content、mime.type、mime.dataurl 三个查询参数补齐 Content-Type。本文拆解三个参数的取值规则、覆盖优先级和规范自己写明的跨站脚本风险。
ERC-1581 创建于 2018 年 11 月 13 日,仓库记录状态为 Stagnant。它给 BIP32 密钥树里那些不装资产的密钥——加密身份、消息通道密钥等——规定了独立分支,前缀固定为 m/43'/60'/1581',之后按用途类型和键索引展开,长标识按 31 位切层。本文拆解路径每一层的含义、拆分规则的例子,并说明和资金密钥分叉为什么既保隐私又方便备份。
ERC-2645 创建于 2020 年 5 月 13 日,仓库记录状态为 Stagnant,作者是 StarkWare 的工程师。ZK 类 Layer2 用对加密证明友好的新曲线签名,钱包得为它们另生密钥。本文拆解该标准的路径结构——purpose 固定 2645,layer 与 application 取名称哈希的低位作域分隔——以及用反复哈希把密钥压进曲线阶的磨数算法和每轮越界概率小于 2 的负 5 次方的依据。
ERC-1900 创建于 2019 年 3 月 28 日,仓库记录状态为 Stagnant。它设想一个链上类型注册表 dType:把 Solidity 的 struct 连同 isInstanceOf、map、structureBytes 等函数装进类型库合约登记入册,让不同合约对同一份数据说同一种话。本文拆解类型库与类型注册表的结构、配套的存储与函数扩展,并讨论依赖它的跨链身份、链上数据互通等构想为何停在纸面。
ERC-2770 创建于 2020 年 7 月 1 日,仓库记录状态为 Withdrawn,撤回理由写明单一实现无需标准化。它定义一个可扩展的元交易转发合约:按注册过的类型验证 ERC-712 签名,把签名者地址追加进数据再调用目标,让众多合约共享一份验签代码。本文拆解 ForwardRequest 的七个字段、类型注册与 verify、execute 的分工,以及单例合约思路与多实现标准化的矛盾。
ERC-7617 创建于 2024 年 2 月 8 日,仓库记录状态为 Draft,扩展 ERC-6944 定义的 ERC-5219 解析模式。它给 request() 返回的头部引入可选的 web3-next-chunk,值为指向下一块数据的 web3:// URL,协议流式逐块取到没有该头为止,以此在服务端 Gas 限额之下送出任意大小的内容。本文拆解取块循环、URL 合法性与目标合约模式的校验,以及规范自述未发现安全考量的含义。
ERC-7618 创建于 2024 年 2 月 8 日,仓库记录状态为 Draft,同样扩展 ERC-6944 解析模式。它规定 request() 若返回 Content-Encoding 头,且该算法不在客户端 Accept-Encoding 支持列表内,协议必须先解压再转发;gzip 与 brotli 是必须支持的两种编码,解码时不得把该头透传给客户端。本文解释为什么不照搬 HTTP 协商、编码不认识时为何直接报错。