更新可信设置

Aptos 验证器在启动时会加载两个可信设置 blob:digest_key.bin 和 pp.bin(公共参数).这两个 blob 由 Aptos Labs 在 aptos-labs/aptos-networks 仓库中发布, 并在节点参与 DKG 之前由共识加载.VFN 和 PFN 不需要 这些文件.

本页面介绍现有验证器运维人员将新版本 blob 部署到节点的步骤.具体流程取决于您的部署方式:

• 源代码 — 您直接运行验证器二进制文件.
• Docker(compose) — 您运行上游的 aptos-node docker-compose 堆栈.
• Kubernetes(Helm chart) — 您在 AWS / GCP / Azure 上运行官方 aptos-node Helm chart.

警告

验证器集群中的每个节点都必须加载相同的字节.在部分验证器上加载过时或不匹配的 blob 将阻止受影响的节点参与 共识.在向重启后的验证器发送流量之前,请始终确认 blake3 校验和与下方发布的值匹配.

已发布的校验和

测试网校验和对应于 aptos-networks@8cfc400 中的 blob(截至 2026-05-15).每当 Aptos Labs 发布新版本时,本表都会更新.

网络	文件	大小(字节)	blake3
testnet	digest_key.bin	4002048590	ffff6ab738c58c1c7eeb697eecbc369205e111c9ef271ab2cbe524869671b441
testnet	pp.bin	889521361	5094dd22376eefde2febae5f2c9935d7eab0440af93166d246aa5c9f8ecb1b52
mainnet	digest_key.bin	待定 — 尚未发布	待定 — 尚未发布
mainnet	pp.bin	待定 — 尚未发布	待定 — 尚未发布

注意

这两个 blob 都通过 Git LFS 存储,因此下载 URL 必须使用 github.com/.../raw/...(它会跟随 LFS 重定向), 而非 raw.githubusercontent.com(后者会返回 135 字节的 LFS 指针文本).使用错误的 URL 会悄无声息地 破坏共识.

源代码部署

如果您直接从 aptos-core 构建的二进制文件运行验证器,请使用此流程.您选择 blob 在磁盘上的位置,并让 validator.yaml 指向它们.

1. 下载 blob

在验证器所在主机上选择一个目录 — 本地持久存储上的任何位置都可以.下面的示例使用 /opt/aptos/genesis/, 与 genesis.blob 和 waypoint.txt 放在一起.

wget -O /opt/aptos/genesis/digest_key.bin \
  https://github.com/aptos-labs/aptos-networks/raw/main/<network>/digest_key.bin
wget -O /opt/aptos/genesis/pp.bin \
  https://github.com/aptos-labs/aptos-networks/raw/main/<network>/pp.bin

将 <network> 替换为相应的网络(testnet 或 mainnet).

2. 使用 Aptos CLI 验证

确认每个文件能够正确反序列化,并计算其 blake3 校验和:

aptos node validate-digest-key --file /opt/aptos/genesis/digest_key.bin
aptos node validate-public-parameters --file /opt/aptos/genesis/pp.bin

每个命令都会输出以下形状的 JSON:

{
  "size": 4002048590,
  "blake3": "ffff6ab738c58c1c7eeb697eecbc369205e111c9ef271ab2cbe524869671b441"
}

根据您所运营的网络,将这两个字段与 已发布的校验和 表进行比较.如果任一值不同, 请不要重启验证器 — 重新下载文件(最常见的原因是传输被截断,或者通过 raw.githubusercontent.com 获取 LFS 指针文本).

3. 配置 validator.yaml

确认您的 validator.yaml 中的 consensus 块引用了这两个文件.路径必须与您在步骤 1 中写入的位置匹配.

consensus:
  digest_key_blob_path: /opt/aptos/genesis/digest_key.bin
  public_parameters_blob_path: /opt/aptos/genesis/pp.bin

4. 重启验证器

按照您正常的重启流程操作(请参阅 升级节点了解特定部署的步骤). 节点在启动时只加载一次 blob;后续的轮换需要再次重启.

Docker(compose)部署

如果您运行 aptos-core/docker/compose/aptos-node 中的上游 docker-compose.yaml,请使用此流程.上游 compose 文件会将可信设置文件从您的工作目录绑定挂载到容器 内的 /opt/aptos/genesis/,并且上游 validator.yaml 已经设置了相应的 consensus 路径 — 因此您只需将 文件放在 genesis.blob / waypoint.txt 旁边即可.

1. 将 blob 下载到您的工作目录

cd ~/$WORKSPACE   # 存放 genesis.blob 和 waypoint.txt 的目录
wget -O digest_key.bin https://github.com/aptos-labs/aptos-networks/raw/main/testnet/digest_key.bin
wget -O pp.bin https://github.com/aptos-labs/aptos-networks/raw/main/testnet/pp.bin

将 testnet 替换为您所运营的网络(主网 blob 尚未发布;参见 已发布的校验和 备注).

