区块链开发框架后端【免费下载链接】substrateSubstrate: The platform for blockchain innovators项目地址https://gitcode.com/gh_mirrors/su/substrate点击查看免费下载subkey是 Substrate 官方提供的一站式密钥管理命令行工具面向 Substrate 生态链如 Polkadot、Kusama 以及各类平行链和 Substrate 项目的开发者与用户。本文以仓库中 scripts/ci/docker/subkey.Dockerfile.README.md 对 subkey 的能力定义为主线结合 bin/utils/subkey/README.md、bin/utils/subkey/SECURITY.md 与 scripts/ci/docker/subkey.Dockerfile 等仓库资料系统讲解如何生成与检查密钥对、从助记词和原始种子恢复密钥、对消息进行签名与验证、派生分层确定性子密钥以及如何通过 Docker 容器安全地使用该工具。读完本文你将能够独立完成 Substrate 链账户密钥的全生命周期管理并掌握容器化部署与安全实践要点。认识 subkeySubstrate 生态的密钥管理工具Substrate 官方文档对subkey的定位是Thesubkeyprogram is a key management utility for Substrate-based blockchains——即面向 Substrate 系区块链的密钥管理工具。根据仓库中 scripts/ci/docker/subkey.Dockerfile.README.md 的定义你可以使用 subkey 完成以下任务生成并检查密码学安全的公钥/私钥对从助记词secret phrase和原始种子raw seed恢复密钥对消息进行签名与验签对编码后的交易进行签名与验签派生分层确定性Hierarchical Deterministic, HD子密钥对。从源码结构看subkey 的完整实现位于仓库的 bin/utils/subkey/ 目录。其中 Cargo.toml 声明了subkey3.0.0 这个独立的二进制 crate入口为 src/main.rs其核心逻辑极简——main()直接调用subkey::run()全部功能通过 src/lib.rs 实现命令行解析依赖clap 4.2.5启用derive特性错误类型则复用sc-cliclient/cli的定义。也就是说subkey 实际上是 Substrate 客户端 CLI 工具链在密钥管理场景下的专门化封装。完全离线的密钥工具subkey 在运行时不需要联网。这一点既是设计特性也是安全要求密钥操作不涉及任何网络请求因此你可以也应该在完全断网的机器上生成和管理密钥。正如 bin/utils/subkey/README.md 强调的for the best security, you should be usingsubkeyon a machine that isnot connectedto the internet.安装与获取 subkeysubkey 的获取方式有两种通过 Cargo 从源码安装或直接使用官方发布的 Docker 容器镜像。通过 Cargo 安装使用cargo install可以只安装subkey这一个工具而无需编译整个节点。仓库给出的推荐命令如下# 安装指定版本的 subkey crate cargo install --force subkey --git https://github.com/paritytech/substrate --version SET VERSION --locked--force覆盖已安装的旧版本--version SET VERSION指定 subkey crate 的版本号例如本仓库中的 3.0.0--locked使用仓库Cargo.lock中锁定的依赖版本保证构建可复现。需要说明的是从源码安装 subkey 需要先具备 Substrate 的构建依赖环境如果构建过程中报错通常是因为缺少系统级依赖。在 Docker 容器中运行对于不想本地编译、又希望隔离运行环境的场景官方在 Docker Hub 发布了parity/subkey镜像直接运行即可docker run -it --pullalways docker.io/parity/subkey:latest command to subkey使用latest标签时建议配合--pullalways确保拉取到最新镜像也可以改用指定版本的标签来固定版本command to subkey即你要执行的 subkey 子命令例如subkey generate。官方镜像的构建细节解析 subkey.Dockerfile仓库中 scripts/ci/docker/subkey.Dockerfile 正是构建该官方镜像的 Dockerfile它从侧面揭示了 subkey 容器的运行模型FROM docker.io/library/ubuntu:20.04 # metadata ARG VCS_REF ARG BUILD_DATE ARG IMAGE_NAME LABEL io.parity.image.authorsdevops-teamparity.io \ io.parity.image.vendorParity Technologies \ io.parity.image.title${IMAGE_NAME} \ io.parity.image.descriptionSubkey: key generating utility for Substrate. \ io.parity.image.sourcehttps://github.com/paritytech/substrate/blob/${VCS_REF}/scripts/ci/docker/subkey.Dockerfile \ io.parity.image.revision${VCS_REF} \ io.parity.image.created${BUILD_DATE} \ io.parity.image.documentationhttps://github.com/paritytech/substrate/tree/${VCS_REF}/subkey # show backtraces ENV RUST_BACKTRACE 1 # add user RUN useradd -m -u 1000 -U -s /bin/sh -d /subkey subkey # add subkey binary to docker image COPY ./subkey /usr/local/bin USER subkey # check if executable works in this container RUN /usr/local/bin/subkey --version ENTRYPOINT [/usr/local/bin/subkey]这份 Dockerfile 的几个关键点值得留意基础镜像与元数据基于ubuntu:20.04通过构建参数VCS_REF、BUILD_DATE、IMAGE_NAME注入版本、构建时间与镜像名并写入 OCI Label用于镜像溯源与审计。非 root 运行创建了 UID 1000、无密码、家目录为/subkey的专用用户subkey并以USER subkey切换容器内进程默认不具备 root 权限——这符合密钥工具最小权限的安全惯例。ENTRYPOINT 直接指向二进制容器的入口就是/usr/local/bin/subkey因此docker run ... subkey generate等价于直接执行subkey generate。构建期自检RUN /usr/local/bin/subkey --version在构建阶段就验证二进制在当前容器内可执行避免发布坏镜像。生成加密安全的密钥对生成随机账户生成一个新密钥对只需一条命令subkey generate输出类似以下均为示例数据切勿复用本文出现的任何种子与助记词Secret phrase hotel forest jar hover kite book view eight stuff angle legend defense is account: Secret seed: 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d Public key (hex): 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 Account ID: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 SS58 Address: 5Hpm9fq3W3dQgwWpAwDS2ZHKAdnk86QRCu7iX4GnmDxycrte输出字段解读generate输出的五类信息需要分清秘密与公开的边界字段性质说明Secret phrase助记词秘密即 mnemonic phrase默认 12 个单词必须妥善保密Secret seed秘密种子秘密即 Private Key一个 64 位十六进制值必须妥善保密Public key (hex)公开公钥的十六进制表示可由秘密信息推导Account ID公开账户标识通常与公钥十六进制一致SS58 Address公开面向特定网络的地址表示见下文其中助记词与秘密种子是仅有的两份秘密信息其余所有字段都可以从它们推导出来。公钥与Account ID独立于具体网络而SS58 Address即公开地址则是公钥针对某一特定网络的编码表示——同一个种子在不同网络中对应不同的 SS58 地址。例如对上述种子Polkadot16m4J167Mptt8UXL8aGSAi7U2FnPpPxZHPrCgMG9KJzVoFqMKusamaJLNozAv8QeLSbLFwe2UvWeKKE4yvmDbfGxTuiYkF2BUMx4MSS58 地址格式是 Substrate 生态统一的账户地址编码规范含前缀、校验和等不同网络通过不同的地址前缀区分。JSON 输出面向自动化默认的文本输出适合人读而脚本自动化场景则推荐 JSON 输出subkey generate --output-type json输出{ accountId: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515, publicKey: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515, secretPhrase: hotel forest jar hover kite book view eight stuff angle legend defense, secretSeed: 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d, ss58Address: 5Hpm9fq3W3dQgwWpAwDS2ZHKAdnk86QRCu7iX4GnmDxycrte }配合jq可以只提取某个字段例如只取秘密种子subkey generate --output-type json | jq -r .secretSeed输出0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d附加用户自定义密码generate支持在种子之外再追加一段用户自定义的密码password它会被混入密钥派生过程subkey generate --password extra_secret输出Secret phrase soup lyrics media market way crouch elevator put moon useful question wide is account: Secret seed: 0xe7cfd179d6537a676cb94bac3b5c5c9cb1550e846ac4541040d077dfbac2e7fd Public key (hex): 0xf6a233c3e1de1a2ae0486100b460b3ce3d7231ddfe9dadabbd35ab968c70905d Account ID: 0xf6a233c3e1de1a2ae0486100b460b3ce3d7231ddfe9dadabbd35ab968c70905d SS58 Address: 5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6iaVC设置密码后仅凭助记词无法恢复原账户。例如直接用助记词检查subkey inspect soup lyrics media market way crouch elevator put moon useful question wide恢复出的是5Fe4sqj2K4fRuzEGvToi4KATqZfiDU7TqynjXG6PZE2dxwyh而不是预期的5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6iaVC。只有同时提供密码才能完整恢复subkey inspect --password extra_secret soup lyrics media market way crouch elevator put moon useful question wide这次输出才会正确地回到5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6iaVC。这意味着密码成为恢复账户的第二个秘密因子——务必把它与助记词分开妥善保存。密钥恢复与检查subkey inspect如果你手头拥有关于某个密钥的部分信息inspect子命令可以帮助你补全并展示它的完整信息。从助记词或种子恢复拥有秘密信息时subkey inspect mnemonic | seed 例如传入秘密种子subkey inspect 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d输出Secret Key URI 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d is account: Secret seed: 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d Public key (hex): 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 Account ID: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 SS58 Address: 5Hpm9fq3W3dQgwWpAwDS2ZHKAdnk86QRCu7iX4GnmDxycrte仅凭公钥信息检查无秘密信息时如果只有公开数据公钥或地址同样可以检查但只会得到公开字段的子集subkey inspect --public pubkey | address 两条使用注意助记词 → 种子是单向的从助记词可以恢复出秘密种子反之从种子无法还原出助记词公开信息不可反推秘密出于显然的原因仅传入公钥或地址时inspect永远无法恢复出任何秘密信息。消息签名与验证使用私钥签名subkey 允许用私钥对消息签名任何人都可以用你的公钥验证签名echo -n msg | subkey sign --suri seed|mnemonic其中--suri指定签名所用的密钥来源秘密种子或助记词。示例MESSAGEhello SURI0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d echo -n $MESSAGE | subkey sign --suri $SURI输出十六进制签名9201af3788ad4f986b800853c79da47155f2e08fde2070d866be4c27ab060466fea0623dc2b51f4392f4c61f25381a62848dd66c5d8217fae3858e469ebd668c注意每次执行sign的输出都会不同因为签名过程中引入了随机性如随机 nonce。每份签名虽然各不相同但都是有效的。使用公钥/地址验证签名给定消息、签名和地址verify可以判断该消息是否确实由该地址对应私钥的持有者签名echo -n msg | subkey verify sig address示例MESSAGEhello URI0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 SIGNATURE9201af3788ad4f986b800853c79da47155f2e08fde2070d866be4c27ab060466fea0623dc2b51f4392f4c61f25381a62848dd66c5d8217fae3858e469ebd668c echo -n $MESSAGE | subkey verify $SIGNATURE $URI验证成功时输出Signature verifies correctly.验证失败例如签名不匹配、消息被篡改或地址不对应时输出Error: SignatureInvalid这套签名/验签机制基于 Substrate 的加密原语构建底层同样支撑着对编码交易的签名与验签场景——在 Substrate 系链上交易签名正是利用同一套私钥派生与签名算法完成的。换句话说generate产出的私钥既可以用来签名消息也可以用于签名链上交易。派生分层确定性HD子密钥subkey 支持通过 SURISecret URI路径派生子密钥。在 SURI 中使用/分隔派生路径即可从一个根密钥派生出结构化、可复现的子密钥树。仓库中的真实用法出现在节点开发链的注释示例里bin/node/cli/src/chain_spec.rs 给出了两种典型写法// for i in 1 2 3 4 ; do for j in stash controller; do subkey inspect $secret/fir/$j/$i; done; done // for i in 1 2 3 4 ; do for j in session; do subkey --ed25519 inspect $secret//fir//$j//$i; done; done // generated with secret: subkey inspect $secret/fir从这段注释可以看出两个关键用法路径派生subkey inspect $secret/fir/$j/$i会在根秘密$secret之后依次追加fir、$j如 stash/controller/session、$i等派生路径段每一段都会派生出一个确定性的子密钥对。这与 BIP32 风格的分层确定性思路一致非常适合为测试网批量生成stash / controller / session三套角色密钥。指定签名算法subkey --ed25519 inspect ...用于在默认的 SR25519 算法之外显式选择 ED25519 算法。Substrate 生态主要使用 SR25519基于 Schnorr 签名速度快、适合链上验证但在需要兼容 ED25519 的场景例如一些已有的签名工具链时可以切换。这种派生方式让开发者可以用一个根助记词 路径规则管理一整组相关密钥而不是为每个账户单独保存一份秘密。虚荣地址生成subkey vanitysubkey 内置了虚荣地址vanity address生成器可以搜索一个地址中包含指定模式的种子subkey vanity --network polkadot --pattern bob其中--network指定目标网络的 SS58 地址格式--pattern指定希望地址包含的字符串。示例输出Generating key containing pattern bob best: 190 top: 189 Secret Key URI 0x8c9a73097f235b84021a446bc2826a00c690ea0be3e0d81a84931cb4146d6691 is account: Secret seed: 0x8c9a73097f235b84021a446bc2826a00c690ea0be3e0d81a84931cb4146d6691 Public key (hex): 0x1a8b32e95c1f571118ea0b84801264c3c70f823e320d099e5de31b9b1f18f843 Account ID: 0x1a8b32e95c1f571118ea0b84801264c3c70f823e320d099e5de31b9b1f18f843 SS58 Address: 1bobYxBPjZWRPbVo35aSwci1u5Zmq8P6J2jpa4kkudBZMqE于是 Bob 得到了一串以自己名字开头的地址1**bob**YxBPjZWRPbVo35aSwci1u5Zmq8P6J2jpa4kkudBZMqE。需要提醒的是虚荣地址生成本质上是暴力搜索模式越短越容易命中模式越长越耗时。例如 3 个字符的bob可以较快搜到而 5 个字符的alice需要尝试的随机地址数量呈指数级增长耗时显著加长。在批量搜索或长时间运行时应根据硬件情况量力而行。密钥安全最佳实践仓库 bin/utils/subkey/SECURITY.md 对密钥安全给出了明确的守则总结如下subkey 会生成并展示两份秘密信息secret phrase助记词一串单词默认 12 个也可为 12、15、18、21 或 24 个secret seed秘密种子一个大十六进制数值。私钥面临两类核心风险丢失没有做好备份密钥一旦丢失即永久无法找回泄露包括恶意软件、钓鱼、键盘记录器、备份存放于联网且未妥善保护的机器等多种途径。你必须确保既不丢失这两份秘密也不让除你之外的任何人访问到它们。具体行动准则☠️绝不在任何情况下向任何人透露助记词或秘密种子——一旦泄露对方即可动用你的资金、代你发送交易☠️ 如果有人索要你的助记词或秘密种子可以确信对方是在试图盗取你的资金✅SS58 地址本来就是公开信息可以放心分享收款或交互只需要你的公开地址⚠️ 同一把密钥在多条链上复用虽然技术上可行但通常不建议除非你有充分的理由并理解其中的风险与弊端建议先在测试网如 Westend上练习测试网上的代币损失不会带来财务后果是安全的实验场所。此外bin/utils/subkey/README.md 还提醒若将 subkey 输出保存到文件务必设置合适的文件权限并在用完后尽快删除。获取完整命令列表本文覆盖了 subkey 的核心高频操作但并非全部能力。任何时刻都可以通过内建帮助查看完整的命令清单subkey --help大多数子命令还提供更细粒度的帮助例如subkey generate --help小结subkey 是 Substrate 生态密钥管理的标准工具generate负责产出密码学安全的密钥对支持 JSON 输出与自定义密码inspect负责从助记词、种子乃至公钥地址恢复和检查密钥信息sign/verify提供消息及交易签名验证能力SURI 路径派生支持按角色批量派生子密钥vanity可生成含指定模式的地址。官方同时提供cargo install与 Docker 容器两种分发方式容器镜像由仓库中的 subkey.Dockerfile 构建以非 root 用户、单二进制入口的方式交付。无论你是 Substrate 节点运营者、平行链开发者还是链上账户的使用者掌握 subkey 就等于掌握了账户密钥从生成、备份、恢复到使用的完整闭环。请始终牢记助记词与秘密种子是你的全部资产离线生成、妥善备份、绝不外泄。赞分享区块链开发框架后端【免费下载链接】substrateSubstrate: The platform for blockchain innovators项目地址https://gitcode.com/gh_mirrors/su/substrate点击查看免费下载相关推荐Substrate Subkey 实用手册账户密钥生成、密钥检视、消息签名验签与靓号地址Substrate Subkey 实用手册账户密钥生成、密钥检视、消息签名验签与靓号地址 本文基于 Substrate 仓库中 subkey 工具的官方文档区块链开发框架后端Gradle 制品签名密钥完全指南从密钥管理到 GPG 验证与依赖验证实战Gradle 制品签名密钥完全指南从密钥管理到 GPG 验证与依赖验证实战 Gradle 官方对自身产出的每一个制品无论发布到制品仓库还是通过发行版渠道分发构建工具开发工具Fleet 许可证License密钥生成完全指南ES256 签名的 JWT 密钥原理与实战Fleet 许可证License密钥生成完全指南ES256 签名的 JWT 密钥原理与实战 Fleet 是开源的设备管理平台open device ma后端前端企业应用运维网络安全上一篇Flet LayoutControl 完全指南尺寸、定位、2D 变换与隐式动画实战下一篇Vuetify0 发布候选RC深度解读API 冻结、默认无障碍与 v1.0 冲刺全景创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Substrate subkey 密钥管理工具实战指南：密钥生成、恢复、签名验证与容器化部署
区块链开发框架后端【免费下载链接】substrateSubstrate: The platform for blockchain innovators项目地址https://gitcode.com/gh_mirrors/su/substrate点击查看免费下载subkey是 Substrate 官方提供的一站式密钥管理命令行工具面向 Substrate 生态链如 Polkadot、Kusama 以及各类平行链和 Substrate 项目的开发者与用户。本文以仓库中 scripts/ci/docker/subkey.Dockerfile.README.md 对 subkey 的能力定义为主线结合 bin/utils/subkey/README.md、bin/utils/subkey/SECURITY.md 与 scripts/ci/docker/subkey.Dockerfile 等仓库资料系统讲解如何生成与检查密钥对、从助记词和原始种子恢复密钥、对消息进行签名与验证、派生分层确定性子密钥以及如何通过 Docker 容器安全地使用该工具。读完本文你将能够独立完成 Substrate 链账户密钥的全生命周期管理并掌握容器化部署与安全实践要点。认识 subkeySubstrate 生态的密钥管理工具Substrate 官方文档对subkey的定位是Thesubkeyprogram is a key management utility for Substrate-based blockchains——即面向 Substrate 系区块链的密钥管理工具。根据仓库中 scripts/ci/docker/subkey.Dockerfile.README.md 的定义你可以使用 subkey 完成以下任务生成并检查密码学安全的公钥/私钥对从助记词secret phrase和原始种子raw seed恢复密钥对消息进行签名与验签对编码后的交易进行签名与验签派生分层确定性Hierarchical Deterministic, HD子密钥对。从源码结构看subkey 的完整实现位于仓库的 bin/utils/subkey/ 目录。其中 Cargo.toml 声明了subkey3.0.0 这个独立的二进制 crate入口为 src/main.rs其核心逻辑极简——main()直接调用subkey::run()全部功能通过 src/lib.rs 实现命令行解析依赖clap 4.2.5启用derive特性错误类型则复用sc-cliclient/cli的定义。也就是说subkey 实际上是 Substrate 客户端 CLI 工具链在密钥管理场景下的专门化封装。完全离线的密钥工具subkey 在运行时不需要联网。这一点既是设计特性也是安全要求密钥操作不涉及任何网络请求因此你可以也应该在完全断网的机器上生成和管理密钥。正如 bin/utils/subkey/README.md 强调的for the best security, you should be usingsubkeyon a machine that isnot connectedto the internet.安装与获取 subkeysubkey 的获取方式有两种通过 Cargo 从源码安装或直接使用官方发布的 Docker 容器镜像。通过 Cargo 安装使用cargo install可以只安装subkey这一个工具而无需编译整个节点。仓库给出的推荐命令如下# 安装指定版本的 subkey crate cargo install --force subkey --git https://github.com/paritytech/substrate --version SET VERSION --locked--force覆盖已安装的旧版本--version SET VERSION指定 subkey crate 的版本号例如本仓库中的 3.0.0--locked使用仓库Cargo.lock中锁定的依赖版本保证构建可复现。需要说明的是从源码安装 subkey 需要先具备 Substrate 的构建依赖环境如果构建过程中报错通常是因为缺少系统级依赖。在 Docker 容器中运行对于不想本地编译、又希望隔离运行环境的场景官方在 Docker Hub 发布了parity/subkey镜像直接运行即可docker run -it --pullalways docker.io/parity/subkey:latest command to subkey使用latest标签时建议配合--pullalways确保拉取到最新镜像也可以改用指定版本的标签来固定版本command to subkey即你要执行的 subkey 子命令例如subkey generate。官方镜像的构建细节解析 subkey.Dockerfile仓库中 scripts/ci/docker/subkey.Dockerfile 正是构建该官方镜像的 Dockerfile它从侧面揭示了 subkey 容器的运行模型FROM docker.io/library/ubuntu:20.04 # metadata ARG VCS_REF ARG BUILD_DATE ARG IMAGE_NAME LABEL io.parity.image.authorsdevops-teamparity.io \ io.parity.image.vendorParity Technologies \ io.parity.image.title${IMAGE_NAME} \ io.parity.image.descriptionSubkey: key generating utility for Substrate. \ io.parity.image.sourcehttps://github.com/paritytech/substrate/blob/${VCS_REF}/scripts/ci/docker/subkey.Dockerfile \ io.parity.image.revision${VCS_REF} \ io.parity.image.created${BUILD_DATE} \ io.parity.image.documentationhttps://github.com/paritytech/substrate/tree/${VCS_REF}/subkey # show backtraces ENV RUST_BACKTRACE 1 # add user RUN useradd -m -u 1000 -U -s /bin/sh -d /subkey subkey # add subkey binary to docker image COPY ./subkey /usr/local/bin USER subkey # check if executable works in this container RUN /usr/local/bin/subkey --version ENTRYPOINT [/usr/local/bin/subkey]这份 Dockerfile 的几个关键点值得留意基础镜像与元数据基于ubuntu:20.04通过构建参数VCS_REF、BUILD_DATE、IMAGE_NAME注入版本、构建时间与镜像名并写入 OCI Label用于镜像溯源与审计。非 root 运行创建了 UID 1000、无密码、家目录为/subkey的专用用户subkey并以USER subkey切换容器内进程默认不具备 root 权限——这符合密钥工具最小权限的安全惯例。ENTRYPOINT 直接指向二进制容器的入口就是/usr/local/bin/subkey因此docker run ... subkey generate等价于直接执行subkey generate。构建期自检RUN /usr/local/bin/subkey --version在构建阶段就验证二进制在当前容器内可执行避免发布坏镜像。生成加密安全的密钥对生成随机账户生成一个新密钥对只需一条命令subkey generate输出类似以下均为示例数据切勿复用本文出现的任何种子与助记词Secret phrase hotel forest jar hover kite book view eight stuff angle legend defense is account: Secret seed: 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d Public key (hex): 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 Account ID: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 SS58 Address: 5Hpm9fq3W3dQgwWpAwDS2ZHKAdnk86QRCu7iX4GnmDxycrte输出字段解读generate输出的五类信息需要分清秘密与公开的边界字段性质说明Secret phrase助记词秘密即 mnemonic phrase默认 12 个单词必须妥善保密Secret seed秘密种子秘密即 Private Key一个 64 位十六进制值必须妥善保密Public key (hex)公开公钥的十六进制表示可由秘密信息推导Account ID公开账户标识通常与公钥十六进制一致SS58 Address公开面向特定网络的地址表示见下文其中助记词与秘密种子是仅有的两份秘密信息其余所有字段都可以从它们推导出来。公钥与Account ID独立于具体网络而SS58 Address即公开地址则是公钥针对某一特定网络的编码表示——同一个种子在不同网络中对应不同的 SS58 地址。例如对上述种子Polkadot16m4J167Mptt8UXL8aGSAi7U2FnPpPxZHPrCgMG9KJzVoFqMKusamaJLNozAv8QeLSbLFwe2UvWeKKE4yvmDbfGxTuiYkF2BUMx4MSS58 地址格式是 Substrate 生态统一的账户地址编码规范含前缀、校验和等不同网络通过不同的地址前缀区分。JSON 输出面向自动化默认的文本输出适合人读而脚本自动化场景则推荐 JSON 输出subkey generate --output-type json输出{ accountId: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515, publicKey: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515, secretPhrase: hotel forest jar hover kite book view eight stuff angle legend defense, secretSeed: 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d, ss58Address: 5Hpm9fq3W3dQgwWpAwDS2ZHKAdnk86QRCu7iX4GnmDxycrte }配合jq可以只提取某个字段例如只取秘密种子subkey generate --output-type json | jq -r .secretSeed输出0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d附加用户自定义密码generate支持在种子之外再追加一段用户自定义的密码password它会被混入密钥派生过程subkey generate --password extra_secret输出Secret phrase soup lyrics media market way crouch elevator put moon useful question wide is account: Secret seed: 0xe7cfd179d6537a676cb94bac3b5c5c9cb1550e846ac4541040d077dfbac2e7fd Public key (hex): 0xf6a233c3e1de1a2ae0486100b460b3ce3d7231ddfe9dadabbd35ab968c70905d Account ID: 0xf6a233c3e1de1a2ae0486100b460b3ce3d7231ddfe9dadabbd35ab968c70905d SS58 Address: 5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6iaVC设置密码后仅凭助记词无法恢复原账户。例如直接用助记词检查subkey inspect soup lyrics media market way crouch elevator put moon useful question wide恢复出的是5Fe4sqj2K4fRuzEGvToi4KATqZfiDU7TqynjXG6PZE2dxwyh而不是预期的5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6iaVC。只有同时提供密码才能完整恢复subkey inspect --password extra_secret soup lyrics media market way crouch elevator put moon useful question wide这次输出才会正确地回到5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6iaVC。这意味着密码成为恢复账户的第二个秘密因子——务必把它与助记词分开妥善保存。密钥恢复与检查subkey inspect如果你手头拥有关于某个密钥的部分信息inspect子命令可以帮助你补全并展示它的完整信息。从助记词或种子恢复拥有秘密信息时subkey inspect mnemonic | seed 例如传入秘密种子subkey inspect 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d输出Secret Key URI 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d is account: Secret seed: 0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d Public key (hex): 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 Account ID: 0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 SS58 Address: 5Hpm9fq3W3dQgwWpAwDS2ZHKAdnk86QRCu7iX4GnmDxycrte仅凭公钥信息检查无秘密信息时如果只有公开数据公钥或地址同样可以检查但只会得到公开字段的子集subkey inspect --public pubkey | address 两条使用注意助记词 → 种子是单向的从助记词可以恢复出秘密种子反之从种子无法还原出助记词公开信息不可反推秘密出于显然的原因仅传入公钥或地址时inspect永远无法恢复出任何秘密信息。消息签名与验证使用私钥签名subkey 允许用私钥对消息签名任何人都可以用你的公钥验证签名echo -n msg | subkey sign --suri seed|mnemonic其中--suri指定签名所用的密钥来源秘密种子或助记词。示例MESSAGEhello SURI0xa05c75731970cc7868a2fb7cb577353cd5b31f62dccced92c441acd8fee0c92d echo -n $MESSAGE | subkey sign --suri $SURI输出十六进制签名9201af3788ad4f986b800853c79da47155f2e08fde2070d866be4c27ab060466fea0623dc2b51f4392f4c61f25381a62848dd66c5d8217fae3858e469ebd668c注意每次执行sign的输出都会不同因为签名过程中引入了随机性如随机 nonce。每份签名虽然各不相同但都是有效的。使用公钥/地址验证签名给定消息、签名和地址verify可以判断该消息是否确实由该地址对应私钥的持有者签名echo -n msg | subkey verify sig address示例MESSAGEhello URI0xfec70cfbf1977c6965b5af10a4534a6a35d548eb14580594d0bc543286892515 SIGNATURE9201af3788ad4f986b800853c79da47155f2e08fde2070d866be4c27ab060466fea0623dc2b51f4392f4c61f25381a62848dd66c5d8217fae3858e469ebd668c echo -n $MESSAGE | subkey verify $SIGNATURE $URI验证成功时输出Signature verifies correctly.验证失败例如签名不匹配、消息被篡改或地址不对应时输出Error: SignatureInvalid这套签名/验签机制基于 Substrate 的加密原语构建底层同样支撑着对编码交易的签名与验签场景——在 Substrate 系链上交易签名正是利用同一套私钥派生与签名算法完成的。换句话说generate产出的私钥既可以用来签名消息也可以用于签名链上交易。派生分层确定性HD子密钥subkey 支持通过 SURISecret URI路径派生子密钥。在 SURI 中使用/分隔派生路径即可从一个根密钥派生出结构化、可复现的子密钥树。仓库中的真实用法出现在节点开发链的注释示例里bin/node/cli/src/chain_spec.rs 给出了两种典型写法// for i in 1 2 3 4 ; do for j in stash controller; do subkey inspect $secret/fir/$j/$i; done; done // for i in 1 2 3 4 ; do for j in session; do subkey --ed25519 inspect $secret//fir//$j//$i; done; done // generated with secret: subkey inspect $secret/fir从这段注释可以看出两个关键用法路径派生subkey inspect $secret/fir/$j/$i会在根秘密$secret之后依次追加fir、$j如 stash/controller/session、$i等派生路径段每一段都会派生出一个确定性的子密钥对。这与 BIP32 风格的分层确定性思路一致非常适合为测试网批量生成stash / controller / session三套角色密钥。指定签名算法subkey --ed25519 inspect ...用于在默认的 SR25519 算法之外显式选择 ED25519 算法。Substrate 生态主要使用 SR25519基于 Schnorr 签名速度快、适合链上验证但在需要兼容 ED25519 的场景例如一些已有的签名工具链时可以切换。这种派生方式让开发者可以用一个根助记词 路径规则管理一整组相关密钥而不是为每个账户单独保存一份秘密。虚荣地址生成subkey vanitysubkey 内置了虚荣地址vanity address生成器可以搜索一个地址中包含指定模式的种子subkey vanity --network polkadot --pattern bob其中--network指定目标网络的 SS58 地址格式--pattern指定希望地址包含的字符串。示例输出Generating key containing pattern bob best: 190 top: 189 Secret Key URI 0x8c9a73097f235b84021a446bc2826a00c690ea0be3e0d81a84931cb4146d6691 is account: Secret seed: 0x8c9a73097f235b84021a446bc2826a00c690ea0be3e0d81a84931cb4146d6691 Public key (hex): 0x1a8b32e95c1f571118ea0b84801264c3c70f823e320d099e5de31b9b1f18f843 Account ID: 0x1a8b32e95c1f571118ea0b84801264c3c70f823e320d099e5de31b9b1f18f843 SS58 Address: 1bobYxBPjZWRPbVo35aSwci1u5Zmq8P6J2jpa4kkudBZMqE于是 Bob 得到了一串以自己名字开头的地址1**bob**YxBPjZWRPbVo35aSwci1u5Zmq8P6J2jpa4kkudBZMqE。需要提醒的是虚荣地址生成本质上是暴力搜索模式越短越容易命中模式越长越耗时。例如 3 个字符的bob可以较快搜到而 5 个字符的alice需要尝试的随机地址数量呈指数级增长耗时显著加长。在批量搜索或长时间运行时应根据硬件情况量力而行。密钥安全最佳实践仓库 bin/utils/subkey/SECURITY.md 对密钥安全给出了明确的守则总结如下subkey 会生成并展示两份秘密信息secret phrase助记词一串单词默认 12 个也可为 12、15、18、21 或 24 个secret seed秘密种子一个大十六进制数值。私钥面临两类核心风险丢失没有做好备份密钥一旦丢失即永久无法找回泄露包括恶意软件、钓鱼、键盘记录器、备份存放于联网且未妥善保护的机器等多种途径。你必须确保既不丢失这两份秘密也不让除你之外的任何人访问到它们。具体行动准则☠️绝不在任何情况下向任何人透露助记词或秘密种子——一旦泄露对方即可动用你的资金、代你发送交易☠️ 如果有人索要你的助记词或秘密种子可以确信对方是在试图盗取你的资金✅SS58 地址本来就是公开信息可以放心分享收款或交互只需要你的公开地址⚠️ 同一把密钥在多条链上复用虽然技术上可行但通常不建议除非你有充分的理由并理解其中的风险与弊端建议先在测试网如 Westend上练习测试网上的代币损失不会带来财务后果是安全的实验场所。此外bin/utils/subkey/README.md 还提醒若将 subkey 输出保存到文件务必设置合适的文件权限并在用完后尽快删除。获取完整命令列表本文覆盖了 subkey 的核心高频操作但并非全部能力。任何时刻都可以通过内建帮助查看完整的命令清单subkey --help大多数子命令还提供更细粒度的帮助例如subkey generate --help小结subkey 是 Substrate 生态密钥管理的标准工具generate负责产出密码学安全的密钥对支持 JSON 输出与自定义密码inspect负责从助记词、种子乃至公钥地址恢复和检查密钥信息sign/verify提供消息及交易签名验证能力SURI 路径派生支持按角色批量派生子密钥vanity可生成含指定模式的地址。官方同时提供cargo install与 Docker 容器两种分发方式容器镜像由仓库中的 subkey.Dockerfile 构建以非 root 用户、单二进制入口的方式交付。无论你是 Substrate 节点运营者、平行链开发者还是链上账户的使用者掌握 subkey 就等于掌握了账户密钥从生成、备份、恢复到使用的完整闭环。请始终牢记助记词与秘密种子是你的全部资产离线生成、妥善备份、绝不外泄。赞分享区块链开发框架后端【免费下载链接】substrateSubstrate: The platform for blockchain innovators项目地址https://gitcode.com/gh_mirrors/su/substrate点击查看免费下载相关推荐Substrate Subkey 实用手册账户密钥生成、密钥检视、消息签名验签与靓号地址Substrate Subkey 实用手册账户密钥生成、密钥检视、消息签名验签与靓号地址 本文基于 Substrate 仓库中 subkey 工具的官方文档区块链开发框架后端Gradle 制品签名密钥完全指南从密钥管理到 GPG 验证与依赖验证实战Gradle 制品签名密钥完全指南从密钥管理到 GPG 验证与依赖验证实战 Gradle 官方对自身产出的每一个制品无论发布到制品仓库还是通过发行版渠道分发构建工具开发工具Fleet 许可证License密钥生成完全指南ES256 签名的 JWT 密钥原理与实战Fleet 许可证License密钥生成完全指南ES256 签名的 JWT 密钥原理与实战 Fleet 是开源的设备管理平台open device ma后端前端企业应用运维网络安全上一篇Flet LayoutControl 完全指南尺寸、定位、2D 变换与隐式动画实战下一篇Vuetify0 发布候选RC深度解读API 冻结、默认无障碍与 v1.0 冲刺全景创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考