Uniswap
Make pool `tickBitmap` and `ticks` storage continuous
Component
Gas Optimization
Describe the suggested feature and problem it solves.
The idea is to change the storage slot derivation for the pool.tickBitmap and pool.ticks mappings from hash-based to offset-based.
This is beneficial because it makes cheaper to compute the slot of multiple subsequent slots. Rather than performing a keccak for every bitmap word or tick struct (~60 gas/slot) it's a constant hashing operation to compute the base slot and a single addition for every additional slot to be computed (~6 gas/slot). While seemingly small this can quickly add up when trying to retrieve information for multiple slots to do external "multi-tick" donates for example.
The continuous layout of the storage has the side benefit that it'll be optimized in line with expected Verkle-Trie gas cost changes (EIP-4762).
Describe the desired implementation.
The desired implementation is to define base "map structs" for type-safety and to ensure that solidity assigns a unique storage slot to the mappings based on the pool's storage slot. Then use a library mounted to the type (with the using syntax) to define get/set operations for the mapping.
This is opposed to directly using Solidity's fixed array syntax for the full range of the int16 and int24 types as this would not only incur extra gas due to the unnecessary bounds checks but also require extra arithmetic to ensure that storage slots are colocated around 0 (as the binary representation of int(-1) is 0xffffff).
Describe alternatives.
No response
Additional context.
No response
