[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-4-anquan-yuanyu-msg-sender-fangwen-kongzhi-chongren":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d3000000-0000-0000-0000-000000000104","a0000000-0000-0000-0000-000000000032","Deep EVM #4：安全原语——msg.sender、访问控制和重入攻击","deep-evm-4-anquan-yuanyu-msg-sender-fangwen-kongzhi-chongren","EVM执行模型如何创建安全漏洞以及如何预防：msg.sender vs tx.origin、重入攻击、delegatecall风险和访问控制模式。","## EVM层面的安全\n\n智能合约安全不是在工作代码之上添加检查——而是理解EVM的执行模型如何创造攻击面。每次外部调用都是潜在的重入点。每次delegatecall都是存储劫持向量。每个未检查的返回值都是静默失败。\n\n## msg.sender vs tx.origin\n\n这两个值看起来相似但具有根本不同的安全属性。\n\n- **msg.sender**（CALLER操作码）：当前执行上下文的直接调用者。每次CALL都会改变。\n- **tx.origin**（ORIGIN操作码）：发起交易的外部拥有账户（EOA）。永不改变。\n\n### tx.origin攻击\n\n使用`tx.origin`进行认证是一个众所周知的漏洞。修复很简单：**始终使用msg.sender**，绝不使用tx.origin进行认证。\n\n## 重入：DAO攻击模式\n\n重入是最臭名昭著的智能合约漏洞——它导致了2016年6000万美元的DAO黑客事件。模式很简单：外部调用在状态更新完成之前将控制权返回给攻击者。\n\n### 检查-效果-交互模式\n\n标准防御是正确排序操作：\n\n1. **检查** — 验证所有条件（require语句）\n2. **效果** — 更新所有状态变量\n3. **交互** — 最后进行外部调用\n\n```solidity\nfunction withdraw() external {\n    uint256 amount = balances[msg.sender];  \u002F\u002F 检查\n    require(amount > 0, \"No balance\");       \u002F\u002F 检查\n    balances[msg.sender] = 0;                \u002F\u002F 效果（在调用之前）\n    (bool success, ) = msg.sender.call{value: amount}(\"\");  \u002F\u002F 交互\n    require(success, \"Transfer failed\");\n}\n```\n\n### 重入保护\n\n```solidity\nabstract contract ReentrancyGuard {\n    uint256 private constant NOT_ENTERED = 1;\n    uint256 private constant ENTERED = 2;\n    uint256 private _status = NOT_ENTERED;\n\n    modifier nonReentrant() {\n        require(_status != ENTERED, \"ReentrancyGuard: reentrant call\");\n        _status = ENTERED;\n        _;\n        _status = NOT_ENTERED;\n    }\n}\n```\n\n## DELEGATECALL：力量与危险\n\nDELEGATECALL在调用合约的上下文中执行另一个合约的代码。被调用方的代码读写调用方的存储。这是代理模式的基础，但也极其危险。\n\n### 存储碰撞攻击\n\n当通过DELEGATECALL执行时，实现合约的变量写入代理的存储槽。攻击者可以将实现地址设置为自己的合约并接管代理。\n\n修复：使用非结构化存储和伪随机槽（ERC-1967标准）。\n\n## 访问控制模式\n\n### Ownable\n最简单的模式：一个`owner`地址拥有特权访问。\n\n### 基于角色的访问控制（RBAC）\nOpenZeppelin的AccessControl提供多角色管理。\n\n### 多签和时间锁\n对高价值操作，结合RBAC与多签和时间锁。\n\n## MEV机器人的实用安全清单\n\n1. **绝不使用tx.origin** — 使用msg.sender或基于签名的认证\n2. **处处使用CEI模式** — 在外部调用之前更新状态\n3. **检查所有返回值** — 特别是低级调用和非标准代币\n4. **使用访问控制** — 只有你的EOA\u002F多签才能调用提取利润的函数\n5. **实现熔断器** — 检测到异常行为时暂停功能\n\n## 总结\n\nEVM中的安全不是你添加的层——而是你如何构建状态转换相对于外部调用的属性。检查-效果-交互模式、重入保护和谨慎的delegatecall使用不是最佳实践——它们是生存要求。","\u003Ch2 id=\"evm\">EVM层面的安全\u003C\u002Fh2>\n\u003Cp>智能合约安全不是在工作代码之上添加检查——而是理解EVM的执行模型如何创造攻击面。每次外部调用都是潜在的重入点。每次delegatecall都是存储劫持向量。每个未检查的返回值都是静默失败。\u003C\u002Fp>\n\u003Ch2 id=\"msg-sender-vs-tx-origin\">msg.sender vs tx.origin\u003C\u002Fh2>\n\u003Cp>这两个值看起来相似但具有根本不同的安全属性。\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>msg.sender\u003C\u002Fstrong>（CALLER操作码）：当前执行上下文的直接调用者。每次CALL都会改变。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>tx.origin\u003C\u002Fstrong>（ORIGIN操作码）：发起交易的外部拥有账户（EOA）。永不改变。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>tx.origin攻击\u003C\u002Fh3>\n\u003Cp>使用\u003Ccode>tx.origin\u003C\u002Fcode>进行认证是一个众所周知的漏洞。修复很简单：\u003Cstrong>始终使用msg.sender\u003C\u002Fstrong>，绝不使用tx.origin进行认证。\u003C\u002Fp>\n\u003Ch2 id=\"dao\">重入：DAO攻击模式\u003C\u002Fh2>\n\u003Cp>重入是最臭名昭著的智能合约漏洞——它导致了2016年6000万美元的DAO黑客事件。模式很简单：外部调用在状态更新完成之前将控制权返回给攻击者。\u003C\u002Fp>\n\u003Ch3>检查-效果-交互模式\u003C\u002Fh3>\n\u003Cp>标准防御是正确排序操作：\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>检查\u003C\u002Fstrong> — 验证所有条件（require语句）\u003C\u002Fli>\n\u003Cli>\u003Cstrong>效果\u003C\u002Fstrong> — 更新所有状态变量\u003C\u002Fli>\n\u003Cli>\u003Cstrong>交互\u003C\u002Fstrong> — 最后进行外部调用\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-solidity\">function withdraw() external {\n    uint256 amount = balances[msg.sender];  \u002F\u002F 检查\n    require(amount > 0, \"No balance\");       \u002F\u002F 检查\n    balances[msg.sender] = 0;                \u002F\u002F 效果（在调用之前）\n    (bool success, ) = msg.sender.call{value: amount}(\"\");  \u002F\u002F 交互\n    require(success, \"Transfer failed\");\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>重入保护\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">abstract contract ReentrancyGuard {\n    uint256 private constant NOT_ENTERED = 1;\n    uint256 private constant ENTERED = 2;\n    uint256 private _status = NOT_ENTERED;\n\n    modifier nonReentrant() {\n        require(_status != ENTERED, \"ReentrancyGuard: reentrant call\");\n        _status = ENTERED;\n        _;\n        _status = NOT_ENTERED;\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"delegatecall\">DELEGATECALL：力量与危险\u003C\u002Fh2>\n\u003Cp>DELEGATECALL在调用合约的上下文中执行另一个合约的代码。被调用方的代码读写调用方的存储。这是代理模式的基础，但也极其危险。\u003C\u002Fp>\n\u003Ch3>存储碰撞攻击\u003C\u002Fh3>\n\u003Cp>当通过DELEGATECALL执行时，实现合约的变量写入代理的存储槽。攻击者可以将实现地址设置为自己的合约并接管代理。\u003C\u002Fp>\n\u003Cp>修复：使用非结构化存储和伪随机槽（ERC-1967标准）。\u003C\u002Fp>\n\u003Ch2 id=\"\">访问控制模式\u003C\u002Fh2>\n\u003Ch3>Ownable\u003C\u002Fh3>\n\u003Cp>最简单的模式：一个\u003Ccode>owner\u003C\u002Fcode>地址拥有特权访问。\u003C\u002Fp>\n\u003Ch3>基于角色的访问控制（RBAC）\u003C\u002Fh3>\n\u003Cp>OpenZeppelin的AccessControl提供多角色管理。\u003C\u002Fp>\n\u003Ch3>多签和时间锁\u003C\u002Fh3>\n\u003Cp>对高价值操作，结合RBAC与多签和时间锁。\u003C\u002Fp>\n\u003Ch2 id=\"mev\">MEV机器人的实用安全清单\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>绝不使用tx.origin\u003C\u002Fstrong> — 使用msg.sender或基于签名的认证\u003C\u002Fli>\n\u003Cli>\u003Cstrong>处处使用CEI模式\u003C\u002Fstrong> — 在外部调用之前更新状态\u003C\u002Fli>\n\u003Cli>\u003Cstrong>检查所有返回值\u003C\u002Fstrong> — 特别是低级调用和非标准代币\u003C\u002Fli>\n\u003Cli>\u003Cstrong>使用访问控制\u003C\u002Fstrong> — 只有你的EOA\u002F多签才能调用提取利润的函数\u003C\u002Fli>\n\u003Cli>\u003Cstrong>实现熔断器\u003C\u002Fstrong> — 检测到异常行为时暂停功能\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"\">总结\u003C\u002Fh2>\n\u003Cp>EVM中的安全不是你添加的层——而是你如何构建状态转换相对于外部调用的属性。检查-效果-交互模式、重入保护和谨慎的delegatecall使用不是最佳实践——它们是生存要求。\u003C\u002Fp>\n","zh","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:25.866972Z","EVM安全深度解析：msg.sender vs tx.origin、重入攻击与防御、delegatecall风险和智能合约访问控制模式。","EVM安全 重入攻击",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000013","Security","security",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","区块链",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0000000-0000-0000-0000-000000000668","为什么Bali在2026年正在成为东南亚的影响力科技中心","weishenme-bali-2026-zhengzai-chengwei-dongnanya-yingxiangli-keji-zhongxin","Bali在东南亚创业生态系统中排名第16位。随着Web3构建者、AI可持续发展初创公司和生态旅游科技公司的集中，该岛正在打造区域影响力科技之都的独特定位。","工程","2026-03-28T10:44:48.898750Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0000000-0000-0000-0000-000000000667","ASEAN数据保护拼图：开发者合规清单","asean-shuju-baohu-pintu-kaifazhe-heguiqingdan","七个ASEAN国家现已拥有全面的数据保护法律，各自具有不同的同意模型、本地化要求和处罚结构。这是一份为构建多国应用程序的开发者准备的实用合规清单。","2026-03-28T10:44:48.893467Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0000000-0000-0000-0000-000000000666","Indonesia 290亿美元数字化转型：软件公司的机遇","indonesia-290yi-meiyuan-shuzihua-zhuanxing-ruanjian-gongsi-jiyu","Indonesia IT服务市场预计在2026年达到290.3亿美元，高于2025年的243.7亿美元。云基础设施、AI、电子商务和数据中心正在推动东南亚最快的增长。","2026-03-28T10:44:48.875457Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":18,"linkedin":18,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]