6

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.

Improve this question

2 Answers 2

Reset to default
4

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.

Improve this answer
6
  • 1
    Moving to 64-bit is an extremely important upgrade to Ethereum, and the use of 256-bit machine was a mistake. Ismael, how much machine code have you written? The way that you are speaking of registers makes me think that you don't understand machine code. Using a 32-bit machine would not impact security and would lower gas fees due to wasted space - more so than even a 64bit machine because we would be storing fewer 0s. The fact that the bool type wastes 255 bits drives me nuts.
    – rook
    Aug 2, 2022 at 18:36
  • 1
    @rook Don't attack the person, but the argument instead. With the information available today and the project needs I'd go for a 64 bits VM, but 7 years ago the experience wasn't the same. If you feel capable write the 64 bits EVM and propose the change to the EF. If it is good it will be accepted, you will get any job you want and paid accordingly. It is easy to talk, writing something that works is much harder.
    – Ismael ♦
    Aug 2, 2022 at 22:51
  • 1
    -My apologies. It doesn't matter how many registers a variable occupies because these machines should have an opcode that can do multiple register comparisons. By making all variables 256bits you end up storing more zeros than actual data, and that is what we are seeing. I would gladly write this VM, this isn't difficult because it's nothing new. The first EVM was entirely new, and that was hard to do - and i have compassion for that. But now that we can see that the EVM stores more empty space than real data - we have real problem.
    – rook
    Aug 2, 2022 at 23:57
  • 1
    Actually, if they need engineers on this project I have a great resume. So for this case - x86 has 8 general purpose registers- which means on a 64bit system two full 256bit keys can be loaded - and then a comparison is then a single operation. The EVM should follow this pattern, who do I need to talk to?
    – rook
    Aug 3, 2022 at 1:44
  • 2
    @rook The Ethereum Foundation and other organizations have grants programs that anyone can apply, ethereum.org/en/community/grants. Before applying I'd suggest to participate in some of the forums and look for others research interests like ethresear.ch.
    – Ismael ♦
    Aug 3, 2022 at 18:10
3

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.

Improve this answer
2
  • 2
    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, 2018 at 10:59
  • So once we migrate to PoS, there has much more space to improve the architecture of EVM?
    – Howard
    Sep 14, 2022 at 6:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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