三条调用指令的差别
以太坊虚拟机里跨合约调用有好几条指令，常被混为一谈。CALL 是常规委托：执行流进入对方地址，存储记账和资金上下文都换到对方名下，目标代码眼中的 msg.sender 变成发起调用的合约。CALLCODE 让当前地址执行目标合约的代码，记账仍落在当前地址，但发起方与金额上下文会被替换成这次调用自身的参数，语义含混，如今基本被弃用。DELEGATECALL 由 EIP-7 在 2015 年 11 月提案、随主网第 1150000 区块的 Homestead 硬分叉上线，它把组合做得最干净：执行流跳进目标合约的字节码，但发起方（CALLER）与附带金额（VALUE）原样从上一层传递过来，存储读写也留在调用方地址名下。EIP-7 规范原文的说法是：子调用拥有与原始调用相同的 sender 和 value。打个比方，A 公司请来 B 公司的流水线上料，但生产记录、库存账本、客户单据全写进 A 公司的本子。
为什么升级靠它
这条语义正是可升级合约的原木。把一个地址固定为代理合约，它自己不存业务数据，收到任何调用就用 DELEGATECALL 把逻辑转发给实现合约；实现合约可以修 bug、换算法，只要存储槽位的排布顺序对得上，换掉实现之后老地址里的数据照常读写。用户眼中那个合约地址永远不变，授权、白名单、缓存都不受影响。反过来说，存储布局成为真正的接口：实现合约若在旧变量之间插入新变量，槽位错位会让资金记账指向错误的格子，这也是升级演练里最常被强调的一点。
信任边界怎么走
对调用者，DELEGATECALL 有一层容易忽略的传递性：被委托的代码以你的身份运行，它可以动用你存储里的权限——比如把管理员角色的地址从你之外改掉，或以你的名义发起代币转账。因此实现合约一旦被替换，等于把整个金库的钥匙交给新代码。另外一个实现细节：这条指令失败时只在栈上留下一个零值，被调用方 revert 携带的数据不会自动传回（要等后来的 Cancun 升级引入相关机制才改变），习惯靠返回值判断成败的合约如果不专门处理，失败会被静默吞掉。
三个词别混：调用者、部署者、拥有者
读代理合约时最容易混淆三个角色。调用者是最初发起交易的外部账户，在 DELEGATECALL 链的任何一层里，CALLER 返回的都是它；部署者是把实现合约放上链的地址，决定源码版本与构造参数；拥有者是存储在某个槽位里的管理员地址，决定能否换实现。同一条指令流里三者身份各自独立，安全审计的核心动作之一，就是分别回答这三问，而不是笼统问这个项目谁说了算。
快速问答
问：DELEGATECALL 会转移 ETH 吗？ 答：不会，它本身不带值，上下文里 ETH 仍归属调用方地址，被执行的代码以调用方余额行动。
问：和 Solidity 的库调用什么关系？ 答：普通内部库函数在编译期直接内联进调用者字节码；带存储引用的外部库调用历史上就靠 DELEGATECALL 语义实现，机制与代理同源。
问：怎么查一个地址是不是转发壳子？ 答：看它的字节码里有没有 DELEGATECALL、再顺着实现地址查存储槽，浏览器看实现地址与管理员。
常见误区
一是把 DELEGATECALL 当普通调用的变体，忽略它以调用方身份跑别人的代码这一信任反转。二是以为换了实现数据会自动兼容，槽位布局才是隐性接口，错位即事故。三是以为调用失败一定留痕，规范规定失败只留一行返回码，不留堆栈，排查要从日志与模拟入手。
风险提示：本文为智能合约机制科普，不构成任何投资建议；与可升级合约交互前请核实其升级权限归属与治理安排。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。