什么是 tx.origin 和 msg.sender？合约判断调用者时为什么不能混用
msg.sender 表示当前调用者，tx.origin 表示交易最初发起者。本文讲清调用链身份、钓鱼授权、代理、元交易和安全检查方法。
用户调用恶意合约，恶意合约再调用你的钱包合约。此时谁是调用者？对钱包合约来说，msg.sender 是恶意合约；tx.origin 仍是最初发起整笔交易的用户。如果权限检查错用了 tx.origin，恶意合约就可能“借着用户本人发起交易”通过验证。
两者都能指向地址，却描述调用链的不同位置。理解它们，是读懂合约授权、代理、中继和钓鱼风险的基础。
msg.sender 回答“当前这一步是谁叫我”；tx.origin 回答“整条交易最初是谁发起”。授权通常必须围绕当前调用上下文设计。
一条调用链里的身份变化
假设 Alice 调用合约 A，A 再调用 B：
| 执行位置 | msg.sender | tx.origin |
|---|---|---|
| A | Alice | Alice |
| B | 合约 A | Alice |
Solidity 官方文档定义 msg.sender 为当前消息调用的发送者，tx.origin 为完整调用链最初的交易发起者，并提醒 msg 的成员会随外部调用变化。
为什么 tx.origin 授权会被钓鱼
一个钱包合约若写 require(tx.origin == owner)，用户访问恶意合约并发起交易后，恶意合约再调用钱包。钱包看到 tx.origin 仍是 owner，于是通过检查；msg.sender 则会暴露当前调用者其实是恶意合约。
- 攻击者诱导用户调用恶意合约，例如领取、铸造或游戏操作。
- 恶意合约在执行中调用受害钱包的转账函数。
- 钱包用 tx.origin 检查 owner，得到最初用户地址。
- 权限通过，资产被转给攻击者指定地址。
这不是私钥泄露，而是授权条件把“用户发起了某笔交易”误解成“用户授权当前每一层调用”。
是不是永远不能读 tx.origin
安全共识是不要用它做身份授权。某些分析、兼容或反合约逻辑可能读取它，但“要求 tx.origin == msg.sender 来阻止合约调用”也会损害智能账户、代理和可组合性，而且不能成为可靠安全边界。协议应明确支持哪些调用模型，而非依赖交易起点猜测意图。
msg.sender 也不是自动安全
正确使用 msg.sender 仍需访问控制、签名验证和业务规则。若函数本来就允许任意调用者指定受害者，或 trusted forwarder 配置错误，检查当前调用者也可能不足。安全取决于“谁被允许做哪件事”，不是换一个变量就完成。
delegatecall 下会怎样
delegatecall 执行目标代码时保留当前调用上下文，msg.sender 和 msg.value 不像普通外部 call 那样改成目标关系。这让代理实现能看到用户，但也要求实现代码理解自己运行在代理上下文。不能把普通 call 的直觉直接套用。
元交易为什么要用 _msgSender
在 ERC-2771 等元交易中，用户签名请求，由可信转发器支付 Gas 并调用目标合约。目标合约看到原生 msg.sender 是转发器，需要通过经过验证的上下文提取真实签名者。OpenZeppelin ERC2771Context 提供 _msgSender 等机制。
这不等于改用 tx.origin。转发器可能由另一个账户提交，tx.origin 只是付费或发送交易的人，不是授权签名者。目标必须信任特定转发器并验证约定格式。
| 场景 | 授权身份来源 |
|---|---|
| 普通直接调用 | msg.sender |
| 合约间调用 | 当前调用合约的 msg.sender |
| ERC-2771 元交易 | 可信转发器验证后的 _msgSender |
| 离线签名授权 | 签名恢复、域、nonce 与期限 |
| 智能账户 | 账户自身的验证与模块规则 |
Multicall 和上下文
批量调用可能通过 self-delegatecall 执行多个函数。与 ERC-2771 等非标准上下文组合时，子调用的发送者与 calldata 后缀处理需要兼容实现。OpenZeppelin 新版本 Multicall 对非 canonical context 做了专门适配。开发者应使用匹配版本并测试，而不是自行复制旧代码。
开发者检查清单
- 全局搜索 tx.origin，确认没有用于 owner、角色、资产或敏感操作授权。
- 梳理每个函数在直接、合约、代理、中继和智能账户调用下的身份。
- 使用成熟 Context、ERC2771Context 和访问控制实现。
- 可信转发器可更新时，保护更新权限并监控变化。
- 离线签名加入域、nonce、期限和明确动作。
- 编写恶意中间合约测试钓鱼调用与嵌套路径。
普通用户能做什么
钱包弹窗显示你在调用一个网站合约，不代表后续只执行该合约自身逻辑。使用交易模拟查看内部调用和资产变化，不要仅凭顶层函数名确认。陌生网站要求执行“验证钱包”交易时格外谨慎，普通登录通常不需要链上资产操作。
常见误区
- “tx.origin 更接近真人所以更安全”：它无法表达用户是否授权中间合约执行敏感动作。
- “msg.sender 永远是用户钱包”：合约调用时它是上一层合约。
- “不支持合约调用能防机器人”：这不是可靠安全边界，还会破坏智能账户与组合性。
- “元交易可以用 tx.origin 找用户”：应验证签名并通过可信上下文解析。
最后总结
- msg.sender 是当前调用者，会随外部调用变化。
- tx.origin 是整笔交易起点，不应作为授权依据。
- 代理、元交易、智能账户和批处理需要明确的上下文设计。
- 权限安全来自正确的身份验证与最小授权，而不是猜测交易起点。
风险提示：恶意合约可在一次用户交易中发起多层内部调用。签名前请核验内部调用、授权对象和资产变化。本文仅作技术科普，不构成任何投资建议。
本文为链上指南原创内容。技术依据参考 Solidity 全局变量官方文档与OpenZeppelin Meta Transactions 文档。