企业官网建设流程全解析

Gas Schedule Changes

【免费下载链接】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

Gas feature version: 30 -> 31

• I have reviewed the gas schedule changes below.

Changes

这份文件虽然在测试目录下，但它同时是发布流程中对人类读者的**核心审查界面**：发布负责人（Release Captain）无需阅读原始 Move 治理脚本，仅凭这份摘要即可快速判断本次 Gas 参数动了什么，并在顶部复选框与关键参数行完成签核。 --- ## 二、摘要文件的四段式结构 从金标准文件可以归纳出摘要文件固定的四段式结构，其生成逻辑在 [summary.rs](https://link.gitcode.com/i/11dd1b323d4b3c106dc57903842222ea) 中逐行对应： ### 1. 标题与 Gas feature version ```markdown # Gas Schedule Changes Gas feature version: 30 -> 31

• 只有存在旧快照（old参数为Some）时才会输出Gas Schedule Changes标题并显示版本迁移区间；
• 若没有旧快照，则输出# Gas Schedule+ 单版本号，并追加一行斜体说明_No previous gas schedule was provided, so a parameter diff cannot be shown._。

2. 总览签核复选框

- [ ] I have reviewed the gas schedule changes below.

这是总览级签核：确保审查者先扫描全部变更再打勾。与之对应，feature-flags.md（Feature Flag 变更摘要）在有变更时也会输出同样的- [ ] I have reviewed the feature flag changes below.复选框；若无变更则直接写_No feature flag changes in this release._且不输出复选框（没有可审查内容就不制造签核负担）。

3. 变更明细表格

## Changes | change | parameter | old | new | sign-off | | -------- | --------------------- | --------: | ---------: | -------- | | modified | instr.add | 50 | 65 | | | added | instr.mul | / | 90 | | | removed | instr.sub | 80 | / | | | modified | txn.max_execution_gas | 920000000 | 1000000000 | [ ] |

当GasScheduleV2::diff返回的变更集为空时，此处输出_No parameter changes._；否则渲染完整表格。

4. 关键参数逐项签核列（sign-off）

表格最后一列sign-off是逐参数签核位：只有关键 Gas 参数会获得自己的[ ]复选框，其余行留空。这份金标准恰好覆盖了三种变更类型与两种签核形态的排列组合，因此成为理想的测试样本。

三、变更类型的判定：底层 diff 算法

摘要表中change列的modified/added/removed三态，直接来自GasScheduleV2::diff的实现，位于 types/src/on_chain_config/gas_schedule.rs：

