开启Web3.0：解绑中心化向量

转载

1929 天前

10384

文章来源：蓝狐笔记

前言：web2.0中，数据所有权归平台所有，这导致时不时出现平台数据泄漏的问题。那么，web3.0的到来，能否实现将数据的所有权和应用逻辑进行解绑。如果能实现，具体如何实现？本文作者Kyle Samani，由“蓝狐笔记”社群的“SL”翻译。

一年前，我按照当时的理解来阐述Web3堆栈。最近又提到了Web3的投资主题，正如我所强调的，Web3的一个关键含义是数据所有权和应用逻辑的解绑。本文，我将解释这种解绑中固有的具体问题，以及我们如何考虑在Web3堆栈中进行投资。

数据库和数据在哪里？

出于实际目的，绝大多数现在的应用都可以被看作为基于数据库的一种UX。虽然有一些例外，例如，视频流和视频游戏。但通常这样看都是正确的。事实上，几乎每个主要的消费者服务，例如Facebook、Reddit、Evernote、Twitter、Google Docs、Gmail、iMessage等，都可以简化为基于数据库的UX。（蓝狐笔记：UX是一种用户体验，基于界面用户跟产品的交互体验。）

在Web2的模型中，应用提供者存储和管理用户数据，因此用户不必自己管理。此外，Web2的应用提供者总是在线，因为他们24/7小时运行服务器，即便用户经常离线（例如在地铁中、网络连接不良、电池没电等）。而在Web3模型中，没有一个中心化的应用提供者，因此，关于数据所有权的范式需要改变。

这引出了几个问题：

1.用户在哪里存储TA的数据（让我们将用户叫做Alice，假设她没有维护自己的服务器）？

2.如果Alice离线，内容发送者如何向她发送内容？

当然，答案必须是：将内容存储在始终在线且可访问的地方，并确保当Alice重新上线后，知道在哪里可以找到发给她的内容。这种范式同时封装了像消息这类P2P应用以及像新闻、社交媒体以及笔记这类传统数据库应用。

要执行此类操作，存在一些机械挑战：

1.其他人（不是Alice）需要知道存储内容和该内容的检索，以便Alice后续可以找到并下载它。

2.Alice需要知道哪里可以找到该索引。

3.通过该索引，Alice需要实际找到并下载底层数据本身。

4.存储数据的人不应该能阅读该内容（如果是私有的），或者对它审查。

通过解决这些问题，数据所有权和应用逻辑可以解绑，从而支持Web3.0走向繁荣。

在探索当代Web3.0创业家们如何解决这些问题之前，可先思考过去已经试图解决这些问题的其他人。

之前对互联网进行去中心化的尝试

有一些团队，包括但不限于Zeronet、Freenet、Scuttlebutt，他们试图“对互联网进行去中心化”。他们试图做这个事情，这比我们今天知道的当代加密时代还要早。大多数这些努力专注于支持狭隘的用例。例如，可抗审查的消息和留言板等。

如果你很好奇，你可以尝试使用下这些系统。你会发现它们的用户体验有很多不足。尽管这些系统存在很多UX问题，但迄今为止，最大的问题是速度。一切都很慢。

为什们它们这么慢？

因为它们在逻辑上全都是去中心化的。

这些系统采用了下列架构的一些变体。我将在加密和P2P的消息应用的背景下描述它们的架构：

这些系统基于如下想法：如果Alice离线时，有人给她发消息，他们会将其发给Bob，而Bob将代表Alice存储该信息。

当Alice重新上线时，她会询问Bob在她离线时是否错过消息（消息索引）。

遗憾的是，Alice得不到以下的保证：1）Bob当前在线；2）在Alice离线时，Bob一直在线；3）Bob实际上拥有她不在线时错过的完整消息索引。为了解决这个问题，Bob可以询问他的对等方他们是否注意到发送给Alice的消息。然而，这些对等方也可能不在线，并且他们也可能只有不完整的消息。

在这种范式中，根本不可能保证消息传递，因为它不清楚消息应该传递到哪里，且谁应该存储消息索引。当消息接受者重新上线时，由于接收者不知道哪里可以找到发送给她的消息列表或数据消息的指向，这还会产生复合问题。

Scuttlebutt是专注于构建P2P社交网络的项目，它试图通过采用类似于Facebook的双向选择朋友系统来解决这个问题。也就是说，一旦Alice和Bob变成朋友，他们共享彼此的朋友列表，这样，Bob可以代表Alice索引和存储Alice朋友们发布的内容。这要求Alice通知她所有的朋友，而Bob是她的代理，反之亦然。然后，当Alice不在线时，她的朋友们发布更新，Alice的朋友可以将更新发送Bob，他能为Alice托管。

