3

As the Ethereum Rationale design says:

32 byte word size - the alternative is 4 or 8 byte words, as in most other architectures, or unlimited, as in Bitcoin. 4 or 8 byte words are too restrictive to store addresses and big values for crypto computations, and unlimited values are too hard to make a secure gas model around. 32 bytes is ideal because it is just large enough to store 32-byte values common in many crypto implementations, as well as addresses (and provides the ability to pack address and value into a single storage index as an optimization), but not so large as to be extremely inefficient.

But the thing is:

  • A 256 bit EVM implementation helps in order to work with addresses, and that's true. But as Ethereum isn't defined as a Cryptocurrency system, so the most important part of the data wouldn't be addresses, would be data used on smart contracts.
  • If the majority of the CPU's on the market actually are made with a 64-bit architecture, and a high percentage of the data which we work with on Ethereum Ecosystem is approximately the same (64 bit, 32 bit, 16 bit, 8 bit..). Do you think an EVM based on a 64-bit architecture or something like that wouldn't improve the performance of all of the system?

Think about it, if you have to iterate an array of 32 or 64 bit data and the EVM memory blocks are 256-bit, it's extra work for the CPU to do the calculations, and a lot of time is lost.

If you think this would be a possible improvement to do, is there any initiative or EIP open? I haven't seen anything.

Thanks.

2

You will have several problems

  • If you keep your storage at 256 bits it will be more complex to access. You need 4 x 64 bits words to address a storage slot. All operations will have to convert 256 bits to 64 bits. Your EVM will be quite complex to implement and audit.

  • If you switch storage to use 64 bits then your EVM will be more simple but storage is much more smaller, and collisions much more likely.

  • You cannot represent addresses natively. Addresses are 20 bytes and you will need 3 x 64 bits registers.

  • You need backward compatibility with old contracts, and you will have to implement some sort of translator.

The CPU is not the bottleneck. Sure there are better VM (And there's research about replacing it with WASM), but the current implementation does its job correctly.

The more important issue is IO, each transaction has a couple of modifications of the Ethereum World state. And a block has around one hundred transactions, and one block is generated each 15 seconds.

1

Of course, it’s difficult to say for sure, but my intuition is that the bottleneck is not the size of the words. The bottleneck is the purposeful imposition of the 14 second block time. The block time is a parameter that the original designers chose to force the miners to expend energy in the form of electricity. Even if you optimized elsewhere in the system, that 14 seconds would not disappear, so the optimization wouldn’t manifest itself.

  • 1
    Yep but with the transition to PoS, and other consensus methodologies, it's not that important that fixed block time, and more important stuff like this EVM implementation. Thats why I asked for that. – CPereez19 May 27 '18 at 10:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.