作者: Alexey Akhunov
翻译 & 校对: 阿剑 & 曾汨
编者注：这篇文章来自 Alexey Akhunov。他是完全专注于以太坊 1.0 的一位开发者。
不少人应该还记得，当整个区块链社区目睹以太坊的状态数据迅速增长，对节点的存储设备性能提出越来越高要求的时候，社区提出了多种解决方案，其中一种就是名噪一时的「状态租金」，即对在状态中存储数据的合约收取租金。
一如文中所述，Alexey 是长期以来唯一全职研究状态租金方案的开发者，如今，他也表示会中止状态租金的研究，转向无状态客户端。我想，这也意味着在以太坊上开发状态租金的努力落下帷幕。
我并不是可惜，事实上我从未支持过状态租金方案。我是想说，工程项目就是如此，会不断遭遇问题，也不断会有新点子冒出来，也会有很多点子日后被证明是不行的。以为提一提解决方案的概念，就算是解决了问题，是对工程的无知，也是轻视。
Alexey 加油！
我本来早该写这篇文章了。不过亡羊补牢，尤为未晚。
最新出版的一个状态租金提案是 3 号方案，但那是在 2019 年 2 月出版的，是很久以前的事情了。
写完这个方案后，我开始考虑如何才能靠谱地落实这个项目。而且，在很久以前，大家就已经意识到，我们绝对需要一种我称之为「生态系统研究」的项目。怎么说呢？
我们在以太坊状态问题研究一开始的时候（最初的提案是在 2018 年 11 月提出的）的知识是：如果对合约存储引入成比例的状态租金（「成比例」意味着合约所交的租金与其所用的状态存储空间是成比例的），会导致当前已有的合约出现漏洞，易受「griefing」攻击（译者注：大意为损人不利己的攻击），因此某些人可以用一笔很小的固定费用导致合约必须永续付出一些租金，最终导致合约的崩溃。
我们同样也假设，大部分乃至所有 dApp 都可以重写成免疫此类攻击的形式。一个值得注意的例子是 ERC-20 代币实现的一个版本。虽然这是一个好的开头（我在当时的估算表明，约有一半的合约存储都被多种 ERC-20 合约的余额和和备用金占据着），但 dApp 的长尾可能非常长（译者注：即类型很多）。
在这种情景下，所谓的「生态系统研究」，就是要细致地分析 dApp 的长尾、重写成免疫漏洞的形式，并与这些 dApp 的维护人员和用户沟通、为变化做好准备。现在已经很清楚了，如果没有这样的「生态系统研究」，向状态租金制度的迁移几乎不可能成功。
不过，也不难意识到，这样的「生态系统研究」是非常艰巨而且非常昂贵的（可能要小几百万美元吧）。我当然不愿意自己动手，这很大程度上是因为我不认为（到现在也仍然不认为），这是我能创造最大价值、获得最多成就感的工作。而且，据我所知，我是事实上唯一全职研究状态租金方案的人，因此我的结论是：这是搞不定的，我们需要另一个计划。
然后，我回到了在投入状态租金项目以前「抛弃」（或者说「忽视」）的想法，叫做「无状态客户端」，或者我现在的称呼是「无状态的以太坊」。我一开始对这个方案产生兴趣是在 2017 年末（在 这篇文章 里滚动到底部就可看见），然后是在开发 Turbo-Geth 项目期间。我最初的怀疑基于这样一个事实：区块见证数据的大小可能相当大。但现在我们回到这个观念，我们正在追问：「有多大」以及「我们能缩小数据吗」？而这篇文章就是我找寻答案的初步尝试。（编者注：中译本见文末超链接《无状态客户端初探》）
我们也知道了，很有可能，相对于使用二叉树，以太坊所用的十六进制默克尔树会让区块见证数据更大（更多数据很快就会披露出来）。但看起来让以太坊 1.0 转用二叉树也是一项不可能完成的任务。如果你想问：「为什么？」答案是，因为我们假设我们在数据库中存储状态的方式会维持原样（即将数据模块化为有向图谱，从哈希值到树节点的指向即为有向图之一边）。不过，如果我们改变了这种模式，Turbo-Geth 切换为二叉树就是非常直接的事情。这也是为什么我当前的最高优先事项之一就是「完成」Turbo-Geth，即处理所有例外情形并提供充分的证据来证明：它的数据模型是可以行得通的，而且也可以被其他实现所接受。
总结一下，状态租金项目当前已经「暂停」了。而当前积极的研究、开发和技术详述主要围绕着「flat db」状态存储模型以及无状态以太坊。自我在三月份写下那篇博客以来，我们又取得了一些进步，我希望能得到更多数据并尽快发表出来。目前你可以到这个网页看看我们当前用来构造区块见证数据的格式；你还可以从中看到 Turbo-Geth 的进展，它已经有望接近「稳定」阶段了（我们仍在大量改动数据格式，因此在完成这部分工作以前，都还称不上是「稳定的」）。
—-
编译者/作者：区块律动BlockBeat
玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。
|
