Nostr2.0：作為比特幣Layer 2 鏈下數據存儲層

Nostr 2.0 可能能夠作為Layer 2 建立在比特幣之上，提供安全的離鏈數據存儲，就像閃電網絡作為Layer 2 提供即時的離鏈支付一樣。

本文將闡述Nostr 中繼如何在保持輕量級特性的同時同步其數據，使用戶可以選擇性地刪除數據，這是Layer 1 區塊鏈所不具備的。同時，與在比特幣區塊鏈中存儲大量數據相比，因為比特幣區塊的容量和速度有限，使用Nostr 中繼存儲數據可能更加便宜。

下面的簡單計算機科學設計改進了Nostr 網絡在標準化的CAP 定理準則下的分佈特性。CAP 代表一致性（Consistency）、可用性（Availability）和分區容忍性（Partition tolerance）

Nostr 中繼不知道一個配置文件何時是不完整的，中繼缺乏一致性（CAP 定理中的C）

中繼缺乏一致性（CAP 定理中的C）

一致性意味著在各個計算機上同步的數據庫是相同的。Nostr 中繼不能以類似區塊鏈逐個區塊同步其數據的方式進行信任最小化的同步。與比特幣全節點不同，Nostr 中繼存儲的數據庫通常是不完整的。除了盲目請求由特定用戶簽名的所有帖子外，Nostr 中繼無法發現缺失的數據。

Nostr 的一致性/ 同步問題：

如果兩個用戶將各自的帖子上傳到不同的Nostr 中繼，那麼這兩個用戶可能無法看到彼此的帖子，因為Nostr 不像一個區塊鏈。在區塊鏈中，每當有新的記錄時，所有全節點都會將區塊鏈同步。所有全節點會將這些數據作為一個區塊同時添加到他們的區塊鏈中。比特幣區塊鏈上的每個全節點都擁有完全相同的區塊鏈。

如果我們希望Nostr 用戶始終能夠看到彼此的帖子，那麼所有的Nostr 中繼都需要一種方式來識別用戶配置文件中缺失的數據，以便它們可以從其他Nostr 中繼或用戶那裡請求缺失的部分。

使用每週的鏈上Merkle 根和整個樹哈希來同步Nostr 中繼

大約每週一次，用戶可以將他們的所有帖子組織成一個Merkle 樹。
Merkle 樹中的每個葉子包含一個帖子的哈希，就像比特幣中每個葉子包含一個交易的哈希一樣。
一旦用戶將整個配置文件組織成一個Merkle 樹，他們將在鏈上的OP_RETURN 中發布Merkle 根，在一個普通的比特幣交易下方。這就是為什麼Nostr 2.0 不需要對區塊鏈進行硬分叉來工作。OP_RETURN 是比特幣交易下方的一個區段，允許在發送者簽名之前附加小的註釋信息。
另外，用戶將對整個樹進行哈希，並將其與Merkle 根一起（在OP_RETURN 中）上傳到鏈上。Merkle 根只是頂部分支的哈希，而不是整個樹的哈希。整個樹的哈希對於用戶和中繼能夠檢測到配置文件數據是否缺失至關重要。

要獲得整個樹的哈希，請將Merkle 根放置在文本文件的根部。然後，在根下方的行上放置Merkle 分支。然後，在分支下方的行上放置Merkle 葉子。一旦樹按照描述的方式排列好，一次性對其進行哈希處理。下面是一個整個樹哈希的示例，它是上面所示的Merkle 樹的整個樹哈希的樣子。整個樹哈希（一次性哈希所有Merkle 樹數據）

Merkle 根和整個樹哈希提供了兩個關鍵功能：

Merkle 根允許用戶和中繼一次下載一個配置文件的一部分，就像能夠下載一個交易而不必下載整個區塊一樣。
整個樹哈希讓用戶和中繼知道他們存儲的配置文件是否不完整。與Merkle 根不同，只有在Merkle 樹中擁有所有數據位時，整個樹哈希才會匹配。

這種廉價的方法可以用來每週或用戶自定義的頻率更新整個配置文件。Nostr 仍然可以像現在一樣工作，但是如果用戶希望所有用戶都能看到他們的帖子，他們可以偶爾支付一些sats 來在Nostr 中繼之間同步他們的數據。

用戶和中繼可以一次下載一個分支的帖子。在每個分支之後，他們會將該分支與最接近Merkle 根的另一個分支進行哈希，以檢查是否與鏈上的Merkle 根匹配（類似於SPV）。如果這些分支一起哈希與Merkle 根匹配，那麼他們就會知道該分支是用戶配置文件的一部分，即使他們還沒有完整的用戶配置文件。用戶可以從許多不同的Nostr 中繼下載同一個配置文件的不同分支，同時驗證每個分支的有效性，並確保下載的配置文件是完整的。

