Nostr 協議架構深度解析：中繼器設計、客戶端實現、密碼學基礎與比特幣整合實踐

摘要

Nostr（Notes and Other Stuff Transmitted by Relays）是一個由比特幣開發者 fiatjaf 設計的去中心化社交協議，其核心理念是構建一個抗審查、無需許可的開放社交網路。本篇文章深入剖析 Nostr 協議的技術架構，涵蓋中繼器（Relay）網路設計與類型、客戶端實現與用戶體驗、事件模型與 NIP 協議規範、密碼學安全機制、隱私保護策略，以及 Nostr 與比特幣生態系統的深度整合。作為比特幣愛好者的首選社交協議，Nostr 在隱私保護與抗審查特性上的設計值得深入研究。本文旨在為比特幣開發者、密碼朋克與社交媒體研究者提供全面的技術參考。

1. Nostr 協議概述與設計理念

1.1 為什麼需要 Nostr

傳統社群媒體平台（如 Twitter、Facebook、Instagram）存在諸多根本性問題：

中心化控制：

平台運營商可以單方面刪除內容、停用帳戶、決定演算法推薦。用戶的粉絲、內容與社交關係完全依賴於平台的善意。

審查風險：

政治敏感話題、批評性言論、邊緣群體的聲音常常遭受平台審查。在某些國家，平台配合政府要求進一步限制了言論自由。

資料所有權缺失：

用戶的社交數據、互動記錄、創意內容被平台據為己有，用於廣告變現，而創作者往往得不到合理補償。

鎖定效應：

用戶難以遷移到其他平台，因為社交關係網路綁定在特定平台上。

Nostr 的設計目標是解決上述問題，創建一個：

• 無需許可（Permissionless）：任何人都可以創建帳戶、部署中繼器、構建客戶端
• 抗審查（Censorship-resistant）：沒有單一實體可以刪除內容或封禁用戶
• 用戶自主（Self-sovereign）：用戶控制自己的身份、內容與社交關係
• 可遷移（Portable）：社交身份與關係可跨客戶端、跨中繼器遷移

1.2 協議設計哲學

Nostr 的設計極度簡潔，這是其成功的關鍵因素之一。協議核心只有兩個角色：

1. 客戶端（Client）：用戶使用的軟體，用於簽署事件、發送至中繼器、讀取來自中繼器的事件
2. 中繼器（Relay）：輕量級伺服器，儲存與分發事件，不執行任何驗證邏輯

中繼器之間不通信，客戶端同時連接多個中繼器。這種「星型拓撲」結構極度簡單，避免了分布式系統中的複雜共識問題。

簡潔性的代價：

• 中繼器是潛在的隱私洩露點（見下文分析）
• 沒有內建的內容審核機制，可能承載垃圾訊息
• 沒有內建的激勵機制，中繼器運營成本由運營商自行承擔

1.3 與其他去中心化社交協議的比較

Nostr 在「簡潔性」與「抗審查性」之間取得了良好平衡，使其成為比特幣社群等技術社群的首選。

2. 密碼學基礎：公鑰作為身份

2.1 身份模型

Nostr 的身份系統極度創新：用戶的公鑰（Public Key）就是其帳戶身份，私鑰（Private Key）控制帳戶的完全訪問權。

為什麼使用橢圓曲線密碼學：

Nostr 採用 Secp256k1 橢圓曲線（與比特幣相同），這使得：

• 比特幣用戶可以直接使用其比特幣錢包作為 Nostr 身份
• 密碼學安全性經過比特幣網路多年運行驗證
• 客戶端與錢包軟體生態可直接復用

公鑰格式：

Nostr 使用 Bech32 編碼格式（如 npub1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3q4htwa2x5kg7f9qqgrah5），與比特幣的 bc1 地址同源的編碼方式。

私鑰管理：

用戶的 Nostr 私鑰應當被視為最高安全等級的秘密。丟失私鑰意味著永久失去帳戶訪問權，洩露私鑰則帳戶完全被盜。

2.2 簽名機制

Nostr 事件使用 ECDSA 簽名（Secp256k1）進行身份驗證。每個事件包含一個簽名字段，客戶端與中繼器可驗證事件確實由公鑰對應的私鑰簽署。

事件簽名格式：

