Reentrancy Attack Ethereum Smart Contract Security Solidity Runtime Protection
背景：为什么重入攻击仍是区块链梦魇
自2015年以太坊上线以来，重入攻击已让 DAO、SpankChain 等多个项目损失数亿美元。它的本质是：合约对外部地址发起转账或调用后，未更新内部账本，被攻击者抢先递归调用回退函数，多次提取资金。一旦合约部署即“代码即法律”，漏洞便无法修补，因此有效机制必须能在运行期即时介入。
现存防线为何止步于部署前
现有手段分为静态检测工具、安全语言、开发规范三大类：
- SmartCheck/Remix/Oyente 等工具依赖硬编码的漏洞模式，易被绕过。
- Obsidian、Vyper 等新语言仍在实验阶段，并不兼容主流合约。
- 最佳实践（比如“先改状态再转账”）全凭开发者自觉。
共同软肋：只在部署前生效。一旦上链，无论出现新型重入模式还是旧逻辑失误，都无法阻断。
新方案：两条账本间的“守恒定律”
我们提出一个不依赖攻击模式、可在链上实时判断交易合法性的核心思路：
- 锁定两条值
contractBalance（协议层记录）与totalParticipantsBalance（应用层记录）。 - 维持守恒量ｘ=a−b
任何操作前后若 Δx ≠ 0，即判定为恶意交易并回滚，同时记录攻击者地址。
公式：∀O∈T : (O 合法) ⇔ (x = x')
该机制兼具防御 + 溯源功能，无需修改已部署字节码。
三种实现架构任你挑
| 架构 | 部署方式 | 开发难度 | 适用场景 |
|---|---|---|---|
| dApp 旁路网关 (Approach 1) | 在前端或中继节点部署校验器 | 最低 | CEX、DeFi Portal |
| 监控合约 (Approach 2) | 新建合约充当“保镖”守护目标合约 | 中 | 多合约统一管理 |
| 内嵌合约 (Approach 3) | 直接在业务合约里加 30 行 Solidity 代码实现自检 | 最高 | 对延迟敏感场景 |
无论哪种方式，交易若未通过守恒校验即自动失败，攻击者地址被实时记录，仅合约 owner 可读。
实验验证：单函数 & 跨函数攻击一网打尽
我们在 Remix JavaScript VM 上完成双案例四场景测试，结果如下：
| 案例 | 是否部署防护机制 | 重入是否成功 | 攻击者地址是否捕获 |
|---|---|---|---|
| 单函数攻击 | 否 | 是 | — |
| 单函数攻击 | 是 | 否 | 是 |
| 跨函数攻击 | 否 | 是 | — |
| 跨函数攻击 | 是 | 否 | 是 |
其中跨函数攻击中，Attacker1 与 Attacker2 试图借共享状态变量“钓鱼”，却因 Δx 异常而被合约自动拦截，证明机制无视攻击路径多样性的鲁棒性。
FAQ：你最关心的 5 个问题
Q1：会不会增加 gas？
单次校验约增加 2,000 gas；单笔大规模批量转账场景 gas/操作下降，可忽略成本。
Q2：合约升级怎么办？
用代理模式 (proxy) 把逻辑合约置换成含自检的版本即可，无需迁移数据。
Q3：参与人数过多会不会溢出？
示例变量均采用 uint256，百万级账户也安全，但建议按业务周期快照 totalParticipantsBalance 降维护成本。
Q4：对 ERC-777、ERC-721 同样适用吗？
只要代币及分账逻辑可抽象为“两条账本之差”，即可扩展。我们已在 NFT 市场原型的买/卖流程中复用。
Q5：能否与现有检测工具复用？
完全兼容。可先用静态工具清扫，再叠加本方案实现“双重保险”。
未来方向
- 协议层硬化：矿工/验证者本地植入该守恒判断，直接过滤恶意交易。
- 漏洞矩阵扩张：将“完整性检查”思想迁移至整数溢出、抢跑等其它漏洞。
- 自动化仪表盘：结合事件日志，实现实时告警和风险评分 API。
一条简单的“守恒定律”，或许就能为千亿级的链上资产再上一把安全锁。