Zeronet和Freenet是更普遍化的项目，而不仅仅是P2P社交网络，它们使用类似的模型，除了没有双向选择的朋友模型。这给系统增加了很多复杂性，这让它变得更加缓慢。与Scuttlebutt模型不同，在Scuttlebutt中，朋友们同意相互帮忙定义信息路径，而Freenet和Zeronet的用户则不得不随机ping其他用户，并询问他们关于他们知道的信息。这就是为什么这些系统如此缓慢的关键原因。

让我们说，在某种机缘情况下，Alice最终将其离线时错过的各种内容索引拼凑起来。也就是说，她知道Carol给她发送了一张照片，且Dave将该照片存储在“dave.com/alicepic1.png”。如果Dave离线，Alice如何能访问该照片呢？

这些都是需要重视的问题。对互联网进行去中心化很难。

逻辑和架构的（去中心化）中心化

上述所有问题的根本原因是缺乏逻辑上的中心化存储和索引。什么是逻辑上的中心化存储？要回答这个问题，它有助于理解分布式系统中的去中心化的三个向量：

1.架构的

>系统中的计算机数量

2.政治的

>能够对系统施加影响的人数

3.逻辑的

>外部代理与系统交互的接口数

为更好理解这些概念，可以阅读“蓝狐笔记”之前发布的文章《以太坊创始人V神：如何理解区块链的“去中心化”》

Web2.0垄断解决了上述的所有问题，因为它们依赖于逻辑上的中心化存储。也就是说，当Alice重新上线时，她只需向中心网络服务器发出请求，网络服务器维持中心存储，它存储了自Alice下线后所有错过的消息。网络服务查询它控制的包含所有用户消息的数据库，然后返回正确的消息。

这种模式的问题在于，Web2.0系统耦合了所有形式的中心化：它们不仅在逻辑上是中心化的，而且在政治上和架构上也是中心化的。

那么，存储系统在逻辑上中心化，但在架构和政治上可以是去中心化的么？

幸运的是，答案是肯定的：用于基于合约存储的IPFS和用于永久存储的Arweave（基于合约的存储：在Y时间段内存储X字节的数据，同时具有Z的可检索性保证。AWS、GCP、Azure、Filecoin以及Sia都是基于合约的存储系统。）

这个系统在逻辑上是中心化的，而在架构和政治上是去中心化的，这究竟意味着什么？理解这个问题最好的方法是考虑一下计算机是如何从网络上的其他服务器上检索基本文件（基于位置的寻址），然后将其与IPFS/Arweave方法进行比较（基于内容的寻址）。

在web2.0的架构中，如果Alice想要从服务器下载图片，Alice会转到一个URL类似于：

Website.com/image.png。当Alice试图访问该URL时，到底发生了什么？

使用DNS，Alice知道在website.com上找到服务器的位置，她会向服务器询问它所托管的图像位于“/image.png”的本地文件系统上。假设服务器想合作，它会检查它的/image.png的目录，如果文件存在，它会返回结果。

注意这个系统是多么脆弱：如果文件被移动、更改，或者服务器很忙，或者服务器因为任何原因不想合作，请求就会失败。

这就是当今网络构建web的基础。

而在像IPFS和Arweave这样的基于内容的寻址系统中，Alice访问的URL是像这样的：

mTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D。

尽管它不具有人类可读性，但它是从内容本身衍生而来，是通过内容确定性地生成。也就是说，当被哈希之后，世界上唯一的一片内容将产生确切的字符串。IPFS和Arweave的神奇之处在于它们处理了允许计算机将QmTkzDwW...解析到网页的所有复杂性。

IPFS和Arweave网络上的内容存储在很多机器上。不管内容存储在多少台机器上，或者这些机器位于世界上的哪个地方，这些协议都会解析像QmTkzDwW... 这样的地址，而不管它实际存储的内容位于何处。

这就是基于内容寻址的神奇之处。它公开了一个单一逻辑接口，基于内容的地址——它将始终正确地解析，不管底层数据存储在哪里，存储在多大的计算机网络上（这些计算机在架构和政治上是去中心化的）。

