Vitalik Buterin：无状态客户端的存储范式是基于「市场化存储」的产物

不妨引入一种基于市场的存储方式：对于每一个状态对象，总有一些用户从该对象中的可用性中获益，而其他用户则愿意存储它。因此，我们通过让使用者直接与存储者签约，以确保其可用性。

作者：Vitalik Buterin 编译：LeftOfCenter 来源：FxAjax ChainNews

ENS 与 ZK Labs 研究员 Dean Eigenmann 发布推文质疑无状态执行环境（EEs）的可行性，表示「对我来说，无状态执行环境（EEs）看起来像是一个糟糕的解决状态增长的方案。我认为它不具可行性，激励过于复杂，导致 ETH2.0 的解决方案不够优雅」。并 @VitalikButerin，询问采用无状态执行环境（EEs）的理由到底是什么？

对此，Vitalik Buterin 发布一系列推文进行了回复：

从历史上看，区块链协议已将数据存储的可用性视为公共资源：所有全节点都存储所有交易信息，使用这些存储资源会对所有其他用户产生成本，使用这些数据必须收费。这就产生了一系列难题，包括「如何为存储定价、目标存储空间是多少，以及存储到底应该是临时存储还是永久存储，租赁方案是什么等等一系列问题 」。

因此，不妨引入另外一种基于市场的存储方式：对于每一个状态对象，总有一些用户从该对象中的可用性中获益，而其他用户则愿意存储它。因此，我们通过让使用者直接与存储者签约，以确保其可用性。

当然，以市场为基础的范式承认，一旦用户疏忽，状态中的某些特定部分将会「消失」， 但是任何基于市场的技术都会遇到这个问题。

因此，有一种观点认为，我们可以利用这种私下签约方式，但是，就其 UX 便利性而言，协议确实应该保证状态的可用性和供给。

无状态客户端的存储范式，正是基于「市场化存储」的产物。

「市场化存储」的一个优点是，用户可为不同级别的可用性保证支付不同金额的费用。但有人可能会质疑，要求用户考虑存储的可用性会使 Dapp 开发的复杂度增加 2 倍。

那么，可以考虑一下折衷路线。比如，在执行环境的范例中，可增加一个「要求区块生成者在区块中必须包含不到一年的随机存储密钥」的执行环境，提供 1 年保证期的状态储存。

但这会留下大量实验的空间，导致出现多个不同程度的状态，例如，如果你只想保留一个「静态见证」的属性，那么可以让该状态占据用过的收据 ID 的一个位域。也就是说，显而易见的是，eth2 将在很大程度上依赖于轻客户端和服务器市场，至少让用户了解到，1000 多个分片是处于未完全同步的状态。

我们还可以采取协议级别的措施来强化状态存储保障，比如，在某些类型的收据上添加 1 年期限的托管证明。

来源链接：twitter.com