AeroNyx

去中心化隐私节点运维与健康检查

AeroNyx2026年6月18日7 分钟阅读75 次浏览

运维 AeroNyx 去中心化隐私节点：健康、节点发现、盲中继、重启恢复、容量、封包运行态、双跳证明质量与受控 Cargo 缓存维护。

「去中心化隐私节点运维与健康检查」是 AeroNyx 文档体系中的正式本地化页面。AeroNyx 将协议层与产品体验分开：协议负责不可关闭的开放能力，产品负责 App、Nodeboard、加密聊天、加密存储和节点运营体验。

概览

本文用简体中文说明「去中心化隐私节点运维与健康检查」在 AeroNyx 开源隐私协议中的作用、当前实现边界、隐私不变量以及开发/节点运营注意事项。

在 AeroNyx 架构中的位置

本主题属于 节点运营者。理解它的关键不是把 AeroNyx 看成单一中心化服务，而是把它看成一组可由客户端、去中心化隐私节点、后端协调器和 Nodeboard 共同使用的开放隐私协议能力。

当前实现重点

  • 所有涉及用户内容的能力都必须通过端到端加密或密文对象传递。
  • 去中心化隐私节点可以报告健康、容量、连接、路径证明和聚合统计，但不能读取消息正文、访问凭据或用户秘密。
  • Nodeboard 用于运营可观测性：展示节点健康、peer discovery、重启恢复、容量、封包/流量与协议状态。
  • 后端在当前阶段负责协调、排序、聚合与公开文档接口；这些职责后续可以逐步下沉到 Rust 协议层。

隐私边界

AeroNyx 的核心不变量是 blind-node invariant：转发节点和 MemChain 协调器只能处理密文、时间戳、证明、聚合健康信号和有限路由元数据。它们不能读取明文、不能看到 DNS 内容、不能知道访问目的地，也不能重建谁和谁通信。

节点与运营者需要关注

节点运营者需要关注带宽、连接上限、IP 池、conntrack、文件描述符、packet drops、pps、bps、peer store、heartbeat 新鲜度和 restart recovery。运营界面应该帮助排障，但不能暴露用户内容或可关联身份的数据。

开发者与产品接入

客户端、App、AI agent 或第三方服务接入时，应优先复用 AeroNyx 的加密信封、签名、盲转发、匿名凭证和健康检查约定。任何新接口都必须明确哪些字段是公开元数据，哪些字段必须留在 E2E payload 内。

当前状态

本页描述的是 AeroNyx 当前可公开说明的协议与产品设计边界。后续如果实现多跳路由、盲签名凭证、加密媒体 blob、MemChain 同步或节点发现升级，应在同一 translation_key 下持续维护。

<!-- memchain-witness-operations-v1:start -->

固定见证节点运维

固定见证是 MemChain 承诺协调节点的显式运营信任策略。只应配置独立运营、经过审计并预期保存该协调节点承诺历史的跟随节点。

toml
[memchain]
commitment_coordinator_enabled = true
commitment_witness_node_ids = ["<64位十六进制Ed25519节点身份-1>", "<64位十六进制Ed25519节点身份-2>"]
commitment_witness_startup_required = false
commitment_witness_min_verified = 2

验证前必须替换全部占位符。最多允许三个唯一、非零的 32 字节 Ed25519 身份，并且这些设置只能用于承诺协调节点。

安全上线流程：先升级至少两个独立审计的跟随节点；在非严格模式加入准确身份；运行 aeronyx-server validate -c /etc/aeronyx/server.toml；重启并确认 operator_pinned 已接受签名证据；重复验证后再开启严格模式。

非严格模式下，见证不可达会产生明确的降级警告，但保留服务可用性。远端较新或历史分叉的有效签名证据始终阻止启动。严格模式下，没有任何已验证的固定见证证据也会阻止启动。

checkpoint 是签名协议接口，匿名浏览器 GET 不是有效健康检查。固定见证增强回滚检测，但本身不构成共识、法定人数或最终性。

已验证的生产部署 — 2026 年 7 月 14 日

一个生产协调节点配置了三个由运营者固定的见证身份。两个独立运营并经过审核的跟随节点现已运行兼容的检查点服务，并各自验证和保存了同一份包含 33 个区块、8,339 个承诺的历史。协调节点接受了两台跟随节点分别签署的 converged 结果，随后开启 commitment_witness_startup_required = true。

经验证的重启中，启动保护报告 configured=3、eligible=3、attempted=3、verified=2、converged=2；UDP 和 TUN 监听只在检查通过后开放。这是运营者固定节点提供的回滚证据，不是共识、法定人数、公链最终性或代币执行。

<!-- witness-threshold-enforced-v1:start -->

已强制执行 2-of-3 启动门槛 — 2026 年 7 月 14 日

生产协调节点现已同时设置 commitment_witness_min_verified = 2 与 commitment_witness_startup_required = true。少于两个不同的固定见证提供有效签名证据时，节点会拒绝启动：零个有效响应返回 signed_checkpoint_unavailable，仅一个有效响应返回 signed_checkpoint_threshold_unmet。最近一次生产重启在 UDP、TUN 和公开 API 监听器开放前成功验证了三个配置见证中的两个。

这是运营者定义的启动门槛，不是网络共识、法定人数、最终性、领导者选举或分叉选择。Rust 心跳状态只上报包括 startup_minimum_verified 在内的聚合策略与结果字段，不暴露见证身份、端点、检查点哈希或签名。