本文开头提到的四个主要技术挑战，基于内容的寻址解决了其中三个（1.3.4），也就是存储内容、让内容下载可访问、确保托管者无法读取隐私信息。但还有一点：如何知道在哪里寻找数据？

索引

尽管IPFS和Arweave充当逻辑上的中心化，但架构和政治上是去中心化的文件系统，这些系统并不是数据库。也就是说，没有办法来查询它们以及询问“请告诉我在日期X和Y之间，Bob发给Alice的所有消息”。

幸运的是，有几种方法能解决这个问题：

第一种方式是直接在区块链上存储消息索引。区块链自身是逻辑上中心化，但架构和政治上是去中心化的数据库。使用去中心化的服务如Graph或中心化的服务如dFuse，Alice能够查询存储在区块链上的索引。区块链并不存储底层数据，只是存储数据的哈希。哈希只是存储在IPFS和Arweave上的内容的指针。Graph和dFuse现在都在使用，很多应用都采用在链上存储内容哈希，而数据存储在内容寻址系统的模式。

第二种方式是利用Textile。Textile构建了一种独特的技术，被称为Threads，它在IPFS上充当私有、加密和个人的数据库。因为这个数据库是基于IPFS构建的，它在逻辑上是中心化的，但架构和政治上是去中心化的。作为逻辑上中心化的数据库，发送者和接收者知道从哪里发送和从哪里阅读信息。此外，Textile近期发布了Cafes，允许用户构建服务器以便于托管他们的Threads（而不是在本地托管Threads）。Textile的下一步构建一个经济层，以激励验证者来为其他用户托管cafes，这类似于Filecoin是IPFS的经济层。

第三种方法是利用OrbitDB。OrbitDB类似于Textile的Threads，除了OrbitDB主要是为公共数据设计（例如用于构建去中心化的twitter），而Textile的Threads本地集成用于私人信息的加密和密钥管理（例如P2P消息）。像Textile，OrbitDB已经上市，且OrbitDB正在底层技术基础上开发一个经济层。

最后一种方法是，有很多团队，他们在构建具有不同去中心化向量的有效传统数据库：Fluence的构建将在用BFT保证的无须许可的环境下运行，而Bluzelle正在构建一个双层系统，该系统具有一组政治上中心化的主节点，以及还有一组架构上去中心化的副本节点。

鉴于一些智能合约团队正在致力于大规模解决数据可用性问题，例如Solana的Replicators（可参考蓝狐笔记之前的文章《为什么Solana是区块链开发者需要的“世界计算机”？》）。

我们对如下方案持怀疑态度：在传统的数据库基础上增加BFT层。相反，我们选择投资“加密原生”数据库如Textile等，以及开发者API层（如The Graph和dFuse的形式）。

通过协议和上述的服务，IPFS、Filecoin、Arwearve、The Graph、dFuse、Textile以及OrbitDB，这里有一个明晰的路径，可供Web3.0产生成果。今天所有这些服务都已经存在，尽管在产品准备就绪和有加密经济实战考验的网络规模形式方面还不成熟，但是，对于其中最重要的问题有了解决方案，为政治上和架构上去中心化的系统提供单一逻辑上的中心化接口。

还剩下什么？

高阶逻辑

现在，我们有了逻辑上中心化但架构上去中心化的存储、索引、检索的解决方案，我们可以考虑更高阶的逻辑。例如：

Alice如何管理多个身份？例如，Alice可能不想在多个应用如Facebook/Google/Snapchat/Reddit上使用相同的公钥。如果她想在一个界面上管理这些身份而不公开链接它们，该怎么办？

考虑Alice想给Bob发送私人信息，但将它存储在IPFS或Arweave上，这些都是公开系统，它们需要利用PFS（完全正向保密）握手。他们如何以异步方式设置PFS并管理所有相关的密钥？

鉴于传统的加密机制仅供双方进行通信，而系统如何支持大型人群的私人通信（如留言板或大型聊天组）？

系统如何支持常见的UX模式，例如群组发现、用户数据恢复以及内容移除等？

虽然这些是不同的技术挑战，但我将所有这些视为“高阶逻辑”问题。

Textile的Threads恰好地解决这些问题。很多方面，人们可以将Textile看作为IPFS的iCloud。虽然这种类比不完美，但它通常有用：iCloud抽象了跨设备同步和应用的数据备份（提供了更好的用户和开发者体验），Textile提供基于IPFS之上提供各种更高级的逻辑工具，使得开发者无缝地进行应用开发，同时确保IPFS上的用户无缝跨设备同步和备份。