安全

📘
前置阅读

智能合约简介

VM 异常处理

智能合约在区块链上表现出极高的设计灵活性——它们可以安全托管巨额资产，并在去中心化网络中永久运行不可篡改的业务逻辑。然而，这种强大的特性在孕育出可信、可自由组合的去中心化生态的同时，也让黑客通过发掘合约漏洞进行恶意套利成为了可能。由于智能合约上链后通常无法直接就地修补，且任何流失的链上资产几乎都无法追回，因此安全防护至关重要。

在向 TRON 主网（Mainnet）部署任何合约前，必须制定与合约托管资产规模相匹配的安全防御措施。本文将为您详细梳理科学的智能合约开发流程，剖析开发中需要重点防范的典型漏洞利用模式。有关部署前的逐项对账检查，请参阅最佳实践章节；有关具体的编译与部署报错，请参阅智能合约错误诊断章节。

1. 规范的合约开发安全流程

行业内大多数灾难性的智能合约安全事故，追根溯源往往是因为开发管理流程存在疏漏，而非黑客发明了什么前所未闻的新型攻击手段。一个安全的合约工程应当至少满足以下流程基线要求：

全量版本控制：将所有智能合约及配套测试脚本纳入 Git 等版本控制系统中。
强制 Pull Request 工作流：杜绝直接向主分支推送代码，所有修改必须通过 Pull Request 提交。
严格的代码同行评审（Code Review）：每个 Pull Request 必须经过至少一名具备合约安全知识的开发人员进行深度复核。
一键式自动化构建与测试：使用适配 TRON 底层特性的工程框架（如 TronBox 等），确保能够通过单条命令在本地或沙箱中自动完成合约编译、部署并运行完整的测试用例。
集成 CI/CD 静态扫描：将 Mythril、Slither 等静态分析扫描工具集成至流水线中，在每次提交 Pull Request 时自动执行，且在合入代码前必须对所有的警告提示进行人工排查与安全确认。
零警告编译通过：修补所有逻辑漏洞，确保 Solidity 编译器在输出目标字节码时不产生任何 Warning 警告。
完备的技术文档：保持合约代码高可读性并配有详尽的逻辑说明文档，确保原作者之外的安全审计人员能快速理清其核心业务流。

📘
在 TVM 字节码上使用 EVM 静态审计工具的注意事项
业界常用的 Mythril 与 Slither 主要是针对以太坊 EVM 虚拟机环境设计的。由于 TVM 在底层兼容绝大多数 EVM 指令集，因此这些工具输出的分析结果具有很高的参考价值。
然而需要注意的是， TRON 网络独有的指令操作码（例如 CALLTOKEN、FREEZEBALANCEV2 等系统自带指令）对于这些 EVM 工具来说是未知的，在扫描时可能会产生误报，或者被分析工具静默跳过。因此，应当将这些 EVM 工具的扫描输出视为辅助性的初轮排查，而非终极的安全结论。对于高额资产存管的智能合约，请务必委托具备 TVM 专属审计能力的第三方专业安全机构进行人工源码审计。

2. 经典合约攻击模式与防御策略

重入攻击（Reentrancy）

重入是智能合约安全领域中最经典且危害最大的一类漏洞。虽然 TVM 虚拟机在底层不支持多线程并发执行，但当一个合约发起跨合约调用交互时，调用方合约的当前执行栈与内存状态会进入挂起状态，直至外部调用执行完毕并返回。这种“挂起-恢复”的设计机制如果处理不当，就会引入重入漏洞：如果被调用的外部恶意合约在控制权交还前，反向重新调用（重入）了发起方合约的某个方法，而此时发起方的状态变量尚未完成更新，恶意合约就能操作过时的状态数据来牟利。

存在重入漏洞的典型代码设计（请勿在生产中照抄）：

// 此合约存在故意引入的严重重入漏洞，请勿在生产环境复制
pragma solidity 0.8.6;

contract Victim {
    mapping (address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        
        // 底层消息调用，导致虚拟机挂起并将控制权渡让给 msg.sender 接收方
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success);
        
        balances[msg.sender] = 0;  // <-- 严重缺陷：用户账目余额在外部转账交互完成后才被清零
    }
}

在上文的 withdraw() 中，合约按以下顺序执行业务：读取用户余额 -> 发送 TRX -> 扣减用户账目。漏洞的核心就发生在发送 TRX 到最终扣减账目这行代码的执行空隙内。一旦 TRX 的转账目标是一个带有恶意 receive / fallback 回调函数的外部合约，该恶意回调就可以在余额尚未清零的真空期内，抢先反向再次调用 withdraw() 方法。

攻击者合约设计示例：

pragma solidity 0.8.6;

interface IVictim {
    function deposit() external payable;
    function withdraw() external;
}

contract Attacker {
    IVictim victim;
    uint256 count;

    constructor(address victimAddress) {
        victim = IVictim(victimAddress);
    }

    function beginAttack() external payable {
        count = 5;
        // 向受害合约存入 1 TRX 启动攻击
        victim.deposit{value: 1 trx}();
        victim.withdraw();
    }

    // 接收 TRX 时触发的回调函数
    receive() external payable {
        if (count > 0) {
            count -= 1;
            // 抢在受害合约执行余额清零前，重入 withdraw 方法
            victim.withdraw();
        }
    }
}

