節點探索與加密多跳中繼

AeroNyx 節點透過經簽署且會到期的描述元彼此發現，並能逐跳轉送端對端加密的酬載，每個中繼只會移除屬於自己的那一層加密。目前，真實使用者的聊天預設經由 AeroNyx 中央中繼（RelayWS）傳送。透過節點路由聊天，是應用程式中需選擇加入的設定。

目前運作中的功能

中心化與去中心化路徑並行運作。

探索如何運作

每個節點都會發布一份以其 Ed25519 身分金鑰簽署的描述元。描述元包含節點 ID、核發與到期時間、選用的公開端點、功能旗標（例如洋蔥中間中繼或聊天中繼）、概略的容量提示，以及用於洋蔥加密的金鑰。節點會拒絕已到期或簽章無效的描述元。

• Gossip 有邊界。 對等節點交換受到速率限制與政策管控，訊息也有大小限制。
• 重新啟動復原。 節點會保留本機對等節點快取，並在重新啟動後退回使用已設定的種子端點。營運者也可以釘選種子。
• 路由選擇。 只有具備可用端點與洋蔥金鑰的新鮮描述元，才會被視為中繼候選。

描述元可以指定哪些端點

簽章能證明是誰發布了描述元，但無法證明其端點可以安全連線。因此，節點只接受兩種形式的端點：

• 透過 http 或 https 的公用 IP 位址；迴路、私人、鏈路本機、CGNAT、文件用、多點傳送與保留範圍都會被拒絕；
• 使用公開 DNS 名稱的 https:// URL。單一標籤名稱、localhost，以及 .local、.internal 與 .home.arpa 等私人尾碼都會被拒絕。

主機名稱會在連線時透過會捨棄所有非公開位址的解析器進行解析，因此名稱無法被指向節點本身、私人網路或雲端中繼資料服務。對等節點用戶端也會忽略代理設定，且絕不跟隨重新導向。

主機名稱形式的存在，是為了讓本身沒有 IP 位址的節點（例如位於雲端閘道後方的 TEE 節點）也能參與。

釘選的種子

若節點啟動時沒有營運者提供的快照，它只會信任自己已持有的身分，因此最後可能只信任它自己。針對這種情況，營運者可以指定某個位址上預期的身分：

[discovery]
pinned_seeds = ["<64-hex node id>@<public ip>:<port>"]

• 被釘選的身分，只有在透過釘選至該身分的身分綁定 TLS 完成一次交換之後，才會首次被接受。
• 被釘選身分之後的每一份描述元，無論來源為何，都必須維持釘選的位址，並宣告支援身分綁定 TLS。
• 信任不會傳遞：種子回應中的其他描述元仍然只是不受信任的候選。
• 被移除的釘選項目無法從舊快取或備份中恢復。

Directory Chain

每個節點也會保留一份經簽署、以雜湊連結的自身描述元事件歷史，稱為其 Directory Chain。其他節點可以鏡像該歷史、擷取描述元物件，並針對特定描述元請求包含證明。由營運者釘選的對等節點可以針對其所見的歷史簽署觀察檢查點。

沒有全域帳本，也沒有單一協調者：每個節點簽署自己的歷史，其他節點則鏡像並檢查它。

身分綁定 TLS

透過 HTTPS 連線到節點通常需要網域名稱，以及由憑證授權單位核發的憑證，而大多數 AeroNyx 節點只能透過 IP 位址連線。因此，節點改以自己的 Ed25519 身分來證明其 HTTPS 端點。

• 運作方式。 節點會建立一個一般的 ECDSA P-256 TLS 金鑰與一份自簽憑證。憑證的某個主體別名帶有一筆綁定資訊 aeronyx-tls-binding:v1:<node id>:<expiry>:<signature>，其中的簽章由節點身分金鑰對一份帶有網域分隔的摘要產生，該摘要涵蓋憑證本身的公開金鑰、節點 ID 與到期時間。TLS 1.3 握手證明節點持有憑證金鑰。身分金鑰絕不對握手簽署。
• 用戶端檢查什麼。 驗證方只會為其原本要連線的節點接受憑證：恰好一筆綁定資訊、節點 ID 與預期相符、未到期、剩餘有效期最多 31 天，並且對本憑證的金鑰具有有效簽章。由憑證授權單位核發的憑證無法通過這項檢查。
• 同一個連接埠。 公開 API 連接埠（8422/TCP）同時提供兩種服務：以 TLS 握手開頭的連線會得到 TLS，其他連線則照舊得到明文 HTTP。此功能預設開啟（discovery.public_api_identity_tls）。
• 節點之間。 經簽署的描述元宣告了協定特性 anpf1-ibt1 的節點會提供身分綁定 TLS。看到該特性的對等節點必須透過釘選至該節點身分的 TLS 連線，絕不會退回明文 HTTP。該特性受描述元簽章保護，因此網路攻擊者無法將其移除以強制降級。若有多個身分宣稱使用同一個端點，就不會產生 TLS 位址，請求會以失敗收場。沒有該特性的舊節點，以及使用 DNS 名稱的閘道端點，則維持原有行為。
• 參考。 原始碼與固定的測試向量：aeronyx-node-tls。

其效果是，節點之間的洋蔥跳點路由資訊、gossip、目錄同步與見證流量，不再能在線路上被讀取。應用程式端以這種方式連線至節點的支援開發中。

多跳中繼如何運作

