Mind the Gap：检测 DAO 治理中的描述-执行不匹配攻击

核心问题是：投票者看到的提案描述，是否忠实对应批准后执行的链上行为。 作者将两者不一致称为描述—执行错配（Description–Execution Mismatch，DEMI）。

• 治理场景：DAO 按 propose→vote→execute 流程决策。作者认为，多数成员依赖描述理解提案，而描述本身不能约束链上执行。
• 现有工具：作者称 Snapshot、Tally 等主要展示提案材料；Tally 的执行预览由提案者提供，不能替代独立可复现的执行轨迹（§4.1、Table 5）。
• 威胁模型：受害系统是带可执行载荷的 DAO 治理；区块链、合约执行和治理基础设施被假定正常（§3.1）。
  • 目标与能力：攻击者可操控任意提案描述及执行载荷，以误导投票、盗取资金或夺取控制权。
  • 约束与知识：不能绕过门槛、quorum、timelock 或治理生命周期；适应性评测另区分 gray-box 与 white-box。
• 核心观察：作者认为，同一 DAO 的历史提案复用生命周期函数，因此可重建治理配置；一致性检查可转为逐动作寻找文本证据。
• 提出的防御：生命周期模拟生成轨迹，DEMI Guard 建立动作—证据映射，Robustness Guard 检查高风险动作的证据。系统定位为执行前人工复核的分流层。

相关研究围绕 DAO 治理安全、治理工具、语义错配检测与提示注入 展开。

DAO 安全与治理机制

• Dotan 等（2023）、Feichtinger 等（2024）——分析真实治理攻击和人的参与因素；Junjie Ma 等（2024）、Wei Ma 等（2024）研究治理过程与提案质量。
• Voting-Bloc Entropy、DAVe（2024）——分别研究去中心化程度度量和密码学验证框架。
• Sharma 等（2024）、Tamai 与 Kasahara（2024）、Van Vulpen 等（2024）——分别研究 Web3 欺诈、抵抗鲸鱼与合谋的投票机制、可升级合约治理。作者称上述工作没有提供自动化、以执行为依据的错配验证（§9）。

治理平台与信息展示

• Snapshot、Tally、项目原生门户——展示描述，部分展示载荷。作者指出，Tally 的模拟结果可选且由提案者提交；Table 5 将其与独立执行结果区分。
• Agora、DAO Stack、Compound、Arbitrum、Uniswap 治理工具或论坛——引言将其列入现有治理工具，未逐项报告检测实验。

文档与执行语义一致性

• DeFiAligner（Gan 等，2024）——结合符号分析和 LLM 检查文档与已部署代码的不一致。作者认为，治理提案还需要完整生命周期模拟，才能得到可验证轨迹。
• 基线方法——在 Tally 的144份标注提案上，对比 All-function keyword match、High-risk keyword match、DeFiAligner-adapted、Direct query 与 Evidence-mapping（Table 1）。DeFiAligner-adapted 使用 GPT-4o。

不可信输入与提示注入

• Greshake 等（2023）——研究 LLM 集成应用中的间接提示注入。
• Hines 等（2024）——研究 Spotlighting 防御；作者引用它作为输入隔离的依据，将提案描述作为不可信数据处理（§6.3）。

作者将本方法的区别归为 独立生命周期模拟、逐动作证据映射和按风险复核证据，而非仅展示载荷或要求 LLM 给出整体判断。

DEMI Detection Framework 将执行轨迹生成与语义审计分开：先得到可复现的链上行为，再检查每个动作是否有描述依据（Figure 4）。

问题定义

• 三个表示：description d 是投票依据，payload p 是执行输入，trace τ 是运行行为。作者要求第三方能在相同链上状态假设下复现或验证轨迹（§3.2）。
• 错配定义：Cons(ϕ(d),ψ(p))=False。其中 φ 表示投票者从描述预期的行为，ψ 表示载荷产生的轨迹；作者据此定义 DEMI。

生命周期模拟

• Profile Building：扫描治理合约历史中的 propose、castVote、execute 调用，提取载荷、提案者、真实投票者、时序参数和执行格式，按 DAO 复用配置。
• Input Building：将目标提案数据与 DAO Profile 合并。模拟分叉点设为 proposalStartBlock+1；作者称这让模拟使用执行前状态（§4.3、Figure 5）。
• 完整生命周期：基于 Foundry forge 推进区块与时间，在本地模拟提案、投票、排队和执行；使用历史投票者身份满足投票流程，而非直接调用执行入口。
• 轨迹过滤：去除只读调用、delegatecall 触发的子轨迹，以及模拟脚本引入且不属于提案 execute 上下文的片段，保留状态变更和价值移动动作。

DEMI Guard：动作—证据映射

