# Why are storage slot values in the EVM limited to 256 bits?

Why is the EVM limited to saving 256 bits in storage slots?

I've seen this post:
Rationale behind 256-bit words in EVM

But the answer doesn't quite explain why storage slot values are limited to 256 bits.

Obviously it puts lots of constraints on higher-level languages, such as Solidity, forcing them to come up with sophisticated and inaccessible storage layouts for dynamic values.

Technically LevelDB/RocksDB/etc can hold more than 256 bits (e.g. block headers), so why was the EVM limited to 256-bit slots?

• I think the answer you linked are very good. And honestly it all makes practical/mathematical sense. They had to chose size that fits in 2^x bits. Most virtual machines, and operating systems are either 32 or 64 bits (2^5 or 2^6). But EVM has to account for the address type of variable (160 bits), meaning that 2^8 is the lowest number that can fit such variable. (2^7 = 128bits < 160bits). Therefore 2^8=256bits>160bits was a logical choice.
– Sky
Commented Dec 26, 2022 at 21:14
• @Sky i am asking about storage on disk, not in memory. Commented Dec 27, 2022 at 8:09

Overall, the use of 256-bit words in the EVM is a trade-off that enables the EVM to support a wide range of data types and cryptographic operations, while also maintaining a relatively simple and efficient design.

The EVM is a stack-based virtual machine that operates on a set of fixed-size word registers, with each word being 256 bits in size. Of course the underlying database could support dynamic sizes for storage slots, but incorporating this into EVM would add to complexity of its design.

Although there was some controversy for a while, discussions with Gavin, Andrew and others led to establishing that the size of values on the stack should be limited to 32 bytes; the other alternative being considered, unlimited-size integers, had the problem that it was too difficult to figure out how much gas to charge for additions, multiplications and other operations.

• The main thing i am interested in is your last sentence - do you have any resources on how it complicates the design? JVM, V8, etc, all support writing and reading unlimited streams of data from disk. Is there any discussion explaining why the EVM doesn't support that? Thank! Commented Dec 27, 2022 at 8:12
• @Tudmotu see the edited answer Commented Dec 27, 2022 at 22:22
• Similarly to the answer I linked to, this discusses the stack, not the storage. The JVM supports 32-bit words on the stack yet is still able to read gigabytes from disk. Would love to find a resource explaining what makes the EVM different than the JVM in that regard. Thanks for the effort tho! 🙏🏼 Commented Dec 29, 2022 at 9:13
• Tudmotu: this is connected with each other, because the EVM can only load/store from storage to stack and all operations are done on the stack. So if you allow dynamic sizes for the storage, you have to allow dynamic sizes for the stack, which increases the complexity as described above. Commented Dec 29, 2022 at 9:30

I believe the storage slot values in the EVM limited to 256 bits mainly because this facilitates Keccak256 hash scheme and elliptic-curve computations. Also, the EVM is a 256-bit word machine that if operates other than 256 bits would require extra steps.

See:

Why are timestamps stored in a uint (256 bit) when they would fit in a uint64?

• Thank you, but I am asking about the slot values, not the slot keys. Why can't I save 512 bits in a single slot? Commented Dec 27, 2022 at 8:16