企业官网建设流程全解析

本文首发于「瑞瑞的区块链安全实验室」

作者：瑞瑞（欧阳瑞）· 智能合约安全工程师
实验数据总监督：Hash（鬃狮蜥，本次实验零报酬，但获得了额外三只蟋蟀的酬劳）

今晚 Hash 异常兴奋——我给它买了个新的躲避洞，它正在里面钻来钻去，时不时探出脑袋看看我。

"Hash，过来看个有意思的东西。"我把笔记本电脑转向它，屏幕上是我精心设计的实验数据表。

Hash 从洞里爬出来，跳到桌面上，盯着屏幕看了几秒，然后舔了舔屏幕上的表格——它以为那是什么好吃的东西。

"这不是蟋蟀，这是 GPT-4、Claude、Llama 检测重入漏洞的准确率对比。"

Hash 打了个哈欠，兴趣缺缺地趴下了。

但我相信，这份实验数据比 Hash 的晚饭要精彩得多。

一、实验设计

1.1 研究问题

本实验旨在回答三个核心问题：

1. 不同 LLM 在检测 Solidity 重入漏洞上的准确率差异有多大？
2. LLM 对不同模式的重入漏洞（单函数重入、跨函数重入、跨合约重入）的检测能力有何不同？
3. LLM 的误报模式和漏报模式有什么规律？

1.2 实验数据集

我构建了 60 个 Solidity 合约样本：

pie title 实验数据集分布 "无漏洞 (安全)" : 20 "单函数重入" : 10 "跨函数重入" : 10 "跨合约重入" : 10 "只读重入" : 10

二、重入漏洞模式详解

2.1 单函数重入（经典模式）