{
  "id": "<32-byte lowercase hex-encoded sha256 of the serialized event data>",
  "pubkey": "<32-byte lowercase hex-encoded public key>",
  "created_at": 1234567890,
  "kind": 1,
  "tags": [],
  "content": "Hello, Nostr!",
  "sig": "<64-byte lowercase hex-encoded signature>"
}

簽名驗證流程：

1. 提取事件中的 pubkey 與 sig
2. 移除 sig 欄位，重新計算事件內容的 SHA-256
3. 使用 pubkey 驗證簽名有效性

2.3 委託機制（NIP-26）

NIP-26 定義了委託（Delegation）機制，允許用戶將部分發布權限委託給其他公鑰，而不洩露完整私鑰。

委託用途：

• 用戶 A 委託給服務 B，使其可以代替 A 發布內容
• 應用場景：第三方客戶端服務、多設備同步、團隊帳戶

委託實現：

委託者創建一個特殊事件，聲明對另一公鑰的委託授權，包含委託的有效期與權限範圍。

3. 事件模型與資料結構

3.1 事件類型（Kind）

Nostr 事件是目前已知宇宙中最豐富多彩的資料結構之一。以下是主要的事件類型：

Kind 0：元數據（Metadata）

{
  "kind": 0,
  "content": "{\"name\": \"Alice\", \"about\": \"Bitcoin maximalist\", \"picture\": \"https://...\"}",
  "tags": []
}

用於發布用戶的個人資料資訊，如暱稱、自我介紹、頭像 URL。

Kind 1：文字筆記（Text Note）

{
  "kind": 1,
  "content": "This is my first Nostr post!",
  "tags": []
}

這是 Nostr 上最基本、最常見的事件類型，相當於 Twitter 的推文。

Kind 2-3：聯繫人列表（Contact List）

{
  "kind": 3,
  "content": "",
  "tags": [["p", "<pubkey1>", "wss://relay1/", "alice"], ["p", "<pubkey2>"]]
}

用於發布關注列表（Following），客戶端據此構建社交圖譜。

Kind 4：加密直接訊息（Encrypted DM）

{
  "kind": 4,
  "content": "<encrypted payload using recipient's pubkey>",
  "tags": [["p", "<recipient pubkey>"]]
}

用於點對點加密訊息，只有接收方可以解密閱讀。

Kind 6-7：通用意義替換（Generic Replaceable Events）

Kind 6：用於替換 Kind 7 的文章

Kind 7：用於替換 Twitter 推文的長文章（Kind 30023 等）

Kind 8：反應（Reaction）

{
  "kind": 8,
  "content": "+",
  "tags": [["e", "<event-id>"]]
}

對特定事件表示喜歡（"+"）或踩（"-"）。

Kind 9734-9735：Zap（閃電支付打賞）

Kind 9734：Zap 請求

Kind 9735：Zap 收據

Kind 30023：長文章（Long Form Content）

用於發布長篇幅文章（如部落格文章），支援 Markdown 格式。

3.2 標籤系統（Tags）

Nostr 事件的靈活性很大程度來自其標籤系統。標籤以二維陣列形式存在，每個標籤包含標籤類型與相關參數：

3.3 可替換事件（Replaceable Events）

可替換事件是 Nostr 的一個重要特性。Kind 編號大於 10000 的事件被視為「可替換」，同一用戶的同類事件僅保留最新的一個。

典型應用：

• Kind 0：元數據替換（用戶更新個人資料）
• Kind 3：關注列表替換
• Kind 30023：長文章更新

d 標籤：

可替換事件可包含 d 標籤（"d" for "directory"），用於區分同一用戶的多個可替換事件：

{
  "kind": 30023,
  "tags": [["d", "my-blog-post-1"]],
  "content": "..."
}

4. 中繼器（Relay）深度分析

4.1 中繼器角色與功能

中繼器是 Nostr 網路的基礎設施，其功能極度簡單：

• 儲存：接收並儲存客戶端發來的事件
• 分發：向訂閱了相關事件篩選條件的客戶端分發事件
• 不驗證：中繼器不驗證簽名、不執行業務邏輯

這種「啞管道」（Dumb Pipe）設計使得中繼器的實現極度簡單，可以用任何語言、任何平台快速開發。

4.2 中繼器類型

公共中繼器：

開放給所有人使用的中繼器。著名公共中繼器包括：

• wss://relay.damus.io
• wss://nos.lol
• wss://relay.nostr.band
• wss://inbox.nostr.com

