0x01 开头的交易几乎灭绝了：EIP-3709 当年想把类型一请出钱包

交易类型表里最短命的成员

以太坊的交易统一装在带类型字节的封套里（见 交易封套是什么？EIP-2718 为什么给交易加类型字节）：最原始的交易没有类型字节，往后依次编号。2020 年 EIP-2930 拿下类型一，给交易加了访问列表 access list，让发送人提前声明这笔操作会碰哪些地址和存储槽，换更准的 Gas 计量。不到一年，EIP-1559 拿下类型二（见 EIP-1559 是什么？以太坊费用怎么由基础费和小费决定），把单一 gasPrice 换成最高费用与优先费两个字段。问题就此出现：类型一本质上是”旧费用结构加一个访问列表”，伦敦升级之后，它既有 1559 用户想要的费用体验的缺失，又不比类型二多出任何结构优势——它唯一的独特性只是一个已经落后一步的组合。EIP-3709 在 2021 年 8 月提出，建议从钱包和服务提供方这一侧把类型一淘汰掉，提案状态至今是 Stagnant。

提案给的升级规则很具体

这并非共识层改动，提案的对象明确写着钱包与 providers：若用户请求签名的交易是类型一（类型字节 0x01），软件应把它改写成类型二再处理。字段映射规则逐条给出：access_list 原样保留；type 从 0x1 改成 0x2；gas_price 字段删除，改为按 1559 规则填 max_fee_per_gas 与 max_priority_fee_per_gas 两个字段。换句话说，提案认为既然类型二本身就带访问列表，继续向用户提供”不带 1559 费用的带访问列表交易”没有任何理由。这类”接口层淘汰”的思路绕开了 hardest fork：不改任何节点规则，老类型继续被链接受，只是工具链不再生产新用户。

访问列表为什么没成为用户功能

值得多说一句的是 access list 本身的命运。它设计上允许用户用”预付小额 Gas 押金”锁定访问路径，但普通钱包几乎从不向用户暴露这个字段，能精确算出列表的只有机器人和少数开发工具。当绝大多数交易的类型二里 access list 都是空数组时，“类型一才有列表、类型二没列表”的原始叙事已经反转——类型二包含了列表字段，类型一反而成了列表能力与费用体验都落后的那一个。3709 的动机部分正是围绕这一点展开：推向类型二本来就是目标，保留类型一只增加签名工具的分叉维护成本。

今天还能撞见类型一吗

在主流 EVM 主网上，普通用户主动发出类型一交易的路径基本消失：主流钱包的默认签名结构、RPC 节点的 gas 价格建议体系都围绕 1559 组织。会撞见 0x01 的场景大多在角落：老脚本原样重放、某些低兼容工具链的默认值、以及浏览器上按类型字节筛历史数据时读到的旧记录。查看自己某笔交易的类型很直接：区块浏览器的交易详情页或节点返回的交易对象里有 type 字段，0x02 是当前的主流形态，无此字段则多半是 legacy。回执里的 effectiveGasPrice 与两项费用上限（见 预估和账单对不上：用回执里的 gasUsed 与 effectiveGasPrice 反算实际手续费）也只在 1559 后的类型上有完整语义。

提案留下的三点经验

第一，以太坊的交易演化是”只加不改”的加法，新类型登场时旧类型不被废除，淘汰靠工具链的自然迁移，3709 是少数给这个迁移写下显式规则的建议。第二，看协议演进时，“某功能是否还支持”与”某功能是否还有人在用”是两个问题，前端工具的行为比共识规则更能决定普通用户实际用哪条路。第三，对做自动化转账与对账的团队，把签名请求里 type 字段的默认值写进配置核查清单，能避免旧库默认发出费用结构落后的交易、在费用高峰被卡住。

顺带把查看路径说具体：在节点侧用 eth_getTransactionByHash 取回交易对象，类型交易在返回里带 type 字段，十六进制的 0x1 与 0x2 一望即知；老客户端返回 legacy 交易时该字段缺席，用 gasPrice 与 maxFeePerGas 哪组字段有值也能倒推类型。浏览器页面通常把类型折叠在详情标签里，找”Transaction type”或”类型”一行即可，不需要解析原始字节。本文为机制解读，不构成投资建议。