去中心化最具挑战、又最受忽视的众多方面之一就是存储。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主要处理类似于发推文的操作。

    减少花费的批量逐步升级（batchescalation）

    在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共识规则带来的好处如速度提升和存储费用减少，用户损失了去中心化，尽管理论上说，用户能随时退出到主链上。此外，一旦所有参与者都关机（shutdown），侧链也会遭受数据损失。也有可能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节点之间分发这个索引：这是一个只允许一名参与者以一个静态且唯一的名字发布索引的中心化环境。

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

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