公共中繼器通常由個人或組織志願運營，沒有收入來源。

付費中繼器：

要求用戶支付比特幣或法定貨幣才能使用的訂閱制中繼器。付費中繼器通常提供：

• 更高的可用性與效能保障
• 更好的隱私保護
• 反垃圾內容機制
• 客戶端支援（如特製功能）

特異化中繼器：

專門服務特定用途或社群的中繼器，如：

• 比特幣愛好者專用中繼器
• 特定國家/語言社群中繼器
• 僅儲存 Kind 30023（長文章）的中繼器

個人中繼器：

用戶自行部署的中繼器，僅服務自己與指定的對象。這種中繼器提供了最高程度的隱私保護。

4.3 中繼器費用模型

中繼器運營涉及伺服器成本與頻寬成本，以下是常見的費用模式：

免費模式：

依靠志願者、慈善組織或平台引流需求支持。這是最常見的早期模式。

比特幣閃電網路付費：

用戶透過閃電網路向中繼器支付微額費用。這種模式的優勢是：

• 即時、全球化、隱私化的支付
• 比特幣愛好者天然接受
• 可實現按使用量付費

訂閱制：

用戶每月支付固定費用（如 $5/月）換取中繼器服務。

POW 驗證：

用戶需要執行一定量的工作量證明（Proof of Work）才能發布，阻止垃圾訊息。

4.4 中繼器連接策略

客戶端連接中繼器的策略會顯著影響用戶體驗與隱私：

廣泛連接：

連接 10-20 個公共中繼器，最大化內容覆蓋，但隱私較差（中繼器可觀察用戶的完整社交圖譜）。

精選連接：

只連接 3-5 個可信中繼器，提供更好的隱私，但可能遺漏部分內容。

Tor/隱私網路連接：

透過 Tor 洋蔥路由連接中繼器，隱藏 IP 地址，增強隱私。

5. 隱私保護機制深度解析

5.1 威脅模型分析

Nostr 的隱私威脅主要來自以下幾個方面：

中繼器觀察：

中繼器可以看到事件的完整內容、發布者的 IP 地址、以及訂閱篩選條件。惡意中繼器可以：

• 建立用戶的社交圖譜
• 追蹤用戶關注的話題
• 識別內容與帳戶之間的關聯

客戶端追蹤：

客戶端可能記錄用戶的活動、用戶設備指紋、並回傳至第三方伺服器。

元資料洩露：

即使內容加密，元資料（發布時間、接收者標籤、事件大小）也可能洩露敏感資訊。

5.2 NIP-04 加密直接訊息

NIP-04 定義了 Nostr 上的點對點加密訊息機制：

加密流程：

1. 發送方使用接收方公鑰加密訊息內容
2. 加密後的 payload 作為事件內容發布到中繼器
3. 接收方讀取事件，解密後獲得原始訊息

加密算法：

NIP-04 使用 ECDH（Elliptic Curve Diffie-Hellman）金鑰交換，結合 AES-256-CTR 對稱加密。

缺陷與 NIP-04 的替代方案：

原始 NIP-04 存在一些密碼學設計缺陷（如缺少訊息完整性保護）。後續提出了 NIP-44 作為更安全的替代方案。

5.3 NIP-44 安全訊息標準

NIP-44 是 NIP-04 的安全改進版本，主要改進包括：

更強的金鑰派生：

使用 HKDF（HMAC-based Key Derivation Function）從 ECDH 共享金鑰派生加密金鑰。

訊息完整性保護：

包含 HMAC 標籤，防止內容篡改。

前向安全：

支援金鑰輪換，減少單一金鑰洩露的影響。

大小混淆：

加密 payload 包含隨機填充，防止大小分析攻擊。

5.4 Tor 整合與洋蔥路由

比特幣社群重視 Tor 整合，Nostr 客戶端同樣支援透過 Tor 連接中繼器：

連接方式：

// 客戶端配置使用 Tor 代理
{
  relayUrls: [
    'wss://relay.example.onion'  // 洋蔥地址
  ],
  proxy: 'socks5://127.0.0.1:9050'  // Tor 代理
}

隱私收益：

• IP 地址對中繼器隱藏
• 網路監視者難以建立連接圖譜
• 跨中繼器的關聯分析變得困難

局限性：

