Nostr2.0：作为比特币 Layer 2 链下数据存储层

作者：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 中继下载同一个配置文件的不同分支，同时验证每个分支的有效性，并确保下载的配置文件是完整的。