总结一下，状态租金项目当前已经 “暂停” 了。而当前努力的研究、开拓和技能详述主要环绕着 “flat db” 状态存储模子以及无状态以太坊。自我在三月份写下那篇博客以来，我们又取得了一些进步，我但愿能获得更大都据并尽快颁发出来。今朝你可以到 这个网页 看看我们当前用来结构区块见证数据的名目；你还可以从中看到 Turbo-Geth 的希望，它已经有望靠近 “不变” 阶段了（我们仍在大量窜改数据名目，因此在完成这部门事情以前，都还称不上是 “不变的”）：https://github.com/ledgerwatch/turbo-geth/issues。

在这种情景下，所谓的 “生态系统研究”，就是要细致地阐明 dApp 的长尾、重写成免疫裂痕的形式，并与这些 dApp 的维护人员和用户相同、为变革做好筹备。此刻已经很清楚了，假如没有这样的 “生态系统研究”，向状态租金制度的迁移险些不行能乐成。

写完这个方案后，我开始思量如何才气靠谱地落实这个项目。并且，在好久以前，各人就已经意识到，我们绝对需要一种我称之为 “生态系统研究” 的项目。怎么说呢？

我原来早该写这篇文章了。不外亡羊补牢，尤为未晚。

我们在以太坊状态问题研究一开始的时候（最初的提案是在 2018 年 11 月提出的）的常识是：假如对合约存储引入成比例的状态租金（”成比例” 意味着合约所交的租金与其所用的状态存储空间是成比例的），会导致当前已有的合约呈现裂痕，易受 “griefing” 进攻（译者注：大意为损人倒霉己的进攻），因此某些人可以用一笔很小的牢靠用度导致合约必需永续支付一些租金，最终导致合约的瓦解。

（完）

最新出书的一个状态租金提案是 3 号方案，但那是在 2019 年 2 月出书的，是好久以前的工作了。

不外，也不难意识到，这样的 “生态系统研究” 长短常难题并且很是昂贵的（大概要小几百万美元吧）。我虽然不肯意本身动手，这很洪流平上是因为我不认为（到此刻也仍然不认为），这是我能缔造最大代价、得到最多成绩感的事情。并且，据我所知，我是事实上独一全职研究状态租金方案的人，因此我的结论是：这是搞不定的，我们需要另一个打算。

原文链接:

以太坊本文来历： 以太坊喜好者 文章作者：以太坊喜好者 我要纠错

我们同样也假设，大部门以致所有 dApp 都可以重写成免疫此类进攻的形式。一个值得留意的例子是 ERC-20 代币实现的一个版本。固然这是一个好的开头（我在其时的估算表白，约有一半的合约存储都被多种 ERC-20 合约的余额和和备用金占据着），但 dApp 的长尾大概很是长（译者注：即范例许多）。

然后，我回到了在投入状态租金项目以前 “丢弃”（可能说 “忽视”）的想法，叫做 “无状态客户端”，，可能我此刻的称号是 “无状态的以太坊”。我一开始对这个方案发生乐趣是在 2017 年尾（在 这篇文章 里转动到底部就可瞥见），然后是在开拓 Turbo-Geth 项目期间。我最初的猜疑基于这样一个事实：区块见证数据的巨细大概相当大。但此刻我们回到这个见识，我们正在追问：”有多大” 以及 “我们能缩小数据吗” ？而这篇文章就是我找寻谜底的劈头实验。（编者注：中译本见文末超链接《无状态客户端初探》）

翻译 & 校对: 阿剑 & 曾

作者: Alexey Akhunov

声明：本文由入驻金色财经的作者撰写，概念仅代表作者本人，毫不代表金色财经附和其概念或证实其描写。

https://medium.com/@akhounov/on-the-state-rent-and-pivot-to-stateless-ethereum-ab4d967ff630

我们也知道了，很有大概，相对付利用二叉树，以太坊所用的十六进制默克尔树会让区块见证数据更大（更大都据很快就会披暴露来）。但看起来让以太坊 1.0 转用二叉树也是一项不行能完成的任务。假如你想问：”为什么？” 谜底是，因为我们假设我们在数据库中存储状态的方法会维持原样（即将数据模块化为有向图谱，从哈希值到树节点的指向即为有向图之一边）。不外，假如我们改变了这种模式，Turbo-Geth 切换为二叉树就长短常直接的工作。这也是为什么我当前的最高优先事项之一就是 “完成” Turbo-Geth，即处理惩罚所有破例景象并提供充实的证据来证明：它的数据模子是可以行得通的，并且也可以被其他实现所接管。

编者注：这篇文章来自 Alexey Akhunov。他是完全专注于 1.0 的一位开拓者。

（文内提供了很多超链接，请点击阅读原文到 EthFans 网站上获取）

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。