单位 6 / 11

DeFi 和协议分析:流动性、MEV 和经济攻击

收益:

  • 能够理解 AMM、流动性池、预言机、闪电贷等 DeFi 构建模块,并在机制解释和场景起草中使用人工智能
  • 能够区分大多数 DeFi 风险是经济/业务逻辑漏洞,而不是代码 bug,而人工智能在原有的经济漏洞上是薄弱的
  • 能够明白,经济安全是通过模拟来证明的,而不是通过思考来证明的,而甲骨文成瘾是最脆弱的一点。

DeFi(去中心化金融)是Web3价值最高、受攻击最多的领域。交易所、借贷协议、流动性池——全部以代码形式运行,并且都在恶劣的环境中转移数百万美元。在本单元中,我们将使用AI作为协议分析助手;我们将学习了解流动性、定价、MEV 和经济攻击,以及人工智能在这一背景领域中的哪些作用和不足。

DeFi 的基本构建模块

  • AMM(自动做市商):一种通过公式(例如 x·y=k)设定价格而不是匹配买家和卖家的交易机制。
  • 流动性池:用户存入代币并进行交易的共同基金。
  • 借贷协议:抵押品借款;当抵押品价值减少时就会发生清算。
  • Oracle:将外界价格带入协议的数据源——DeFi 最关键、最脆弱的依赖。
  • 闪电贷:在单笔交易中无抵押贷款并在同一笔交易中归还的贷款;它既有合法用途,也有攻击工具。

MEV 和经济攻击

MEV(最大可提取价值——由权威机构订购/添加/删除交易提取的价值)是 DeFi 特有的风险类别。待处理的交易出现在公共池(mempool)中;这种可见性为以下攻击打开了大门:

  • Front-running:看到一笔有利可图的交易,并在其前面插入自己的交易。
  • 三明治攻击:在受害者购买前后进行交易,并从差价中获利。
  • 预言机操纵:通过立即改变池的价格来欺骗协议,通常是使用闪电贷。

这些攻击不是来自代码的“错误”,而是来自经济设计的可利用性。这就是人工智能最困难的地方:擅长扫描技术代码的人工智能往往无法检测到特定于协议的经济漏洞。

注意:大多数 DeFi 漏洞不是“代码错误”,而是经济/业务逻辑漏洞。人工智能的标准代码扫描会遗漏这些;这是最需要人类专业知识、模拟和建模的领域。

人工智能在 DeFi 分析中的作用

1.机制说明。人工智能能够以简单的语言解释复杂协议(例如基于曲线的 AMM)的工作原理。这提供了快速进入分析的机会。

2. 生成情景/反假设。 “在什么价格变动下,该债务协议将进入清算危机?”人工智能生成场景草稿,其中包含以下问题:这些都是通过模拟进行测试的。

3. 提醒已知的攻击模式。 AI 会像清单一样唤起过去 DeFi 攻击的模式(预言机操纵、重入、清算螺旋)。

4.模拟方案草案。人工智能可以针对要测试的场景制定计划;但模拟本身是通过工具(Foundry、Tenderly)完成的。

弱提示/强提示

弱提示:

这个 DeFi 协议安全吗?

强力提示:

您的角色:DeFi 协议分析师。检查下面的协议机制。一一考虑以下经济攻击向量:预言机操纵(使用闪电贷)、三明治/抢先交易、清算螺旋、流动性撤回效应。对于每个向量:如何触发、需要什么条件、可能的影响。这些是要通过模拟进行检验的假设;不要肯定地说“安全/不安全”。生成实际的攻击代码;仅描述出于防御目的的风险。

四个可复制模板

1)机制说明:

用通俗易懂的语言一步步解释该协议的定价/流动性机制:用户进行交易时会发生什么,价格是如何确定的,有哪些外部依赖?标记你不明白的部分或留下不清楚的部分。

2)经济攻击面:

绘制该协议的经济攻击面:在预言机、流动性、抵押品、清算、治理中可以利用哪些假设?为每个风险写下一个条件(“假设”)。将其作为假设提出并通过模拟来证实。

