盲中继滥用防护

盲中继滥用防护是 AeroNyx 节点在为其他节点转发加密中继流量之前所施加的一组限制。它仅凭已签名的路由元数据和本地计数器来遏制滥用或不稳定的节点。它从不解析密文、保留路由历史，也从不暴露谁在与谁通信。

范围

盲节点规则

中继可以认证路由元数据、执行有边界的策略、转发不透明信封并返回签名回执。它绝不能检查载荷，也绝不能暴露可用于重建路由、用户身份或关系的元数据。具体而言，中继不会记录或暴露：

• 消息、数据包、媒体或记忆的明文
• DNS 查询、目的地、域名、URL 或浏览历史
• 路由 ID、完整路径、端点 URL 或客户端 IP 地址
• 完整公钥、接收方身份、消息 ID 或社交图谱关系
• 私钥、凭证秘密、钱包级流量或解密材料

准入流水线

每个请求在能够使用转发容量之前都要通过以下检查。第 1 至 6 步按此顺序执行。在第 7 步中，发往本节点的请求会进入其自身的终端或洋葱处理流程，而发往其他节点的请求则会在解析出下一跳之后进行预留。

1. request gate: process-wide admission window and in-flight limit (64 requests)
2. crypto admission: a free slot for signature and onion work, or Backpressure
3. authenticate the signed previous hop and envelope
4. previous-hop rate limit and quarantine check
5. envelope metadata: size, age and future-skew limits
6. self-loop check
7. route loop, TTL and next-hop descriptor checks, plus the route replay reservation
8. forward the opaque ciphertext, or peel the terminal layer and deliver

每项决策都基于已签名的路由元数据和本地汇总状态，从不基于解密后的内容。

运行时限制

以下是节点源代码中的当前默认值。它们是运行参数，而非永久性的协议承诺。

上一跳速率限制与隔离

速率限制以上一跳的签名身份为键。同一个上一跳在 60 秒内发送超过 120 个请求，就会对该跳启动为期五分钟的本地隔离。另有一个独立的失败计分，在五分钟内出现 12 次计分失败后也会启动同样的隔离。只有以下原因会计入分数：

invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted

传输超时、确认丢失、重复重试和重放冲突不会增加分数，因此健康的节点不会因网络问题而被隔离。桶存储有上限，空闲的桶会被逐出，因此该防护机制不会演变为长期的通信图谱。

路由重放与重试

每个中继请求都携带一个路由 ID。当节点的聊天中继存储启用时（[memchain.chat_relay] enabled = true），路由预留和已完成的响应会保存在其 SQLite 数据库中，因此重放保护在重启后仍然有效。否则，节点使用具有相同容量和时间窗口的内存注册表。如果全部 8192 个槽位都被活跃路由占用，新路由会以 replay_capacity 被拒绝，直到有槽位过期。

重复的路由 ID 有以下四种结果之一：

最后一种结果适用于持久化存储。签名回执只有作为新鲜证据时才有效，因此节点不会在 120 秒后重放回执。

当向下一跳转发因超时、连接错误或请求错误而失败时，节点最多总共尝试三次。每次重试前的短暂延迟由路由 ID、下一跳和尝试次数推导得出。下游节点报告为明确拒绝的失败不会重试。

加密运算准入（运营者容量说明）

签名检查、洋葱剥层和回执签名都是 CPU 密集型操作，因此每个节点进程都会对其加以限制：

• 槽位总数： 主机报告的 CPU 线程数的一半，向上取整，最少 4 个，最多 8 个，因此即使只有一两个线程的主机也有 4 个槽位。
• 入站请求： 比总数少一个槽位，以确保出站路由创建和回执完成始终能够推进。因此在最小的主机上，入站请求也有 3 个槽位。
• 所有槽位都繁忙时： 请求会立即以 HTTP 429 和 backpressure 原因被拒绝。它不会在队列中等待。

因此，在小型主机上，中继在突发流量下会较早地卸载负载。backpressure_dropped 计数器不断上升，意味着节点需要更多 CPU 或更少的中继流量。

汇总运行时计数器

节点在其心跳中上报粗粒度的累计计数器和新鲜度时间戳，位于：

system_stats.discovery_status.peer_store.runtime.blind_relay
system_stats.discovery_status.peer_store.blind_relay_quality
system_stats.discovery_status.peer_store.peer_health_summary

这些计数器描述的是节点运行情况。它们不是消息日志或计费数据，也不能证明任何特定对话曾经发生。

证据质量

质量摘要将四类证据区分开来：已接受的不透明中继工作、合成可达性探测、合成两跳探测，以及针对客户端发起的投递的终端签名回执。real_relay_ready 要求有一份新鲜且经过认证的客户端投递回执。合成证据从不会被报告为用户流量。

proof_scope 指明所见到的最强证据：client_message_delivery、relay_acceptance、message_delivery、control_plane、single_hop_control_plane、attempted 或 none。

不暴露流量关系的节点健康状态

peer_health_summary 让运营者能够找出出现故障或被隔离的节点，而无需看到谁在与谁通信。

包含： 缩短的节点 ID 前缀、粗粒度的健康和描述符状态、gossip 和路由成功的新鲜度、路由成功和失败的汇总计数、隔离状态、剩余时间以及粗粒度的原因分桶。

从不包含： 完整的节点公钥、路由 ID、端点列表、加密数据块或载荷哈希、消息 ID、接收方身份、客户端 IP 地址、目的地、DNS 数据或社交图谱关系。

源代码索引

节点软件以 AGPL-3.0 许可在 github.com/AeroNyxNetwork/AeroNyx 开源。路由的构建方式请参阅 节点发现与加密多跳中继。

常见问题

中继节点能读取或记录它转发的流量吗？

不能。中继检查已签名的路由元数据并转发不透明信封。它只保留汇总计数器，从不保留载荷、路由历史或接收方身份。

当节点重试同一路由时会发生什么？

如果首次尝试已完成，节点会重放其已存储的响应，不会再次投递任何内容。如果首次尝试仍在进行，节点会返回可重试的 route_in_flight。同一路由 ID 下的不同请求会以 replay_conflict 被拒绝。

重放保护在节点重启后仍然有效吗？

是的，前提是节点的聊天中继存储已启用。此时路由预留和已完成的响应会保存在 SQLite 中。如果没有该存储，节点会使用重启时即被清空的内存注册表。

为什么某个节点会被隔离？

节点在 60 秒内发送超过 120 个请求，或在五分钟内出现 12 次计分的校验失败后，会被隔离五分钟。超时、确认丢失和重复重试不计为失败。

为什么我的节点在负载下会返回 backpressure？

因为其所有中继加密运算槽位都处于繁忙状态。节点为签名和洋葱运算分配约为其 CPU 线程数一半的槽位（最少 4 个，最多 8 个），并会立即拒绝超出的请求，而不是将其排队。