区块律动官网
扫码登录后可以使用日历,收藏文章
扫码下载 专业区块链研究机构 与咨询平台
Multicoin:如何做到Web3 数据所有权和应用程序逻辑分离?
Web 3
数据所有权
应用程序
收藏
分享文章
Multicoin:如何做到Web3 数据所有权和应用程序逻辑分离?
链闻 ChainNews 2019-07-30

原文标题:《Multicoin:Web3 数据所有权和应用程序逻辑分离究竟该怎么做?》

原文作者:Kyle Samani,Multicoin Capital 联合创始人

原文编译:链闻 詹涓

一年前我写文章诠释了当时我所理解的 Web3 堆栈。最近,我撰写了《论百万亿美元加密货币市场中三个核心投资主题》(Crypto Mega Theses),详细介绍了关于 Web3 的投资观点。正如我所强调的那样,Web3 的一个关键含义是数据所有权和应用程序逻辑分离。

在本文中,我将解释在 Web3 分离中所导致的特殊问题,以及我们如何考虑在 Web3 堆栈中进行投资。

Multicoin:Web3 数据所有权和应用程序逻辑分离究竟该怎么做?

WechatIMG166.png

Kyle Samani,Multicoin Capital 联合创始人

数据库和数据在哪里?

实际上,绝大多数现代应用程序都可以看作是数据库之上的用户体验 (UX)。虽然有一些例外(如视频流媒体和视频游戏),但这通常是成立的。几乎所有主要的 C 端服务,例如 Facebook、Reddit、Evernote、Twitter、Google Docs、Gmail、iMessage 等,都可以简化为数据库之上的 UX。

在 Web2 模型中,应用程序提供者存储和管理用户数据,这样用户就不必这样做。此外,Web2 应用程序提供商总是在线的,因为他们时刻都在运行服务器,而用户经常离线(搭乘地铁、网络连接不佳、电池有问题之类)。

而在 Web3 模型中,没有中心化的应用程序提供商,因此整个数据所有权范式都需要做出相应的更改。

这就引出了两个问题:

假设用户(我们姑且称她为 Alice)没有维护自己的服务器,那么 Alice 将数据存储在哪里 ?

在 Alice 离线的情况下,内容发送者如何将内容发送给 Alice?

当然,答案必须是:将内容存储在始终在线且可访问的地方,并确保在 Alice 重新上线时,她知道在哪里能找到发送给自己的内容。这个范式同时囊括了点对点应用(如聊天工具)和传统数据库应用(如报纸、社交媒体和笔记应用程序)。

要实现这一点,有几个操作方面的挑战:

Alice 以外的人需要知道如何存储内容、该内容的索引放在何处,以便 Alice 以后可以找到并下载它。

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

有了这个索引,Alice 需要自己找到,并下载数据本身。

无论是谁在存储数据,都不应该能够读取内容(如果是私有的),或者对其进行审查。

通过解决这些问题,可以将数据所有权和应用程序逻辑分离,从而使 Web3 蓬勃发展。

在探索当代 Web3 创业者们是如何解决这些问题之前,有必要考虑一下在过去,人们是如何尝试解决这些问题的。

去中心化互联网曾经作出的尝试

有一些团队,包括但不限于 Zeronet、Freenet 和 Scuttlebutt,已经尝试过他们口中所说的「去中心化互联网」。在我们今天所知的现代加密时代之前,他们就试图这么做过。这些尝试主要聚焦在狭窄的用例上,例如,专门适用于专制政权国家用户的抗审查的消息传输工具和留言板。

如果你对此感到好奇,我建议你试用下这些系统,你会发现它们的在体验上还有很多需要改进的地方。交互体验方面的问题显而易见,此外,到目前为止,这类系统最大的问题还是速度。一切都慢得要命。

这到底是怎么回事?它们为什么这么慢?

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

这些系统采用了以下体系结构的一些变体。我以某个加密点对点聊天工具为例,试着描述它们的架构:

1、这些系统基于这样一种逻辑,如果有人在 Alice 离线时向她发送消息,他们将把消息发送给 Bob,Bob 将代表 Alice 存储该消息。

2、在 Alice 回到网上时,她会问 Bob 她离线时是否错过了什么(消息索引)。

3、遗憾的是,Alice 不能保证 1) Bob 现在在线,2) Bob 在线时 Alice 却不在线,3) Bob 实际上拥有她离线时错过的所有消息的索引。

为了解决这个问题,Bob 可以询问他的对等点,是否知道发送给 Alice 的任何消息。然而,这些对等点可能也处于或已经处于脱机状态,而且它们拥有的信息也可能不完整。

在此范例中,根本不可能保证消息传递,因为不清楚应该在何处传递消息,以及谁应该存储消息索引。当收件人重新联机时,这会产生复杂的问题,因为收件人不知道在哪里可以找到发送给她的消息列表或数据消息引用。

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

