引介 | Web3 上的内容何去何从?

去中心化最具挑战、又最受忽视的众多方面之一就是存储。Web3 上的内容存储在哪里?如何安全高效地分散存储?

Kauri 知识网络旨在管理大量的长篇文档,包括图表、图片、视频、和其他数据丰富的文件格式。理论上,你可以在以太坊区块链上存储任何东西,但 Gas 耗费会随着文件大小的增加而大幅增加(按 2018 年 9 月中旬的 Gas 价格,1MB 的存储要花掉几百美金)。

为了以更节约的方式处理长篇文件,我们利用了 IPFS(星际文件系统)作为分布式存储层。然而要处理文件作者的以太坊地址索引和文件存储地址的的 IPFS 哈希,仍然是个挑战。

本质上,我们的研究范围缩减到了三个去中心化解决方案,即:链上索引,侧链索引,和 IPFS 只读公开索引。第三个方案也是最不去中心化的一个。

Kauri 网络上需要的核心数据就是一个至少包含作者的以太坊地址和文章哈希的索引。这个索引会跟用户将文章提交到去中心化环境中时的时间戳有关联。三个方案的利弊将在下文详细讨论。

存储方案1:链上索引

设置

采用链上索引的方式,数据存储在 IPFS(你也可以使用 Swarm,Storj,Sia 或其他分布式存储方案),指向数据的固定长度的、唯一的 IPFS 哈希以交易的形式存在以太坊区块链上。

优势

索引存在主链上,用户可以在全球范围内证明文章的所有权。文章存在主链上,可被其他 dApp 用于多种用途:在 Kauri 基础上开发、创建和收集徽章、分发内容、或打造全球声望。设想一下,你拥有一个全球的专业履历,收集了你在 Kauri 发布的技术文章、Gitcoin 的解决方案、在 Peepeth 的订阅内容,参加的区块链活动和聚会等等。链上存储是三个方案里最去中心化的一个。

劣势

主要的劣势在于将数据存储在主链上的花费波动大。为了减少花费,我们考虑采用类似 Peepeth 用到的批处理机制,在批写入主链之前,将最多 15 个操作存储在链下。我们推测,15 个操作的限制是基于一条 peep 消息 280 个字符的限制,以及 Peepeth 上的其它功能,比如用户关注。但 Kauri 和 Peepth 有本质的不同,即 Kauri 旨在处理大文件,而 Peepth 主要处理类似于发推文的操作。

减少花费的批量逐步升级(batch escalation)

在 Kauri 上逐步升级(escalating) 一批文章需要在把数据写进区块链之前,将不升级(non-esclated)的一系列文章存储在 MongoDB 数据库上,并在稍后取回。在获取不升级的文章时,系统会生成一个检查点文件,受托人要对根哈希和检查点哈希签名;检查点文件随后上传至IPFS,根哈希、检查点哈希和受托人签名再返回前端。前端提交前述所有信息到智能合约,智能合约则生成一个事件。智能合约成功提交后,IPFS 内的检查点文件进行更新。

批量逐步升级的方案,所有内容是存在 IPFS 上的。但这个索引会是中心化的,直到有人触发链上逐步升级或所有文章定期升级(例如每24小时、每隔一天、每周)。这个方案存在一个问题,即当用户把文章存在链下时,其他人可以盗取文章并宣布对文章的拥有权。

存储方案2:侧链索引

设置

侧链索引方案是将数据存储在一个将以太坊区块链作为底层的 Layer-2 侧链上。侧链会根据具体使用情景使用其自有的共识规则集,可以是权益证明 PoS、委任权益证明 DPoS、权威证明PoA,或其他协议。我们调研了 Loom网络PoA 网络 两个侧链方案的可行性。

优势

将文章数据迁移到侧链,用户仅能享受到主链提供的部分好处(例如安全,可及性、透明、众多参与者),而不是所有好处(例如失去容错性)。按定义,Kauri 侧链会更快而且免费,因为大概它会按权威证明 PoA 或委任权益证明 DPoS 共识机制运行在一个较低全局性的环境里。侧链与主链可双向交流,用户可以将侧链资产转移到主链。最后,其他侧链参与者可以在 Kauri 上和 Kauri 的侧链上开发。

劣势

为获得侧链 PoS/DPoS/PoA 共识规则带来的好处如速度提升和存储费用减少,用户损失了去中心化,尽管理论上说,用户能随时退出到主链上。此外,一旦所有参与者都关机(shut down),侧链也会遭受数据损失。也有可能 Kauri 起初只会有一个节点。