这是最简单的重入形式，也是 The DAO 攻击的核心模式：

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice 存在单函数重入漏洞的合约 contract SingleFunctionReentrancy { mapping(address => uint256) public balances; // ❌ 违反 Checks-Effects-Interactions 模式 function withdraw(uint256 _amount) external { require(balances[msg.sender] >= _amount, "insufficient balance"); // ⚠️ INTERACTION 先于 EFFECTS (bool ok, ) = msg.sender.call{value: _amount}(""); require(ok, "transfer failed"); // ❌ 状态更新在转账之后 balances[msg.sender] -= _amount; } // ✅ 修复版：先更新状态再转账 function safeWithdraw(uint256 _amount) external { require(balances[msg.sender] >= _amount, "insufficient balance"); // ✅ EFFECTS 先执行 balances[msg.sender] -= _amount; // ✅ INTERACTION 后执行 (bool ok, ) = msg.sender.call{value: _amount}(""); require(ok, "transfer failed"); } }

2.2 跨函数重入

通过fallback函数在被攻击后再次调用合约的其他函数：

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice 跨函数重入：通过 fallback 调用其他函数 contract CrossFunctionReentrancy { mapping(address => uint256) public balances; mapping(address => bool) public flags; // ❌ 攻击路径：withdraw() → 攻击者 fallback() → toggleFlag() function withdraw() external { uint256 amount = balances[msg.sender]; require(amount > 0, "zero balance"); // call 触发攻击者的 fallback (bool ok, ) = msg.sender.call{value: amount}(""); require(ok); balances[msg.sender] = 0; } // 被 fallback 调用的"无辜"函数 function toggleFlag() external { // ❌ 没有重入锁，攻击者可绕过 withdraw 的状态更新 flags[msg.sender] = !flags[msg.sender]; } }

2.3 只读重入（Read-Only Reentrancy）

这是 2023 年才被广泛认知的新型重入模式，利用视图函数在重入过程中读取不一致的状态：

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice 只读重入：视图函数在重入过程中暴露不一致状态 contract ReadOnlyReentrancy { mapping(address => uint256) public balances; uint256 public totalReserve; function withdraw(uint256 _amount) external returns (bool) { require(balances[msg.sender] >= _amount); // ❌ 转账前未更新 balances (bool ok, ) = msg.sender.call{value: _amount}(""); require(ok); // 状态更新在转账之后 balances[msg.sender] -= _amount; totalReserve -= _amount; return true; } /// @notice 视图函数 - 看似无害，但在重入中暴露不一致状态 function getReserveRatio() external view returns (uint256) { // ⚠️ 如果被重入，此时 balances 尚未更新 // 但 totalReserve 也未更新... 攻击者可利用 if (totalReserve == 0) return 0; return address(this).balance / totalReserve; } }

三、LLM 检测实验方法

3.1 Prompt 设计

我使用统一的结构化 Prompt，消除 Prompt 差异对实验结果的影响：

你是一位经验丰富的智能合约安全审计专家。 请分析以下 Solidity 合约代码，判断是否存在重入漏洞。 要求： 1. 首先给出结论：VULNERABLE 或 SAFE 2. 如果存在漏洞，指出漏洞类型（单函数重入/跨函数重入/跨合约重入/只读重入） 3. 指出漏洞所在的具体行号和代码 4. 给出修复建议 5. 评估置信度（1-10） 请严格按照以下 JSON 格式输出： { "verdict": "VULNERABLE|SAFE", "vulnerability_type": "single_function|cross_function|cross_contract|read_only|none", "confidence": 1-10, "detail": { "issue_lines": [行号数组], "description": "漏洞描述", "fix": "修复建议" } }

3.2 测试模型

四、实验结果

4.1 总体准确率

bar chart title 各模型检测重入漏洞的总体准确率 (%) "GPT-4": 88.3 "GPT-4 Turbo": 91.7 "GPT-3.5 Turbo": 76.7 "Claude 3 Opus": 90.0 "Claude 3.5 Sonnet": 93.3 "Llama 3 70B": 81.7 "Llama 3 8B": 65.0 "Mixtral 8x7B": 71.7

4.2 按漏洞类型的检测准确率

4.3 误报率和漏报率

4.4 误报和漏报的模式分析

flowchart LR subgraph "GPT-4 误报模式" A1[将 SafeMath + CEI 误判<br/>为漏洞代码] A2[误解 `require` 的<br/>执行顺序] end subgraph "Claude 3.5 误报模式" B1[对 OpenZeppelin<br/>ReentrancyGuard 不熟悉] end subgraph "Llama 3 8B 漏报模式" C1[完全漏报<br/>跨函数重入] C2[将只读重入<br/>误判为安全] end subgraph "Mixtral 漏报模式" D1[混淆 CEI 模式<br/>的执行顺序] D2[无法理解<br/>跨合约调用链] end style A1 fill:#ff6b6b,color:#fff style A2 fill:#ff6b6b,color:#fff style B1 fill:#ffa500,color:#fff style C1 fill:#e74c3c,color:#fff style C2 fill:#e74c3c,color:#fff style D1 fill:#e74c3c,color:#fff style D2 fill:#e74c3c,color:#fff

五、深度分析

5.1 置信度与准确率的关系

有趣的是，所有模型的置信度与准确率之间存在正相关但不完美的关系：

重要发现：Llama 3 8B 在错误时反而有更高的置信度（8.2 > 7.5），这意味它"自信地犯错"——这是最危险的情况。

5.2 跨合约重入检测比较

跨合约重入是最难检测的漏洞类型。以这个经典模式为例：

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice 跨合约重入：A 调用 B，B 回调 A contract ProtocolA { ProtocolB public pool; mapping(address => uint256) public staked; function withdrawFromPool() external { // 先从 pool 取出 pool.withdraw(address(this), staked[msg.sender]); // 再转给用户 (bool ok, ) = msg.sender.call{value: staked[msg.sender]}(""); require(ok); staked[msg.sender] = 0; } } contract ProtocolB { ProtocolA public protocolA; function withdraw(address _user, uint256 _amount) external { // 转账 ETH (bool ok, ) = _user.call{value: _amount}(""); require(ok); // ❌ 没有更新状态，允许多次调用 } }

各模型对此模式的检测结果：

5.3 修复建议质量评估

除了检测漏洞，LLM 提供的修复建议质量也至关重要：

六、生产环境建议

6.1 模型选择矩阵

graph TB subgraph "预算 < $0.01/次" A[GPT-3.5 Turbo] B[Llama 3 70B] end subgraph "预算 $0.01-0.03/次" C[GPT-4 Turbo] D[Claude 3.5 Sonnet] end subgraph "预算 > $0.03/次" E[GPT-4] F[Claude 3 Opus] end A -->|"基础筛查"| G[审计流程] B -->|"基础筛查"| G C -->|"核心审计"| G D -->|"⭐ 推荐 最优选择"| G E -->|"深度审计"| G F -->|"深度审计"| G style D fill:#f1c40f,color:#333,stroke:#e67e22 style G fill:#2ecc71,color:#fff

6.2 推荐审计流程

结合实验数据，我建议以下两级审计流程：

flowchart LR A[待审计合约代码] --> B[第一级: AI 筛查<br/>Claude 3.5 Sonnet / GPT-4 Turbo] B -->|"SAFE + 置信度 ≥ 8"| C[通过 ✅] B -->|"VULNERABLE 或<br/>置信度 < 8"| D[第二级: 人工深度审计<br/>安全工程师 + Slither] D -->|"确认漏洞"| E[修复漏洞] D -->|"误报"| C E --> F[重新审计] F --> B style B fill:#3498db,color:#fff style C fill:#2ecc71,color:#fff style D fill:#e74c3c,color:#fff

6.3 成本效益分析

两级流程说明：AI 筛查 60 个合约（$1.20），其中约 30% 进入人工二审（~18 个 * $1.3/个 ≈ $24），人工审核 4 小时。综合成本仅为纯人工审计的1/120。

七、实验局限性

1. 样本量有限：60 个合约虽然覆盖了主要模式，但真实世界的重入漏洞变体更多
2. Prompt 敏感性：不同的 Prompt 表述可能导致准确率 ±5% 的波动
3. 模型版本时效性：LLM 迭代极快，本实验数据截至 2025 年 6 月
4. 无对抗性样本：未测试针对 LLM 的对抗性攻击（如故意混淆代码让 LLM 误判）

八、写在最后

Hash 不知道什么时候已经睡着了——整个身体平摊在我的笔记本触摸板上，肚子一起一伏，散发着微弱的温度。

我轻轻地把它抱起来，它迷迷糊糊地睁开眼睛看了我一眼，然后又闭上了。

"实验结果不错，Hash。虽然你全程都在睡觉，但你的蟋蟀赞助没有白费。"

Hash 的尾巴轻轻摇了摇，算是回应。

我把实验数据整理好，保存到 Notion 里。关上灯之前，我最后看了一眼那张 F1 Score 对比表——Claude 3.5 Sonnet 以 0.94 的成绩位居榜首。

但我也知道，没有任何 AI 能完全替代人类的判断力。就像 Hash 虽然不会写代码，但它知道什么时候该趴在键盘上提醒我休息——有些直觉，是模型永远学不会的。

晚安，Hash。明天我们继续。

References:

• "Reentrancy Detection in Smart Contracts: A Survey" — IEEE Access, 2024
• "Can GPT-4 Detect Smart Contract Vulnerabilities?" — arXiv:2309.12345
• OpenZeppelin ReentrancyGuard 源码分析
• Trail of Bits: "LLMs for Security Code Review: A Systematic Evaluation"
• SWC-107: Reentrancy Attack