作者：Colby Serpa；編譯：DAOrayaki
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% 攻擊刪除數據就越困難。
由於我們可以驗證某些分支屬於特定用戶，所以每當 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 保護服務。
用戶將無法訪問此相同的信任系統，因爲他們不是完整節點。不過，用戶可以依賴。
金融家間接連接到數百個 Nostr 中繼
由於用戶在其輕錢包中自動存儲了所有區塊頭，用戶可以查看最活躍的礦工是哪些。礦工成爲金融家將使用戶能夠篩選出最受歡迎的礦工，這樣他們就不必盲目地將資金與沒有與網絡的生存能力相關的隨機金融家綁定。
金融家（礦工）只需要將他們的 sats 與 Nostr 中繼鎖定，而不需要在用戶和中繼之間傳遞數據本身。金融家（礦工）只需籤署用戶的請求，以便用戶可以直接與金融家連接的所有 Nostr 中繼進行交互 - 如上所述的 ZKCSP+Lightning 的 4 個步驟。
結論
如果沒有比特幣的 Nakamoto 共識區塊鏈，閃電網絡將無法存在，因爲用戶將沒有地方存儲其離鏈交易的捆綁證明。
就像用戶將所有這些閃電網絡交易捆綁在一起並將小證明放入區塊鏈中一樣，我們將捆綁所有 Nostr 數據並將小證明放入區塊鏈中。與閃電網絡在第二層提供即時支付的方式相同，Nostr 可能能夠在第二層提供數據存儲，而無需承擔不安全的側鏈的風險。
它採用了與閃電網絡相同的方法，其中比特幣的 Nakamoto 共識區塊鏈位於第一層，Nostr+ZKCSP 閃電位於第二層。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。