Zeronet 和 Freenet 比 P2P 社交网络更加一般化,它们使用了类似的模型,只是在好友模型中没有双重选择。这给系统增加了相当多的复杂性,并且把速度拖得更慢。与 Scuttlebutt 这种朋友们同意为确定的信息路径互相帮助的模型不同,Freenet 和 Zeronet 的用户必须随机联系其他用户,询问他们知道哪些信息。这就是为什么这些系统如此缓慢的关键所在。

4、假设 Alice 终于把她离线时错过的所有东西的索引拼凑起来了。也就是说,她知道 Carol 给她发了一张照片,而 Dave 把照片保存在「dave.com/alicepic1.png」。如果 Dave 此时离线,Alice 如何访问照片?

这些问题并非小事。让互联网去中心化是很困难的。

逻辑和架构(去)中心化

上述所有问题的根本原因是缺乏逻辑中心化的存储和索引。什么是逻辑中心化存储?为了回答这个问题,最好先理解分布式系统中去中心化的三个向量:

架构:系统中计算机的数量

政治:能够对系统施加影响的人数

逻辑:外部代理与系统交互的接口数目

推荐大家阅读 Vitalik Buterin 的 这篇文章 可以更好地解释这些概念。

Web2 垄断解决了上一节所述的所有问题,因为它们依赖逻辑上中心化的存储。也就是说,当 Alice 重新联机时,她只需要询问维护中心化存储的中心化网络服务,自上次联机以来她错过了哪些消息。网络服务查询它控制的包含所有用户消息的数据库,并返回正确的消息。

这个模型的问题是,这些 Web2 系统将所有形式的中心化捆绑在一起:它们在逻辑上是中心化的,在政治上是中心化的,在架构上也是中心化的(除了用于伸缩目的)。

那么,是否存在逻辑上中心化、但在架构和政治上去中心化的存储系统呢?

幸运的是,答案是一个响亮的「是」:星际文件系统 (IPFS) 用于基于合约的存储,Arweave 用于永久存储(基于合约的存储:在保证 Z 可检索的前提下,为 Y 段时间存储 X 字节的数据。AWS、GCP、Azure、Filecoin 和 Sia 都是基于合约的存储系统)。

系统在逻辑上是中心化的,但在结构和政治上是去中心化的,这究竟意味着什么?理解这一点的最佳方法是考虑计算机如何从当今网络上的另一台服务器上检索基本文件(基于位置的寻址),然后将其与 IPFS/Arweave 方法(基于内容的寻址)进行比较。

在 Web2 体系结构中,如果 Alice 想从服务器下载图片,她将转到一个类似于 website.com/image.png 的 URL。当 Alice 尝试去那个 URL 时会发生什么?

使用域名解析服务(DNS),Alice 知道在 website.com 上在哪里可以找到服务器,她将向服务器询问它托管在本地文件系统上的映像,地址是「/image.png」。假设服务器想要合作,它将检查目录中的 /image.png,如果文件存在,则返回该文件。

请注意这个系统是多么脆弱:如果文件移动、更改、服务器繁忙或服务器由于任何原因不合作,请求将失败。

这就是目前网络构建的基础。

在 IPFS 和 Arweave 中使用的基于内容的寻址系统中,Alice 访问的 URL 是这样的:QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D。

虽然它不是人类可读的,但它由它所派生的内容确定性地生成。也就是说,在全网中只有一个单一的内容,在散列后,会产生那个精确的字符串。IPFS 和 Arweave 的神奇之处在于,它们可以处理所有的复杂性,使计算机能够解析 QmTkzDwW……,并引领用户进入这个网页。

WechatIMG167.jpeg

IPFS 和 Arweave 网络上的内容存储在许多机器上。但无论内容存储在多少台机器上,或者这些机器位于世界的哪个位置,这些协议都解析类似 QmTkzDwW 这样的地址——与实际内容存储在哪里无关。

这就是基于内容寻址的神奇之处。它提供了一个逻辑接口——基于内容的地址,无论底层数据存储在架构和政治上去中心化、庞大无比的计算机网络的哪个位置,它总是能够正确地解析。

在本文开头概述的四个主要技术挑战中,基于内容的寻址解决了第 1、第 3 和第 4 条(存储内容,使内容可供下载,并确保主机不能读取私有信息)。但是第 2 条呢?去哪里查找数据?

索引

尽管 IPFS 和 Arweave 在逻辑上是中心化的,而在架构上和政治上是去中心化的文件系统,但这些系统不是数据库。也就是说,无法查询它们并询问「请显示在日期 X 和日期 Y 之间 Bob 发送给 Alice 的所有消息。」

好在有几种方法可以解决这个问题。

一种方法是直接存储区块链上消息的索引。区块链本身是在逻辑上中心化、但在架构和政治上是去中心化的数据库。使用像 Graph 这样的去中心化服务或像 dFuse 这样的中心化服务,Alice 可以查询存储在区块链上的索引。区块链不存储底层数据,而只是数据的散列。该散列只是指向存储在 IPFS 或 Arweave 中的内容的指针。Graph 和 dFuse 现在都是实时的,许多应用程序都采用了这种将在链上存储散列的模型,这些散列指向存储在内容寻址系统中的数据。

