Today, the EVM exposes 32-byte slots, but hardware works in ~4KB pages. Reading one slot pulls in an entire page, so most of the bandwidth is unused. Hashing keys also destroys locality, so related data ends up scattered.
We instead treat a 4096-byte (128 slot) page as the unit of access and commitment. Storage is grouped into pages, and each page is committed with a binary tree.
Gas follows access patterns. The first touch to a page is expensive. Once loaded, all slots in that page are warm. This makes contiguous layouts (arrays, structs) naturally cheaper, without breaking sparse ones.
Any feedback or discussion is appreciated on:
exact gas schedule for page-level SLOAD / SSTORE and how to track net state growth
commitment scheme details especially single-slot proof size under the BLAKE3 tree
worst-case read amplification if logical pages do not align with physical I/O
how this changes Solidity storage patterns in practice
From prior discussion, once one slot in the page has been loaded, then all other slots in that page would be charged the low warm access storage load cost, rather than the high cold access cost.
This is bringing some exciting new possibilities. With a little bit of assembly magic, page-aware arrays, and mappings to arrays or structs will definitely unlock some new patterns.
To make MIP-8 easier to understand for everyone out there, I built an interactive explainer for MIP-8: [pageified-storage.vercel.app](https://pageified-storage.vercel.app) It walks through the core idea with a few interactive demos.
Shoutout to Ben from CL for the great feedback that shaped this into its current form, and the broader CL team for clean docs on this mip.
Would love feedback on accuracy, missing examples, or anything that could make the concept click better for developers seeing MIP-8 for the first time.
Shouldn’t the 0 -> Y -> 0 case still consume BASE_SSTORE_COST? It makes sense to bypass the growth fee and decrement slot_delta_counter[P] since the tx-local growth is being undone, but the operation is still an SSTORE.
I am very curious about how the existing data will be switched from the current MonadDB MPT structure to the MIP8-based structure. At the moment, it seems that the existing data is still stored using hash(slot). If switching to hash(page_index), will a large amount of data need to be migrated during the upgrade? Or will there be a read-time migration compatibility layer?
You are correct here. This is underspecified here. This will be corrected along with a slight change to the gas schedule to address another under-specified issue.
For smart contract developers interested in building protocols on a “page-ified EVM,” we’ve released a version of Monad Foundry with MIP-8 support.