aptos-core Flow 规格推断评测语料 Corpus V3.2Move 规范推断基准的构成与度量原理【免费下载链接】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-core 仓库中aptos-move/flow/evaluation/spec-inference下的评测语料文档 corpus-v3.2/README.md完整解读 V3.2 这套用于衡量AI Agent 能否写出正确的 Move 形式化规范的基准语料任务 ID 体系与 27 个目标函数清单、wp_hard的判定语义、基于 Etna 私有源码的可复现构建链、变异体mutant双集合评分机制、手写参考规范的模块布局以及轮次选择round selection算法。读完可以掌握如何按文档与源码理解该语料的每个目录与脚本的职责如何复现/校验语料包以及契约强度是如何通过 refutation 与 scoring 两套互不重叠的变异集合来量化测量的。语料定位从 V2 到 V3 的动机corpus-v3.2/README.md 开篇即声明V3.2 是正式的基准This is the benchmark完整的评测轮次full run计划在这一版语料上进行上一版 V1.1 仅作为基础设施保留不再是运行目标。整体架构详见 DESIGN.md。V3 替换 V2 的原因在文档中写得很明确V2 在两个维度上饱和了目标太小小到可以在脑中装下——Agent 没有任何理由去调用工具如最弱前置条件推断 WP猜测即可通过只评分规范能否验证通过——而一个更含糊vaguer的契约反而更容易通过验证无法区分契约强弱。因此 V3 从两个方向选择任务目标本身要抗拒猜测并引入变异体mutants使契约强度可测量。DESIGN.md 进一步交代了 V1 被替换的原因Aptos 框架是公开的其.spec.move文件也是公开的——V1 抽查的 24 个目标中有 16 个在函数本身上游就已存在公开规范Agent 的成功可能是回忆而非推断。V3 采用私有源码Etna正是为了拿到没有人写过规范的函数。任务 ID 体系与 25 个就绪目标语料共27 个目标23 个来自 EtnaDecibel 私有 Move 代码的代号2 个来自公开的aptos-experimental入选条件是上游不携带规范2 个为本研究自行编写。Etna 源码不会被提交进仓库后文复现一节详述。任务 ID 采用FAMILY-tag-NNN三段式两个字母的模块家族码、区分同模块内目标的短标签、以及全语料连续编号。例如LP-price-021是extracted_liquidation_price模块中get_liquidation_price函数编号 21。编号 001–027 无断档按模块组装时顺序分配因此相邻编号同属一个家族VS-fees-001到VS-redeem-004就是vault_share_math的四个目标。编号不携带难度、排名或顺序含义ID 是稳定的出现在所有调度、产物与元数据文件中任务被搁置或排除时不会重新编号。25 个目标处于ready状态且指定规范后能在20 秒兼容性时限内完成验证——这一条保证了变异评分的可负担性每个变异体都要对目标重验一次。其中 21 个标记hard4 个刻意保留为guessable作为对照用于把装置性故障和真正困难的任务区分开。文档给出的完整目标清单如下原表完整继承任务目标考察点难度VS-fees-001vault_share_math::calculate_unrealized_fees五个带 guard 的 return一个交叉相乘的u128比值测试hardVS-shares-002vault_share_math::convert_existing_shares_to_asset_amount组合伙伴函数刻意简单guessableVS-contrib-003vault_share_math::convert_new_assets_to_share_count元组结果、零份额快速路径、资不抵债断言hardVS-redeem-004vault_share_math::calculate_redemption_funds_and_fee组合——下界溢出自由仅来自被调函数契约hardOV-order-006extracted_order_validation::validate_order_input为何从不 abort短路越过%守卫guessableUC-credits-008extracted_tier_lookup::credits_for_duration_days最后匹配胜出扫描首个匹配的读法是另一个函数hardUC-leverage-009extracted_tier_lookup::leverage_for_tier_rank同一扫描、精确 rank 谓词hardTR-order-010extracted_bulk_order_utils::validate_price_ordering相邻对扫描带提前返回双向严格hardTR-discard-011extracted_bulk_order_utils::discard_price_crossing_levels最小不穿越索引——前缀事实不是 foldhardBA-base-012extracted_base_math::compute_base_needed需要发明引理——见下文hardMM-min-013extracted_minmax::find_min_value先读values[0]空输入时 aborthardMM-max-014extracted_minmax::find_max_value同一循环从 0 起空输入时返回——配对探针hardMD-median-015extracted_median::get_median_price全函数total无循环、无算术、无 abortguessableBK-bucket-016extracted_bucket_index::get_bucket_index提前return结果是最小的容许索引hardTF-taker-017extracted_taker_fee::calculate_min_net_taker_fee100 - pct在 100 以上下溢——源码从未提及的 aborthardDV-dev-018extracted_deviation::calculate_deviation_bps在预期 abort 处返回哨兵值hardTS-trial-019extracted_trial_size::trial_size_for唯一的显式范围检查背后藏着三个未声明的 aborthardTL-lev-020extracted_tier_leverage::checked_max_tier_leverage量词 abort 与累积最大值二者互不蕴含hardLP-price-021extracted_liquidation_price::get_liquidation_price零杠杆意味着零除数在算术上不可见hardSM-select-022selection_machine::select函数值function values——见下文hardWU-consume-023extracted_work_units::consume_order_match_work_unitsmut饱和转移u32两次溢出hardWU-limit-024extracted_work_units::get_max_order_placement_limit钳制除法下限为 1guessableQP-part-025lomuto_partition::partition原地置换in-place permutation——见下文hardPM-curve-027extracted_payout_math::compute三段下取整插值畸形输入只在中间分支 aborthard五个携带独特能力的目标文档指出五个目标携带其余目标不具备的能力是理解这套语料难度来自哪里的关键VS-redeem-004组合推理它调用两个同模块兄弟函数其shares - shares_for_fee不溢出下界的性质只在被调函数的契约中成立在调用方函数体内不可见。契约若只从调用方视角写无法关闭这个义务。BA-base-012辅助推理仅靠循环不变量写不出完整契约——给累积值命名需要一个递归的 spec 函数排除累加器u128溢出需要一个前缀和有界性的单调性引理且该引理要用递归apply证明。累积刻意是线性的推理才是难度而不是求解器耗时。SM-select-022函数值语料中唯一非 Etna 提取的目标Etna 没有函数值代码因此也是唯一不含专有源码的目标。一个有界选择循环通过应用一个续延continuation来抽取候选接受第一个容许者失败若干次后交还位置以便重启。续延与测试都是参数契约需要在它们之上写result_of和aborts_of第k次抽取后的状态需要对函数值写递归 spec 函数。QP-part-025原地置换对u64向量做 Lomuto partition是唯一原地重排输入的目标同样因为 Etna 没有排序代码而自行编写。pivot 落在哪、两侧是什么是普通的循环不变量工作pivot 穿过两次交换难点在于声明结果是重排而非改写直接的forall/exists包含式、裸递归计数、甚至求和代理都会耗尽求解器。参考实现采用[weight 20]下的计数 spec 函数、按段segments证明的 swap 引理以及入口点forall … apply——其触发器trigger正是求解器编码vector::swap时产生的双重update。这个形状下所有证明与所有反例refutation约一秒完成。PM-curve-027分段插值同样的畸形输入在曲线之下与之上都正常返回却在中间分支 abort所以完整的 abort 条件必须包含分支守卫精确结果还要保留加宽后的乘法与下取整除法。wp_hard的含义与空契约陷阱wp_hard记录的是仅靠 WP最弱前置条件推断到不了一个可验证的契约它是任务的属性而非缺陷一个 WP 已经能解决的目标会保留该家族的简单成员。理解这一项需要一段背景当循环没有不变量时havoc 会让推断条件的一部分保持无约束WP 丢弃这些子句产出一个携带aborts_if_is_partial的空契约——它能编译、能验证。在研究场景之外伴随诊断信息是 warning这本身是对的人仍可利用 WP 推导出的东西但只问求解器是否成功的评判下这是错的因为空契约与完整契约不可区分——结果所有循环目标都被记录为wp_hard: false把语料中最难的目标标成了WP 搞定的。ProverOptions::uninvariant_loop_is_error把该诊断升级为 error。从源码与文档的对应关系看move-flow experiment infer始终设置它筛选是绝不能漏掉这一点的消费者评测会话则通过EvaluationConfig::uninvariant_loop_is_error设置使得任何实验臂arm都不能把空契约误当作完成的契约普通 Flow 使用不受影响。三个目标上的 WP 产物无辅助的 WP 推断在VS-shares-002、LP-price-021、TS-trial-019三个目标上产生一个不可证明的sathard子句为一条会 abort 的路径生成了正常返回的ensures并在其旁边复制了一个aborts_if。文档说明它不是求解器难度尽管叫sathard也与循环无关——三个目标都没有循环它不是坏任务——三者都能对着参考规范证明通过因此准入由良构 可验证的参考决定WP 困难度只作为任务属性记录两个 hybrid 臂都会收到它且禁止通过删除sathard子句来让证明通过所以阅读这三个目标的会话记录时需带着这一背景。VS-redeem-004也携带sathard子句但不是此产物其子句携带对兄弟调用的result_of属于上文所述的组合难度。溯源Provenance私有源码的可复现构建这是 V3.2 工程上最精细的部分。Etna 从固定 commit导出而 vendored 标准库与 trading 目标则从 aptos-core 的活动工作树读取于是 build.py拒绝在有已跟踪修改的树上重新生成否则语料会挂在一个并不包含这些修改的 commit 名下记录的哈希描述的将是任何人无法重建的源码。--allow-dirty可以覆盖该检查但会在清单中记录reconstructible: false使声明永远不会在沉默中变假。提交进仓库的清单记录其生成源码是否来自干净的 aptos-core 树发布构建必须报告tracked_modifications: false且reconstructible: true--allow-dirty仅限开发使用。这一点在 manifest.json 中可以直接验证其provenance.aptos_core字段当前记录reconstructible: true、tracked_modifications: falseprovenance.etna固定到私有仓库的 commit1a71823845dc092c825996d433adaf9843ea78aa而generated_file_sha256为每一个生成文件deps/*.move、etna/*.move、trading/*.move登记了 SHA-256。从 build.py 的实现可以看到更强的保证etna_tree()不是读取工作目录而是通过git archive commit move导出固定 commit 的树对象见 build.py#L26-L31 中对仓库与 commit 的锚定因此一个脏的 checkout 无法改变语料构建的内容——导出 commit 取代了读取工作目录直接消除了失败模式。轮次选择select_round.py的盲化处理完整一轮的成本是每任务 × 每臂 × 每副本各一个会话所以一轮可以只运行就绪目标的一个子集。选择器 select_round.py只从语料自身对每个任务及其目标源码的描述中选取——绝不参考任何臂的行为——并把结果作为round_selection字段写进每个清单记录和 metadata/selection.json。没有任何删除被搁置的样本仍在语料中等待后续轮次。脚本头部注释给出的规则顺序为(1) 保留每个独有携带某特征层stratum的任务(2) 冗余簇strata 相同或目标源码近重复内保留一个代表——最大的目标作为最丰富契约的代理(3) 其余名额按稀有度加权的新颖性填充(4)guessable任务设上限。源码中近重复的相似度阈值为SOURCE_SIMILARITY 0.50select_round.py#L44。当前选择是25 个就绪目标中的 20 个selection.json 显示其完整构成全部 38 个 strata 无一丢失strata_lost: []跨 15 个模块、10 个含循环任务guessable恰为 3 个上限。审计发现的两个近重复目标对是MM-max-014/MM-min-013源码相似度 0.895与UC-credits-008/UC-leverage-0090.555DV-dev-018、LP-price-021、TF-taker-017、WU-limit-024携带相同 strata保留最大者、其余搁置held_back中逐条记录了搁置原因。两个任务被明确排除在调度之外调度器丢弃任何screening_status非ready的目标显式指名它们是错误而非覆盖任务目标原因PN-pnl-005extracted_pnl_math::calculate_pnl规范与代码之间的有符号除法分歧在 blockers/ 中做了归约QT-quote-007extracted_quote_math::compute_quote_needed与BA-base-012相同的引理需求但其逐层p * s / m使证明非线性且在尝试过的任何预算下最长 240s都无法消解blockers/README.md 记录了PN-pnl-005的细节WP 推断出貌似完整的契约含MIN_I64取负溢出与两个MAX_I128转换上界但其自身的ensures随后失败归约到signed-div-narrowing.move后每个操作孤立验证都通过组合后收窄 abort 条件被拒绝——求解器找到了规范商超出i64范围而可执行代码不 abort的状态呈现为规范级/与代码在边界附近截断与 floor 语义的分歧。QT-quote-007保留而非删除因为它是选择引理目标时优先线性累积这一原则的证据。变异体两个互不重叠的集合变异体只修补实现绝不修补规范。装置把它应用到包的副本上再用Agent 写出的成品规范重跑求解器求解器失败 → 变异体被杀死killed契约足够精确以至于察觉了错误求解器成功 → 存活survived契约对着错误代码也验证通过。反证集refutation每个就绪目标 3 个变异体QP-part-0254 个共76 个留置评分集scoring20 个被选任务各 3 个共60 个。abort代码不在考察范围内只改变 abort 携带哪个代码的变异体测的是错误码钉扎而非契约强度。文档还交代了一个质量控制细节首批草稿有两个因此被丢弃——它们把守卫从x 0削弱为x 00 到达除法后函数仍 abort只有 abort代码变了完整契约无法观测到这个差异validate_mutants将其记录为survived后它们被可观测的编辑替换。为什么必须是两个集合反证机制会把存活变异体作为失败反馈给 Agent变异集就此变成训练材料在同一集合上给臂评分等于就告诉过它的东西考它。因此两个集合永不重叠集合路径角色refutationmutants/以类别形式展示给 Agent——额外的生命scoringmutants-scoring/留置严格成功分strict-successharness.controller拒绝两个根解析相等的运行author_mutants.py --disjoint-from拒绝与反证变异体重复文件、偏移与编辑的评分变异体。操作上有明确的时序约定调度时传入 scoring 根harness.pilot --mutants-root使其摘要进入记录的装置身份启动时传入反证根harness.pilot_run --refutation-mutants-root。不带--mutants-root的轮次运行scoring_mode: core此时strict_success构造性为 false对契约本身说明不了什么。评分集用 author_mutants.py 编写该脚本计算偏移量与摘要并拒绝在文件中不恰好出现一次的锚点。变异体存储的是偏移量、长度与对生成文件的 SHA-256外加一次最小编辑而不是它重写的代码本身变异体与参考规范都在轮次之前、且看不到任何臂的输出时编写。公开与自编写源码的可读描述放在 mutant-specs/引用私有 Etna 源码的描述属于 gitignored 的mutant-specs/private/目录——提交的运行时清单只保留锚定摘要与最小编辑。参考规范按模块提交的只增补丁一个变异体只有在手写参考规范能杀死它之后才算essential。参考按模块组织——25 个就绪目标分布在 17 个模块上——且只有规范被提交形式是 references/ 下只添加行、从不删除行的补丁。各模块杀死情况模块任务数杀死变异体vault_share_math412/12extracted_bulk_order_utils39/9extracted_minmax26/6extracted_tier_lookup26/6extracted_work_units26/6extracted_base_math13/3extracted_bucket_index13/3extracted_deviation13/3extracted_liquidation_price13/3extracted_median13/3extracted_order_validation13/3extracted_payout_math13/3extracted_taker_fee13/3extracted_tier_leverage13/3extracted_trial_size13/3selection_machine13/3lomuto_partition14/4验证命令仓库内可直接执行查看python3 corpus-v3.2/build_references.py --verify .venv/bin/python -m harness.validate_mutants --config config/default.json \ --reference corpus-v3.2/references/build/MODULE --baseline corpus-v3.2/package \ --target TARGET --mutants corpus-v3.2/mutants/TASK/mutants.json --timeout 20注意一个联动效应向包中添加模块会改变每个参考包的树哈希--verify会标记其他模块其任务需要重新验证。复现语料包与查看方式Move 源码没有提交。aptos-core是公开的而 Etna 不是所以所有从 Etna 派生的东西——package/sources/与references/build/——都 gitignored只跟踪配方、规范、摘要与锚点。提交的筛选记录保留判定、耗时、参考哈希与无路径的工具身份它们省略原始编译器与求解器诊断信息因为其源码帧可能引用生成的 Etna 文件并使用语料相对的参考标签以免暴露本地 checkout 路径。python3 corpus-v3.2/build.py # clone 到 corpus-v3.2/.etna python3 corpus-v3.2/build.py --etna PATH # 从已有 checkout 读取 pin python3 corpus-v3.2/build.py --verify # 重新生成并比对不写任何东西要阅读而非运行语料用 compose.py 按任务组合到未跟踪目录每个任务拿到Agent 收到的模块、写入参考规范后的同一模块、以及每个变异体的 unified diffpython3 corpus-v3.2/compose.py # 输出到 corpus-v3.2/inspect/ python3 corpus-v3.2/compose.py --task MM-min-013 --output DIR提取是最小化的函数体逐字节拷贝只允许两处变换且都记录在模块头部——载体结构体缩减为目标实际读取的字段全局配置读取变成参数。任何基于该语料的发布产物都需要自己的披露决策契约形状可以在不复现专有源码的情况下被描述但语料包本身在没有披露的情况下不可再分发。全量运行前的剩余工作与边界文档明确语料、参考与两套变异集合已完整且可复现反证机制所需的两个装置改动均已就位留置评分集mutants-scoring/——因为反证会把展示给 Agent 的集合变成训练材料用--mutants-root corpus-v3.2/mutants-scoring调度未带它的轮次是scoring_mode: core更大的墙钟预算——反证使第三个控制器回合成为常态max_wall_seconds: 2700时pilot-qp-ref3单元有三分之一在修复中途被切断会被记为失败从而误读为反证伤害了该臂config/default.json 现允许3600秒与探针的 40 秒/验证条件预算operational_timeout_seconds/eventual_timeout_seconds共同构成文档所述参考规范 0.7–1.2s 即可证明、正确契约绰绰有余的评分环境。剩下的不是语料工作量而是关于轮次元规模大小的决定。文档还划出两条边界PN-pnl-005是永久排除而非推迟——其阻塞项是求解器缺陷而非目标属性除非该缺陷被修复否则不回归harness/review_stage.py是 V1 工具V3 不需要——V3 的参考是已提交的规范补丁变异体直接编写。小结Corpus V3.2 的设计逻辑可以概括为一条链私有源码保证规范不可回忆 → 任务选择针对猜测即过的漏洞hard/guessable 分层 配对探针→wp_hard与空契约陷阱的显式定义保证WP 失败是可归因的任务属性 → 反证/评分双变异集合把契约强度变成可量化指标 → 摘要锚定的构建链build.py/manifest.json/--verify保证整个基准在任何有权限的机器上逐字节可重建。对研究者而言manifest.json、selection.json 与 DESIGN.md 是三个最值得继续深入的入口前者给出每个目标文件的 SHA-256 与任务特征层中间件记录每一次取舍的理由后者交代三个实验臂agent_only/hybrid_guided/hybrid_flexible与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 aptos-core Flow 规格推断评测语料 Corpus V3.2：Move 规范推断基准的构成与度量原理
aptos-core Flow 规格推断评测语料 Corpus V3.2Move 规范推断基准的构成与度量原理【免费下载链接】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-core 仓库中aptos-move/flow/evaluation/spec-inference下的评测语料文档 corpus-v3.2/README.md完整解读 V3.2 这套用于衡量AI Agent 能否写出正确的 Move 形式化规范的基准语料任务 ID 体系与 27 个目标函数清单、wp_hard的判定语义、基于 Etna 私有源码的可复现构建链、变异体mutant双集合评分机制、手写参考规范的模块布局以及轮次选择round selection算法。读完可以掌握如何按文档与源码理解该语料的每个目录与脚本的职责如何复现/校验语料包以及契约强度是如何通过 refutation 与 scoring 两套互不重叠的变异集合来量化测量的。语料定位从 V2 到 V3 的动机corpus-v3.2/README.md 开篇即声明V3.2 是正式的基准This is the benchmark完整的评测轮次full run计划在这一版语料上进行上一版 V1.1 仅作为基础设施保留不再是运行目标。整体架构详见 DESIGN.md。V3 替换 V2 的原因在文档中写得很明确V2 在两个维度上饱和了目标太小小到可以在脑中装下——Agent 没有任何理由去调用工具如最弱前置条件推断 WP猜测即可通过只评分规范能否验证通过——而一个更含糊vaguer的契约反而更容易通过验证无法区分契约强弱。因此 V3 从两个方向选择任务目标本身要抗拒猜测并引入变异体mutants使契约强度可测量。DESIGN.md 进一步交代了 V1 被替换的原因Aptos 框架是公开的其.spec.move文件也是公开的——V1 抽查的 24 个目标中有 16 个在函数本身上游就已存在公开规范Agent 的成功可能是回忆而非推断。V3 采用私有源码Etna正是为了拿到没有人写过规范的函数。任务 ID 体系与 25 个就绪目标语料共27 个目标23 个来自 EtnaDecibel 私有 Move 代码的代号2 个来自公开的aptos-experimental入选条件是上游不携带规范2 个为本研究自行编写。Etna 源码不会被提交进仓库后文复现一节详述。任务 ID 采用FAMILY-tag-NNN三段式两个字母的模块家族码、区分同模块内目标的短标签、以及全语料连续编号。例如LP-price-021是extracted_liquidation_price模块中get_liquidation_price函数编号 21。编号 001–027 无断档按模块组装时顺序分配因此相邻编号同属一个家族VS-fees-001到VS-redeem-004就是vault_share_math的四个目标。编号不携带难度、排名或顺序含义ID 是稳定的出现在所有调度、产物与元数据文件中任务被搁置或排除时不会重新编号。25 个目标处于ready状态且指定规范后能在20 秒兼容性时限内完成验证——这一条保证了变异评分的可负担性每个变异体都要对目标重验一次。其中 21 个标记hard4 个刻意保留为guessable作为对照用于把装置性故障和真正困难的任务区分开。文档给出的完整目标清单如下原表完整继承任务目标考察点难度VS-fees-001vault_share_math::calculate_unrealized_fees五个带 guard 的 return一个交叉相乘的u128比值测试hardVS-shares-002vault_share_math::convert_existing_shares_to_asset_amount组合伙伴函数刻意简单guessableVS-contrib-003vault_share_math::convert_new_assets_to_share_count元组结果、零份额快速路径、资不抵债断言hardVS-redeem-004vault_share_math::calculate_redemption_funds_and_fee组合——下界溢出自由仅来自被调函数契约hardOV-order-006extracted_order_validation::validate_order_input为何从不 abort短路越过%守卫guessableUC-credits-008extracted_tier_lookup::credits_for_duration_days最后匹配胜出扫描首个匹配的读法是另一个函数hardUC-leverage-009extracted_tier_lookup::leverage_for_tier_rank同一扫描、精确 rank 谓词hardTR-order-010extracted_bulk_order_utils::validate_price_ordering相邻对扫描带提前返回双向严格hardTR-discard-011extracted_bulk_order_utils::discard_price_crossing_levels最小不穿越索引——前缀事实不是 foldhardBA-base-012extracted_base_math::compute_base_needed需要发明引理——见下文hardMM-min-013extracted_minmax::find_min_value先读values[0]空输入时 aborthardMM-max-014extracted_minmax::find_max_value同一循环从 0 起空输入时返回——配对探针hardMD-median-015extracted_median::get_median_price全函数total无循环、无算术、无 abortguessableBK-bucket-016extracted_bucket_index::get_bucket_index提前return结果是最小的容许索引hardTF-taker-017extracted_taker_fee::calculate_min_net_taker_fee100 - pct在 100 以上下溢——源码从未提及的 aborthardDV-dev-018extracted_deviation::calculate_deviation_bps在预期 abort 处返回哨兵值hardTS-trial-019extracted_trial_size::trial_size_for唯一的显式范围检查背后藏着三个未声明的 aborthardTL-lev-020extracted_tier_leverage::checked_max_tier_leverage量词 abort 与累积最大值二者互不蕴含hardLP-price-021extracted_liquidation_price::get_liquidation_price零杠杆意味着零除数在算术上不可见hardSM-select-022selection_machine::select函数值function values——见下文hardWU-consume-023extracted_work_units::consume_order_match_work_unitsmut饱和转移u32两次溢出hardWU-limit-024extracted_work_units::get_max_order_placement_limit钳制除法下限为 1guessableQP-part-025lomuto_partition::partition原地置换in-place permutation——见下文hardPM-curve-027extracted_payout_math::compute三段下取整插值畸形输入只在中间分支 aborthard五个携带独特能力的目标文档指出五个目标携带其余目标不具备的能力是理解这套语料难度来自哪里的关键VS-redeem-004组合推理它调用两个同模块兄弟函数其shares - shares_for_fee不溢出下界的性质只在被调函数的契约中成立在调用方函数体内不可见。契约若只从调用方视角写无法关闭这个义务。BA-base-012辅助推理仅靠循环不变量写不出完整契约——给累积值命名需要一个递归的 spec 函数排除累加器u128溢出需要一个前缀和有界性的单调性引理且该引理要用递归apply证明。累积刻意是线性的推理才是难度而不是求解器耗时。SM-select-022函数值语料中唯一非 Etna 提取的目标Etna 没有函数值代码因此也是唯一不含专有源码的目标。一个有界选择循环通过应用一个续延continuation来抽取候选接受第一个容许者失败若干次后交还位置以便重启。续延与测试都是参数契约需要在它们之上写result_of和aborts_of第k次抽取后的状态需要对函数值写递归 spec 函数。QP-part-025原地置换对u64向量做 Lomuto partition是唯一原地重排输入的目标同样因为 Etna 没有排序代码而自行编写。pivot 落在哪、两侧是什么是普通的循环不变量工作pivot 穿过两次交换难点在于声明结果是重排而非改写直接的forall/exists包含式、裸递归计数、甚至求和代理都会耗尽求解器。参考实现采用[weight 20]下的计数 spec 函数、按段segments证明的 swap 引理以及入口点forall … apply——其触发器trigger正是求解器编码vector::swap时产生的双重update。这个形状下所有证明与所有反例refutation约一秒完成。PM-curve-027分段插值同样的畸形输入在曲线之下与之上都正常返回却在中间分支 abort所以完整的 abort 条件必须包含分支守卫精确结果还要保留加宽后的乘法与下取整除法。wp_hard的含义与空契约陷阱wp_hard记录的是仅靠 WP最弱前置条件推断到不了一个可验证的契约它是任务的属性而非缺陷一个 WP 已经能解决的目标会保留该家族的简单成员。理解这一项需要一段背景当循环没有不变量时havoc 会让推断条件的一部分保持无约束WP 丢弃这些子句产出一个携带aborts_if_is_partial的空契约——它能编译、能验证。在研究场景之外伴随诊断信息是 warning这本身是对的人仍可利用 WP 推导出的东西但只问求解器是否成功的评判下这是错的因为空契约与完整契约不可区分——结果所有循环目标都被记录为wp_hard: false把语料中最难的目标标成了WP 搞定的。ProverOptions::uninvariant_loop_is_error把该诊断升级为 error。从源码与文档的对应关系看move-flow experiment infer始终设置它筛选是绝不能漏掉这一点的消费者评测会话则通过EvaluationConfig::uninvariant_loop_is_error设置使得任何实验臂arm都不能把空契约误当作完成的契约普通 Flow 使用不受影响。三个目标上的 WP 产物无辅助的 WP 推断在VS-shares-002、LP-price-021、TS-trial-019三个目标上产生一个不可证明的sathard子句为一条会 abort 的路径生成了正常返回的ensures并在其旁边复制了一个aborts_if。文档说明它不是求解器难度尽管叫sathard也与循环无关——三个目标都没有循环它不是坏任务——三者都能对着参考规范证明通过因此准入由良构 可验证的参考决定WP 困难度只作为任务属性记录两个 hybrid 臂都会收到它且禁止通过删除sathard子句来让证明通过所以阅读这三个目标的会话记录时需带着这一背景。VS-redeem-004也携带sathard子句但不是此产物其子句携带对兄弟调用的result_of属于上文所述的组合难度。溯源Provenance私有源码的可复现构建这是 V3.2 工程上最精细的部分。Etna 从固定 commit导出而 vendored 标准库与 trading 目标则从 aptos-core 的活动工作树读取于是 build.py拒绝在有已跟踪修改的树上重新生成否则语料会挂在一个并不包含这些修改的 commit 名下记录的哈希描述的将是任何人无法重建的源码。--allow-dirty可以覆盖该检查但会在清单中记录reconstructible: false使声明永远不会在沉默中变假。提交进仓库的清单记录其生成源码是否来自干净的 aptos-core 树发布构建必须报告tracked_modifications: false且reconstructible: true--allow-dirty仅限开发使用。这一点在 manifest.json 中可以直接验证其provenance.aptos_core字段当前记录reconstructible: true、tracked_modifications: falseprovenance.etna固定到私有仓库的 commit1a71823845dc092c825996d433adaf9843ea78aa而generated_file_sha256为每一个生成文件deps/*.move、etna/*.move、trading/*.move登记了 SHA-256。从 build.py 的实现可以看到更强的保证etna_tree()不是读取工作目录而是通过git archive commit move导出固定 commit 的树对象见 build.py#L26-L31 中对仓库与 commit 的锚定因此一个脏的 checkout 无法改变语料构建的内容——导出 commit 取代了读取工作目录直接消除了失败模式。轮次选择select_round.py的盲化处理完整一轮的成本是每任务 × 每臂 × 每副本各一个会话所以一轮可以只运行就绪目标的一个子集。选择器 select_round.py只从语料自身对每个任务及其目标源码的描述中选取——绝不参考任何臂的行为——并把结果作为round_selection字段写进每个清单记录和 metadata/selection.json。没有任何删除被搁置的样本仍在语料中等待后续轮次。脚本头部注释给出的规则顺序为(1) 保留每个独有携带某特征层stratum的任务(2) 冗余簇strata 相同或目标源码近重复内保留一个代表——最大的目标作为最丰富契约的代理(3) 其余名额按稀有度加权的新颖性填充(4)guessable任务设上限。源码中近重复的相似度阈值为SOURCE_SIMILARITY 0.50select_round.py#L44。当前选择是25 个就绪目标中的 20 个selection.json 显示其完整构成全部 38 个 strata 无一丢失strata_lost: []跨 15 个模块、10 个含循环任务guessable恰为 3 个上限。审计发现的两个近重复目标对是MM-max-014/MM-min-013源码相似度 0.895与UC-credits-008/UC-leverage-0090.555DV-dev-018、LP-price-021、TF-taker-017、WU-limit-024携带相同 strata保留最大者、其余搁置held_back中逐条记录了搁置原因。两个任务被明确排除在调度之外调度器丢弃任何screening_status非ready的目标显式指名它们是错误而非覆盖任务目标原因PN-pnl-005extracted_pnl_math::calculate_pnl规范与代码之间的有符号除法分歧在 blockers/ 中做了归约QT-quote-007extracted_quote_math::compute_quote_needed与BA-base-012相同的引理需求但其逐层p * s / m使证明非线性且在尝试过的任何预算下最长 240s都无法消解blockers/README.md 记录了PN-pnl-005的细节WP 推断出貌似完整的契约含MIN_I64取负溢出与两个MAX_I128转换上界但其自身的ensures随后失败归约到signed-div-narrowing.move后每个操作孤立验证都通过组合后收窄 abort 条件被拒绝——求解器找到了规范商超出i64范围而可执行代码不 abort的状态呈现为规范级/与代码在边界附近截断与 floor 语义的分歧。QT-quote-007保留而非删除因为它是选择引理目标时优先线性累积这一原则的证据。变异体两个互不重叠的集合变异体只修补实现绝不修补规范。装置把它应用到包的副本上再用Agent 写出的成品规范重跑求解器求解器失败 → 变异体被杀死killed契约足够精确以至于察觉了错误求解器成功 → 存活survived契约对着错误代码也验证通过。反证集refutation每个就绪目标 3 个变异体QP-part-0254 个共76 个留置评分集scoring20 个被选任务各 3 个共60 个。abort代码不在考察范围内只改变 abort 携带哪个代码的变异体测的是错误码钉扎而非契约强度。文档还交代了一个质量控制细节首批草稿有两个因此被丢弃——它们把守卫从x 0削弱为x 00 到达除法后函数仍 abort只有 abort代码变了完整契约无法观测到这个差异validate_mutants将其记录为survived后它们被可观测的编辑替换。为什么必须是两个集合反证机制会把存活变异体作为失败反馈给 Agent变异集就此变成训练材料在同一集合上给臂评分等于就告诉过它的东西考它。因此两个集合永不重叠集合路径角色refutationmutants/以类别形式展示给 Agent——额外的生命scoringmutants-scoring/留置严格成功分strict-successharness.controller拒绝两个根解析相等的运行author_mutants.py --disjoint-from拒绝与反证变异体重复文件、偏移与编辑的评分变异体。操作上有明确的时序约定调度时传入 scoring 根harness.pilot --mutants-root使其摘要进入记录的装置身份启动时传入反证根harness.pilot_run --refutation-mutants-root。不带--mutants-root的轮次运行scoring_mode: core此时strict_success构造性为 false对契约本身说明不了什么。评分集用 author_mutants.py 编写该脚本计算偏移量与摘要并拒绝在文件中不恰好出现一次的锚点。变异体存储的是偏移量、长度与对生成文件的 SHA-256外加一次最小编辑而不是它重写的代码本身变异体与参考规范都在轮次之前、且看不到任何臂的输出时编写。公开与自编写源码的可读描述放在 mutant-specs/引用私有 Etna 源码的描述属于 gitignored 的mutant-specs/private/目录——提交的运行时清单只保留锚定摘要与最小编辑。参考规范按模块提交的只增补丁一个变异体只有在手写参考规范能杀死它之后才算essential。参考按模块组织——25 个就绪目标分布在 17 个模块上——且只有规范被提交形式是 references/ 下只添加行、从不删除行的补丁。各模块杀死情况模块任务数杀死变异体vault_share_math412/12extracted_bulk_order_utils39/9extracted_minmax26/6extracted_tier_lookup26/6extracted_work_units26/6extracted_base_math13/3extracted_bucket_index13/3extracted_deviation13/3extracted_liquidation_price13/3extracted_median13/3extracted_order_validation13/3extracted_payout_math13/3extracted_taker_fee13/3extracted_tier_leverage13/3extracted_trial_size13/3selection_machine13/3lomuto_partition14/4验证命令仓库内可直接执行查看python3 corpus-v3.2/build_references.py --verify .venv/bin/python -m harness.validate_mutants --config config/default.json \ --reference corpus-v3.2/references/build/MODULE --baseline corpus-v3.2/package \ --target TARGET --mutants corpus-v3.2/mutants/TASK/mutants.json --timeout 20注意一个联动效应向包中添加模块会改变每个参考包的树哈希--verify会标记其他模块其任务需要重新验证。复现语料包与查看方式Move 源码没有提交。aptos-core是公开的而 Etna 不是所以所有从 Etna 派生的东西——package/sources/与references/build/——都 gitignored只跟踪配方、规范、摘要与锚点。提交的筛选记录保留判定、耗时、参考哈希与无路径的工具身份它们省略原始编译器与求解器诊断信息因为其源码帧可能引用生成的 Etna 文件并使用语料相对的参考标签以免暴露本地 checkout 路径。python3 corpus-v3.2/build.py # clone 到 corpus-v3.2/.etna python3 corpus-v3.2/build.py --etna PATH # 从已有 checkout 读取 pin python3 corpus-v3.2/build.py --verify # 重新生成并比对不写任何东西要阅读而非运行语料用 compose.py 按任务组合到未跟踪目录每个任务拿到Agent 收到的模块、写入参考规范后的同一模块、以及每个变异体的 unified diffpython3 corpus-v3.2/compose.py # 输出到 corpus-v3.2/inspect/ python3 corpus-v3.2/compose.py --task MM-min-013 --output DIR提取是最小化的函数体逐字节拷贝只允许两处变换且都记录在模块头部——载体结构体缩减为目标实际读取的字段全局配置读取变成参数。任何基于该语料的发布产物都需要自己的披露决策契约形状可以在不复现专有源码的情况下被描述但语料包本身在没有披露的情况下不可再分发。全量运行前的剩余工作与边界文档明确语料、参考与两套变异集合已完整且可复现反证机制所需的两个装置改动均已就位留置评分集mutants-scoring/——因为反证会把展示给 Agent 的集合变成训练材料用--mutants-root corpus-v3.2/mutants-scoring调度未带它的轮次是scoring_mode: core更大的墙钟预算——反证使第三个控制器回合成为常态max_wall_seconds: 2700时pilot-qp-ref3单元有三分之一在修复中途被切断会被记为失败从而误读为反证伤害了该臂config/default.json 现允许3600秒与探针的 40 秒/验证条件预算operational_timeout_seconds/eventual_timeout_seconds共同构成文档所述参考规范 0.7–1.2s 即可证明、正确契约绰绰有余的评分环境。剩下的不是语料工作量而是关于轮次元规模大小的决定。文档还划出两条边界PN-pnl-005是永久排除而非推迟——其阻塞项是求解器缺陷而非目标属性除非该缺陷被修复否则不回归harness/review_stage.py是 V1 工具V3 不需要——V3 的参考是已提交的规范补丁变异体直接编写。小结Corpus V3.2 的设计逻辑可以概括为一条链私有源码保证规范不可回忆 → 任务选择针对猜测即过的漏洞hard/guessable 分层 配对探针→wp_hard与空契约陷阱的显式定义保证WP 失败是可归因的任务属性 → 反证/评分双变异集合把契约强度变成可量化指标 → 摘要锚定的构建链build.py/manifest.json/--verify保证整个基准在任何有权限的机器上逐字节可重建。对研究者而言manifest.json、selection.json 与 DESIGN.md 是三个最值得继续深入的入口前者给出每个目标文件的 SHA-256 与任务特征层中间件记录每一次取舍的理由后者交代三个实验臂agent_only/hybrid_guided/hybrid_flexible与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考