Diem Management 工具集全解：基于 diem-management crate 的 Genesis 仪式与链上运维-北京尧图网络

Diem Management 工具集全解基于 diem-management crate 的 Genesis 仪式与链上运维【免费下载链接】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/diemDiem 区块链的启动与日常运维离不开一套面向角色分工的 CLI 工具集。diem-managementcrate 为 Diem 提供了构建命令行工具的统一框架并在此基础上派生出diem-genesis-tool执行创世仪式与diem-operational-tool创世后链上运维两个独立工具。本文将围绕 config/management/README.md 展开完整讲解其设计动机、角色模型、配置文件规范、Genesis 端到端流程与运维命令体系并结合仓库源码与测试用例帮助你掌握从安全存储初始化、密钥上传、创世构建到验证启动的全套实操方法。一、为什么需要拆分为多个管理工具diem-managementcrate 的定位是「为各种目的构建 CLI 工具的框架」。官方在 config/management/README.md 中给出的拆分解释是将不同用途拆成多个独立工具是为了简化用户体验、避免不同使用场景之间的混淆。从代码层面看这一框架体现在 config/management/src/lib.rs 中它集中暴露了config、error、secure_backend、storage、transaction、validator_config、waypoint等公共模块并定义了execute_command!宏把「命令分发执行错误处理」统一封装。两个工具的命令入口config/management/genesis/src/main.rs 与 config/management/operational/src/main.rs结构完全一致解析 structopt 参数、调用Command::from_args().execute()、成功打印输出、失败打印错误并以状态码 1 退出。工具树结构如下diem-management |- diem-genesis-tool 用于执行 Diem 区块链创世仪式的工具 |- diem-operational-tool 用于对 Diem 区块链执行管理运维操作的工具每个工具都有独立的 README 文档创世工具文档与运维工具文档下文将分别深入。二、系统角色模型Genesis 组织方式的前提两个工具的功能设计都由节点在系统中的组织方式决定。创世工具文档明确了以下角色划分Diem root 账户diem root维护 validator owner 集合、validator operator 集合以及活跃 validator set。Treasury compliance 账户treasury compliance维护 VASP、DDDual Destinations及其相关事务。创世时发布的初始 Move 模块集合。Validator ownerOW在链上拥有账户账户内含 validator 配置并指定一个 validator operator。Validator operatorOP在链上拥有账户有权操作 validator 配置。对应到创世工具的布局Layout定义config/management/genesis/src/layout.rs 用四个字段精确映射了这些角色pub struct Layout { pub operators: VecString, // 所有 OP 的名称列表 pub owners: VecString, // 所有 OW 的名称列表 pub diem_root: String, // diem root 身份名 pub treasury_compliance: String, // treasury compliance 身份名 }运维工具的文档则补充了一条重要的当前实现约定owner-address 目前被有意设置为全 0因为它目前尚未被使用见 config/management/operational/README.md。三、统一配置文件为 Genesis 与运维共用的 YAML虽然两个工具都支持在每条命令上直接指定 backend 参数但这样既繁琐又容易出错。因此官方建议所有参与者先构造一份配置文件在 Genesis 阶段使用后续也能被运维工具复用。示例配置如下出自 config/management/genesis/README.md# config.yaml chain_id: MAINNET json_server: http://127.0.0.1:8080 shared_backend: type: github repository_owner: REPOSITORY_OWNER repository: REPOSITORY namespace: REPOSITOR_FOLDER token: from_config: test validator_backend: type: vault server: 127.0.0.1:8200 namespace: VIRTUAL_NAMESPACE token: from_config: test字段说明原文档定义源码印证字段含义与使用要点chain_id指定一个独立的链。它会被写入 genesis、在网络连接时被校验并且是每笔交易的一部分。由协会association提供。对应 config/management/src/config.rs 中的ChainId类型反序列化时使用chain_id::deserialize_config_chain_idjson_server指定一个 Diem JSON Server。可以是任何连接到你网络的节点包括你自己的或协会运行的。Genesis 阶段不使用它因此初始配置时可填一个虚拟值shared_backend指向协会共享存储shared storage的指针例如 GitHub 仓库validator_backend指向本地 validator 节点安全存储的指针例如 Vault需要说明的是配置结构体还包含shared_backend与validator_backend之外的若干可覆盖入口config/management/src/config.rs 提供了override_chain_id、override_json_server、override_shared_backend、override_validator_backend方法允许命令行参数覆盖配置文件中的值shared_backend_with_namespace则为共享存储动态设置命名空间对应不同参与者的目录隔离。3.1 安全后端Secure Backend的四种格式除了 YAML 配置两个工具还支持在命令行上以分号分隔的键值对直接指定 backend。定义在 config/management/src/secure_backend.rs解析逻辑要求必须包含backend键。支持的四种格式如下宏生成的 help 文本与源码一致Vault: backendvault;serverURL;tokenPATH_TO_TOKEN 可选 namespaceNAMESPACE、ca_certificatePATH_TO_CERT GitHub: backendgithub;repository_ownerREPOSITORY_OWNER;repositoryREPOSITORY;tokenPATH_TO_TOKEN 可选 branchBRANCH默认 master、namespaceNAMESPACE InMemory: backendmemory OnDisk: backenddisk;pathLOCAL_PATH从实现细节看config/management/src/secure_backend.rs 中 Vault 后端会强制启用disable_cas并为管理工具设置 10 秒的连接/响应超时GitHub 后端的 token 从磁盘路径文件读取Token::FromDisk。该文件的单元测试也覆盖了上述四种格式的解析包括缺少必需键时报错、多余参数报错等场景可作为格式校验的依据。四、Genesis 端到端流程总览创世过程从「协会初始化」到「链启动」分为四个阶段完整继承自 config/management/genesis/README.md初始化仪式Initialization ceremony协会为数据上传搭建安全后端shared storage例如 GitHub并为每个 OW 和 OP 分发凭据。协会生成diem root key将公钥上传到共享存储。协会将初始 Move 模块集合上传到共享存储。每个 OW 生成私有owner key将公钥上传到共享存储。每个 OP 生成私有operator key将公钥上传到共享存储。Validator 初始化Validator initialization每个 OW 选定一个 OP用其owner key签名提交事务并上传到共享存储。对 OP 支持的每个 validatorOP 生成 network、execution、consensus 密钥以及 full node 和 validator 端点的网络地址。OP 用其operator key签名生成包含这些数据的事务并上传到共享存储。Genesis 构建Genesis每个 OP 下载累积数据以生成genesis.blob。协会下载累积数据以生成genesis.blob和 genesis waypoint。启动Starting协会发布与 genesis 相关的数据、genesis.blob和 genesis waypoint。每个 OP 下载协会提供的 genesis waypoint并插入其 Diem 实例。每个 OP 验证genesis.blob、waypoint 与本地配置是否正确并将结果广播给其他 OP 和协会。当足够数量quorum的 validator 状态正确后协会指示 OP 启动 validator。当足够数量的 validator 上线后区块链开始处理交易。需要特别强调原文中的三条 Notes这决定了本工具当前的能力边界该流程描述的是「尚未最终确定、但由当前 Diem Testnet 状态延伸而来」的组织实例化过程该实现尚未在 Move 中完整落地因此本工具映射的是当前状态新加入现有区块链的 OP/OW 遵循相同流程账户初始创建与配置设置委托给协会完成。此外Requirements 明确指出每个 OW 或 OP 实例都应能访问安全存储方案使用 Diem Secure Storage 的参与者可直接使用本工具否则需要自备工具。五、参与方操作手册一步步命令详解端到端流程假设每个参与者都有自己的安全存储方案如 Vaulttoken 存放在磁盘上可供管理工具读取的文件中。协会负责提供shared storage的入口例如 GitHub 仓库与仓库 owner并为每个参与者划分独立命名空间GitHub 命名空间即仓库内的目录。每个参与者需要为自己的 GitHub 账户获取一个具有repo作用域的 token 并保存在本地文件。最后每个参与者应在安全存储中初始化各自密钥diem_root、treasury_compliance、owner或operator初始化方式不在本文档范围内。5.1 协会Association的命令发布 layout 到共享存储layout 文件内包含参与者的名称与角色cargo run -p diem-genesis-tool -- \ set-layout \ --config config_file.yaml \ --path $PATH_TO_LAYOUTlayout 是一个 toml 格式的配置文件格式如下[operator] [alice, bob] [owner] [carol, dave] diem_root erin treasury_compliance fred每个字段映射到本文档所述的一种角色。注意原文档示例中 key 为[operator]/[owner]而源码 config/management/genesis/src/layout.rs 中字段名为operators/ownerstoml 反序列化对单复数形式的处理以实际运行版本为准命令对应的测试用例 config/management/genesis/src/command.rs 展示了operators/owners字段名的 layout 写法并验证 layout 会被写入common命名空间的layout键。发布初始 Move 模块集合到共享存储目录内只能包含.mv扩展名的 Move 字节码文件cargo run -p diem-genesis-tool -- \ set-move-modules \ --config config_file.yaml \ --dir $MOVE_MODULES_DIR发布diem root公钥到共享存储cargo run -p diem-genesis-tool -- \ diem-root-key \ --config config_file.yaml发布treasury compliance公钥到共享存储cargo run -p diem-genesis-tool -- \ diem-treasury-compliance-key \ --config config_file.yaml在 OW 与 OP 都完成各自环节后构建 genesis waypointcargo run -p diem-genesis-tool -- \ create-waypoint \ --config config_file.yaml从源码看create-waypoint会先复用genesis命令从共享存储重建 genesis 事务再调用 config/management/genesis/src/waypoint.rs 中的create_genesis_waypoint它会打开一个临时 DiemDB通过db_bootstrapper::generate_waypoint::DiemVM计算 waypoint。5.2 Validator OwnerOW的命令将 OW 的密钥上传到 GitHub 共享存储cargo run -p diem-genesis-tool -- \ owner-key \ --config config_file.yaml选定负责运营 validator 节点的 OP通过指定该 OP 在共享 GitHub 中注册的名称cargo run -p diem-genesis-tool -- \ set-operator \ --config config_file.yaml \ --operator-name $OPERATOR_NAMEset-operator命令会将选定的 OP 名称写入共享存储中对应 OW 命名空间的validator_operator键config/management/src/lib.rs 常量command.rs 中的 test_set_operator 验证了该行为。5.3 Validator OperatorOP的命令将 OP 的密钥上传到 GitHub 共享存储cargo run -p diem-genesis-tool -- \ operator-key \ --config config_file.yaml为每个受管 validator 上传带签名的 validator-config 事务。owner-name对应 OW 在共享 GitHub 中注册的名称GitHub 中的命名空间与 OP 的命名空间对应cargo run -p diem-genesis-tool -- \ validator-config \ --config config_file.yaml \ --owner-name $OWNER_NAME \ --validator-address /dns/$VALIDATOR_DNS/tcp/$VALIDATOR_PORT \ --fullnode-address /dns/$VFN_DNS/tcp/$VFN_PORT从源码看validator-config会构造并签名一条ValidatorConfig事务config/management/genesis/src/validator_config.rs。command.rs 中的 test_validator_config 验证了上传到共享存储的 validator-config 事务的发送者是 operator 账户地址、事务 payload 是含 4 个参数的ScriptFunction、第一个参数反序列化后正是 owner 的账户地址。密钥上传类命令如owner-key、operator-key在 config/management/genesis/src/key.rs 中实现默认从 validator 存储读取私钥并推导公钥上传也支持通过--path-to-key直接指定 bcs 或 hex 格式的 ed25519 公钥文件读取逻辑见 config/management/src/lib.rs 的read_key_from_file优先尝试 bcs 解码失败则按 hex 解码。收到协会信号后构建 genesiscargo run -p diem-genesis-tool -- \ genesis \ --config config_file.yaml \ --path $PATH_TO_GENESIS将协会发布的 genesis waypoint 插入本地存储cargo run -p diem-genesist-tool -- \ insert-waypoint \ --config config_file.yaml \ --waypoint $WAYPOINT执行 verify确认本地存储与 Genesis 对应、Genesis 与 waypoint 对应cargo run -p diem-genesis-tool -- \ verify \ --config config_file.yaml \ --genesis_path $PATH_TO_GENESISverify命令的输出会逐一报告各密钥项的状态测试用例 test_verify 中通过统计输出中 Key not set 的出现次数来断言校验项数量。5.4 创世工具命令全集源码枚举创世工具支持的全部子命令在 config/management/genesis/src/command.rs 中定义共 12 个create-waypoint、genesis、insert-waypoint、diem-root-key、operator-key、owner-key、set-layout、set-move-modules、set-operator、treasury-compliance-key、validator-config、verify。每个子命令的执行结果要么打印输出如create-waypoint打印Waypoint: wp、verify打印配置状态要么打印Success!。5.5 端到端测试一次完整 Genesis 的脚本化演练仓库内置的端到端测试 config/management/genesis/src/command.rs 完整复现了上述流程依赖docker/vault/run.sh提供的 Vault 实例其步骤即是最好的实战参考定义并上传 layout指定operator_alice/bob/carol_shared为 operatorsalice/bob/carol_shared为 ownersdave_shared同时担任diem_root与treasury_compliance写入common命名空间。从diem_framework_releases::current_module_blobs()导出当前版本的所有 Move 模块字节码文件调用set-move-modules。初始化dave的存储并上传diem-root-key与treasury-compliance-key。初始化每个 OW 的存储并上传owner-key。初始化每个 OP 的存储并上传operator-key。每个 OW 调用set-operator指定其 OP。每个 OP 调用validator-config为对应 OW 上传带签名的配置测试中使用/ip4/0.0.0.0/tcp/6180作为 validator 与 fullnode 地址6180 即 Diem 网络默认端口。调用genesis生成 genesis 文件并断言其非空。每个 OP 依次执行create-waypoint、insert-waypoint、verifyverify_genesis完成验证闭环。注意测试注释中特别提醒Vault 相关的测试若运行过快可能因 Vault 内数据同步问题偶发失败解决办法是两次运行之间重启 Vault 服务。六、diem-operational-tool创世后的链上运维diem-operational-tool面向 OP用于在创世后对 Diem 区块链执行维护类功能。其功能由系统角色组织方式决定OW 在链上拥有账户含 validator 配置并指定 OPOP 在链上拥有账户且有权更新 validator 配置见 config/management/operational/README.md。运维工具支持的全部子命令定义在 config/management/operational/src/command.rs按功能可归为以下几类类别子命令用途链上查询account-resource、validator-config、validator-set展示链上账户资源、validator 配置与 validator set 信息治理create-validator、create-validator-operator、add-validator、remove-validator创建 validator / validator operator 账户增减 validator set 成员密钥轮换rotate-consensus-key、rotate-validator-network-key、rotate-fullnode-network-key、rotate-operator-key轮换共识密钥、网络密钥与 operator 密钥配置管理set-validator-config、set-validator-operator设置 validator 配置与 operator密钥/身份extract-private-key、extract-public-key、extract-peer-from-file、extract-peer-from-storage、extract-peers-from-keys、generate-key从存储提取或生成密钥从 x25519 公钥提取 trusted peer 身份打印print-account、print-key、print-x-key、print-waypoint从 validator 存储打印账户、ed25519 公钥、x25519 公钥用于 noise 握手与 waypoint网络检查check-endpoint、check-validator-set-endpoints探测端点/链上全部端点的监听状态事务insert-waypoint、validate-transaction插入 waypoint、验证事务两个工具共用insert-waypoint实现diem_management::waypoint::InsertWaypoint与创世工具保持一致。七、命名空间与仓库映射的重要说明原文档对共享存储的命名空间语义做了明确约定使用工具前务必理解Vault 中的命名空间对于 secrets 表现为子目录对于 transit 表现为前缀加__例如namespace__。GitHub 中的命名空间表现为仓库内的子目录。GitHub 仓库与仓库 owner 的 URL 映射https://github.org/REPOSITORY_OWNER/REPOSITORY由shared_backend配置中的repository_owner与repository字段决定。owner-address 约定目前被有意设置为全 0因为当前阶段尚未使用见 config/management/operational/README.md。另外config/management/src/lib.rs 中的常量还定义了事务相关默认值可作参考GAS_UNIT_PRICE 0、MAX_GAS_AMOUNT 1_000_000、GAS_CURRENCY_CODE XUS_NAME、TXN_EXPIRATION_SECS 3600。八、如何开始使用阅读两份工具文档Genesis 工具文档与 Operational 工具文档。按本文第三节构造config.yaml确保本地 Vault或其他安全存储已初始化相应密钥GitHub token 具备repo作用域并保存在磁盘文件中。依据角色协会 / OW / OP按第五节顺序执行对应cargo run -p diem-genesis-tool -- ...命令本地联调时可参考docker/vault/run.sh启动 Vault 并运行内置端到端测试。创世完成后OP 使用cargo run -p diem-operational-tool -- ...执行密钥轮换、配置更新、validator set 治理与网络检查等日常运维。需要注意以上命令均以cargo run形式在仓库根目录执行实际生产环境中通常编译为独立二进制后分发。各命令支持在每条命令上用--shared-backend/--validator-backend覆盖配置文件中的对应后端但官方推荐优先使用配置文件以降低出错概率。【免费下载链接】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 Management 工具集全解：基于 diem-management crate 的 Genesis 仪式与链上运维

相关推荐

mustbe踩坑实录：3个高频面试题背后的版本升级陷阱

GM 工具实战指南：Fleet 仓库的 GitHub 批量管理与交互式工作流

SumatraPDF 受限模式（Restricted Use）配置指南：用 sumatrapdfrestrict.ini 构建 Kiosk / 内嵌查看器

更多资讯

深圳杯数学建模避坑指南：源码解析助你搞定建模

5步搞定行行重行行翻译完整示例性能优化

如何快速本地构建BoostNote-Legacy：开发环境搭建与VSCode调试完整教程

10分钟搞定黑苹果EFI：OpCore Simplify一键生成工具完整指南

别被标题党忽悠，一文搞懂爱奇艺转换器mp4背后的代码逻辑

gatsby-source-wordpress 预览（Preview）配置完全指南：在 WordPress 中接入 Gatsby 实时内容预览

今日更新

OneUptime 自定义探针（Custom Probe）部署实战：私网监控、代理配置与断连排障全指南

大众TL52625前端框架材料要求详解：从性能测试到落地执行

TiXL 浮点运算算子库 Lib.numbers.float 完全指南：44 个算子的参数详解、源码原理与实战串联

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？