ENDGAME: How we've achieved 10ms blocks
Testnet is here. Let’s have a deeper discussion around a technical nuance of our system: mini-blocks.
Their sole purpose is to push MegaETH’s performance limits, and play an essential role in achieving a real-time blockchain. But understanding the how and why are important–so let’s talk about them.
First, some terms and definitions.
GLOSSARY
EVM Blocks
For the rest of the article, this is what we'll use to refer to "traditional" blocks, which are backwards compatible within the broader EVM ecosystem.
They preserve their full metadata weight, allowing for things like RPCs, developer tooling, and block explorers to integrate with MegaETH without having to entirely refactor their system.
These are produced in 1s intervals.
Mini-Blocks
Our term for the lightweight (in terms of metadata), more-frequent blocks produced by MegaETH.
These blocks are produced in parallel to EVM blocks and offer the same inclusion guarantees, with the only difference being a heavily-reduced interval of propagation to the remainder of the network.
These blocks are produced in 10ms intervals, with ambitions of reducing this number to 1ms.
Block Times
The time between same-blocks of either aforementioned classification. EVM-to-EVM or mini-to-mini.
Because we have built our system to offer the exact same guarantees for mini-blocks as EVM blocks, we would like to work towards a future where "block times" are expressly considered towards mini-blocks as the entirety of the chain can be interpreted solely through their view.
VISUALIZED
KEY PROPERTIES, COMPARISONS
So, we've covered the definitions, given some high-level details and threw on a visualization to help with mental models.
Now, let’s talk about ecosystem comparisons and what properties are/are not preserved with our implementation.
ECOSYSTEM COMPARISONS
1. Base's Flashblocks (link)
Recently implemented on Sepolia testnet, these utilize TEEs to create sub-blocks/pre-confirmations of transactions in 200ms intervals within the 2s block times.
Both systems will enjoy revert protection of their smaller blocks while Flashblocks introduces some trust assumptions from TEE providers.
2. Solana's Shreds (link)
MegaETH's multi-view design compared to Solana's shredding architecture
Shreds are something recently brought to light due to Base's Flashblocks implementation and are similar to mini-blocks in frequency (~15ms), but with one key difference: Solana has consensus.
With consensus requirements comes the risk of blocks being produced but not confirmed/guaranteed, which would extend to shreds. That means you will have instances of a shred being propagated before the leader finishes their block, which they then do not do in time, causing the shreds to be invalid and need to be dropped.
This is a small % of total in Solana's current paradigm, but is a byproduct of a consensus-having protocol.
3. Hyperliquid's Dual-block Architecture (link)
This one is mostly a mental model/conceptual equivalent in terms of desired outcome, but implemented differently.
Visual comparison of Hyperliquid's dual-block architecture against mini and EVM blocks
The goal of their design is to create a chain that possesses the ability to both (a) process transactions quickly and (b) process large/heavy transactions.
Their solution for this is to have two separate mempools for the different-sized tx, process them into different-sized blocks and to then interleave them into the chain.
MegaETH's ambitions are the same, but we achieve this outcome without the need to segregate tx and interleave by (a) using an execute-then-order parallel execution design and (b) utilizing node specialization to practically eliminate compute/gas as a restraint on developers.
The combination of the above means we can achieve consistent 10ms block times of mini-blocks across transaction types of all complexity and size-levels without the added complexity of tx and block segregation.
KEY PROPERTIES
Rollback Guarantees
Mentioned above, but reiterated here: mini-blocks are first-class citizens within MegaETH and enjoy all guarantees shared by EVM blocks. A rollback on any given mini-block is as-serious an offense as an EVM block rollback and would come with the same slashing risk.
If we are to realize the vision of creating the first real-time blockchain we must not only be performant, but also consistent and reliable. Data recovery and revert protection are highly-valued properties of our ecosystem.
Parameter Setting
The implementation of things like EIP-1559 are at the EVM-block level to preserve EVM equivalence, which means our current Base fee (0.0025 Gwei), Block size (2G gas) and Target (1G gas) are all with respects to the 1s interval.
Elastic Block Production
The current configuration is one tuned for maximum performance and reduced waste, which means instead of creating empty blocks at set intervals neither mini nor EVM blocks are produced if no tx are present, making the systems block times elastic and demand-based.
This is an implementation detail which can be modified if deemed useful in the future, but we will continue to elect for performance and efficiency when given the choice.
Ethereum JSON RPC Compatibility
We have enhanced several endpoints to allow for mini-block ingestion while preserving regular Ethereum JSON RPC backwards compatibility, with an aim to continue both enhancing what is in place as well as rolling out new APIs based on early builder feedback.
EVM/Mini Metadata Differences
Coming to developer docs near you soon™️
FIN
If the above caught your attention, be on the lookout for our forthcoming developer docs and join the builder program to see what real-time can do for your app.
The future will be RABBIT SPEED and powered by MINI-BLOCKS.
great explanation and visualisation thanks for this. let‘s make ETH great again in realtime!