• 输入与输出：输入描述和过滤后的执行动作；为每个动作提取最小支持文本，输出证据、是否被描述、置信度和汇总（Figure 7）。
• 设计理由：作者认为，无需恢复描述与轨迹的完整语义等价；逐动作寻找明确依据即可作为错配检查的基础。
• 聚合配置：部署模型为 GPT-4o，temperature=1.0，N=5 次独立推理后多数投票（§5.2、§5.4）。附录 D.3.1 给出了完整提示词。

Robustness Guard：复核证据与风险

• 复核对象：输入描述、执行动作及映射结果，检查证据是否来自原文、是否支持对应动作、是否过度宽泛或偏离提案目的（§4.5）。
• 风险区分：Table 9 将资金操作、所有权或管理权、角色权限、合约升级和危险操作列为高风险；作者对这些动作要求更明确的证据。
• 实现呈现：§4.5 将风险约束描述为追加到 DEMI Guard 提示词；附录 D.3.2 同时给出了接收映射结果的独立复核提示词。
• 输入隔离：部署版本将描述放入不可信数据区域，要求模型将其作为审计材料。附录 D.3.2 给出了完整提示词；附录 D.4、Figure 11 给出规避示例，不在此复述。

证据分为 历史提案检测、受控对抗评测和部署规模扫描，三者的数据集与成功口径需要分别理解。

实验设置

• 被测模型：GPT-4o-mini、GPT-4o、GPT-4.1、GPT-5、GPT-5.6、Claude Sonnet 4.5、Claude Opus 4.8、Claude Fable 5、Kimi K3。
• 模拟数据：Ethereum 全链扫描识别3,681个治理相关合约，筛选有执行历史、Etherscan 已验证且支持投票的358个 DAO，包含10,190份已执行提案（§6.1）。
• 检测数据：配置比较用 Tally 的144份标注提案；完整系统用3,864份，其中893份 mismatched、2,971份 matched，采用分层4折交叉验证（§5、§6.2）。
• 人工标注：两名专家独立逐动作检查，一致率98.5%、Cohen’s κ=0.958；58份分歧经第三人标注及三人共识处理（附录 D.1）。
• 基线与指标：关键词规则、DeFiAligner-adapted、Direct query、Evidence-mapping；报告 Precision、Recall、F1，以及模拟覆盖率。决策阈值的具体数值未报告。
• 对抗协议：GPT-4o 分别承担攻击生成、护栏和投票者判断；投票者模型 temperature=0。84份已检测恶意提案进行3次独立试验，每次4轮红蓝对抗（§6.3）。

主结果

据 Table 3：Tally 的144份标注提案，比较同一模型的 Direct query 与 Evidence-mapping（EM）。

表格较宽，可左右滑动

被测模型	Direct Recall	EM Precision	EM Recall	EM F1
GPT-4o	46.6%	83.9%	83.0%	0.834
GPT-4.1	57.1%	84.5%	85.7%	0.851
GPT-5	62.5%	60.8%	98.9%	0.753
GPT-5.6	64.8%	76.4%	92.0%	0.835
Claude Sonnet 4.5	78.8%	68.3%	98.5%	0.807
Claude Opus 4.8	68.4%	78.6%	93.7%	0.855
Claude Fable 5	35.1%	81.4%	85.7%	0.835
Kimi K3	54.0%	62.0%	92.0%	0.741

• 跨模型取舍：EM 在这些模型上均有更高 Recall，但 GPT-5、Claude Sonnet 4.5、Kimi K3 的 Precision 低于各自 Direct query。作者将其解释为偏向召回的取舍。
• 完整系统：在3,864份提案、GPT-4o、N=5、分层4折条件下，Precision 为81.7% ±1.1%，Recall 为98.3% ±0.6%，F1 为0.892 ±0.008（Table 7）。
• 去除护栏：相同全数据集评测中，Precision 为79.8% ±1.5%，Recall 为82.4% ±2.1%，F1 为0.810 ±0.018。作者将系统定位为人工复核分流层。

模拟覆盖与真实提案扫描

• 覆盖结果：支持332/358个 DAO（92.7%），获得9,098/10,190份提案的执行结果（89.3%）（Table 6）。
• 模拟失败：26个 DAO、1,092份提案未获得结果；作者归因为链上 revert、分叉点不可用的外部 oracle 依赖及非标准投票逻辑（§6.1）。
• 部署扫描：以10,190份已执行提案为扫描范围，671份被标记，人工确认544份，127份仍需项目方确认；确认项含69份恶意、475份不负责任提案，9份获项目方确认（§7、§8）。

自适应攻击与留出泛化

• 知识条件：white-box 获得完整护栏提示词和风险分类；gray-box 只知道公开方法。执行行为保持不变，攻击方改写描述；蓝队据规避案例添加规则。
• 防御口径：护栏标记提案，或投票者模型识别到高风险接收方或金额，均算防御成功。作者报告各轮防御率接近70–80%；纯文本无法核查 Figure 10a 的曲线位置与逐轮值。
• 留出结果：84份提案按索引分半，在一半强化、另一半攻击，3次试验下基础护栏 white-box 防御率为77.8%，强化护栏为66.7%（§6.3）。Figure 10b 文字标注为78%与67%；作者认为此流程中的鲁棒性可能来自结构。

