闪贷嵌套闪贷：一层套一层的原子结构，断了先赔哪一层

闪电贷的基础叙事很干净：一笔交易里借来一笔钱，用完还回去，没还成就整体回滚。但当脚本复杂到在某一段逻辑里需要另一家协议的资金周转时，就出现了嵌套：闪贷 A 的执行流中再触发闪贷 B，B 的回调里再执行操作、归还 B，然后继续 A 的剩余步骤、归还 A。这种套娃结构在债务重组、多协议原子清算与跨市场套利里真实存在，也最常出现在攻击交易的解剖报告里。它的机制问题只有一个：嵌套之后，回滚还是那个保护伞吗，费用还是那笔费用吗。

先明确回滚边界的性质：智能合约事务性作用于整笔交易，不作用于单个层级。嵌套闪贷无论套几层，只要最外层调用以未归还状态结束或任何一层的 revert 沿调用栈向上传播，整笔交易回滚——链上状态回到交易前，没有任何一层”部分完成”。所谓”断了先赔哪一层”在状态层面答案是都不赔：B 没还上，A 的后续不执行，A 自身也没还上，整链回滚。真实的损失分布发生在状态之外的两个地方：已消耗的 gas（嵌套结构调用的合约多、逻辑长，gas 上限设置与真实消耗之间的余量浪费更大），以及嵌套引入的调用栈深度与 gas 上限风险——链对单交易 gas 有块级上限，层数与协议数堆多了，可能还没执行到归还步骤就触顶失败，这种失败与逻辑错误一样全军覆没，却更难在模拟里复现。

费用结构是另一种”叠加不摊薄”。每层闪贷按各自协议费率对各自的借出金额计费：A 层按本金计一次，B 层若借出额是过桥用途也要计费一次，总费率成本是各层相加而不是取优。更要注意的是”以贷养贷”的时序约束：B 的归还时点在 A 的归还之前，两层各自独立校验、独立计费，设计脚本时的资金流图必须画到每一层的每一跳，任何一层在回调结束时余额差一个最小单位都会整笔失败——闪贷合约通常要求精确归还加费用，不存在”下笔补上”。

嵌套结构的合理性判断可以用三个问题过滤。其一，两层借款是否服务同一原子目标？若 B 层资金其实可以在交易完成后单独操作，嵌套只是把两笔交易强行缝合成一笔，徒增失败率。其二，是否存在等价的非嵌套路径？多数”闪贷里再闪贷”的需求可以重排为单次借入更大的金额、在回调内部自行分配用途，一层解决——单次借入的成本是单层费率加一次 gas，通常低于嵌套。其三，你是否承担了清算级时序？嵌套最常见的正当场景就是清算：用 A 层闪贷垫付被清算债务、释放抵押物、在 B 层闪贷过桥下完成抵押物置换并重建债务，所有步骤对时间敏感，拆开就有被抢先或价格漂移的风险。这类场景嵌套是为原子性付费，值不值取决于缝隙期的损失期望。

最后是从用户视角读嵌套交易的能力。区块浏览器里一笔嵌套闪贷的内部调用树特征明显：同一交易内出现两次闪贷事件（同协议会有两条借贷事件记录）、多段借贷与还款事件交替、中间夹着清算与兑换调用。审计自己的授权与自动化工具时，看到这棵树的脚本若来自第三方仓库，重点核对每层回调里的资金流向目标地址——嵌套结构天然适合把一段”看似归还”的资金在 B 层回调里顺路转走，事件日志里归还记录齐全、但净流向不对，是攻击脚本的典型指纹。

风险提示：闪电贷及其嵌套调用对时序与余额校验极度敏感，脚本缺陷会造成 gas 损失或执行失败；运行第三方闪贷脚本存在资金被截留的现实风险。本文只做机制说明，不构成投资建议，不提供任何攻击或利用路径。