第二种方法是利用 Textile。Textile 建立了一种称为 Threads 的独特技术,在 IPFS 之上充当一个私有的、加密的个人数据库。因为这个数据库是基于 IPFS 构建的,所以它在逻辑上是中心化的,但在架构和政治上去中心化。作为逻辑中心化的数据库,发送方和接收方知道从哪里发送和读取信息。此外,Textile 最近推出了 Cafes,使用户能够建立服务器来托管 Threads(而不是在本地托管)。Textile 的下一步是建立一个经济层,以激励验证器为其他用户提供 Cafes 托管,这类似于 Filecoin 是 IPFS 的经济层。

第三种方法是利用 OrbitDB。OrbitDB 类似于 Textile 的 Threads,只是 OrbitDB 主要是为公共数据设计的(例如,用于构建去中心化的 Twitter),而 Textile 的 Threads 从本质上就为私有信息(例如点对点聊天工具)集成了加密和密钥管理。和 Textile 一样,OrbitDB 现在也已投入使用,OrbitDB 团队正在底层技术的基础上开发一个经济层。

最后,Fluence 和 Bluzelle 等团队正在构建有效的传统数据库,这些数据库使用拜占庭容错 (BFT) 保证下在无许可环境中运行。

考虑到智能合约团队正在大规模解决数据可用性问题(如 Solana 的 Replicators),我们对在传统数据库之上添加 BFT 层的想法持怀疑态度。相反,我们选择投资的是 Textile 这类「加密货币原生」数据库和以 Graph 和 dFuse 为代表的开发人员 API 层。

有了上面描述的协议和服务,例如 IPFS、Filecoin、Arweave、the Graph、dFuse、Textile 和 OrbitDB,Web3 就有了明确的实现路径。所有这些服务目前都已经能够使用,不过还不全然是生产就绪、达到了网络规模、并且经过了实战验证。

然而,对于最重要的问题已经有了解决方案——为政治上和架构上去中心化的系统提供一个逻辑上中心化的接口。

还有什么遗漏的吗?

更高阶的逻辑

既然我们有了逻辑中心化但架构去中心化的存储、索引和检索的解决方案,我们就可以考虑更高阶的逻辑了。

举几个例子:

Alice 如何管理多个身份?比方说,Alice 可能不想在 Facebook / 谷歌 / Snapchat / Reddit 上使用相同的公钥。如果她想在一个单独的接口中管理这些身份而不公开链接,又该怎么办呢?

假设 Alice 希望向 Bob 发送私人信息,但要将信息存储在 IPFS 或 Arweave 上(按定义它们属于公共系统),他们需要利用完美前向保密 (perfect forward secrecy,PFS) 握手。如何以异步方式设置 PFS 并管理所有关联的密钥?

鉴于传统的加密方案只适用于两方通信,系统如何支持大型群组,比如留言板或大型聊天组的私人通信呢?

系统如何启用常见的交互模式,如群组发现、用户数据恢复、内容删除等?

虽然这些都是不同的技术挑战,但我大致上将所有这些问题归类为「更高阶的逻辑」问题。

Textile 的 Threads 恰好解决了这类问题。在许多方面,人们可以将 Textile 看作是在 IPFS 上的 iCloud。

虽然这个比喻并不完美,但还算好懂:就像 iCloud 为应用程序抽象跨设备同步和数据备份(提供更好的用户和开发人员体验)一样,Textile 在 IPFS 之上提供了所有更高阶的逻辑工具,使开发人员可以无缝地进行应用程序开发,同时确保 IPFS 上的用户无缝跨设备同步和备份。

展望未来

Web3 的生态系统在很多方面都非常多样化,包括正在解决的问题的类型、团队的位置、所使用的经济模型等。尽管没有一个逻辑上中心化的实体来协调整个事情,但是 Web3 堆栈正在走到一起,这一点非常了不起。

然而,这也意味着系统中存在大量的熵,因此很难理解更高层次的主题。在这篇文章中,我总结如下:

从 Web2 到 Web3 的过渡中,最大的挑战是从将所有三个中心化的向量(逻辑、架构和政治)解绑,过渡到在逻辑上中心化但在政治和架构上去中心化的系统。

我们相信 Web3 将是一个范式的转变,在未来的十年里,它将释放出数万亿美元的价值,我们希望支持最优秀的创业者建立基础的 Web3 基础设施。

分享文章
你可能感兴趣
下载区块律动App,赢iPhone11
论状态租金和以太坊无状态客户端
V 神评价 MimbleWimble:只有零知识证明 ZK-SNARKs 等全局匿名集,才能真正保证隐私安全
Dragonfly Capital:已破解 Grin 网络 96% 的交易,MimbleWimble 隐私保护方案有严重缺陷
微信扫描二维码 分享这篇文章 您还可以 复制原文链接
合作伙伴 PARTNER