以太坊合约里最常用的一条身份指令是CALLER：谁调用了我。它忠实但短视——只回答上一跳。外部拥有账户发的交易经过转发合约、代理合约、DELEGATECALL链，到真正干活的那段代码时，CALLER可能已经变成了某个中间合约的地址。EIP-3520在2021年4月提出一条ENTRYPOINT指令：不看上一跳，看最上游，返回当前这笔交易的入口地址——也就是交易原始接收者，若无接收者（合约创建交易）则返回零地址。提案状态是Stagnant。
为什么要知道最初派给了谁
一个具体到日常的例子是签名钱包和智能合约钱包。用户把交易发给钱包合约，钱包合约验完签名和授权限额后，再调目标协议。协议合约里的CALLER是钱包，不是用户。想按用户维度记台账——每个用户使用了多少额度、是否命中黑名单——就只能依赖钱包合约传参自报身份，而自报是可以撒谎的。ENTRYPOINT给合约一个不能撒谎的参照：这笔交易在链上的原始收件人。提案动机段写得很清楚，这既服务访问控制，也让钱包类应用能可靠地记录交易归属。
它和CALLER、TXORIGIN的三角关系
熟悉以太坊的人第一反应是：这角色不是有TXORIGIN吗？恰恰相反，三者定位完全不同。TXORIGIN返回发起交易的账户地址——即签名者，容易被钓鱼合约拿去做钓鱼比对；CALLER返回直接调用者——即上一跳；ENTRYPOINT返回交易的原始接收地址——即第一跳的目的地。一个场景分输赢：钓鱼合约诱导用户直接给它发交易时，TXORIGIN和ENTRYPOINT高度重合，正规协议靠对比二者可以拉响警报；正常场景下用户发给智能钱包，ENTRYPOINT是钱包地址，TXORIGIN是用户地址。三条坐标互补，谁也替代不了谁。
为什么停在原地
指令本身没有安全黑洞——它只是把一个原本就在交易数据里的字段暴露给合约。阻力在别的层面：对绝大多数协议来说CALLER加显式传参已经够用；智能账户生态又很快找到了协议外围的解法，4337把用户身份写进Operation结构的sender字段，验证和执行的上下文里身份自带；以太坊的后续身份类提案（比如把签名者变成可查询指令的系列讨论）吸引了同样的注意力。一条锦上添花、共识成本为零但收益同样分散的指令，很难挤进任何一次升级的载荷清单，六个月沉默后自动挂Stagnant。
一条边界测试
设想一个没有ENTRYPOINT的世界会怎么实现同样的检查：钱包给协议的每个接口加一个用户地址参数，协议再信任钱包一回。于是问题变成协议能否验证这个参数——验证依赖钱包代码路径，代理升级换了逻辑就全盘失效。ENTRYPOINT想提供的正是把这类验证从信任链上摘下来的快捷方式。反过来说，它的Stagnant状态也提醒合约作者：任何依赖转发方自报身份的协议，都要假设对方会升级、会出错、会被劫持。
一次转发的完整记账
把一笔典型的多跳交易摊开：用户从外部拥有账户签名，交易主体是发给智能钱包合约的调用，钱包验签后再调一个路由器合约，路由器最后调协议金库。协议金库抬头看CALLER，得到路由器地址——路由器是公共合约，所有用户共用一个，按它记账毫无信息量；查TXORIGIN得到用户账户地址，但这要求金库信任签名者即操作者，而智能账户场景下签名者可能只是门槛之一；ENTRYPOINT给出钱包合约地址——一个用户专属、不可伪造、与用户一一绑定的锚点。金库把台账记在这个锚上，再配合钱包链上代码的哈希查询，就能在不信任任何转发声明的前提下重建用户维度视图。三种坐标各有用，缺的那一格恰恰是转发世界的身份证。
快速问答
问：ENTRYPOINT会暴露用户隐私吗？ 答：它返回的是交易的接收方，本来就在每笔交易里公开，没有新增泄露。 问：和账户抽象冲突吗？ 答：不冲突，提案动机本身就是让智能钱包生态把身份检查写得更直白。
风险提示：本文描述技术提案，不构成任何投资建议。提案状态以EIP官网为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。