1. 傳送者使用每個中繼公布的洋蔥金鑰，為每一跳將酬載包上一層加密。
2. 每個中繼會檢查前一跳的簽章、時間戳記與重放狀態，移除自己的那一層，並轉送剩下的不透明資料塊。它絕不會看到內層。
3. 最後（終端）節點會將訊息交接給接收者的中繼收件匣（預設為中央中繼），並且只有在該中繼接受之後，才回傳經簽署的回執。回執綁定了路由 ID、對酬載的承諾、終端節點的身分以及遞送時間。它證明的是訊息已被接受進入中繼保管，而不是接收者已讀取。關閉交接功能的節點會把訊息保留在自己的儲存空間中，並簽署同類的回執，因此僅憑回執無法區分這兩種情況。

各方能看到什麼

沒有任何單一節點能把您的網路位址與您正在寫信給誰連結起來。終端節點與中央中繼都看得到誰寫信給誰。

協定最多接受三個經驗證的中繼跳點。應用程式的隱私路由使用兩個。中繼的濫用限制說明請參閱 盲中繼濫用防護。

應用程式中的聊天

• 預設：訊息經由中央 RelayWS 服務傳送。訊息內容為端對端加密，但該服務會處理遞送中繼資料。請參閱 聊天中繼用戶端整合。
• 隱私路由（需選擇加入，預設關閉）：開啟且路由就緒時，應用程式會優先透過兩跳洋蔥路由傳送一對一訊息。若沒有任何洋蔥路由接受該訊息，應用程式會將其保留在裝置上；除非您針對該則訊息予以核准，否則不會改用標準中繼。
• 匿名信箱（Beta）：一個獨立的投遞功能，僅在連線至隱私網路期間運作。一般對話不使用它。

匿名信箱拉取大小

過去，無論項目大小，一次信箱拉取結果都是一個固定的 163,130 位元組的映像，因此一則短訊息就要產生約 160 KiB 的回應。拉取版本 2 透過經簽署的協定特性 anpf1-ampc1 協商，會把密封項目填補到五個大小級別中最小的那一級（4,204、16,492、65,644 或 131,180 位元組，或編解碼器允許的上限）。現在，一個 4,096 位元組的項目會以 4,518 位元組傳送。

TEE 節點

有一個正式環境節點在 Phala Cloud 的可信執行環境（Intel TDX 上的 dstack）中執行。它只擔任匿名信箱與洋蔥中繼：其 VPN 已停用、MemChain 已關閉，而其身分金鑰來自 dstack 金鑰服務。它只能透過閘道上的 TLS 主機名稱連線，這也是加入主機名稱端點的原因。應用程式目前不會驗證該節點的 TEE 證明。

即時狀態

彙總網路狀態公布於：

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

中繼與探索的彙總資料位於 data.protocol_status 底下，例如 peer_store.blind_relay 與 peer_store.peer_quorum。閱讀時請注意兩點：

• 節點層級的彙總資料只計算最近 120 秒內有心跳的節點，因此離線節點會從 protocol_status.reported_nodes 等計數中移除。network.total_nodes 與 network.vpn_nodes 仍會計算已註冊的作用中節點，無論是否上線。
• 合成探測計數器（probe_*、two_hop_probe_*）衡量的是路徑健康狀態。它們不是使用者流量。

公開回應只包含計數、狀態分組與時間戳記。它絕不包含節點 ID、端點、路由 ID、酬載、接收者、用戶端 IP 位址、DNS 資料或社交圖譜關係。請參閱 網路統計與隱私邊界。

常見問題

我的 AeroNyx 聊天訊息會經過去中心化節點嗎？

預設不會。訊息經由中央 RelayWS 服務傳送。您可以在應用程式中開啟隱私路由，在路由就緒時透過經由節點的兩跳洋蔥路由傳送一對一訊息。若沒有任何路由接受某則訊息，應用程式會保留該訊息，直到有可用路由，或您核准透過標準中繼傳送該則訊息。

中繼節點能讀取它所轉送的訊息嗎？

不能。中繼只會移除自己的那一層加密，並轉送不透明的資料塊。訊息內容在對話參與者之間也是端對端加密的。

什麼是 Directory Chain？

Directory Chain 是每個節點自身經簽署、以雜湊連結的描述元歷史。其他節點會鏡像它，並可請求包含證明。它沒有全域協調者。

位於閘道後方的節點如何加入網路？

它可以發布一個 https:// 主機名稱作為其端點。其他節點會在連線時解析該名稱，且只使用公開位址，因此該名稱無法被重新導向至私人或內部目標。

為什麼公開統計頁面顯示的已註冊節點數比線上節點還多？

network.total_nodes 與 network.vpn_nodes 計算的是已註冊的作用中節點，無論是否上線。請與 network.online_vpn_nodes 比較。協定與轉發計數只包含心跳新鮮的節點。

節點的 HTTPS 需要網域名稱或憑證授權單位嗎？

不需要。節點可以用自己的身分金鑰證明其 HTTPS 端點：其 TLS 憑證帶有節點身分對憑證金鑰所做的簽章，知道節點 ID 的用戶端或對等節點即可驗證。位於閘道後方的節點仍然可以改用 https:// 主機名稱。

經簽署的遞送回執證明了什麼？

它證明終端節點已將訊息接受進入中繼保管，實際上就是接收者的中繼收件匣。它不能證明接收者已經看到或讀過該訊息。如需此類證明，請使用聊天協定的送達回執與已讀回執。