合约为什么看不见你的原始交易：EIP-3508 的三个数据操作码

你发的一笔交易，合约只看到一小截

在以太坊上点一次「确认」，钱包广播的是一整笔交易：接收方是谁、携带多少 ETH、附带哪段输入数据。但如果你的交易先到一个聚合合约，再由它依次调用其他合约，链条深处的合约并不能回看整笔交易的原始内容——每一条 CALL 指令都会开启新的执行上下文，每个上下文只携带自己的输入数据。这就是很多人对「链上可见性」的第一层误解：交易在浏览器里人人可查，不等于执行时每个合约都能读到它。能公开验证的是链上存了什么；执行过程中合约能访问什么，是另一套完全不同的规则。

合约为什么看不见你的原始交易：EIP-3508 的三个数据操作码图 2 — 合约为什么看不见你的原始交易：EIP-3508 的三个数据操作码 · 图 2

三条新指令把源头数据开给全链路

EIP-3508 在 2021 年 4 月 16 日提交，想给虚拟机加三条指令：ORIGINDATALOAD（0x47）按字节偏移从原始交易数据里取一个 32 字节字，行为对应现有的 CALLDATALOAD；ORIGINDATASIZE（0x48）返回原始数据的长度，对应 CALLDATASIZE；ORIGINDATACOPY（0x49）把原始数据的一段复制进内存，对应 CALLDATACOPY。三条指令与现有对应物的唯一区别，就是数据源从「当前调用的输入」换成「整笔交易最初始的 data 字段」。配套提案 EIP-3520 又加了一条 ENTRYPOINT（0x4a），让合约能读到这笔交易最初的接收方地址——与数据指令配合，就能回答「这次调用最初是谁、冲着哪个合约发起的」。两份提案按 EIPs 仓库原文核验时均为 Stagnant，从未上链。

省的是哪笔 Gas

动机部分算的是传数据的账。多层调用想把同一份大结构体送到第三层合约，现实做法是第一层把它作为参数转给第二层，第二层再转给第三层——同一份字节被反复装进调用数据、反复拷贝，每装一次按字节收费一次，payload 一大还可能撞上每笔交易的 gas 上限。原文列举的受益场景包括验证默克尔证明的合约和链下数据进链的 Layer2 类方案：数据本来就随交易进来了，让每一层直接去源头读，就能把 O(层数×数据量) 的搬运费压成一次读取。提案顺带提到一个副作用：完全依赖源头数据的合约，天然能确认自己处理的数据没被中间合约篡改过——因为数据根本没经过中间人之手。

编号彩蛋：那三个槽位后来给了谁

提案挑选的 0x47、0x48、0x49 三个操作码槽位后来并不安静。按 EIPs 仓库各原文标注：0x47 在 2019 年 3 月提交的 EIP-1884 里给了 SELFBALANCE（2021 年柏林升级上线），0x48 在 2021 年 1 月的 EIP-3198 里给了 BASEFEE——后者随 EIP-1559 费用市场上线，如今真实运行在主网。也就是说，EIP-3508 若复活，指令编号必须重新挑选。这个细节对读者的实际用处是：在资料里看到 0x48 出现，先确认语境——它指的是已上线的 BASEFEE，而不是这份停摆提案里的 ORIGINDATASIZE，两者毫无关系。

普通用户该用它读什么

把机制翻回日常：交易输入数据字段本身怎么解码，本栏目在交易的输入数据字段怎么读：四字节选择器、参数槽位与解不出来的情况里讲过四字节选择器与参数槽位，本文补充的是「多层调用下数据长什么样」这一维度。签名前在钱包里看到复杂调单时，值得建立三个判断：第一，页面上展示的 to 地址只是第一跳，实际资金走向由后续调用决定，浏览器里的内部交易列表才是完整链路；第二，合约之间转交数据时可能改参数，中间合约的可信度因此不是抽象问题——聚合器、路由器类合约正是在这一层做文章；第三，「原始数据不可见」意味着依赖中间层转达的合约只能信任直接调用者，这是设计缺陷也是防线，第三方合约声称「我看到的和你签的一样」时，你需要的是链上核对而不是口头承诺。

停摆多年，为什么还值得读

EIP-3508 停在 Stagnant 的理由原文没有展开，从后续历史看，虚拟机改进路线长期让位于扩容与安全议题。但它描述的问题一个字没变：跨合约的数据搬运仍然按字节收费，路由器和 L2 桥仍然要在每一层重新装填参数，社区隔几年就会重新提出类似方案。读懂它，也就读懂了为什么复杂的 DeFi 调单往往比直转贵一个数量级——差价的一部分正是这份「层层转包」的数据搬运费。