结论先说
以太坊上的一笔操作，可以由别人替你提交、替你付 gas，而合约仍然认得出真正下令的人——这就是 ERC-2771 解决的问题。该提案在 EIP 官方页面上的状态为 Final（最终定稿），创建于 2020 年 7 月，比账户抽象流水线更早。它的核心是一个叫“受信任转发器”的合同组件：用户只在链下签名，转发器把签名重新打包成普通链上交易并支付 gas，同时在 calldata 末尾附上用户的真实地址；信任该转发器的合约在判断“这是谁发起的”时，用末尾附送的地址代替 msg.sender。它与后来的ERC-4337 UserOperation怎么执行？解决同一类体验问题，但走的是合约侧约定俗成的轻量路线。
四个角色怎么分工
规范页面定义了四个角色。交易签名者：用私钥在本地签名，自己不上链广播。Gas 中继：链下服务，收集这些签好名的请求，掏 gas 把它们送上链。受信任转发器：一个被目标合约显式信任的合约，负责验证签名、追加真实发送者地址、再调用业务合约。接收方：接受元交易的业务合约。串起来的链路是：用户签名，链下传给中继，转发器验签后发起标准交易，业务合约从 calldata 尾部截取二十字节的真实发起者地址，然后按正常逻辑执行。整条链路的要点落在“信任”二字：合约只对来自指定转发器地址的请求套用这套解析规则。
为什么“信任”两个字是重点
反过来想就明白了：如果任何人都能在 calldata 末尾附一个自称的发送者地址，攻击者不需要任何签名，就能冒充任意用户。所以 ERC-2771 的安全性完全建立在“入口唯一”上——解析尾部地址的规则只应用于从配置的转发器进来的调用，其他任何地址发起的交易都按普通规则处理或直接被拒。EIP 的安全考虑部分对此写得很明确：合约必须显式配置并只信任指定转发器，不能对所有调用方一视同仁地解析尾部数据。规范还给了一个协议支持发现机制：合约通过 isValidSignature 之类的接口返回它接受的转发器地址列表，集成方在接入前先核对这份名单，避免把交易签给一个没人认账的中间人。
用户实际感受到什么
最常见的场景是第一次进入某个应用：钱包里还没有该链 gas 代币，项目方或合作中继替你付掉第一笔费用；另一类场景是简化操作流、批量动作打包。核验逻辑随之改变：区块浏览器里的交易哈希属于转发器，不属于你，你的“那笔操作”以链下签名的形式存在，所以排查时先看业务合约是否按逻辑给你记了账，而不是找自己名下的广播记录。另一个要知道的服务边界：转发器伪造不了签名者——验签在链上，但它可以选择不出你的请求，比如排队、限流或选择性服务；“受信任”买的是身份正确，不是服务必达。
与账户抽象的分界线
ERC-2771 只解决“让合约认得出真实发起者”这一个环节：谁付 gas、请求怎么进块、防重放的 nonce 怎么管，规范只给了框架，细节由各家的转发器实现自定。从用户视角划分：2771 式代付通常是项目方补贴型福利，换个应用就用不了；想把自己的账户升级成可编程智能账户、自选 gas 支付方，那是账户抽象与 EIP-7702 的地盘。两套机制可以并存，出问题时分清在哪一层——合约不认地址、转发器不干活、还是账户层逻辑报错，查的对象完全不同。
小结
ERC-2771 把“代付代投”写成合约可读的约定：转发器付 gas 上链，在 calldata 尾部附送真实签名者的二十字节地址，合约只对配置过的入口认这个尾注。使用带这类功能的福利交易前查两件事：官方公示的转发器地址是否与合约登记一致，以及该转发器不工作时怎么回退到自付交易。本文为机制说明，依据 EIP 官方页面整理，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。