⚡️ Storage slot optimization idea (using address directly)

[seinmyung25]

I have a quick question about a storage-slot optimization idea.

Instead of deriving a mapping slot via keccak256(owner, slot), I’m considering using the address directly under a dedicated namespace, e.g.:

bytes32 private constant _BALANCE_SPACE_SEED = 0x87a211a2000000000000000000000000000000000000000000000000000000;

function balanceOf(address owner) public view returns (uint256 result) {
    /// @solidity memory-safe-assembly
    assembly {
        result := sload(or(_BALANCE_SPACE_SEED, owner))
    }
}

Would this be safe and correct.
Are there any risks of storage collisions or other security issues with or(_BALANCE_SPACE_SEED, owner).

[atarpara]

@seinmyung25 it will increase runtime evm code size.

[seinmyung25]

@atarpara Thanks for the feedback!

I've created PR #1507 with a bitwise optimization approach.

Measurements:

• Code size: -19 bytes (MockERC20 3,256 → 3,237 bytes)
• Gas: Eliminates mstore + keccak256 in balance slot operations

Turns out it reduces both code size and runtime gas. Would appreciate your review!

[atarpara]

Thanks @seinmyung25 for the PR! This optimization does save runtime gas, but there is one security concern.

With this approach, all balance storage slots occupy a fixed, contiguous range:

0x87a211a2000000000000000000000000000000000000000000000000000000000000
0x87a211a2000000000000000000000000000000000000000000000000000000000001
...
0x87a211a200000000000000000000ffffffffffffffffffffffffffffffffffffffff

In contrast, Solidity mappings distribute values pseudo-randomly across the full 2²⁵⁶ storage space using keccak256. This optimization concentrates all balances into only 2¹⁶⁰ consecutive slots. As a result, child contracts that introduce additional mappings have a significantly higher risk of storage collisions with this namespace compared to standard keccak-based storage.

@Vectorized, what are your thoughts on this?

[Vectorized]

we want to preserve storage layout for upgrade compatibility, and also a storage layout change will make the audits outdated.

once the gas is good enough, like as of now, the benefits of keeping upgrade compatibility outweighs keccak savings.

[seinmyung25]

@atarpara @Vectorized

I understand the concern: adopting this would render the audit report outdated and deviate from established Solidity storage layout conventions, which makes it difficult to justify given the potential risk.

I mainly brought it up from a “pure optimization” angle, and I wasn’t sure whether it had already been considered and rejected for the same reasons. I also don’t really have a good place to sanity-check ideas like this, so I’d love to understand what the real-world risks look like. Any thoughts would be appreciated.

On the “consecutive range” point: I had the same gut reaction that it feels riskier. That said, while it’s true that other mappings are much more likely to land somewhere inside that reserved range, we usually can’t assume balances are populated for every address. So my current thinking is that the chance of colliding with an actually used balance slot (i.e., overwriting a real stored value) doesn’t necessarily increase just because the namespace is contiguous — but I may be missing something, and that’s why I wanted to float the idea and get feedback.