我尚未看到有人直截了当地讨论这个问题，所以在 Fellowship of Ethereum Magicians 这里写个帖子应该会蛮有意思的。
我想试着回答这个问题：从理论上来说，在当前的以太坊 1.x 链上（也就是不使用分片），扩展的极限在哪里。我倾向于用纯理论方法来讨论这个问题，也就是从一个项目管理的角度出发，而不是给出一个严格科学的答案或真的要去实现这样的扩展。如果看起来极有可能在现有链上获得大幅度的性能提升，那么为“扩展以太坊 1.x”作出的更为果敢的行动和投资便是合理的。
我已经跟 @fredhr、@jpitts、@AlexeyAkhunov、EWASM 团队的几位成员讨论过，而 @karalabe 近来也在 Eth 1.x 板块中讨论同样的主题，所以，这篇帖子应视为我自己对这些讨论的归纳和结论。
所有在此处列明的观念都有一个共同的前提：实现它们无需重大的协议层变更，也不会与 Serenity 要引入的诸多变更相冲突。许多方案实现起来甚至都不需要硬分叉；大多数不会涉及协议层变更。少数几样最然毫无疑问是比较激进的，但也“不需要重大的协议层变更”，当然，何谓“重大”也是见仁见智的东西。
我们这里不会谈到还停留在纸面上的、“有一天也许会实现”的技术；都是已经在其它地方得到证明 以及/或者 经过充分研究的技术。比如，我在下文就不会把 STARK 包括进去，它们现在的形式似乎还不可用。
可行的扩展技术及其理论上的极限，开列如下，大致 以 可行性/可信度 排列：
单纯将所有这些数字相乘，你可以得出 18.7 亿倍的扩展规模，但这显然是虚高的，因为：（1）这里面估计的都是“理想状况”，但许多方案都可能得不到理想的实现；（2）这假设了所有方案之间都完全没有冲突，显然是不现实的。
但是，即便我们假设只有 10% 的方案可以得出成果，并且其中只有 1% 的理想性能/无冲突性，那也还有 187.5 万倍。这还是一个很高的数字，有可以努力的空间。
上述讨论中还有一个明显的弱点，即这些都是“自上而下”的设想，不是“自下而上”的方案，即，**可能这些观念在理论上都是行得通的，但到了要在现有的客户端上实现的时候才会发现它们并不是那么好用，**这个过程甚至要花掉跟开发 Serenity 一样长的时间（例如：无状态客户端，就面临着糟糕的用户体验挑战），或是可能会破坏掉别的一些属性（例如：可用性），又或者相互之间实在无法兼容。
另一个警告是，正如 @karalabe 和 @AlexeyAkhunov 在他们的 ETH 1.x 提案中解释的那样，**任何扩展的尝试都会立即增加状态和存储的数据大小，所以，这才是所有有意义的扩展方案（包括 1.x 和 2.0）的实际瓶颈所在。
**
最后，也许单链的扩展有着不可逾越的限制因素，比如说 同步时间（也许可以通过无状态客户端来缓解）以及 I/O 读写速度上限。
请各位告诉我，我还遗漏了什么东西，或者哪一点上搞错了。
总而言之，我讨论这个主题并不是要形成任何具体的扩展方案，更多是从抽象的、项目管理的视角，来思考到底是要再投资 ETH1.x，还是完全投身 ETH2.0 。
谢谢！
@AlexeyAkhunov：
区块预处理、状态预计算
这一方案其实已经在一定程度上被引入了—— Geth 的一个最近版本高效地把合约存储项包含在了状态缓存中（我不太了解 Parity 的情形，但 Turbo-Geth 从一开始就在开发这一方案）。这意味着，如果你是一名矿工，并且正在挖某个块，但是别人抢先了，你需要先加载你自己的区块才能开始挖下一个。但是，因为你想挖并且加载的块和别人挖出的块很可能有着几乎相同的交易集合，你的缓存相当于是预热了，摒弃哦加载也会变得更快。
这可能还意味着（意外的收获），那些挖空块的矿工在一定程度上受到了惩罚。
但是，即便我们假设只有 10% 的方案可以得出成果，并且其中只有 1% 的理想性能/无冲突性……
我怀疑大部分方案都不是基于现在的以太坊的，而是基于许多东西已经升级的条件下。所以，它们没法直接组合在一起。我更愿意把这些数字直接相加，而不是相乘。
我讨论这个主题并不是要形成任何具体的扩展方案，更多是从抽象的、项目管理的视角
我支持这种倾向（我当然支持），我同样也认为，我们可以让以太坊 1.0 变得更可变更（其中一种思路是让客户端不再支持所有历史规则，这样就可以让客户端变得更简单——这样也可以砍掉历史上的测试——正如我在 “后向-前向同步讨论帖” 中说的那样）。
@Chandan：
187 万倍扩展意味着单区块大小从 24K 乘以 187 万倍（接近 30 GB）
你想让以太坊的网络层分发 30 GB 到全网 10000 个全节点吗？
区块大于 1MB 就变得不可控了，所以理论上的扩展极限是 40 倍才对。
@Lane Rettig：
Hmm。我很确定我们可以实现更高的扩展，比如使用像 zk-SNARK 这样的压缩技术，但对于我们这里的讨论来说，显得过于理论化了。
@fubuloubu：
40 倍已经不错了，平均来说就是每天 5200 万笔交易。如果 Layer-2 可以普及并实现 100 倍扩展，那我们就已经是使用少数升级实现重大扩展了。
上面的思路确实很棒，但状态削减似乎才是几乎所有方案的瓶颈，因为不然的话一台普通的电脑就没法在长期中完全同步了。那么状态削减现在是第一优先级吗？我们倒是可以做出一个 40 倍扩展的原型，但状态大小还是会成为瓶颈。而且，光是削减状态大小本身也可以提高吞吐量。
同样地，我觉得不言而喻的是，任何 Serenity 之前发布的创举都很有可能被直接运用。这可能意味着，现在的扩展性提升在长期中也就是分片的扩展性系统，在我看来完全值得投资。
@gcolvin：
编译好的 EVM 在那些标准测试中跟 EWASM 一样快甚至更快。Same safety concerns，请看 https://github.com/gcolvin/evm-drag-race/blob/master/time-vs-gas.pdf。
@Idct：
考虑扩展的硬上限，例如，一个节点每秒可以执行多少次 ecrecover()，或者符合节点网络带宽的交易数据速率，等等，可能有助于判断哪个方案是在解决哪个问题、帮助回答你提出的问题。
原文链接: https://ethereum-magicians.org/t/hypothetical-maximum-scale-of-eth-1-x/2264
作者: Lane Rettig, etc.
翻译&校对: 阿剑