• Tor 網路本身可能被監視
• 某些 Tor 出口節點可能記錄流量
• Tor 使用體驗通常比明網慢

5.5 隱私最佳實踐

1. 使用專用 Nostr 密鑰：避免將比特幣主錢包用於 Nostr
2. 多個身份分離：使用不同密鑰處理不同社群
3. 中繼器選擇：優先使用可信的、Tor 托管的中繼器
4. 內容加密：敏感內容使用 NIP-44 加密
5. 避免 IP 指紋：使用 VPN 或 Tor 隱藏真實 IP

6. Nostr 與比特幣深度整合

6.1 閃電打賞（Zap）

Zap 是 Nostr 最具比特幣特色的功能，允許用戶向內容創作者進行比特幣閃電網路微支付打賞。

Zap 工作流程：

1. 接收方在個人資料中設定閃電地址（Lightning Address，如 alice@bitcoinplebs.com）
2. 發送方點擊 Zap 按鈕，客戶端生成 Zap 請求事件
3. 客戶端使用 LNURL 協議向接收方的閃電地址發起支付請求
4. 支付完成後，發送方客戶端發布 Zap 收據事件（Kind 9735）
5. 接收方客戶端監聽 Zap 收據，通知接收方

Kind 9734 vs Kind 9735：

• Kind 9734：Zap 請求，由發送方發布
• Kind 9735：Zap 收據，由接收方發布，標記 Zap 完成

Zap 的經濟意義：

Zap 為內容創作者提供了一種去中心化、即時、全球化的收入方式，打破了平台對廣告收入和付費訂閱的壟斷。

6.2 Lightning Address 整合

Lightning Address 是一種類似於 Email 地址的閃電支付識別符：

格式：username@domain.com

解析流程：

1. 付款方輸入 Lightning Address
2. 客戶端向 https://domain.com/.well-known/lnurlp/username 發起 HTTP 請求
3. 伺服器返回付款上限與 Invoice 生成 URL
4. 客戶端生成 Invoice，完成支付

Nostr 應用：

大多數 Nostr 客戶端支援在用戶資料中設定 Lightning Address，粉絲可以直接向該地址支付，或透過 Zap 功能在 Nostr 內直接打賞。

6.3 比特幣錢包直接登入

比特幣友善的 Nostr 客戶端支援直接使用比特幣錢包登入：

Alby 瀏覽器擴充：

Alby 是一款專為比特幣設計的瀏覽器錢包，內建 Nostr 支援。用戶可以直接使用 Alby 中管理的比特幣密鑰作為 Nostr 身份，無需額外創建 Nostr 專用密鑰。

流程：

1. 用戶安裝 Alby 擴充
2. 在支援的 Nostr 客戶端中選擇「使用 Alby 登入」
3. Alby 彈窗確認，用戶同意使用其公鑰
4. 客戶端使用 Alby 的私鑰進行事件簽署

安全性：

• 用戶的比特幣私鑰不會離開 Alby錢包
• 每次簽署都需要用戶明確確認
• 可設置多簽或硬體錢包整合

6.4 NWC 與閃電網路隱私

NWC（NIP-47 Wallet Connect）是 Nostr 的一個重要協議，定義了客戶端如何代表用戶與閃電網路節點交互：

使用場景：

• 第三方 Nostr 客戶端可以透過 NWC 發起 Zap
• 不用將完整的閃電節點訪問權限授予客戶端

工作流程：

1. 用戶在 Alby 等錢包中創建 NWC 連線，獲得連線 URI
2. 第三方客戶端使用 URI 建立連線
3. 客戶端發起的支付請求由用戶錢包確認與執行

6.5 比特幣原生的聲譽系統

比特幣在鏈上累積的經濟歷史可以用於 Nostr 的聲譽系統：

閃電網路節點聲譽：

在 Nostr 上運行閃電節點的用戶，其節點的比特幣年齡、Liquidity、可靠性等指標可以作為聲譽參考。

Ordinals 收藏與活動：

用戶持有的 Ordinals NFT、BRC-20 代幣可以展示其比特幣文化參與度。

閃電網路支付記錄：

透過 Zap 累計收到的比特幣數量可以作為內容價值的市場信號。

7. 客戶端實現深度解析

7.1 Damus

Damus 是最早一批 Nostr 客戶端之一，以其功能完整性和比特幣友好特性聞名：

主要功能：

