以太坊没有算错，钱为什么还是会丢？

假设一笔攻击交易有合法签名、支付了足够 Gas，被验证者收入区块，EVM 逐条执行 opcode， 最终所有节点算出同一个状态根。以太坊有没有“出错”？没有。若合约允许攻击者在余额尚未清零时重复提款， 网络只是忠实执行了它收到的程序。

这正是应用层安全最反直觉的地方：确定性不会判断意图。协议可以保证交易排序、执行规则与状态转换 对所有节点一致，却不知道开发者本来想让“每人只能提款一次”，也不知道某个价格源刚刚被操纵。智能合约控制真实资产， 交互通常不可逆，部署后的代码又默认难以修改，所以应用需要比普通后端更明确的安全规格。 ^[1]

攻击者不必“破解以太坊”。公开网络给了所有人相同接口：部署合约、发起嵌套调用、借用原子流动性、 读取状态、组合多个协议。安全设计必须假定调用者会选择最不利的输入与顺序，而不是按产品界面的正常路径操作。 Solidity 官方安全说明因此把每次外部合约交互都视为潜在危险，并建议从控制流、调用失败、授权与资源边界一起考虑。 ^[2]

EVM 调用是同步的。合约 A 执行 call、调用代币钩子或另一个未知合约时，会暂停自己的当前函数， 把剩余 Gas 与控制权交给 B。B 可以返回，也可以先调用 A 的另一个入口。只要整笔交易尚未结束，嵌套调用都共享同一份可变化的链上状态。

function withdraw() external {
  uint256 amount = balances[msg.sender];
  require(amount > 0);

  // 先交出控制权
  (bool ok,) = msg.sender.call{value: amount}("");
  require(ok);

  // 回来以后才清零：太晚
  balances[msg.sender] = 0;
}

function withdraw() external {
  uint256 amount = balances[msg.sender];
  require(amount > 0);

  // 先提交本地状态
  balances[msg.sender] = 0;

  // 最后才交出控制权
  (bool ok,) = msg.sender.call{value: amount}("");
  require(ok);
}

右侧采用 Checks-Effects-Interactions：先检查前置条件，再写入本地效果，最后与外部系统交互。 当攻击者回调时，余额已经是 0，第二次提款会失败。Solidity 文档明确提醒，重入并不只来自 ETH 转账， 任何对其他合约的调用都可能交出控制权，多合约场景还会让依赖状态在背后发生变化。 ^[2]

重入不止一种形状

四道防线，各自解决不同问题

1. 先写不变量例如“任意时刻，已支付总额不得超过已扣减债权”。不变量决定测试真正要攻击什么。
2. 调整顺序使用 Checks-Effects-Interactions，在交出控制权前提交本地状态；跨函数共享状态也要统一审视。
3. 增加互斥锁ReentrancyGuard 可阻止受保护入口在活动调用期间再次进入，但不能修复错误会计或未保护的旁路。
4. 隔离外部交互优先采用 pull payment，让接收者主动领取；限制回调面，避免在一个函数中混合多项敏感状态变化。

OpenZeppelin 的工具库提供 ReentrancyGuard 与 Pausable 等构件； 它们是经过维护的基础模块，不会自动替你选择正确的函数边界、角色或不变量。 ^[3]

Solidity 的 public 与 external 描述函数怎样被调用，不描述谁被授权。 private 只限制其他合约从源码接口直接调用，不会把链上数据变成秘密。真正的授权必须在每个敏感入口明确检查调用者、角色与条件。

Ownable、角色与时间锁不是三个等级，而是三种工具

OpenZeppelin 将“每个组件只能做其工作所需之事”概括为最小权限原则，并特别提醒 DEFAULT_ADMIN_ROLE 默认既管理其他角色又管理自己，因此风险很高。时间锁让维护操作先排队， 用户有机会审查并退出，但角色不可用也可能让系统永久卡住。 ^[4]

权限审查要看完整生命周期