3)压力情景:

考虑以下场景:如果抵押代币下跌 50%,如果预言机价格暂时偏离 30%,如果撤回 80% 的流动性,协议会是什么?写下每个场景的连锁反应。不要要求数值精确;指定需要模拟。

4)历史攻击模式匹配:

该协议的设计是否与已知的 DeFi 攻击模式(例如单源预言机、闪电贷开放价格)具有相似的条件?出于防御目的指出相似之处;不要采取漏洞利用步骤,它只会产生一个关注点。

三个迷你箱(数量)

案例 1 — 早期发现 Oracle 风险。一个团队正在设计一个新的债务协议。在机制解释中,YZ 标注了“价格取自单一池,可以通过闪电贷操纵”的假设。该团队在模拟中证实了这一点,并转向 TWAP + 多源。预计避免的损失:协议的全部锁定值。教训:人工智能在唤起已知模式方面很有价值。

案例 2——人工智能错过了最初的漏洞。在另一个协议中,该漏洞是由两种机制(奖励+清算)相互作用产生的独特经济错误。 AI一一发现每一个机制“完美无缺”;看不到互动。人体建模和模拟捕获。教训:虽然组件是正确的,但整体的经济性是人工智能的盲点。

案例 3 — 模拟计划节省了时间。一位分析师将 15 种不同的压力场景草拟到 AI 中,而不是手工规划;然后在 Foundry 运行它。计划时间从 1 天缩短到 2 小时;但对结果的解释和决定是人的。教训:人工智能计划、车辆措施、人类决定。

模拟的必要性

在 DeFi 中,安全不是通过“思考”来证明的;并通过仿真进行测试。协议的经济稳健性可以通过数值运行不同的价格、流动性和攻击场景来理解。 AI可以规划和起草这些模拟的代码;但产生和解释结果的是工具和人员。人工智能产生的“可能耐用”的说法不是模拟结果,不能这样表述。

提示:当您收到 AI 的 DeFi 风险评估时,您应该询问每个假设“我用什么模拟来测试它?”把它变成一个问题。无法测试的安全声明并不是 DeFi 的保证。

常见错误

  • 像代码错误一样扫描经济赤字。 DeFi 风险主要在于商业逻辑。
  • 相信人工智能会说“安全”并跳过模拟。需要进行测试。
  • 逐一验证组件并跳过交互。整体经济至关重要。
  • 信任来自单一来源的 Oracle。最常见的 DeFi 灾难。
  • 忽略 MEV/抢先交易。忘记公共内存池的事实。
  • 生成漏洞利用代码。只有防御性分析才是合法的。

综上所述

  • DeFi 是一个高价值且充满敌意的空间;风险主要存在于经济/商业逻辑中。
  • MEV、抢先交易、三明治和预言机操纵是 DeFi 特有的攻击类别。
  • AI强于机制解释和场景绘制;原来的经济赤字很弱。
  • 经济安全是通过模拟而不是思考来证明的;人工智能计划、车辆措施。
  • Oracle 依赖是 DeFi 最脆弱的点;需要多种资源和 TWAP。

应用任务

选择 AMM 或借贷协议(有清晰的文档)。将“机制描述”和“经济攻击面”提示应用于AI。对于人工智能产生的每一个风险假设,“我会用什么模拟来测试它?”回答问题。然后找到该协议的实际审计报告,并将实际发现结果与人工智能标记的风险进行比较:人工智能发现了什么,错过了什么?

清单

  • [ ]我从代码+经济两个维度讨论了风险。
  • [ ] 我评估了 MEV/抢先交易。
  • [ ] 我还检查了 Oracle 依赖性。
  • [ ] 我质疑各组成部分(整个经济)的相互作用。
  • [ ] 我将每个假设与模拟计划联系起来。
  • [ ] 我用模拟取代了AI的“安全”。
  • [ ]我只是出于防御目的进行分析。