• 即時通訊（Kind 1 帖子）
• 私訊（Kind 4 加密 DM）
• Zap 打賞（Kind 9734/9735）
• 個人資料管理
• 客戶端內建比特幣閃電錢包

平台支援：

• iOS（App Store）
• Android（Google Play）

7.2 Snort

Snort 是一款輕量級的 Web 客戶端，強調速度與簡潔性：

設計特點：

• 完全基於 Web，無需安裝
• 快速加載，適合低頻寬環境
• 可部署為自架實例

功能：

• 即時通訊
• Zap
• Lightning Address 支援

7.3 Amethyst

Amethyst 是 Android 平台的功能最完整的 Nostr 客戶端之一：

主要功能：

• 完整的 Kind 支援
• 視覺化關注圖譜
• NIP-04/44 加密私訊
• Zap 打賞
• 多帳戶管理

7.4 Iris

Iris 是一款強調社交圖譜可視化的 Nostr 客戶端：

特色功能：

• 社交圖譜視覺化
• 話題追蹤
• 多中繼器管理

7.5 客戶端開發者工具

nostr-tools：

JavaScript/TypeScript 開發套件，支援 Nostr 事件的創建、驗證、發布。

nostr-hooks：

React Hooks 庫，簡化 Nostr 客戶端的 React 開發。

nostr-sdk：

Rust 語言 SDK，支援後端服務開發。

8. NIP 協議標準全景

NIP（NIPs = Nostr Implementation Possibilities）是 Nostr 協議的改進提案系統。以下是主要 NIP 的概覽：

9. Nostr 生態系統數據（2025-2026）

9.1 網路規模統計

9.2 生態亮點項目

Damus：

iOS/Android 客戶端，下載量超過 100 萬次，Bitcoiners 首選社交 App。

Highlighter：

比特幣教育內容平台，基於 Nostr 構建。

Zap.stream：

比特幣直播平台，結合 Nostr 與閃電支付。

Nostr.build：

Nostr 內容聚合器，展示創意內容。

Nsec Bunker：

NIP-46 遠程簽署服務，提供安全的密鑰管理。

10. 未來發展方向

10.1 技術改進方向

更安全的加密訊息：

NIP-44 作為 NIP-04 的替代方案正在推廣，未來可能出現更多安全增強。

更好的中繼器激勵：

隨著閃電網路的普及，中繼器可能開始使用比特幣 Micropayment 機制獲得收益。

Nostr 原生身份系統：

類似於 ENS（Ethereum Name Service），Nostr 可能發展出原生的名稱系統。

增強隱私：

混洗交易所（Mixers）、洋蔥路由增強、追蹤保護等隱私功能將持續完善。

10.2 應用場景拓展

去中心化部落格平台：

基於 Nostr Kind 30023 的長文章功能，開發者正在構建完整的部落格生態。

去中心化電子商務：

NIP-15 市場標準支援商品列表，未來可能出現 Nostr 原生的電商平台。

企業內部通訊：

企業可以使用 Nostr 架構部署私有社交網路，保留抗審查特性的同時符合合規要求。

遊戲與虛擬世界：

去中心化社交與遊戲的結合，Nostr 可能成為 Web3 遊戲的社交層。

11. 結論

Nostr 代表了一種全新的社交網路範式，其基於公鑰密碼學的極簡設計為用戶提供了真正的數位主權。儘管協議本身仍在快速演進中，其核心架構已被證明穩健且具有生命力。

對於比特幣社群而言，Nostr 的價值不僅在於其作為比特幣友善的社交平台，更在於其展示了一種「密碼學第一」（Cryptography-first）的網路設計思路。這種思路與比特幣的去中心化、安全、無需許可的價值觀高度契合。

展望未來，隨著閃電網路的持續普及與比特幣愛好者社群的蓬勃發展，Nostr 有望成為比特幣生態系統中不可或缺的社交基礎設施，為全球比特幣用戶提供一個安全、私密、自由的交流空間。

標籤：Nostr、比特幣、閃電網路、去中心化社交、Zap、Lightning Address、中繼器、隱私保護、NIP 協議、抗審查、密碼學

相關文章：

• Nostr 比特幣社群媒體應用完整指南
• Nostr 比特幣社交應用深度實踐
• Nostr NIP 協議深度技術分析
• 比特幣與 AI 整合的深度技術分析