Over the last two days, I’ve been optimizing a smart contract library which performs merkle-patricia proof verification for advanced commit-reveal schemes.
Before this project, I was often satisfied with heuristics such as “put storage data in structs” and “never use a for loop” in order to avoid egregious gas expenses. Although these heuristics can go a long way, I wanted to see if I could discover a few other perhaps more subtle heuristics which could save me a gas or two.
Declaring variables to memory.
When writing complex logic in a function, I’ve often found myself repeatedly reading the same storage variable. As it turns out, thats not the best idea.
A variable should be declared to memory if used more than once in a function.
The SLOAD opcode which reads a data word from storage costs 200 gas whereas the MSTORE and MLOAD opcodes which write and read from memory cost only 3 gas each.
The following code demonstrates the heuristic:
Using the right type.
My intuition told me I should always use the smallest possible datatype to prevent reserving space I know I will never use. Yet again, my intuition mislead me.
The most optimized storage type is always 32 bytes / 256 bit long unless struct packing is possible.
Any storage is compiled down to a byte array which is stored in the storage merkle-patricia tree of the contract. Each item in this byte array needs to consist of 32 bytes (256 bit). This means any smaller data is padded with zeros to fill the 32 bytes which requires additional operations from the EVM and costs more gas!
The following code shows the difference between declaring a uint256 and uint128 in storage.
Struct packing subtleties.
I’ve mentioned a couple times already that struct packing is a good heuristic. When I learned this heuristic, I started putting all my storage data in structs. As it turns out, there are some subtleties to address.
Struct packing only works when the combined data is a multiple of 32 bytes.
In the previous heuristic, we mentioned data gets padded to 32 bytes. Inside a struct, it’s possible to place multiple datatypes which add up to 32 bytes yet behave like a single 32 bytes object when stored. However, the following subtleties apply:
- Putting a 32 bytes type in a struct is more expensive than keeping it outside.
- Packing works in multiples of 32 bytes therefore putting a type smaller than 32 bytes alone in a struct does not cause any saving.
- It’s possible to pack numbers and strings together.
Thats it for now!
If you have any heuristics/subtitles to share, give me a shout @thegostep
My friend Hernando Castano shared a great article which covers the details of implementing quicksort in solidity. Worth a read!
Happy optimizing! 😄
