基于64位的EVM不是更有效吗？

Question

正如以太理论设计所述：

32字节字大小--可选为4或8个字节字，就像大多数其他架构中的那样，或者是无限制的，如比特币。对于加密计算来说，4或8个字节字的限制太小，无法存储地址和大值，而且无限的值太难建立一个安全的gas模型。32字节是理想的，因为它仅仅大到足以存储许多密码实现中常见的32字节值以及地址(并提供了将地址和值打包到一个存储索引中作为优化的能力)，但并不是那么大，以至于效率极低。

但问题是：

• 256位EVM实现有助于处理地址，这是正确的。但是，由于Ethereum没有被定义为加密货币系统，所以数据中最重要的部分不是地址，而是智能契约上使用的数据。
• 如果市面上CPU的大部分实际上是用64位架构制造的，而我们在Ethereum生态系统上使用的数据中有很大一部分是相同的(64位、32位、16位、8位)。你认为基于64位架构的EVM或类似的东西不会改善整个系统的性能吗？

想想看，如果你必须迭代一个32或64位数据的数组，而EVM内存块是256位，那么CPU进行计算是额外的工作，而且浪费了很多时间。

如果你认为这是一个可能的改进，是否有任何主动或EIP开放？我什么都没看到。

谢谢。

Answer 1

你会有几个问题

• 如果您将存储保持在256位，那么访问起来就会更加复杂。您需要4x64位字来寻址存储槽。所有操作都必须将256位转换为64位。您的EVM实现和审计将非常复杂。
• 如果您将存储切换到使用64位，那么EVM将更简单，但是存储要小得多，碰撞的可能性更大。
• 您不能以本地方式表示地址。地址是20个字节，您需要3x64位寄存器。
• 您需要与旧合同向后兼容，并且必须实现某种类型的翻译。

CPU不是瓶颈。当然，还有更好的VM (还有关于用WASM替换它的研究)，但是当前的实现正确地完成了它的工作。

更重要的问题是IO，每个事务都有几个对Ethereum状态的修改。一个块大约有100个事务，每15秒生成一个块。

Answer 2

当然，很难确定，但我的直觉是，瓶颈不是单词的大小。瓶颈是有目的地施加14秒的阻塞时间。阻塞时间是一个参数，最初的设计师选择迫使矿工以电的形式消耗能量。即使您在系统的其他地方进行了优化，14秒也不会消失，因此优化不会自动显示出来。