逐個下載分支可以防止延遲攻擊，這種攻擊可能會癱瘓許多分佈式網絡，這就是為什麼比特幣白皮書中使用Merkle 根和分支來保護SPV 輕錢包的原因。

為什麼Merkle 根不能像整個樹哈希一樣的功能？

如果Nostr 中繼僅依賴於Merkle 根，那麼它們將無法知道Merkle 樹何時完整，因為最接近Merkle 根的每對分支都會哈希到同一個Merkle 根中。

為了確保用戶的配置文件完整，中繼或用戶會將他們更新後的整個Merkle 樹進行哈希，並驗證它是否與鏈上的整個樹哈希匹配。如果整個樹哈希匹配，那麼用戶數據就是完整的。如果整個樹哈希不匹配，那麼中繼或用戶可以告訴其他中繼他們的最新葉子編號，並請求缺失的分支，直到整個樹哈希匹配為止。為了跟踪每週左右添加的所有新Merkle 根，Nostr 中繼必須成為比特幣全節點。Nostr 2.0 中繼通過間接獲得報酬來存儲比特幣區塊鏈，同時增強了比特幣和Nostr 的安全性。

Nostr 存儲的限制：用戶的經驗法則

由於中繼有權選擇要存儲的內容，與比特幣全節點不同，Nostr 中繼可能會丟失一些用戶數據。因此，用戶應該只在Nostr 中繼上存儲數據，如果用戶可以在本地進行備份。Web5 的自託管服務可以讓用戶將備份同步到所有本地設備上，這將降低對使用Nostr 感到擔憂的用戶的風險。歸根結底，只有區塊鍊是數據真正不可變的地方。雖然如此，Nostr 是一個相當安全的混合方案，對於許多應用程序仍然能夠良好運行。下面列出了權衡的方面：

三層信任最小化

第1 層：不可變且昂貴的數據存儲，極難被審查。（鏈上區塊同步所有比特幣全節點）
第2 層：可變且廉價的數據存儲，中等難度的審查。（離鏈Merkle 樹和鏈上哈希，按需同步Nostr 中繼）
本地數據存儲同步到所有本地設備，容易被審查。（本地集中化）

基於Nakamoto 共識的區塊鍊和Nostr 之間的根本權衡

存儲特定地址數據的Nostr 中繼越多，越難以審查該數據。這意味著由許多Nostr 中繼託管的熱門數據可能比很少被下載的不受歡迎數據更難以被審查。

另一方面，Nakamoto 共識區塊鏈可以防止基於數據的年齡進行審查。數據在區塊鏈中存在的時間越長，使用51% 攻擊刪除數據就越困難。

使用可檢索性證明（Proof-of-Retrievability）的ZKCSP 與閃電網絡支付Nostr 中繼

由於我們可以驗證某些分支屬於特定用戶，所以每當Nostr 中繼將一小段數據傳遞給用戶時，就可以向它們支付報酬。為了實現這一點，用戶需要下載區塊鏈的頭部（就像在SPV 中那樣），以便能夠執行輕錢包的典型功能。用戶將利用輕錢包的SPV 功能從鏈上獲取特定的交易，該交易將在其OP_RETURN 中包含用戶配置文件的Merkle 根和整個樹哈希。現在，用戶可以支付中繼逐個分支地下載該用戶的配置文件，並通過將它們進行哈希運算以與鏈上的Merkle 根匹配來驗證每個分支。

為了向Nostr 中繼發送sats（比特幣的最小單位），以交換提供數據，我們使用Gregory Maxwell（著名比特幣核心開發者）的ZKCP 設計（零知識條件支付）[1]的演化版本，即ZKCSP：可檢索性證明[2]與閃電網絡相結合。

根據ZKCSP 白皮書的描述：

「…不需要可信任的第三方…我們還為可檢索性證明的情況實現了ZKCSP 協議，客戶向服務器支付費用以獲得證明客戶數據在服務器上正確存儲。」 [2]

用戶與幾位融資者啟動了一個閃電智能合約。
用戶向周圍的融資者發送請求。融資者對該請求進行簽名。
用戶將融資者簽署的請求直接發送給與這些融資者連接的Nostr 中繼。
用戶現在啟動ZKCSP 構造，以確保只有在正確請求的數據被傳遞後，Nostr 中繼才會從融資者那裡獲得支付。

一旦發生第3 步，用戶在第4 步中啟動ZKCSP 構造之前，將在融資者簽署的原始請求之上進行修改。用戶將在原始請求之上添加額外的內容，指定從用戶和融資者的餘額中扣除的金額（它們必須是相同的金額，加上融資者的費用），然後用戶將對其添加到原始消息上的內容進行簽名。

