隔空读别人的存储槽：EIP-2330 的 EXTSLOAD 想用便宜十倍换可预测

合约读别人账本，为什么这么贵

每个人都能用区块浏览器查任意合约的存储，但执行中的合约做不到——合约之间的数据往来只能靠函数调用。想读一个 ERC-20 代币在某地址的余额，正经做法是 CALL 对方的 balanceOf，这一路要付出：跨合约调用本身、把参数按 ABI 编码、对方合约加载代码、分发到对应函数、函数内部再读一次槽。EIP-2330 的动机部分把这称为「registry 型合约」的困境：ENS 解析器、代币余额表这类结构，底层其实就是简单映射，可调用方却要为整套仪式买单，而且 view 函数可能顺手读好几个不相干的槽，成本雪上加霜。

EXTSLOAD 的规格：两个入参一个出参

2019 年 10 月 29 日提交的 EIP-2330 由 Dominic Letz 与 Santiago Palladino 提出，给虚拟机加一条指令 EXTSLOAD（0x5c）：从堆栈弹出两个值——被读合约的地址和存储槽号——然后把那个合约存储里对应槽的值压回栈；目标账户不存在时按原文规定压 0。Gas 部分按提案写作时的计价环境，等于账户访问费加存储读取费之和，账户若已在访问集合里则访问费为零，这套热冷计价正是它的依赖项 EIP-2929 定义的。原文给出了两个关键词：贵了十倍以上的场景有望降十倍，而且成本变得可预测——不再取决于对方 view 函数内部顺手读了几个槽。

0x5c 这个编号，后来的真主人

这里有一个查资料时必须弄清的撞车。EIP-2330 挑中的 0x5c 槽位，真正把它用上的是坎昆升级（2024 年 3 月）带来的 TLOAD——瞬时存储读取指令，出自 2018 年 6 月就提交、多年后才落地的 EIP-1153。也就是说今天虚拟机里 0x5c 的行为与 EXTSLOAD 毫无关系；这份提案若复活也得换编号。同一号段附近，2020 年 9 月的另一份 Stagnant 提案 EIP-2936 也曾圈定 0x5c 做清理用途，两份提案的候选槽位互相重叠，属于提案生涯不了了之的注脚之一。按 EIPs 仓库原文核验时，EIP-2330 状态为 Stagnant，主网不存在「合约隔空读他人存储」这条指令。

与链下读法、访问列表的分工

这条假想指令针对的读者场景其实有两类，先分清才不会用错工具。链下应用读槽位从来不需要它：任何节点都有 eth_getStorageAt 这类接口，直接返回某合约某槽的原始值，读懂键怎么拼见 eth_getStorageAt怎样读映射槽？，映射键的计算规则在 Solidity 存储布局讨论里也有专文，槽位算术可参考 Solidity存储槽位怎么计算？。提案要救的是链上场景——比如一个路由器合约想在校验里顺手查对方登记表的成本能否承受。另一条常被拿来对照的现实路线是访问列表：2718 类型交易允许预先声明将触碰的地址与槽，让同笔交易内的读取走热价，这是「声明换折扣」，而 EXTSLOAD 是「直读省仪式」，机制方向完全不同，访问列表的计价细节可看 区块怎么汇总访问列表：EIP-2930 访问列表与区块级的 EIP-3584。

用户视角：省的是执行费，验证费一分不少

把提案翻成中文搜索结果里的高频问题：「跨合约读取为什么那么贵」「为什么 DeFi 复杂操作费高」。答案之一就在上面那笔账里。但普通持有者更应从边界读起：第一，这条指令从未生效，任何教程声称「用 EXTSLOAD 检查合约」都要立刻警惕；第二，即使有一天生效，它读的也只是原始槽位，含义仍要靠目标合约的存储布局解释——读到的 32 字节本身没有语义；第三，它不改变存储公开这一事实，链上数据的可读性带来的隐私问题不因提案生灭，敏感信息永远不要写上链。

为什么停摆至今

原文没有写停摆原因，从技术侧能看出线索：提案要求以访问列表计价为前提，而 2929 在 2020 年底才随柏林升级上线，赶上了；但「给裸读开侧门」与「通过接口信任合约逻辑」两种世界观在社区长期拉锯，直接读槽绕过了对方代码的任何逻辑，读到的一致性无法保证（合约可能在多个槽间维护不变量）。这份权衡没有共识，提案就停在原地。读懂它，你就理解了合约世界里一个基本事实：数据公开不等于数据易读，更不等于可读即可靠。

风险提示

本文涉及的指令编号、提案状态与计价描述按 EIPs 官方仓库原文核验，可能随社区推进变化，请以仓库当前内容为准。本文不构成投资建议；解读合约数据请结合官方文档，谨防以过时机制为名的诈骗教程。