1. 授予初始角色在构造或初始化时给了谁？是否可能被陌生人抢先初始化？
2. 使用每个敏感函数是否真的使用正确 modifier？内部旁路、批处理器与代理入口是否绕过检查？
3. 转移所有权是否采用两步接受？新旧管理员交接期间，谁可以操作？错误地址能否撤回？
4. 撤销角色更换后旧主体是否彻底移除？链上事件和监控能否确认当前持有人？
5. 失效密钥被盗、签名者离线或治理受攻击时，是否有取消、暂停、恢复和退出路径？

区块链节点必须对同一输入算出同一结果。如果合约在执行中各自访问互联网，不同节点可能收到不同价格、超时或响应， 共识就无法确定。因此，外部数据必须先由某个机制观察、验证、聚合，再通过交易写到链上供合约读取。

Ethereum.org 将预言机问题拆成正确性、可用性和激励相容性：数据是否来自正确来源且未被篡改，是否及时可获得， 报告者是否承担说谎成本。多节点、多来源与经济激励能降低单点风险，但不会让任何数据天然成为“绝对真相”。 ^[5]

闪电贷通常是放大器，不是根因

闪电流动性让攻击者无需长期资本，就能在一笔原子交易中借入大量资产、推动薄池现货价、让受害协议按扭曲价格放贷， 最后偿还借款。若受害协议读取的是可被单笔交易操纵的价格，根因是价格源与风险窗口不匹配； 闪电贷只是把达到操纵规模的门槛压低。

安全读取不是一个函数名，而是一组前置条件

1. 先定义价格含义报价资产、基准资产、小数位、单位、符号与有效范围必须写入规格和测试。
2. 核对新鲜度读取更新时间并按业务风险设置 maxAge；陈旧时应安全失败，而不是悄悄沿用。
3. 降低可操纵性使用与风险规模匹配的深度、多源聚合或时间窗口；评估操纵成本而非只看品牌。
4. 设计故障模式区分暂停新增风险、允许还款、允许提款、启用备用源；“全部继续”与“全部冻结”通常都过于粗糙。
5. 限制连锁后果借款上限、单资产限额、价格偏差阈值与清算节流可把单次错误限制在可承受范围。

普通合约部署后，其地址上的运行时代码不会像服务器文件那样被覆盖。可升级系统通过间接层实现变化： 用户始终调用代理地址；代理读取实现地址，再用 delegatecall 执行实现代码。 代码来自实现，msg.sender、余额与存储上下文却属于代理。

EIP-1967 解决的是“代理元数据放在哪里、怎样被工具发现”的标准化问题，不替应用保证谁有权升级或新逻辑是否安全。 标准建议实现或管理员槽变化时发出事件，因为持续监控这些变化本身就是安全要求。 ^[8]

可升级系统新增了五类核心风险

1. 升级授权失守错误的 _authorizeUpgrade、过宽角色或管理员密钥失陷，可以把全部逻辑换成恶意实现。
2. 初始化被抢实现没有构造器上下文；代理若未原子调用 initializer，后来者可能先认领 owner 或关键参数。
3. 存储布局冲突重排、删除、改变变量类型或继承顺序，会让新代码用新名字解释旧槽位，造成静默数据破坏。
4. 升级能力被锁死UUPS 实现若丢失兼容接口或授权路径，系统可能无法继续升级；错误回滚假设也会制造永久故障。
5. 治理绕过承诺即使代理技术完全正确，单一管理员的即时升级仍可以突然改变费用、资产控制和退出规则。

OpenZeppelin 的代理说明将状态与逻辑分离，并强调升级前后必须保持存储布局兼容； 可升级合约还需要用只执行一次的 initializer 代替普通构造器逻辑。 ^{[6] [7]} UUPS 通过实现合约中的升级逻辑和授权决定谁能更换实现，EIP-1822 则定义了可兼容实现的接口思路。 ^[9]

