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.