2026/9/18 15:24:53
FEATURED · 精选文章 
Aptos Move 最弱前置条件WP规范推断move_package_wp 工具契约与诊断处理全指南【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core导读本文围绕 Aptos 仓库中aptos-move/flow的规范推断Specification Inference工作流展开深入讲解其核心工具move_package_wp——一个基于最弱前置条件Weakest Precondition, WP推理、从 Move 函数实现自动派生形式化规范并写回源码的 MCP 工具。你将掌握该工具的参数与输出模式、五种典型诊断结果的准确含义与修复动作、pragma opaque与继承式 partial 规则的边界以及如何区分规范缺陷与工具缺陷。本文以 wp_tool.md 为骨架结合 package_spec_infer.rs 源码实现逐条印证。WP 推理的基本原理在深入工具之前先理解其数学内核。wp_concepts.md 给出的定义简洁有力最弱前置条件推理从返回returns、中止aborts、调用calls与状态更新state updates向后推导刻画每种行为对应的初始状态集合循环由其不变量表示不变量未约束的值在循环之后被视为任意值。这意味着move_package_wp不是正向模拟执行而是反向求解条件它回答的是为了满足某个函数的所有可观察行为调用方必须满足什么前置条件、函数会以何种方式中止、会修改哪些全局状态。循环之所以需要不变量是因为向后推理无法机械地穿过任意次迭代只能依赖一个进入时成立、每次迭代保持的断言来抽象整段循环。move_package_wp 工具概览与调用方式工具定位在 core_tools.md 描述的Move 包检查工具族move_package_status、move_package_manifest、move_package_query之外move_package_wp是规范推断专用工具。在 README.md 的工具清单表中它的定位被描述为move_package_wp— Infer and inject specifications with weakest preconditions (hybrid tactics only)即仅在后端混合hybrid策略下可用与agent-only纯 Agent 直接推理、不含 WP 工具策略互斥。参数与默认值工具的契约在 package_spec_infer.rs 中由MovePackageSpecInferParams精确定义参数类型必填说明package_pathstring是Move 包目录路径即包含Move.toml的目录filterstring?否作用域过滤module、module::function或address::module::function支持数字或命名地址裸模块名必须无歧义。省略时推断整个包的所有目标模块spec_output枚举否输出模式默认inlinefilter的三级粒度与验证工具move_package_verify保持一致。从源码看filter会被resolve_filter解析为(VerifiedScope, VerificationScope)见 package_spec_infer.rs并且当设置了filter时工具会构建一个全新环境build_filtered_env只把匹配 filter 的文件作为 primary target——这与move_package_verify的动机一致避免缓存环境中所有模块都是 target导致 prover 的字节码流水线遍历整个包从而在不打算验证的模块例如storage_slot上 panic。输出模式inline 与 filespec_output枚举定义在 package_spec_infer.rsinline默认推断出的规范被注入原始源码文件。实现上prover 先生成stem.enriched.move富化文件工具读取其内容、覆盖写回原文件、再删除富化文件见 package_spec_infer.rs。file为每个目标模块生成伴生的stem.spec.move文件原始源码保持不动见 package_spec_infer.rs。无论哪种模式循环不变量永远留在其可执行循环旁边不随spec_output移动到伴生文件。写回后工具会调用source_check::check_inferred_output做格式与 AST 校验并通过source_check::format_file格式化每个被修改文件最终返回被修改文件的路径清单以及统计到的[inferred标记数量这是后文标记纪律的落点。调用示例# 推断整个包所有目标模块默认 inline 注入源码 move_package_wp package_pathsources/ # 只推断某个模块 move_package_wp package_pathsources/ filtermy_module # 只推断某个函数 move_package_wp package_pathsources/ filtermy_module::transfer # 推断到伴生 .spec.move 文件保留原始源码 move_package_wp package_pathsources/ filtermy_module::transfer spec_outputfile结果解读五种情形与对应动作原文档的核心是按函数解读结果的决策树。这是使用 WP 工具最关键的部分——警告不是普通提示每种警告都对应一种明确的工作项或工具缺陷声明。情形一无警告 —— 生成规范按构造正确没有警告意味着生成的规范在构造上是完整且正确的包括隐式算术中止如溢出、除零边界中止如越界索引资源中止如访问不存在的资源被调用方callee的中止传播。需要特别强调两个边界WP 不运行 prover。无警告不代表证明通过——验证可能仍然超时。此时修复方向是修理证明或改用等价的、对求解器友好的表达式前提是不削弱契约不能为了好证而删条件。工具 bug 的判定标准对未修改的、无警告的WP 输出若出现编译错误或反例这是工具缺陷tool bug应报告该失败条件而不是去改规范。这一点在源码中亦有呼应无过滤路径会先clear_diag()清理历史诊断再运行推断见 package_spec_infer.rs确保警告来源干净。情形二缺失或不足的循环不变量这是最常见也最需要动手的情形。动作是添加一个进入时成立、且被每次迭代保持的不变量。关键辅助机制警告会携带有界循环头观测值bounded loop-head observations。源码中对应LOOP_INVARIANT_EVIDENCE_DEPTH与options.inference.loop_invariant_evidence evidence_depth见 [package_spec_infer.rs](https://link.gitcode.com/i/dca48152f50a491f0f9d6de1ae0962d4#L78, L124)——prover 会展开循环前若干次迭代报告循环头处的取值帮助你归纳出不变量。但文档明确警告这些观测只是显示的那段执行前缀的描述不是证明。正确的迭代流程是为该函数补齐不变量 →删除该函数过期的、由 WP 生成的函数子句保留不变量、helper 和用户手写的子句→ 重跑 WP。spec_inf_rules.md还给出了常见的循环不变量形状累积accumulation、搜索search、量化遍历quantified traversal、有状态遍历stateful traversal以及针对内联高阶迭代器的folds_of提示。情形三部分 opaque / 无体 callee 规范 —— 唯一合法的调用方 partial这是唯一能让调用方规范合理地为 partial的 callee 情形。当被调用方契约自身是 partial 的aborts_if_is_partial调用方将没有确切的 abort 条件可以陈述因此保留pragma aborts_if_is_partial不要删除它来宣称 totality在契约中注明是哪个命名 callee 引入的 partiality不要重写调用方也不要删掉 pragma 去伪装成完备。配套规则在 spec_inf_rules.md 中被称为继承式 partialityInherited partiality它只计入你发现的 partiality推断报告给 callee 的或你接手时树上已有的自己写出来的 partiality 不算——把一个 helper 标成 partial 再拿它当挡箭牌会被候选检查candidate check拒绝。在 callee 保持 partial 期间调用方必须保持 partial且这个警告不是对调用方的修复义务不需要反复重跑 WP。情形四透明 callee 缺少完整 opaque 契约当被调用方是**透明transparent**的、又没有完整的 opaque 契约时WP 无法补全调用方。分两种处理路径callee 在可编辑范围内例如当前模块内先为 callee 推断并验证其 opaque 契约再对调用方重跑 WPcallee 在可编辑范围之外把该依赖报告为corpus/package blocker——其所有者必须提供完整且已验证的 opaque 契约。文档特别强调绝不能用这种情形来为调用方的aborts_if_is_partial辩护。这正是继承式 partiality规则的反面教材。情形五未建模的 prover intrinsic —— 工具缺陷pragma intrinsic函数执行的是 prover 内建语义builtin而非其 Move 函数体。因此不要为其添加源码级 spec不要把它们改成 opaqueWP 工具必须在内部提供该 builtin 的值value、中止abort与变更mutation语义。遇到此类警告应视为 WP 工具缺陷并上报。spec_inf_rules.md 同步规定不要为pragma intrinsic函数合成普通契约prover 提供其语义。总则什么算工具缺陷文档最后给出收口定义条件的意外丢失、畸形输出或任何其他推断失败都是工具缺陷而不是削弱规范的邀请。也就是说move_package_wp的警告体系是要么修情形二、四要么保留并记录情形三要么上报情形一的后半、情形五唯一不允许的响应是通过削弱契约让问题消失。配套工作流从 WP 输出到候选检查move_package_wp不是孤立工具它嵌在aptos-move/flow的完整规范推断闭环中。任务编排定义在 spec_inf_tasks.md两种混合策略的差异在于 WP 的使用方式hybrid-guided默认按固定顺序执行——先在请求作用域上跑 WP含循环→ 按本文第五节的决策树逐个修复诊断、逐函数重跑 → 简化 WP 产物保持每个 result/abort/frame 义务不变→ 跑候选检查。README.md中的调用形式为/move-inf与/move-inf hybrid-flexible sources/x.move。hybrid-flexibleWP 作为可选推断通道何时用、是否与直接推理和不变式合成搭配由 Agent 自行决策。两种策略的终点都是 candidate_check.md 描述的move_spec_check候选检查——它是唯一决定工作是否完成的裁判会编译包、验证目标并拒绝自我削弱的契约禁用/跳过验证、空洞条件、无 callee 依据的 partial-abort pragma。它同时取代了收尾时的move_package_verify调用前者重复即将做的验证后者重复已经做过的证明。一个值得注意的实现细节在度量measured场景下uninvariant_loop_is_error会把无不变量的循环从产出可验证空契约升级为必须失败见 package_spec_infer.rs 与EvaluationConfig::uninvariant_loop_is_error的注释防止循环被静默抽象成空契约。输出纪律与工程质量红线结合 spec_inf_rules.md 与 verification_ref.md使用 WP 工具时必须遵守以下纪律这些也是候选检查会强制执行的标记纪律每个你撰写的条件与不变量标[inferred]绝不标记用户既有子句。源码正是通过统计[inferred出现次数来计量推断产出的见 package_spec_infer.rs。opaque 契约的诚实性对目标函数撰写的规范必须pragma opaque并且该契约必须被证明真的成立——pragma opaque不会抑制函数自身函数体的验证。契约缺结果、缺 abort、缺 frame 不只是不完整而是错误——调用方会基于一个实现不兑现的承诺被验证。同理不要给检查范围之外的 helper 加pragma opaque它会在调用点被假定、却永远不会被验证检查会拒绝它透明 helper 不需要契约prover 直接读其函数体。不削弱原则绝不删减行为条件、绝不添加限制性requires来挡反例、绝不启用 partial abort 覆盖、绝不省略 frame、绝不跳过验证。诊断分类先行见 verification_ref.md编译/规范语言错误先修语法与名字解析后置条件反例追溯正常路径abort 反例枚举直接与传递的 abort 来源frame 失败对照modifies子句超时视为未解决既不是假也不是已验证。超时策略先简化 WP 生成或手写的表达式去冗余、提取公因子、修复vacuous/sathard循环输出用split_vcs_by_assert与小assert提示切分义务用等价 frame/有界关系/递归 helper 替换敌意无界量词偏好加法递推而非非线性闭式用apply显式实例化引理并给[weight N]最后才考虑提高 per-condition 超时。结论一份可执行的诊断契约move_package_wp的价值在于把规范推断从黑盒变成了带明确责任边界的流程WP 引擎负责按构造生成完备条件含隐式中止与 callee 传播人类/Agent 负责四件事——补循环不变量、为可编辑范围内的透明 callee 推断 opaque 契约、记录并保留继承的 callee partiality、以及把超时当作证明问题而非规范问题去修。剩下的一切异常无警告输出上的反例、未建模 intrinsic、条件丢失都属于工具缺陷应当上报而非修掉症状。这套契约在 wp_tool.md 中被精确定义并由 package_spec_infer.rs 的实现在工程上落地——理解它就理解了 Aptos 形式化验证流水线的入口。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Aptos Move 最弱前置条件（WP）规范推断：move_package_wp 工具契约与诊断处理全指南
Aptos Move 最弱前置条件WP规范推断move_package_wp 工具契约与诊断处理全指南【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core导读本文围绕 Aptos 仓库中aptos-move/flow的规范推断Specification Inference工作流展开深入讲解其核心工具move_package_wp——一个基于最弱前置条件Weakest Precondition, WP推理、从 Move 函数实现自动派生形式化规范并写回源码的 MCP 工具。你将掌握该工具的参数与输出模式、五种典型诊断结果的准确含义与修复动作、pragma opaque与继承式 partial 规则的边界以及如何区分规范缺陷与工具缺陷。本文以 wp_tool.md 为骨架结合 package_spec_infer.rs 源码实现逐条印证。WP 推理的基本原理在深入工具之前先理解其数学内核。wp_concepts.md 给出的定义简洁有力最弱前置条件推理从返回returns、中止aborts、调用calls与状态更新state updates向后推导刻画每种行为对应的初始状态集合循环由其不变量表示不变量未约束的值在循环之后被视为任意值。这意味着move_package_wp不是正向模拟执行而是反向求解条件它回答的是为了满足某个函数的所有可观察行为调用方必须满足什么前置条件、函数会以何种方式中止、会修改哪些全局状态。循环之所以需要不变量是因为向后推理无法机械地穿过任意次迭代只能依赖一个进入时成立、每次迭代保持的断言来抽象整段循环。move_package_wp 工具概览与调用方式工具定位在 core_tools.md 描述的Move 包检查工具族move_package_status、move_package_manifest、move_package_query之外move_package_wp是规范推断专用工具。在 README.md 的工具清单表中它的定位被描述为move_package_wp— Infer and inject specifications with weakest preconditions (hybrid tactics only)即仅在后端混合hybrid策略下可用与agent-only纯 Agent 直接推理、不含 WP 工具策略互斥。参数与默认值工具的契约在 package_spec_infer.rs 中由MovePackageSpecInferParams精确定义参数类型必填说明package_pathstring是Move 包目录路径即包含Move.toml的目录filterstring?否作用域过滤module、module::function或address::module::function支持数字或命名地址裸模块名必须无歧义。省略时推断整个包的所有目标模块spec_output枚举否输出模式默认inlinefilter的三级粒度与验证工具move_package_verify保持一致。从源码看filter会被resolve_filter解析为(VerifiedScope, VerificationScope)见 package_spec_infer.rs并且当设置了filter时工具会构建一个全新环境build_filtered_env只把匹配 filter 的文件作为 primary target——这与move_package_verify的动机一致避免缓存环境中所有模块都是 target导致 prover 的字节码流水线遍历整个包从而在不打算验证的模块例如storage_slot上 panic。输出模式inline 与 filespec_output枚举定义在 package_spec_infer.rsinline默认推断出的规范被注入原始源码文件。实现上prover 先生成stem.enriched.move富化文件工具读取其内容、覆盖写回原文件、再删除富化文件见 package_spec_infer.rs。file为每个目标模块生成伴生的stem.spec.move文件原始源码保持不动见 package_spec_infer.rs。无论哪种模式循环不变量永远留在其可执行循环旁边不随spec_output移动到伴生文件。写回后工具会调用source_check::check_inferred_output做格式与 AST 校验并通过source_check::format_file格式化每个被修改文件最终返回被修改文件的路径清单以及统计到的[inferred标记数量这是后文标记纪律的落点。调用示例# 推断整个包所有目标模块默认 inline 注入源码 move_package_wp package_pathsources/ # 只推断某个模块 move_package_wp package_pathsources/ filtermy_module # 只推断某个函数 move_package_wp package_pathsources/ filtermy_module::transfer # 推断到伴生 .spec.move 文件保留原始源码 move_package_wp package_pathsources/ filtermy_module::transfer spec_outputfile结果解读五种情形与对应动作原文档的核心是按函数解读结果的决策树。这是使用 WP 工具最关键的部分——警告不是普通提示每种警告都对应一种明确的工作项或工具缺陷声明。情形一无警告 —— 生成规范按构造正确没有警告意味着生成的规范在构造上是完整且正确的包括隐式算术中止如溢出、除零边界中止如越界索引资源中止如访问不存在的资源被调用方callee的中止传播。需要特别强调两个边界WP 不运行 prover。无警告不代表证明通过——验证可能仍然超时。此时修复方向是修理证明或改用等价的、对求解器友好的表达式前提是不削弱契约不能为了好证而删条件。工具 bug 的判定标准对未修改的、无警告的WP 输出若出现编译错误或反例这是工具缺陷tool bug应报告该失败条件而不是去改规范。这一点在源码中亦有呼应无过滤路径会先clear_diag()清理历史诊断再运行推断见 package_spec_infer.rs确保警告来源干净。情形二缺失或不足的循环不变量这是最常见也最需要动手的情形。动作是添加一个进入时成立、且被每次迭代保持的不变量。关键辅助机制警告会携带有界循环头观测值bounded loop-head observations。源码中对应LOOP_INVARIANT_EVIDENCE_DEPTH与options.inference.loop_invariant_evidence evidence_depth见 [package_spec_infer.rs](https://link.gitcode.com/i/dca48152f50a491f0f9d6de1ae0962d4#L78, L124)——prover 会展开循环前若干次迭代报告循环头处的取值帮助你归纳出不变量。但文档明确警告这些观测只是显示的那段执行前缀的描述不是证明。正确的迭代流程是为该函数补齐不变量 →删除该函数过期的、由 WP 生成的函数子句保留不变量、helper 和用户手写的子句→ 重跑 WP。spec_inf_rules.md还给出了常见的循环不变量形状累积accumulation、搜索search、量化遍历quantified traversal、有状态遍历stateful traversal以及针对内联高阶迭代器的folds_of提示。情形三部分 opaque / 无体 callee 规范 —— 唯一合法的调用方 partial这是唯一能让调用方规范合理地为 partial的 callee 情形。当被调用方契约自身是 partial 的aborts_if_is_partial调用方将没有确切的 abort 条件可以陈述因此保留pragma aborts_if_is_partial不要删除它来宣称 totality在契约中注明是哪个命名 callee 引入的 partiality不要重写调用方也不要删掉 pragma 去伪装成完备。配套规则在 spec_inf_rules.md 中被称为继承式 partialityInherited partiality它只计入你发现的 partiality推断报告给 callee 的或你接手时树上已有的自己写出来的 partiality 不算——把一个 helper 标成 partial 再拿它当挡箭牌会被候选检查candidate check拒绝。在 callee 保持 partial 期间调用方必须保持 partial且这个警告不是对调用方的修复义务不需要反复重跑 WP。情形四透明 callee 缺少完整 opaque 契约当被调用方是**透明transparent**的、又没有完整的 opaque 契约时WP 无法补全调用方。分两种处理路径callee 在可编辑范围内例如当前模块内先为 callee 推断并验证其 opaque 契约再对调用方重跑 WPcallee 在可编辑范围之外把该依赖报告为corpus/package blocker——其所有者必须提供完整且已验证的 opaque 契约。文档特别强调绝不能用这种情形来为调用方的aborts_if_is_partial辩护。这正是继承式 partiality规则的反面教材。情形五未建模的 prover intrinsic —— 工具缺陷pragma intrinsic函数执行的是 prover 内建语义builtin而非其 Move 函数体。因此不要为其添加源码级 spec不要把它们改成 opaqueWP 工具必须在内部提供该 builtin 的值value、中止abort与变更mutation语义。遇到此类警告应视为 WP 工具缺陷并上报。spec_inf_rules.md 同步规定不要为pragma intrinsic函数合成普通契约prover 提供其语义。总则什么算工具缺陷文档最后给出收口定义条件的意外丢失、畸形输出或任何其他推断失败都是工具缺陷而不是削弱规范的邀请。也就是说move_package_wp的警告体系是要么修情形二、四要么保留并记录情形三要么上报情形一的后半、情形五唯一不允许的响应是通过削弱契约让问题消失。配套工作流从 WP 输出到候选检查move_package_wp不是孤立工具它嵌在aptos-move/flow的完整规范推断闭环中。任务编排定义在 spec_inf_tasks.md两种混合策略的差异在于 WP 的使用方式hybrid-guided默认按固定顺序执行——先在请求作用域上跑 WP含循环→ 按本文第五节的决策树逐个修复诊断、逐函数重跑 → 简化 WP 产物保持每个 result/abort/frame 义务不变→ 跑候选检查。README.md中的调用形式为/move-inf与/move-inf hybrid-flexible sources/x.move。hybrid-flexibleWP 作为可选推断通道何时用、是否与直接推理和不变式合成搭配由 Agent 自行决策。两种策略的终点都是 candidate_check.md 描述的move_spec_check候选检查——它是唯一决定工作是否完成的裁判会编译包、验证目标并拒绝自我削弱的契约禁用/跳过验证、空洞条件、无 callee 依据的 partial-abort pragma。它同时取代了收尾时的move_package_verify调用前者重复即将做的验证后者重复已经做过的证明。一个值得注意的实现细节在度量measured场景下uninvariant_loop_is_error会把无不变量的循环从产出可验证空契约升级为必须失败见 package_spec_infer.rs 与EvaluationConfig::uninvariant_loop_is_error的注释防止循环被静默抽象成空契约。输出纪律与工程质量红线结合 spec_inf_rules.md 与 verification_ref.md使用 WP 工具时必须遵守以下纪律这些也是候选检查会强制执行的标记纪律每个你撰写的条件与不变量标[inferred]绝不标记用户既有子句。源码正是通过统计[inferred出现次数来计量推断产出的见 package_spec_infer.rs。opaque 契约的诚实性对目标函数撰写的规范必须pragma opaque并且该契约必须被证明真的成立——pragma opaque不会抑制函数自身函数体的验证。契约缺结果、缺 abort、缺 frame 不只是不完整而是错误——调用方会基于一个实现不兑现的承诺被验证。同理不要给检查范围之外的 helper 加pragma opaque它会在调用点被假定、却永远不会被验证检查会拒绝它透明 helper 不需要契约prover 直接读其函数体。不削弱原则绝不删减行为条件、绝不添加限制性requires来挡反例、绝不启用 partial abort 覆盖、绝不省略 frame、绝不跳过验证。诊断分类先行见 verification_ref.md编译/规范语言错误先修语法与名字解析后置条件反例追溯正常路径abort 反例枚举直接与传递的 abort 来源frame 失败对照modifies子句超时视为未解决既不是假也不是已验证。超时策略先简化 WP 生成或手写的表达式去冗余、提取公因子、修复vacuous/sathard循环输出用split_vcs_by_assert与小assert提示切分义务用等价 frame/有界关系/递归 helper 替换敌意无界量词偏好加法递推而非非线性闭式用apply显式实例化引理并给[weight N]最后才考虑提高 per-condition 超时。结论一份可执行的诊断契约move_package_wp的价值在于把规范推断从黑盒变成了带明确责任边界的流程WP 引擎负责按构造生成完备条件含隐式中止与 callee 传播人类/Agent 负责四件事——补循环不变量、为可编辑范围内的透明 callee 推断 opaque 契约、记录并保留继承的 callee partiality、以及把超时当作证明问题而非规范问题去修。剩下的一切异常无警告输出上的反例、未建模 intrinsic、条件丢失都属于工具缺陷应当上报而非修掉症状。这套契约在 wp_tool.md 中被精确定义并由 package_spec_infer.rs 的实现在工程上落地——理解它就理解了 Aptos 形式化验证流水线的入口。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