ERC-7201 规定了命名空间存储布局的注释与槽位推导方式，让多个模块可以各自拥有不与常规存储树碰撞的区域。 它提升可分析性，但编译器不会仅凭注释替你强制正确实现，开发者仍需负责布局一致。 ^[10]

现代 DApp 很少只是一份合约。借贷市场可能依赖多个代币、价格源、DEX、利率模型、清算机器人、 代理管理员和前端路由。每个组件都有自己的代码与治理边界，系统安全因此是一张图，而不是一份审计报告。

把“事故原因”拆成根因、放大器与后果

一个虚构借贷事故，四类风险如何串在一起

先把自然语言承诺变成可测试不变量

测试工具各自看见不同种类的问题

Solidity 的 SMTChecker 可对断言、状态变量与外部调用模型进行形式化分析；它将外部调用视为未知代码， 正体现了安全设计不应假定被调用方一定温顺。 ^[12] 源码验证则帮助使用者确认公开源码与链上字节码对应，但“代码已验证”只证明对应关系，不证明逻辑安全。 ^[11]

四类风险的最小防线矩阵

1. 重入CEI + 统一互斥边界 + pull 模式 + 跨函数/跨合约不变量测试 + 外部回调最小化。
2. 权限最小权限 + 角色拆分 + 多签 + 两步转移 + 高危操作时间锁 + 角色与事件持续监控。
3. 预言机多源/抗操纵设计 + 新鲜度和单位检查 + 偏差限制 + 资产上限 + 明确的故障降级策略。
4. 升级成熟代理标准 + 原子初始化 + 布局校验 + 升级模拟 + 明确授权 + 延迟与实现地址监控。

1. 资产在哪里？由哪个合约持有，用户拿到的是原生资产、份额、债权还是跨链映射？谁能移动或冻结它？
2. 最重要的不变量是什么？总资产、总负债、份额价格、抵押率与权限边界怎样定义？有没有机器可检查的断言？
3. 外部调用在哪里？发送 ETH、调用代币、钩子、DEX、预言机或插件之前，本地状态是否已经稳定？
4. 哪些函数是高危入口？提款、铸币、参数、暂停、救援、迁移与升级是否都使用了正确访问控制？
5. 当前权限由谁持有？是单一 EOA、多签、DAO、时间锁还是 AccessManager？阈值、成员与角色能否链上核对？
6. 权限变化多久生效？升级与关键参数是否有公开排队期？紧急路径能否绕过延迟，绕过范围多大？
7. 价格从哪里来？有多少独立来源，市场深度如何，读取的是现货还是时间/节点聚合，单位与方向是什么？
8. 数据失效时怎样处理？更新时间、异常范围、网络停机、市场关闭与脱锚分别触发暂停、备用源还是沿用旧值？
9. 合约能升级吗？代理类型、当前实现、管理员、时间锁与初始化状态是什么？升级历史和事件是否公开？
10. 依赖也能变化吗？代币、预言机、DEX、桥和治理自身是否可升级或暂停？上游变化会破坏哪些本地假设？
11. 发生异常时谁先发现？监控哪些角色、实现槽、价格偏差、资金流与失败事件？告警是否有人值守并有权限行动？
12. 最坏损失被限制了吗？单资产上限、速率限制、分仓、保险或应急退出能否把一次失误限定在系统可承受范围？

证据强度从低到高

1. 重入的核心外部调用交出控制权；危险不是“回调”本身，而是回调看到并消费了尚未稳定的状态。
2. 权限的核心授权必须逐函数、逐角色、逐生命周期设计；主体被攻破时的最大能力比“管理员人数”更重要。
3. 预言机的核心链上确定性只能确定地使用输入；数据来源、时间、单位、操纵成本和失效策略都属于应用逻辑。
4. 升级的核心代理让状态地址保持不变、逻辑可替换；修复能力同时创造授权、初始化、布局与治理风险。
5. 系统的核心安全沿依赖图传播。任何上游可变性、回调或经济假设都应进入威胁模型和故障预算。