以太坊 1.x 的扩展极限

我尚未看到有人直截了当地讨论这个问题，以是在 Fellowship of ETHereum Magicians 这里写个帖子应该会蛮有意思的。

我想试着回覆这个问题：从理论上来说，在当前的以太坊 1.x 链上（也就是不使用分片），扩展的极限在那里。我倾向于用纯理论方式来讨论这个问题，也就是从一个项目治理的角度出发，而不是给出一个严酷科学的谜底或真的要去实现这样的扩展。若是看起来极有可能在现有链上获得大幅度的性能提升，那么为“扩展以太坊 1.x”作出的更为果敢的行动和投资即是合理的。

我已经跟 @fredhr、@jpitts、@AlexeyAkhunov、EWA 团队的几位成员讨论过，而 @karalabe最近也在 ETH 1.x板块中讨论同样的主题，以是，这篇帖子应视为我自己对这些讨论的归纳和结论。

所有在此处列明的看法都有一个配合的条件：实现它们无需重大的协议层换取，也不会与 Serenity 要引入的诸多换取相冲突。许多方案实现起来甚至都不需要硬分叉；大多数不会涉及协议层换取。少数几样虽然毫无疑问是对照激进的，但也“不需要重大的协议层换取”，固然，何谓“重大”也是见仁见智的器械。

我们这里不谈判到还停留在纸面上的、“有一天也许会实现”的手艺；都是已经在其它地方获得证实 以及/或者 经由充实研究的手艺。好比，我在下文就不会把 STARK 包罗进去，它们现在的形式似乎还不能用。

可行的扩展手艺及其理论上的极限，开列如下，大致以 可行性/可信度 排列：

降低叔块率，缩短区块处置时间（讨论可见此处）：10 倍

使用更好的数据结构提高 I/O 读写速率（看法泉源：@AlexeyAkhunov）：4 倍

通过状态租金或无状态客户端限制账户/存储树的增进（看法泉源：我自己的设想，以及与 @AlexeyAkhunov讨论的功效：I/O 负载降低后，区块处置的速率可以更快，而限制了状态之后，我们便可以随时间推移从硬件升级中看到越来越显著的 I/O 效果）：5 倍

区块预宣布（pre-announcement）、状态预盘算（pre-warming）（看法泉源：@AlexeyAkhunov）：5 倍

类似于 Bitcoin-NG 的 leader 选举和区块提议（看法泉源：分片 Wiki）：50 倍

EWA 以及 JIT 汇编（泉源：@gcolvin在去年做的基准测试事情，这里是代码和讨论）：50 倍（modulo concerns about JIT safety）

并行处置生意（泉源：EWA 团队的内部讨论）：50 倍

多维度 Gas/计量（Gas 是一个钝器，设计得过于守旧；若是我们可以，好比说，将 I/O 读写和盘算的 Gas 计量尺度星散开来，我们就可以在区块中塞入更多生意）（泉源：我自己）

单纯将所有这些数字相乘，你可以得出 18.7 亿倍的扩展规模，但这显然是虚高的，由于：（1）这内里估量的都是“理想状态”，但许多方案都可能得不到理想的实现；（2）这假设了所有方案之间都完全没有冲突，显然是不现实的。

然则，即便我们假设只有 10% 的方案可以得出功效，而且其中只有 1% 的理想性能/无冲突性，那也另有 187.5 万倍。这照样一个很高的数字，有可以起劲的空间。

上述讨论中另有一个显著的弱点，即这些都是“自上而下”的设想，不是“自下而上”的方案，即，可能这些看法在理论上都是行得通的，但到了要在现有的客户端上实现的时刻才会发现它们并不是那么好用，这个历程甚至要花掉跟开发 Serenity 一样长的时间（例如：无状态客户端，就面临着糟糕的用户体验挑战），或是可能会损坏掉其余一些属性（例如：可用性），又或者相互之间着实无法兼容。

另一个忠告是，正如 @karalabe和 @AlexeyAkhunov在他们的 ETH 1.x 提案中注释的那样，任何扩展的实验都市立刻增添状态和存储的数据巨细，以是，这才是所有有意义的扩展方案（包罗 1.x 和 2.0）的现实瓶颈所在。

**，也许单链的扩展有着不能逾越的限制因素，好比说 同步时间（也允许以通过无状态客户端来缓解）以及 I/O 读写速率上限。

请列位告诉我，我还遗漏了什么器械，或者哪一点上搞错了。

总而言之，我讨论这个主题并不是要形成任何详细的扩展方案，更多是从抽象的、项目治理的视角，来思索到底是要再投资 ETH1.x，照样完全投身 ETH2.0 。