前言: 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... 解析到网页的所有复杂性.
(屏幕截图 2019-07-24 11.24.19 AM)
(关于 IPFS 可参考蓝狐笔记之前的文章《IPFS: 基于区块链的去中心化存储网络》)
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 上的用户无缝跨设备同步和备份.
展望未来
Web3.0 生态系统在很多方面都非常多样化, 包括要解决的问题类型, 团队的位置, 所使用的经济模型等. 尽管没有一个逻辑上中心化的实体在协调整个事情, 但 Web3.0 堆栈正在一起到来, 这是很了不起的. 然而, 这也意味着, 系统中有很多熵, 因此对于更高级别的主题人们很难理解. 在本文中, 我将其提炼如下:
从 Web2.0 向 Web3.0 过渡最大挑战是从具有三个中心化向量 (逻辑, 架构和政治上) 的耦合系统向逻辑上中心化但架构和政治上去中心化的系统转变.
我们相信 Web3.0 将成为一种范式转移, 将在下一个十年解锁数万亿美元的价值.
------
风险警示 : 蓝狐笔记所有文章都 不能作为投资建议或推荐 , 投资有风险 , 投资应该 考虑个人风险承受能力 , 建议对项目进行深入考察, 慎重做好自己的投资决策.
来源: http://www.tuicool.com/articles/iyayUvi