尧图网站建设 
Diem 创世初始化深入解析Genesis 模块的 Move 入口与链上状态引导流程【免费下载链接】diemDiem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.项目地址: https://gitcode.com/gh_mirrors/di/diem本文围绕 Diem 框架中的GenesisMove 模块language/diem-framework/modules/Genesis.move系统讲解 Diem 区块链从空状态启动时如何完成框架初始化、账户引导、验证者集合建立与首次重配置。通过本文读者将掌握Genesis::initialize与create_initialize_owners_operators的完整调用链、各参数含义与构造方式理解 Rust 侧 genesis 工具vm-genesis与 Move 侧模块之间的协作关系并了解 Move Prover 对创世代码的形式化验证思路。Genesis模块是 Diem 框架在全新状态fresh state下执行的 Move 初始化入口。它的存在把创世这一庞大而敏感的引导流程固化为一组可验证、可复现的 Move 函数链一旦发布出第一个NewEpochEvent并启动时间戳系统便从创世态切换为运行态此后所有链上不变量invariants开始生效。Genesis 模块的整体定位从源码结构看Genesis模块自身不定义任何资源resource它扮演的是编排者角色把分散在DiemAccount、DiemConfig、DiemSystem、DiemTimestamp、DiemVMConfig等十余个模块中的初始化函数按严格顺序串起来执行。模块头部的 use 声明Genesis.move列出了它依赖的全部框架模块账户与角色DiemAccount、Roles经账户模块间接使用、ValidatorConfig、ValidatorOperatorConfig链上配置DiemConfig、DiemConsensusConfig、DiemVMConfig、DiemTransactionPublishingOption、DiemVersion系统资源DiemSystem验证者集合、DiemBlock、DiemTimestamp、ChainId货币与合规Diem、XUS、XDX、DualAttestation、AccountFreezing、TransactionFee标准库Signer、Vector模块仅暴露三个函数initialize、initialize_internal与create_initialize_owners_operators均以fun私有形式定义——它们只允许被同地址下的模块调用无法作为交易脚本从链外直接触发从而保证了创世流程只能由节点软件内部的 genesis 代码驱动。框架初始化initialize与initialize_internal函数签名与参数语义initialize是框架初始化的对外入口Genesis.move其 10 个参数完整定义了创世时刻链的基本属性参数类型含义dr_accountsignerDiemRoot管理账户签名者tc_accountsignerTreasuryCompliance财务合规账户签名者dr_auth_keyvectoru8DiemRoot 账户最终轮换到的认证密钥32 字节tc_auth_keyvectoru8TreasuryCompliance 账户最终轮换到的认证密钥initial_script_allow_listvectorvectoru8初始允许执行的脚本哈希白名单is_open_modulebool是否开放模块发布true 时任何人可发布模块instruction_schedulevectoru8VM 指令 gas 表BCS 序列化native_schedulevectoru8VM 原生函数 gas 表BCS 序列化chain_idu8链 ID标识主网/测试网/开发网initial_diem_versionu64链上记录的初始 Diem 版本号initialize本身只是薄封装把所有参数原样转交给initialize_internalGenesis.move。后者的注释明确说明了设计意图Internal so it can be used by both genesis code, and for testing purposes——即内部版本既供真实创世调用也供单元测试复用。测试辅助函数setup标注#[test_only]见 Genesis.move正是以4u8TESTING 链 ID、空白名单、空 gas 表等简化参数调用initialize_internal供 language/diem-framework/tests/DiemTimestampTests.move 等测试文件初始化测试环境。初始化顺序为什么是这个顺序initialize_internal内部的调用顺序严格依赖模块间的前置关系Genesis.moveDiemAccount::initialize—— 先建立账户体系骨架如授予 DiemRoot/TreasuryCompliance 角色、发布Account资源后续所有账户创建依赖它。ChainId::initialize—— 记录链 ID链身份的第一份链上数据。DiemConfig::initialize—— 在 DiemRoot 地址发布Configuration资源epoch 0、last_reconfiguration_time 0并创建NewEpochEvent事件句柄见 DiemConfig.move。所有后续配置项的发布都依赖DiemConfig基础设施。DiemConsensusConfig::initialize—— 初始化共识参数占位配置。Diem::initialize与XUS::initialize、XDX::initialize—— 注册货币XUS 为美元稳定币XDX 为篮子币其中XUS/XDX需要tc_account参与涉及 TreasuryCompliance 对货币的管理权。AccountFreezing::initialize、TransactionFee::initialize—— 账户冻结机制与交易费账户后者挂在 TreasuryCompliance 名下。DiemSystem::initialize_validator_set—— 以空验证者集合初始化DiemConfigDiemSystem并把ModifyConfigCapabilityDiemSystem存入CapabilityHolderDiemSystem.move。DiemVersion::initialize、DualAttestation::initialize、DiemBlock::initialize_block_metadata—— 版本号、合规双重证明开关与区块元数据能力。认证密钥轮换通过extract_key_rotation_capability→rotate_authentication_key→restore_key_rotation_capability三步把 DiemRoot 与 TreasuryCompliance 的认证密钥轮换为调用方传入的dr_auth_key/tc_auth_keyGenesis.move。这一步是创世安全的关键创世交易本身由临时密钥签名轮换后临时密钥即失去效力。DiemTransactionPublishingOption::initialize—— 应用脚本白名单与开放模块开关。DiemVMConfig::initialize—— 写入 instruction/native gas 调度表。最后一步DiemTimestamp::set_time_has_started—— 在 DiemRoot 地址发布CurrentTimeMicroseconds资源并置 0DiemTimestamp.move。第 12 步是全流程的分水岭在此之前DiemTimestamp::is_genesis()为 true链处于创世态各类initialize才能被允许执行在此之后is_operating()变为 trueGenesis.move 源码注释明确指出所有由DiemTimestamp::is_operating() ...守卫的不变量将变为激活的验证条件。这也解释了为什么set_time_has_started必须排在最后——它一执行系统就完成初始化了之后任何初始化操作都会因assert_genesis()失败而中止。验证者集合引导create_initialize_owners_operatorscreate_initialize_owners_operators负责在框架初始化完成后建立初始验证者集合Genesis.move。它接收 10 个等长的并行向量owners/owner_names/owner_auth_keys验证者 owner 账户的 signer、UTF-8 名称与认证密钥consensus_pubkeys各验证者用于签名共识消息的 Ed25519 公钥operators/operator_names/operator_auth_keysoperator 账户可以是 owner 自己及其名称与认证密钥validator_network_addresses/full_node_network_addresses验证者自身网络与全节点网络的NetworkAddress其编码规范见 types/src/network_address函数开头用 8 条assert严格校验 10 个向量长度一致Genesis.move任何不匹配都会以错误码 0 中止防止索引越界。随后进入while循环逐个处理每个验证者创建 owner 账户DiemAccount::create_validator_account用 16 字节全零前缀的dummy_auth_key_prefix创建账户再立刻用真实认证密钥轮换create each validator account and rotate its auth key to the correct value。先创建后轮换是刻意为之——创世时账户尚未拥有最终密钥需要先在受控状态下落地再固化密钥。创建 operator 账户若不存在通过DiemAccount::exists_at判断。operator 与 owner 是同一地址时跳过创建否则同样创建后用真实认证密钥轮换。随后assert(ValidatorOperatorConfig::get_human_name(operator_address) operator_name, 0)校验 operator 名称一致性。绑定关系ValidatorConfig::set_operator(owner, operator_address)把 owner 的操作权委托给 operator——链上运营模型中的所有权与操作权分离在创世一刻即被固化。写入验证者配置ValidatorConfig::set_config(operator, owner_address, consensus_pubkey, validator_network_address, full_node_network_address)由 operator 账户为对应 owner 写入共识公钥与网络地址。加入验证者集合DiemSystem::add_validator(dr_account, owner_address)DiemSystem.move将验证者追加进DiemConfigDiemSystem.validatorsconsensus_voting_power恒为 1并触发重配置。值得注意add_validator内部调用set_diem_system_config→DiemConfig::set_with_capability_and_reconfigure但由于此刻DiemTimestamp::is_genesis()仍为 truereconfigure_会提前返回见 DiemConfig.move 中的短路条件因此这些中间步骤不会产生NewEpochEvent真正的首个 epoch 事件由后续 genesis 流程统一发出。Rust 侧驱动vm-genesis 如何构造创世交易Move 模块本身不执行——真正把上述函数跑起来的是 Rust 侧的创世工具vm-genesislanguage/tools/vm-genesis/src/lib.rs。其核心入口encode_genesis_change_set描述了两阶段执行模型lib.rs阶段一状态初始化在GenesisStateViewgenesis_context.rs提供的空数据视图上创建 MoveVM 会话依次执行create_and_initialize_main_accounts→ 调用Genesis::initializelib.rs。注意参数构造dr_auth_key/tc_auth_key来自AuthenticationKey::ed25519(public_key)脚本白名单来自VMPublishingOptioninstruction/native gas 表来自INITIAL_GAS_SCHEDULE的 BCS 序列化initial_diem_version取DIEM_MAX_KNOWN_VERSION.major。随后手动调用DiemAccount::epilogue把 DiemRoot 账户的序列号sequence number从 0 提升到 1lib.rs避免后续从该账户发出的首个交易与创世交易序列号冲突。create_and_initialize_owners_operators→ 将Validator结构体数组逐字段拆成 10 个MoveValue::Vector调用Genesis::create_initialize_owners_operatorslib.rs。reconfigure→ 调用DiemConfig::emit_genesis_reconfiguration_eventDiemConfig.move把 epoch 从 0 提升到 1 并发出全链第一个NewEpochEvent。若链 ID 属于 TESTNET / DEVNET / TESTING额外执行create_and_initialize_testnet_minting创建测试网铸币账户并铸造 XUSlib.rs。阶段二发布标准库在新的空会话上调用publish_stdlib按模块依赖图拓扑序把整个标准库模块发布到核心代码地址CORE_CODE_ADDRESS并断言所有模块发布在同一个地址下lib.rs。两个阶段的 WriteSet 通过squash合并为单个创世ChangeSet。最后verify_genesis_write_set对生成结果做一致性断言lib.rs前两个事件必须是 DiemRoot 与 TreasuryCompliance 的账户创建事件且必须恰好存在一个序列号为 0 的NewEpochEvent。Validator结构体lib.rs完整刻画了每个创世验证者所需的全部字段地址、UTF-8 名称、认证密钥、Ed25519 共识公钥、operator 地址/名称/认证密钥、验证者网络地址与全节点网络地址。测试用TestValidator::new_test_set默认生成 10 个确定性验证者种子[1u8; 32]供generate_test_genesis生成人工创世 WriteSet 用于测试lib.rs。创世期间的密钥与账户模型创世流程隐含一套完整的密钥分层模型。Rust 侧通过固定种子GENESIS_SEED [42; 32]生成创世密钥对GENESIS_KEYPAIRlib.rs测试场景中 DiemRoot 与 TreasuryCompliance 共用该密钥而diem_root、treasury_compliance、owner、operator、consensus等密钥名称在 config/global-constants/src/lib.rs 中统一定义供安全存储Safety Rules、Key Manager等组件引用保证各组件对同一把密钥的命名一致。创世过程中密钥的流转顺序可以归纳为临时签名密钥创建账户→ 全零占位认证密钥dummy auth key创建时→ 目标认证密钥轮换后。轮换能力KeyRotationCapability被提取、使用、恢复的三步操作保证了认证密钥只能在受控的创世上下文内变更且之后该能力归还给账户。形式化验证Move Prover 视角下的创世initialize附带的 spec 块Genesis.move揭示了创世验证的特殊性spec initialize { /// Assume that this is called in genesis state (no timestamp). requires DiemTimestamp::is_genesis(); }注释解释了方法论创世验证的目标是证明函数结束后所有激活的不变量成立这无法像常规模块那样做模块化modular验证而必须把 Genesis 模块与提供不变量的模块放在一起联合验证。原因在于initialize_internal末尾的set_time_has_started会一次性激活DiemTimestamp::is_operating() ...形式的海量全局不变量如 DiemConfig.move 的运行态必有 Configuration、DiemSystem.move 的运行态必有 DiemConfig 与 CapabilityHolder等。源码也如实记录了当前工程局限联合验证存在超时timeout潜在解法是把initialize调用的各模块初始化函数标记为 opaque不透明并局部证明各模块的不变量。相应地DiemTimestamp::set_time_has_started的 spec 使用pragma delegate_invariants_to_caller把不变量证明责任委托给调用方 Genesis与上述策略完全呼应DiemTimestamp.move。常见问题与易混淆点为什么initialize和initialize_internal两个函数都要存在前者是带值签名者的薄封装后者接收引用签名者以便在测试中复用。两者参数完全一致任何修改必须同步。创世 vs 运行态如何判定核心判据是 DiemRoot 地址下是否存在CurrentTimeMicroseconds资源is_genesis()为不存在见 DiemTimestamp.move。链上大量操作增删验证者、改配置、更新区块时间都以assert_operating()为前提。为什么标准库发布放在独立的第二阶段会话发布模块前需要先基于第一阶段落地的账户与配置状态完成引导同时模块字节码的拓扑排序发布要求所有模块位于同一地址独立会话便于单独管理这组 WriteSet 变更并与第一阶段 squash 合并。脚本白名单与开放模块initial_script_allow_list与is_open_module共同构成创世时的发布策略。encode_genesis_transaction默认使用VMPublishingOption::locked(LegacyStdlibScript::allowlist())lib.rs即仅允许标准库脚本的锁定模式。延伸阅读模块实现language/diem-framework/modules/Genesis.move链上配置基础设施language/diem-framework/modules/DiemConfig.move验证者集合language/diem-framework/modules/DiemSystem.move时间戳与创世态判定language/diem-framework/modules/DiemTimestamp.moveRust 侧创世执行器language/tools/vm-genesis/src/lib.rs创世数据视图language/tools/vm-genesis/src/genesis_context.rs全局密钥命名config/global-constants/src/lib.rs测试参考language/diem-framework/tests/DiemTimestampTests.move【免费下载链接】diemDiem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.项目地址: https://gitcode.com/gh_mirrors/di/diem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Diem 创世初始化深入解析：Genesis 模块的 Move 入口与链上状态引导流程
Diem 创世初始化深入解析Genesis 模块的 Move 入口与链上状态引导流程【免费下载链接】diemDiem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.项目地址: https://gitcode.com/gh_mirrors/di/diem本文围绕 Diem 框架中的GenesisMove 模块language/diem-framework/modules/Genesis.move系统讲解 Diem 区块链从空状态启动时如何完成框架初始化、账户引导、验证者集合建立与首次重配置。通过本文读者将掌握Genesis::initialize与create_initialize_owners_operators的完整调用链、各参数含义与构造方式理解 Rust 侧 genesis 工具vm-genesis与 Move 侧模块之间的协作关系并了解 Move Prover 对创世代码的形式化验证思路。Genesis模块是 Diem 框架在全新状态fresh state下执行的 Move 初始化入口。它的存在把创世这一庞大而敏感的引导流程固化为一组可验证、可复现的 Move 函数链一旦发布出第一个NewEpochEvent并启动时间戳系统便从创世态切换为运行态此后所有链上不变量invariants开始生效。Genesis 模块的整体定位从源码结构看Genesis模块自身不定义任何资源resource它扮演的是编排者角色把分散在DiemAccount、DiemConfig、DiemSystem、DiemTimestamp、DiemVMConfig等十余个模块中的初始化函数按严格顺序串起来执行。模块头部的 use 声明Genesis.move列出了它依赖的全部框架模块账户与角色DiemAccount、Roles经账户模块间接使用、ValidatorConfig、ValidatorOperatorConfig链上配置DiemConfig、DiemConsensusConfig、DiemVMConfig、DiemTransactionPublishingOption、DiemVersion系统资源DiemSystem验证者集合、DiemBlock、DiemTimestamp、ChainId货币与合规Diem、XUS、XDX、DualAttestation、AccountFreezing、TransactionFee标准库Signer、Vector模块仅暴露三个函数initialize、initialize_internal与create_initialize_owners_operators均以fun私有形式定义——它们只允许被同地址下的模块调用无法作为交易脚本从链外直接触发从而保证了创世流程只能由节点软件内部的 genesis 代码驱动。框架初始化initialize与initialize_internal函数签名与参数语义initialize是框架初始化的对外入口Genesis.move其 10 个参数完整定义了创世时刻链的基本属性参数类型含义dr_accountsignerDiemRoot管理账户签名者tc_accountsignerTreasuryCompliance财务合规账户签名者dr_auth_keyvectoru8DiemRoot 账户最终轮换到的认证密钥32 字节tc_auth_keyvectoru8TreasuryCompliance 账户最终轮换到的认证密钥initial_script_allow_listvectorvectoru8初始允许执行的脚本哈希白名单is_open_modulebool是否开放模块发布true 时任何人可发布模块instruction_schedulevectoru8VM 指令 gas 表BCS 序列化native_schedulevectoru8VM 原生函数 gas 表BCS 序列化chain_idu8链 ID标识主网/测试网/开发网initial_diem_versionu64链上记录的初始 Diem 版本号initialize本身只是薄封装把所有参数原样转交给initialize_internalGenesis.move。后者的注释明确说明了设计意图Internal so it can be used by both genesis code, and for testing purposes——即内部版本既供真实创世调用也供单元测试复用。测试辅助函数setup标注#[test_only]见 Genesis.move正是以4u8TESTING 链 ID、空白名单、空 gas 表等简化参数调用initialize_internal供 language/diem-framework/tests/DiemTimestampTests.move 等测试文件初始化测试环境。初始化顺序为什么是这个顺序initialize_internal内部的调用顺序严格依赖模块间的前置关系Genesis.moveDiemAccount::initialize—— 先建立账户体系骨架如授予 DiemRoot/TreasuryCompliance 角色、发布Account资源后续所有账户创建依赖它。ChainId::initialize—— 记录链 ID链身份的第一份链上数据。DiemConfig::initialize—— 在 DiemRoot 地址发布Configuration资源epoch 0、last_reconfiguration_time 0并创建NewEpochEvent事件句柄见 DiemConfig.move。所有后续配置项的发布都依赖DiemConfig基础设施。DiemConsensusConfig::initialize—— 初始化共识参数占位配置。Diem::initialize与XUS::initialize、XDX::initialize—— 注册货币XUS 为美元稳定币XDX 为篮子币其中XUS/XDX需要tc_account参与涉及 TreasuryCompliance 对货币的管理权。AccountFreezing::initialize、TransactionFee::initialize—— 账户冻结机制与交易费账户后者挂在 TreasuryCompliance 名下。DiemSystem::initialize_validator_set—— 以空验证者集合初始化DiemConfigDiemSystem并把ModifyConfigCapabilityDiemSystem存入CapabilityHolderDiemSystem.move。DiemVersion::initialize、DualAttestation::initialize、DiemBlock::initialize_block_metadata—— 版本号、合规双重证明开关与区块元数据能力。认证密钥轮换通过extract_key_rotation_capability→rotate_authentication_key→restore_key_rotation_capability三步把 DiemRoot 与 TreasuryCompliance 的认证密钥轮换为调用方传入的dr_auth_key/tc_auth_keyGenesis.move。这一步是创世安全的关键创世交易本身由临时密钥签名轮换后临时密钥即失去效力。DiemTransactionPublishingOption::initialize—— 应用脚本白名单与开放模块开关。DiemVMConfig::initialize—— 写入 instruction/native gas 调度表。最后一步DiemTimestamp::set_time_has_started—— 在 DiemRoot 地址发布CurrentTimeMicroseconds资源并置 0DiemTimestamp.move。第 12 步是全流程的分水岭在此之前DiemTimestamp::is_genesis()为 true链处于创世态各类initialize才能被允许执行在此之后is_operating()变为 trueGenesis.move 源码注释明确指出所有由DiemTimestamp::is_operating() ...守卫的不变量将变为激活的验证条件。这也解释了为什么set_time_has_started必须排在最后——它一执行系统就完成初始化了之后任何初始化操作都会因assert_genesis()失败而中止。验证者集合引导create_initialize_owners_operatorscreate_initialize_owners_operators负责在框架初始化完成后建立初始验证者集合Genesis.move。它接收 10 个等长的并行向量owners/owner_names/owner_auth_keys验证者 owner 账户的 signer、UTF-8 名称与认证密钥consensus_pubkeys各验证者用于签名共识消息的 Ed25519 公钥operators/operator_names/operator_auth_keysoperator 账户可以是 owner 自己及其名称与认证密钥validator_network_addresses/full_node_network_addresses验证者自身网络与全节点网络的NetworkAddress其编码规范见 types/src/network_address函数开头用 8 条assert严格校验 10 个向量长度一致Genesis.move任何不匹配都会以错误码 0 中止防止索引越界。随后进入while循环逐个处理每个验证者创建 owner 账户DiemAccount::create_validator_account用 16 字节全零前缀的dummy_auth_key_prefix创建账户再立刻用真实认证密钥轮换create each validator account and rotate its auth key to the correct value。先创建后轮换是刻意为之——创世时账户尚未拥有最终密钥需要先在受控状态下落地再固化密钥。创建 operator 账户若不存在通过DiemAccount::exists_at判断。operator 与 owner 是同一地址时跳过创建否则同样创建后用真实认证密钥轮换。随后assert(ValidatorOperatorConfig::get_human_name(operator_address) operator_name, 0)校验 operator 名称一致性。绑定关系ValidatorConfig::set_operator(owner, operator_address)把 owner 的操作权委托给 operator——链上运营模型中的所有权与操作权分离在创世一刻即被固化。写入验证者配置ValidatorConfig::set_config(operator, owner_address, consensus_pubkey, validator_network_address, full_node_network_address)由 operator 账户为对应 owner 写入共识公钥与网络地址。加入验证者集合DiemSystem::add_validator(dr_account, owner_address)DiemSystem.move将验证者追加进DiemConfigDiemSystem.validatorsconsensus_voting_power恒为 1并触发重配置。值得注意add_validator内部调用set_diem_system_config→DiemConfig::set_with_capability_and_reconfigure但由于此刻DiemTimestamp::is_genesis()仍为 truereconfigure_会提前返回见 DiemConfig.move 中的短路条件因此这些中间步骤不会产生NewEpochEvent真正的首个 epoch 事件由后续 genesis 流程统一发出。Rust 侧驱动vm-genesis 如何构造创世交易Move 模块本身不执行——真正把上述函数跑起来的是 Rust 侧的创世工具vm-genesislanguage/tools/vm-genesis/src/lib.rs。其核心入口encode_genesis_change_set描述了两阶段执行模型lib.rs阶段一状态初始化在GenesisStateViewgenesis_context.rs提供的空数据视图上创建 MoveVM 会话依次执行create_and_initialize_main_accounts→ 调用Genesis::initializelib.rs。注意参数构造dr_auth_key/tc_auth_key来自AuthenticationKey::ed25519(public_key)脚本白名单来自VMPublishingOptioninstruction/native gas 表来自INITIAL_GAS_SCHEDULE的 BCS 序列化initial_diem_version取DIEM_MAX_KNOWN_VERSION.major。随后手动调用DiemAccount::epilogue把 DiemRoot 账户的序列号sequence number从 0 提升到 1lib.rs避免后续从该账户发出的首个交易与创世交易序列号冲突。create_and_initialize_owners_operators→ 将Validator结构体数组逐字段拆成 10 个MoveValue::Vector调用Genesis::create_initialize_owners_operatorslib.rs。reconfigure→ 调用DiemConfig::emit_genesis_reconfiguration_eventDiemConfig.move把 epoch 从 0 提升到 1 并发出全链第一个NewEpochEvent。若链 ID 属于 TESTNET / DEVNET / TESTING额外执行create_and_initialize_testnet_minting创建测试网铸币账户并铸造 XUSlib.rs。阶段二发布标准库在新的空会话上调用publish_stdlib按模块依赖图拓扑序把整个标准库模块发布到核心代码地址CORE_CODE_ADDRESS并断言所有模块发布在同一个地址下lib.rs。两个阶段的 WriteSet 通过squash合并为单个创世ChangeSet。最后verify_genesis_write_set对生成结果做一致性断言lib.rs前两个事件必须是 DiemRoot 与 TreasuryCompliance 的账户创建事件且必须恰好存在一个序列号为 0 的NewEpochEvent。Validator结构体lib.rs完整刻画了每个创世验证者所需的全部字段地址、UTF-8 名称、认证密钥、Ed25519 共识公钥、operator 地址/名称/认证密钥、验证者网络地址与全节点网络地址。测试用TestValidator::new_test_set默认生成 10 个确定性验证者种子[1u8; 32]供generate_test_genesis生成人工创世 WriteSet 用于测试lib.rs。创世期间的密钥与账户模型创世流程隐含一套完整的密钥分层模型。Rust 侧通过固定种子GENESIS_SEED [42; 32]生成创世密钥对GENESIS_KEYPAIRlib.rs测试场景中 DiemRoot 与 TreasuryCompliance 共用该密钥而diem_root、treasury_compliance、owner、operator、consensus等密钥名称在 config/global-constants/src/lib.rs 中统一定义供安全存储Safety Rules、Key Manager等组件引用保证各组件对同一把密钥的命名一致。创世过程中密钥的流转顺序可以归纳为临时签名密钥创建账户→ 全零占位认证密钥dummy auth key创建时→ 目标认证密钥轮换后。轮换能力KeyRotationCapability被提取、使用、恢复的三步操作保证了认证密钥只能在受控的创世上下文内变更且之后该能力归还给账户。形式化验证Move Prover 视角下的创世initialize附带的 spec 块Genesis.move揭示了创世验证的特殊性spec initialize { /// Assume that this is called in genesis state (no timestamp). requires DiemTimestamp::is_genesis(); }注释解释了方法论创世验证的目标是证明函数结束后所有激活的不变量成立这无法像常规模块那样做模块化modular验证而必须把 Genesis 模块与提供不变量的模块放在一起联合验证。原因在于initialize_internal末尾的set_time_has_started会一次性激活DiemTimestamp::is_operating() ...形式的海量全局不变量如 DiemConfig.move 的运行态必有 Configuration、DiemSystem.move 的运行态必有 DiemConfig 与 CapabilityHolder等。源码也如实记录了当前工程局限联合验证存在超时timeout潜在解法是把initialize调用的各模块初始化函数标记为 opaque不透明并局部证明各模块的不变量。相应地DiemTimestamp::set_time_has_started的 spec 使用pragma delegate_invariants_to_caller把不变量证明责任委托给调用方 Genesis与上述策略完全呼应DiemTimestamp.move。常见问题与易混淆点为什么initialize和initialize_internal两个函数都要存在前者是带值签名者的薄封装后者接收引用签名者以便在测试中复用。两者参数完全一致任何修改必须同步。创世 vs 运行态如何判定核心判据是 DiemRoot 地址下是否存在CurrentTimeMicroseconds资源is_genesis()为不存在见 DiemTimestamp.move。链上大量操作增删验证者、改配置、更新区块时间都以assert_operating()为前提。为什么标准库发布放在独立的第二阶段会话发布模块前需要先基于第一阶段落地的账户与配置状态完成引导同时模块字节码的拓扑排序发布要求所有模块位于同一地址独立会话便于单独管理这组 WriteSet 变更并与第一阶段 squash 合并。脚本白名单与开放模块initial_script_allow_list与is_open_module共同构成创世时的发布策略。encode_genesis_transaction默认使用VMPublishingOption::locked(LegacyStdlibScript::allowlist())lib.rs即仅允许标准库脚本的锁定模式。延伸阅读模块实现language/diem-framework/modules/Genesis.move链上配置基础设施language/diem-framework/modules/DiemConfig.move验证者集合language/diem-framework/modules/DiemSystem.move时间戳与创世态判定language/diem-framework/modules/DiemTimestamp.moveRust 侧创世执行器language/tools/vm-genesis/src/lib.rs创世数据视图language/tools/vm-genesis/src/genesis_context.rs全局密钥命名config/global-constants/src/lib.rs测试参考language/diem-framework/tests/DiemTimestampTests.move【免费下载链接】diemDiem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.项目地址: https://gitcode.com/gh_mirrors/di/diem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考