存储方案3:IPFS 上的只读公开索引

设置

在 Kauri 现有环境下,一个只读的公开索引会周期性地上传到 IPFS。上传者大概会是 Kauri 网络目前的维护人员,即Kauri团队。这个方案实施起来很简单,因为索引可以固定在每晚或每隔一晚或每周上传。

优势

采用 IPFS 上的公开索引方案,用户仍可以验证 Kauri 网络上数据的一致性。任何知道哈希值的用户都可通过 IPNS 快速访问。

劣势

在 IPFS 上,只有一个参与者可以通过一个静态的独一无二的名字发布索引。因此,这个方案是不抗审查的(因为它完全由 Kauri 维护)。而且,IPFS 上只读的公开索引会受限于速度,因为目前发布到 IPNS 上需时接近两分钟。

三种方案对用户的要求

方案一:链上索引 = 费用

对于链上索引方案,Kauri 用户信任主链,在主链上直接交易,支付相应 Gas 费用。对用户的主要要求就是交易费。一旦将索引写入区块链,它就能触达到其他 dApp 和其他区块链用户。

方案二:侧链索引 = 时间 & 难度

对于侧链上索引方案,在实施 Loom 或 POA 网络侧链的情况下,用户无需支付主链上的存储费用,但非常依赖退出侧链的路径,当发生任何恶意活动时,用户必须被立即导向退出侧链。退出侧链并不是瞬时的,因为存在挑战期。

方案三:IPFS 上的只读公开索引 = 时间 & 难度 & 不太去中心化

对于 IPFS 只读索引方案,用户需验证 Kauriz 中间件 API 上的数据的是否与公共索引一致。简而言之,用户不能只信任主链或侧链实现,还必须有 Kauri 运营者会一致、可靠且定期地上传索引的预期。

为什么向用户收取存储费用是明智的?

第一个解决方案,即链上索引依然是最具前景的 Web3 去中心化存储方案。用户支付的费用保证了索引在主链上是持久存在的,且数据能可靠地触达到其他 dApp 和其他以太坊区块链用户。侧链如果被可靠地实施起来,也能保证一部分去中心化优势。但它给用户带来了使用难度,因为数据必然从主链转移到侧链上,用户必须监控侧链上的恶意行为。IPFS 上的只读公共索引则偏离了区块链的去中心化,而转向在 IPFS 节点之间分发这个索引:这是一个只允许一名参与者以一个静态且唯一的名字发布索引的中心化环境。

找到一个安全高效且优雅的存储方案仍然是以太坊生态上的一个挑战。这个围绕安全、去中心化和可扩展性的三难问题不仅存在于扩容话题的讨论中,也影响对大文件内容的管理。但在批处理方案和侧链方案之间,产生了许多引人注意的去中心化存储方案。

在接下去几个月,随着开发者们为了解决扩展和存储问题而测试驱动这些 Layer 2 解决方案, Kauri 团队希望不仅是记录他们的进步,也把 Kauri 自身视作是积极开发 Web3 解决方案的众多 dApps 之一。

免责声明:作者上述观点不代表 Consensys AG 的观点。ConsenSys 是一个去中心化社区,ConsenSys Media 是社区成员自由表达各种观点和想法的平台。更多关于 ConsenSys 和以太坊的内容,请访问我们的官网。


原文链接: https://media.consensys.net/the-forgotten-side-of-decentralization-f713aaa8c8b4
作者: Kauri Team
翻译&校对: 夏丹 & 阿剑


你可能还会喜欢:

引介 | 剖析以太坊的存储成本
干货 | 为什么去中心化和分布式存储对一个更好的互联网至关重要?
干货 | 公有链的基本挑战: Part 2

本文来源于互联网:引介 | Web3 上的内容何去何从?

原创文章,作者:酷毙编辑,如若转载,请注明出处:http://www.dailybtc.cn/%e5%bc%95%e4%bb%8b-web3-%e4%b8%8a%e7%9a%84%e5%86%85%e5%ae%b9%e4%bd%95%e5%8e%bb%e4%bd%95%e4%bb%8e%ef%bc%9f/

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

在线咨询:点击这里给我发消息

邮件:[email protected]

工作时间:周一至周五,9:30-18:30,节假日休息

QR code