如果外部使用 1 TRX 作为攻击资金调用 Attacker.beginAttack()，将会在链上触发如下的循环重入利用链条：

Attacker 合约向 Victim 存入 1 TRX。
Attacker 触发 Victim.withdraw()。Victim 读取其余额记录（1 TRX），并执行底层的 .call 划转资金。
Victim 的转账动作会默认触发 Attacker 合约的 receive() 回调，控制权发生让渡。
Attacker 判定计数器 count 大于 0，在 receive 回调内部反向再次触发 Victim.withdraw()。
此时由于上一次调用中 Victim 的 balances[msg.sender] = 0 尚未运行，其本地余额记录依然为 1 TRX。因此，Victim 将再次放行并向 Attacker 划转 1 TRX。
该过程会循环递归执行，直至计数器归零或虚拟机栈溢出报错。

在整个攻击链条中，Victim 合约最终被迫支付的 TRX 数额将远远大于 Attacker 实际存入的 1 TRX，而超额支付的 TRX 资金其实都是非法窃取自其他正常用户存放在 Victim 里的Token余额。

解决方案：严格遵循“检查-生效-交互”设计模式

重新调整转账方法中的执行顺序，确保所有合约状态的修改都必须在外部调用发生前写入完成：

pragma solidity 0.8.6;

contract NoLongerVulnerable {
    mapping (address => uint256) public balances;

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        
        balances[msg.sender] = 0;       // 1. 生效（先将本地账目状态清零修改完毕）
        
        (bool success, ) = msg.sender.call{value: amount}("");  // 2. 交互（最后向外部发起转账）
        require(success);
    }
}

该模式的基本原则是先检查（校验入参与权限） → 再生效（更新本地状态变量） → 后交互（向外部发起Token转账或跨合约方法调用）。在这种安全的排列顺序下，当控制权渡让给被调用合约时，我们本地的账目数据已完成了扣减，因此即便其触发重入调用，所操作的也是已经扣减完毕的最新数据，从而彻底杜绝了套利空间。

对于涉及核心资产调度的敏感方法，强烈建议额外搭配使用 OpenZeppelin 的 ReentrancyGuard 防重入修饰符，实施多层防御。需要注意的是，防重入锁只能捕获并阻断违背模式顺序的代码漏洞，它并不能代替“检查-生效-交互”模式本身，二者在开发中应相辅相成。

拒绝接收原生Token（TRX）导致的拒绝服务（DoS）

在 TRON 中，智能合约可能会由于各种主客观原因拒绝接收外部发来的 TRX。例如，合约的回调方法 receive / fallback 中显式抛出了 revert；或者是因为回调逻辑过于臃肿，导致其耗尽了由内置 .transfer() 方法转发的极小的固定能量上限（Solidity 编译器默认仅为此类调用转发非常低微的固定能耗）。

如果您的合约在设计上强行假设每一次原生Token转账都必须 100% 成功，攻击者就可以故意使用一个拒绝接收 TRX 的特种恶意合约作为业务接收方，一旦您的合约在划转失败时抛出 revert，就会导致您的整个核心业务流直接锁死（陷入拒绝服务状态）。

针对该安全威胁的防御措施包括：

改用低层调用方法：优先使用 call{value: amount}("") 接口来替代内置的 transfer(amount)。.call 会自动将当前交易所剩的所有可用能量额度转发给目标合约，有效规避由于能量分配不足引起的报错。
变“推送模式”为“提取模式”：避免在合约逻辑中主动向用户地址推送Token，而是设计一个“资产暂存槽”，由用户在需要时自行发起提取（Pull）交易将资产提回。这种模式能将转账失败的报错边界完全局限在用户自身的提取交易中，绝不破坏合约主线逻辑。
显式捕获并处理转账失败状态：如果某些业务流必须主动向外推送资产，请确保显式对转账返回的 bool 成功标识进行逻辑判定与分支处理（例如转账失败时记录未发余额账单），切忌直接使用 require(success) 触发交易回滚。

整数溢出与下溢（Overflow / Underflow）

在 Solidity v0.8.0 及更高版本中，编译器在生成指令时会自动内置算术溢出与下溢的检测与 revert 校验机制。如果您的合约不得不使用低于 v0.8.0 的老编译器版本进行构建，则必须显式采用 SafeMath 库来进行一切数学运算。开发中请仔细核查您的 pragma solidity 编译器版本声明以及 tronbox-config.js 中的配置，确保这些底层的自动防溢出安全保护已经正确生效。

pragma solidity 0.8.6;

contract MathExample {
    uint256 public total;

    function add(uint256 amount) external {
        // 自 Solidity 0.8.0 起，如果 total + amount 发生上溢，交易会自动触发 revert
        total += amount;  
    }
}

如果个别底层循环算法出于能耗极致优化的考量，需要绕过编译器的自动溢出监测，可以在代码中显式包裹 unchecked { ... } 块。使用该语法即代表您已在链下完全确保了数学运算边界的绝对正确性。

前置阅读