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

作者:Vitalik Buterin
编译:LeftOfCenter

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

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

对此,Vitalik Buterin 发布一系列推文进行了回复:
Vitalik Buterin:无状态客户端的存储范式是基于「市场化存储」的产物
从历史上看,区块链协议已将数据存储的可用性视为公共资源:所有全节点都存储所有交易信息,使用这些存储资源会对所有其他用户产生成本,使用这些数据必须收费。这就产生了一系列难题,包括「如何为存储定价、目标存储空间是多少,以及存储到底应该是临时存储还是永久存储,租赁方案是什么等等一系列问题 」。

image (2).jpg

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

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

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

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

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

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

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

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

来源链接:twitter.com