如果用戶指定要發送的sats 超過其擁有的數量，或者超過融資者在該Nostr 中繼上凍結的數量，那麼Nostr 中繼將拒絕該請求，因為中繼將無法得到支付。

通過這種方式，用戶可以與許多Nostr 中繼連接，同時只與少數融資者凍結他們的資金。閃電網絡也可以採用類似的方式，其中信任最小化的融資者是用戶和商家之間的無需許可的中間人。在Nostr 2.0 中也可以使用普通的P2P 閃電跳，但是如果路由和通道平衡經常失敗，這種方法可能會很有用。

白名單解鎖付費Nostr 中繼

如果Nostr 中繼希望存儲所有這些用戶查看的數據，它們可以將某些密鑰加入白名單。如果Nostr 中繼無法將希望存儲數據的用戶加入白名單，那麼它們將存儲發送給它們的任何數據。如果用戶始終可以免費向中繼發送數據，那麼用戶將永遠不需要支付Nostr 中繼。只有當中繼有拒絕存儲無法支付的數據的選項時，Nostr 才能提供付費選項。免費中繼仍然存在，但目前不存在付費中繼的選項。

付費的Nostr 中繼可以使用白名單選擇性地存儲其付費用戶每天查看的所有數據，而不是試圖免費存儲所有Nostr 數據。一些Nostr 中繼將繼續採用免費模式，但在最大規模上，這是不可持續的，因為大多數免費中繼只是熱情的愛好者。白名單（即使我們能夠為每個Nostr 配置文件安全地分配一個公鑰）賦予Nostr 中繼決定哪些數據存儲的能力，將不可能實現。

每個配置文件一個公鑰解鎖白名單功能：比特幣地址成為您的Nostr 公鑰

該系統最終使我們能夠為每個配置文件分配一個公鑰。

用戶為每個帖子創建新的公鑰沒有任何好處…因為它們都與他們的配置文件關聯！這與比特幣地址不同。與比特幣不同，讓用戶在同一個應用程序中擁有多個公鑰並不會提高隱私。

Nostr 配置文件的公鑰必須與包含每週哈希值（用戶所有帖子的Merkle 根和整個樹哈希）的比特幣交易的公鑰匹配。與Nostr 用戶使用Schnorr 簽名不同，他們將需要使用比特幣錢包（移動錢包/ 輕錢包或完整節點）進行簽名。

這個美妙之處在於，每個Nostr 賬戶都將用其比特幣地址表示，這意味著用戶可以直接向Nostr 賬戶發送付款，而無需請求兩個不同的公鑰。這降低了新用戶在系統中的認知成本。用戶仍然需要向彼此發送公鑰或DNS 以在Nostr 上找到對方，而不是使用用戶名。

如果其他Nostr 應用程序使用不同的公鑰，它們仍然可以附加到相同的去中心化身份（DID）上- 這樣，識別您的賬戶的方式在應用程序間仍然保持一致。不過，這個Nostr 共識規則將限制每個Nostr 應用程序上的每個配置文件只能使用一個公鑰。

DHT 作為對等發現排行榜。

中繼可以使用分佈式哈希表（DHT）來找到其他中繼。中繼可以通過列出存儲數據的公鑰來在分佈式哈希表中共享其白名單。這樣，對於某個公鑰的數據缺少分支的中繼可以掃描DHT 並直接連接到聲稱存儲那些缺少分支的其他中繼的IP 地址。然後，中繼可以直接從這些Nostr 中繼下載缺少的分支。

中繼還將能夠通過檢查這些中繼在鏈上解決了多少以前的ZKCSP 交易- 近期和全部時間- 來找到最活躍的中繼。在這個系統中，所有Nostr 中繼都成為完整節點，所以審計其他中繼的先前交易將是輕鬆的。這將使得偽造信任成本昂貴，因為鏈上交易總是需要交易費用。如果Nostr 中繼打開許多通道與自己建立信任，以獲取其他中繼的信任，他將不得不支付大量交易費用來維持每週的虛假聲譽。在攻擊者無法提供缺失的分支之後，超時將導致中繼斷開連接- 因此這只是一種暫時的、代價高昂的攻擊（就像51% 攻擊是一種暫時的、代價高昂的攻擊）。

DHT 不像挖礦那樣匿名，因為每個Nostr 中繼的公鑰將在DHT 中的IP 地址旁邊列出，但它將避免中繼在網絡上盲目發送請求的需求- 在足夠大的規模下，這將導致網絡超載。希望獲得更高隱私性的Nostr 中繼可以使用VPN 或其他IP 保護服務。

用戶將無法訪問此相同的信任系統，因為他們不是完整節點。不過，用戶可以依賴。