2. 使用 Aptos CLI 验证

aptos node validate-digest-key --file digest_key.bin
aptos node validate-public-parameters --file pp.bin

将 size 和 blake3 与 已发布的校验和 表中您所在网络的值进行比较.如果不匹配, 请重新下载 — 请不要用错误的文件重启验证器.

3. 确认 docker-compose.yaml 和 validator.yaml 是最新的

上游文件既包含绑定挂载,也包含 consensus 块.如果您是在添加这些之前设置的验证器,请从 aptos-core 的 testnet 分支刷新这两个文件(参见 测试网文件),并调和任何本地修改. 需要确认的相关部分:

docker-compose.yaml(validator 服务):

volumes:
  # …已有的挂载(genesis.blob、waypoint.txt、validator.yaml、身份文件)…
  - type: bind
    source: ./digest_key.bin
    target: /opt/aptos/genesis/digest_key.bin
  - type: bind
    source: ./pp.bin
    target: /opt/aptos/genesis/pp.bin

validator.yaml:

consensus:
  digest_key_blob_path: /opt/aptos/genesis/digest_key.bin
  public_parameters_blob_path: /opt/aptos/genesis/pp.bin
  # …safety_rules 等其他共识设置…

4. 重启验证器

docker compose restart validator

或重新创建堆栈以拾取 docker-compose.yaml 的任何更改:

docker compose up -d

Kubernetes 部署(Helm chart)

如果您通过官方 aptos-node Helm chart 部署验证器(AWS,GCP 和 Azure 上的典型设置),请使用此流程.您不需要 手动下载 blob — chart 的 init 容器会在首次重启时将其下载到持久卷,并在后续重启时跳过.

1. 更新 trustedSetup chart values

在 chart 的 trustedSetup 块中设置 URL(可选地覆盖磁盘路径).chart 将 blob 写入持久 aptos-data PVC 上的 trustedSetup.path,并在 validator.yaml 中配置 consensus.digest_key_blob_path / public_parameters_blob_path 进行匹配 — 无需进一步的 validator 配置.

trustedSetup:
  # 持久 aptos-data PVC 上的位置.默认值适用于大多数部署.
  path: /opt/aptos/data/trusted-setup
  # 即使 URL 未变,也通过递增此整数来强制重新下载.默认为 0.
  refreshCounter: 0
  digestKeyUrl: "https://github.com/aptos-labs/aptos-networks/raw/8cfc400bc1e42a232b5b36cde779a5b71d4d275b/testnet/digest_key.bin"
  publicParametersUrl: "https://github.com/aptos-labs/aptos-networks/raw/8cfc400bc1e42a232b5b36cde779a5b71d4d275b/testnet/pp.bin"

提示

将 URL 锁定到 aptos-networks 的某个提交 SHA,而非 main.锁定能使轮换变得显式和可比对,并防止 main 在下一次 pod 重启时悄无声息地推出新的字节.

2.(可选)在工作站上预先验证校验和

chart 在集群内部获取字节,因此集群内的下载过程不会经过 aptos CLI.在部署前对 URL 进行健全性检查:在本地下载 一份副本,并对其运行 源代码验证步骤:

wget -O /tmp/digest_key.bin \
  https://github.com/aptos-labs/aptos-networks/raw/8cfc400bc1e42a232b5b36cde779a5b71d4d275b/testnet/digest_key.bin
aptos node validate-digest-key --file /tmp/digest_key.bin

将打印的 blake3 与 已发布的校验和 表进行比较.

3. 应用并重启

运行您通常的 chart 部署命令(helm upgrade,pulumi up,Terraform apply 等).init 容器检测到磁盘上的 .url 标记不再匹配新的 URL,将 blob 下载到 trustedSetup.path,并写入新的标记.随后 validator 容器加载 新获取的文件.

注意

首次重启需要支付一次性下载成本. 在测试网上,这两个 blob 总计约 4 GiB,一次性获取到持久数据 PVC. 后续重启通过标记检查跳过下载,并在几秒钟内启动.

在不更改 URL 的情况下强制重新下载

如果您怀疑磁盘损坏,或希望从相同的 URL 重新获取(例如,从写入一半的下载中恢复),将 trustedSetup.refreshCounter 加一并重新应用.init 容器会清除现有标记,从而强制在下一次 pod 重启时重新下载每个 blob.

trustedSetup:
  refreshCounter: 1 # 原为 0
  # URL 不变

确认集群一致性

在您的验证器重启后(任一流程),有两个 Prometheus 指标将每个已加载 blob 的 blake3 作为标签暴露出来:

• aptos_dkg_digest_key_blake3{blake3="<hex>"} 1
• aptos_dkg_public_params_blake3{blake3="<hex>"} 1

在 Grafana 中跨整个验证器集群按 blake3 标签分组.健康的发布显示每个指标只有一个标签值,且与 已发布的校验和 表匹配.多个值表示至少有一个验证器正在运行过时的 blob.