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

DAOrayaki

特邀专栏作者

2023-06-22 10:30

本文約4721字，閱讀全文需要約7分鐘

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

AI總結

展開

原文作者：Colby Serpa

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

圖片描述

中繼缺乏一致性（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 樹中擁有所有數據位時，整個樹哈希才會匹配。

一級標題

為什麼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 保護服務。