提示注入压力测试

• 测试内容：将4类恶意指令模板加入恶意描述，评测其是否使护栏判为一致；不复述模板内容（§6.3）。
• 未隔离输入：作者报告单模板最高成功率60%，至少一种模板成功的比例68%。论文未报告这些比例的样本分母。
• 输入隔离后：作者报告成功率4%，对应1个残留案例；未报告分母。该实验没有将上述比例拆分到每种模板。

其他消融与分析

• 策略比较：144份提案、GPT-4o，DeFiAligner-adapted 的 Precision/Recall/F1 为63.1%/93.2%/0.752；DEMI Guard 为79.3%/100%/0.884（Table 1）。
• 规则基线：同一144份数据，All-function keyword 的 Precision/Recall 为60.6%/97.7%；High-risk keyword 为63.6%/39.8%（Table 1）。
• 温度：144份数据、GPT-4o EM，temperature=0.0 与1.0 的 F1 分别为0.834、0.791（Table 2）。
• 推理次数：144份数据，N=1/3/5/7 的 F1 为0.812/0.843/0.839/0.835；Table 4 未单独标明模型，§5.4 按 GPT-4o 费率说明成本。
• 成本与延迟：上述 N 设置每提案成本为0.016 美元/0.048 美元/0.080 美元/0.112 美元；作者报告并行推理端到端延迟接近单次的∼8.8s（§5.4）。
• 规避案例：附录 D.5 讨论动作替换、合法性包装、部分披露；作者称风险复核纠正了基础 EM 的这些误判，未报告各类样本数或独立准确率。

作者明确提出的后续方向是 跨链治理支持与治理流程层面的预防措施；报告中的数据范围也有需要区分之处。

作者指出的局限与后续方向

• 跨链治理：§6.1 的 Coverage limitations 将 L2-native timelocks、bridge-based voting 列为 future work，当前范围为 Ethereum L1 Governor-pattern DAOs。
• 流程保障：§8 建议投票前提供可复现执行预览、为高影响提案设置结构化审查、展示风险信号；这是作者提出的治理层缓解方向。
• 数据分发约束：附录 B 说明完整轨迹部分来自不能再分发的专有 archive RPC，发布材料提供代表性开放子集和轨迹再生成脚本。

实验覆盖范围

• 目标提案：§2.1 只讨论带链上可执行载荷的提案；纯社会或信号提案、委托基金会后续执行的治理动作不属于研究范围。
• 检测与对抗：完整检测在3,864份历史提案上做4折验证；适应性攻击使用84份已检测恶意提案、GPT-4o、3次试验与4轮对抗（§6.2、§6.3）。
• 判定口径：防御率同时计入护栏拦截和投票者模型识别风险，不能直接当作护栏独立拦截率；提示注入比例的分母未报告（§6.3）。
• 数据数量不一致：附录 D.1 将69份恶意、475份不负责任提案写为893份 mismatched 的子分类，却未解释其余项；§7 将这两组数量用于另一部署扫描中的544份确认案例。
• 展示与公开材料：Figure 2 的金额文字、正文轨迹及后文案例存在数值或单位表达差异，不能据此重算损失；附录 B 明确列出的公开人工标注集是144份。

这是面向 DAO 治理的执行前错配检测研究：攻击者可以提交看似合理的描述，但让获批载荷执行另一种行为，投票描述并不直接约束代码。

• 方法链条：从历史交易重建 DAO Profile，在执行前链上状态模拟完整治理生命周期，再逐动作提取描述依据。Robustness Guard 复核证据，部署版本加入不可信输入隔离。
• 模拟覆盖：在筛选后的 Ethereum 活跃治理数据上，支持332/358个 DAO，得到9,098/10,190份提案执行结果，提案覆盖率89.3%（Table 6）。
• 检测表现：Tally 的3,864份标注提案、GPT-4o 完整系统、分层4折验证下，平均 Precision 为81.7%，Recall 为98.3%，F1 为0.892（Table 7）。
• 模型与对抗：144份提案上的8模型比较中，EM 的 Recall 均高于 Direct query（Table 3）；留出 white-box 攻击中，基础与强化护栏防御率为77.8%、66.7%（§6.3）。
• 实际扫描：10,190份提案扫描中人工确认544份错配，含69份恶意与475份不负责任提案；作者报告其中9份获项目方确认（§7、§8）。
• 作者结论：作者认为，逐动作证据与高风险披露要求可支撑执行前审计，但仍有自适应绕过。系统用于提示人工复核，不能将模型判断等同于自主批准或拒绝提案。