<!-- witness-threshold-enforced-v1:end --> <!-- memchain-witness-operations-v1:end --> <!-- signed-commitment-ledger-related-v1:start -->

相关协议规范

签名承诺账本与见证保护

<!-- signed-commitment-ledger-related-v1:end --> <!-- aof-semantic-integrity-v1:start -->

MemChain AOF 完整性检查

将这项只读门槛加入每次计划升级与重启。由于输出只有聚合信息，可安全用于运维自动化。

bash
sudo aeronyx-server memchain verify-aof \
  --config /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain
结果运营者操作
status: verified 且 torn_tail_bytes: 0继续配置验证与受保护的重启流程。
torn_tail_detected不要手工编辑文件。仅受保护的 append-open 可在完整语义扫描后移除不完整物理尾部。
命令返回完整性错误立即停止。保留 AOF 与日志进行事故审查；完整记录的语义损坏必须 fail closed。

隐私: 不得上传、粘贴或公开 AOF 文件本身；只分享验证器的聚合输出。

完整的完整性与证明边界: 签名承诺账本与见证保护.

<!-- aof-semantic-integrity-v1:end --> <!-- build-cache-maintenance-v1:start -->

受控 Cargo 编译缓存维护

频繁源码编译可能在节点上留下数十 GB 可重新生成的 Cargo 对象。统一运维命令可以在不删除协议状态、不重启服务的前提下盘点并回收空间。

1. 只读盘点，不修改主机

先运行只读盘点。输出包含旧仓库 target、隔离 build root、固定 Rust 版本、受保护 binary 的 SHA-256 与文件系统聚合容量。

bash
cd /root/open/AeroNyx
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. 预览每个待删除项目

逐行检查 dry-run。真正删除必须使用 root 并明确传入 --yes；status 与 upgrade 不会暗中触发清理。

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --dry-run

3. 执行已确认的清理

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --yes

如果使用自定义 build root，请在三个命令中都导出 AERONYX_BUILD_TARGET_ROOT，确保盘点与清理解析同一个隔离 target 布局。

保留范围与可删除范围

  • 受保护: 命令保留正在使用的 target/release/aeronyx-server、当前固定工具链/服务缓存、其他 release 可执行文件与回滚产物、/var/lib/aeronyx 协议数据、/etc/aeronyx 身份/配置，以及同机其他服务的缓存。
  • 可重新生成: 只删除明确可重建的 Cargo 产物，例如旧 debug/跨目标目录、deps、build、.fingerprint、incremental、.rlib、.rmeta、.d，以及同一服务的旧工具链 target。
  • 执行保护: 删除前会取得与 install/upgrade 相同的部署锁，并验证 systemd MainPID 指向受保护 binary；清理前后都会计算 hash，任何变化都会失败。

维护后验证

缓存清理不会重启节点，也不要求排空活跃会话。完成后检查服务健康、启动就绪、发现 quorum 与双跳证明新鲜度。

bash
./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

生产验证证据 — 2026 年 7 月 26 日

一次受控生产执行回收 50,649,768 KiB，文件系统使用率从 90% 降至 65%。受保护 binary SHA-256、MainPID 与重启次数均未变化；启动检查保持零失败，双跳证明保持 ready/stable。

隐私边界: 盘点只输出本地路径、大小、工具链版本、binary hash 与聚合容量；不会读取或打印密文 payload、MemChain 记录、密钥、节点身份、路由、客户端地址、DNS、目的地或社交图谱。

<!-- build-cache-maintenance-v1:end --> <!-- memchain-llm-provider-operations-v1:start -->

可选认知 worker 服务商运维

SuperNode 认知 worker 是可选功能，默认关闭。只应在信任角色明确的处理节点上启用。

最小本地服务商配置

toml
[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://127.0.0.1:11434/v1"
api_key = ""
model = "llama3.2"
max_tokens = 1000
temperature = 0.3

[memchain.supernode.routing]
fallback = "local-ollama"

[memchain.supernode.privacy]
default_level = "structured"
allow_full_for = []

也支持 api_key = "$ENV_VAR"。不要把秘密写入已提交的配置。

OpenAI 兼容 endpoint 写法

以下三种写法都会解析到同一个 Chat Completions endpoint：

  • https://provider.example
  • https://provider.example/v1
  • https://provider.example/v1/chat/completions

当 type = "anthropic" 时可省略 api_base；当前 runtime 使用 Anthropic 官方 Messages endpoint。

失败与资源行为

  • 模型成功响应在 JSON 解析前限制为 8 MiB；非成功诊断响应限制为 64 KiB。
  • 传输、API、解析及空响应失败会让该服务商进入 30 秒单调时钟冷却，而不是永久禁用。
  • HTTP 429 的 Retry-After 会在 1-300 秒范围内执行；缺失时使用 30 秒。
  • 路由器可以切换到其他健康服务商，并在冷却结束后自动重新考虑失败服务商，不需要定时任务。

重启前执行 aeronyx-server validate -c /etc/aeronyx/server.toml。本文行为已进入当前 main 源码；已安装节点必须重新构建或升级到包含该变更的版本。

隐私边界：存储和 relay 节点仍是节点盲的。启用的认知 worker 与外部服务商会看到配置隐私级别允许的 prompt。保持 default_level = "structured"；除非已取得处理完整内容的明确同意，否则 allow_full_for 应为空。

<!-- memchain-llm-provider-operations-v1:end -->