pub fn diff<'a>(old: &'a Self, new: &'a Self) -> BTreeMap<&'a str, DiffItem<u64>> { let mut old = old.to_btree_map_borrowed(); let new = new.to_btree_map_borrowed(); // 遍历 new：键同时存在于 old 且值不同 -> Modify；仅存在于 new -> Add // 遍历剩余 old：仅存在于 old -> Delete // ... }

其判定规则为：

注意diff基于BTreeMap实现，返回的键天然按参数名字典序排列，因此表格行序是确定且稳定的——这也是金标准比对能够逐字节成立的前提。

测试数据佐证

金标准对应的两份输入快照就放在同一测试目录下：

• gas_old.json：feature_version: 30，含txn.large_transaction_cutoff=600、txn.max_execution_gas=920000000、instr.add=50、instr.sub=80；
• gas_new.json：feature_version: 31，含txn.large_transaction_cutoff=600、txn.max_execution_gas=1000000000、instr.add=65、instr.mul=90。

对照可得：

• instr.add：50 → 65，即modified；
• instr.mul：新出现，即added（old 记为/）；
• instr.sub：被移除，即removed（new 记为/）；
• txn.max_execution_gas：920000000 → 1000000000，modified，且因其属于关键参数而带[ ]；
• txn.large_transaction_cutoff：600 → 600，值未变，不进入变更集。

这正是一份理想的"一网打尽"测试夹具：单次比对同时覆盖三种变更类型和关键/非关键两类参数。

四、关键参数清单：哪些行必须逐项签核

哪些参数会获得独立的sign-off复选框，由 summary.rs 中的常量表决定：

const CRITICAL_GAS_PARAMS: &[&str] = &[ "txn.max_execution_gas", "txn.max_io_gas", "txn.max_storage_fee", "txn.max_transaction_size_in_bytes", "txn.maximum_number_of_gas_units", "txn.gas_unit_scaling_factor", ];

这六项参数直接决定单笔交易的 Gas 上限、IO 上限、存储费用上限与交易大小上限，一旦放宽或收紧会立刻影响全网手续费水平与交易吞吐边界，因此必须逐项显式确认。渲染逻辑在 emit_gas_change_table 中：命中清单的参数在 sign-off 列输出[ ]，其余参数留空——"总览签核 + 关键参数逐项签核"形成两级审查防线。

五、表格的源码级对齐：为什么原文如此整齐

细看金标准表格，old与new两列是右对齐、数字按宽度补空的。这并非偶然，而是 table.rs 刻意实现的源码级对齐：渲染器先计算每列最大字符宽度（含表头，最少 3 格以保持分隔线合法），再按列对齐方向（change/parameter/sign-off 左对齐，old/new 右对齐）在生成 Markdown 原文时就补足空格。

let aligns = [ Align::Left, // change Align::Left, // parameter Align::Right, // old Align::Right, // new Align::Left, // sign-off ];

因此expected_gas_summary.md不只是"渲染后好看"，其原始.md文本本身就是对齐的——这既提升了 diff 审查的可读性，也让金标准比对具备强稳定性（任何列宽或对齐变化都会使测试失败，从而被显式捕获）。

六、这份摘要从哪里来：生成链路与 CLI 命令

expected_gas_summary.md所代表的产物，在真实发布流程中位于 bundle 的summary/gas-schedule-changes.md（文件名由常量GAS_SUMMARY: &str = "gas-schedule-changes.md"定义），由generate-bundle命令在生成发布包时一并产出：

cargo run -p aptos-release-tool -- generate-bundle \ --release-config aptos-move/aptos-release-tool/data/framework-release.yaml \ --bundle "$BUNDLE_DIR"

其生成链路在 commands/generate.rs 中依次为：

1. generate_scripts：生成多步治理脚本（scripts/N-*.move，头部以// Script hash:注释打入字节码哈希供治理投票审计）与metadata.json；
2. materialize_gas：从发布配置的Gas条目拉取新旧快照写入gas/old.json、gas/new.json（materialize_gas 还会先比较old == new，无变化则跳过 Gas 产物）；
3. write_gas_summary：基于两份快照调用GasScheduleV2::diff并渲染成summary/gas-schedule-changes.md；
4. 复制config.yaml、计算全部文件校验和与全局摘要、写入bundle.toml；
5. 最后自动执行一遍完整性校验，全部通过才宣告生成成功。

端到端测试 tests/e2e.rs 验证了上述产物清单（含summary/gas-schedule-changes.md）确实全部落地。注意该测试运行在 256MB 栈的专用线程上，因为 Move 框架编译器递归过深、默认测试线程栈会溢出——这也是项目对框架编译深度的真实写照。

七、金标准测试：如何验证与更新

单元测试 gas_summary_matches_golden 是这份金标准文件的"守护者"：

• 它从测试目录加载gas_old.json与gas_new.json，调用write_gas_summary生成实际输出，再与expected_gas_summary.md逐字节比对；
• 测试刻意设计为纯函数（不编译框架），因此即使框架变更导致端到端测试失败，该测试依然保持绿色，成为快速更新金标准的首选入口。

更新金标准只需设置基线更新环境变量后运行：

UB=1 cargo test -p aptos-release-tool --lib

测试失败时的报错信息也会明确提示set UB=1 to update，将"金标准过期"转化为一键刷新操作。

八、签核的强制执行：verify-bundle --require-signoff

摘要文件的复选框不是摆设，verify-bundle命令通过--require-signoff将其变成发布前置门禁：

cargo run -p aptos-release-tool -- verify-bundle \ --bundle "$BUNDLE_DIR" \ --require-signoff

【免费下载链接】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