Comparison of Base, MegaETH, and Solana Pre-confirmation Mechanisms: How to Balance Speed and Security?

PANews
2025-03-20 23:28:25
Collection
The pre-confirmation mechanism can enhance user experience, but it requires users to temporarily trust that the block producer is honest and reliable.

Author: Shiva

Compiled by: Tim, PANews

The pre-confirmation mechanisms of Base, MegaETH, and Solana are Flashblocks, Miniblocks, and Shreds, respectively.

Who is the fastest?

Who is the safest?

Who will prevail?

Here’s everything you need to know:

Comparison of Base, MegaETH, and Solana's Pre-confirmation Mechanisms: How are Speed and Security Balanced?

TLDR:

  • Flashblocks, miniblocks, and shreds are the "pre-confirmation" mechanisms on Base, MegaETH, and Solana chains, respectively.
  • The pre-confirmation mechanism provides users with "inclusion guarantees," meaning transactions will be included in the next block.
  • Pre-confirmation mechanisms can enhance user experience, but they require users to temporarily trust that the block producers are honest and reliable.

Comparison of Base, MegaETH, and Solana's Pre-confirmation Mechanisms: How are Speed and Security Balanced?

Base Flashblocks

The current block confirmation time on Base is 2 seconds.

Every 2 seconds, all tools such as block explorers, RPCs, and wallets receive updates on the block and database status and share them with users.

The above status updates lack "finality" (immutability), but the sorter has performed "pre-confirmation."

The 2-second update delay does not provide a good user experience, as users have become accustomed to higher speeds.

Flashblocks directly address this user experience issue by reducing the pre-confirmation time to 200 milliseconds:

  • The sorter operates in a Trusted Execution Environment (TEE) and sorts transactions based on priority fees.
  • Every 200 milliseconds, the sorter creates a sub-block (Flashblock) and broadcasts it to L2 nodes.
  • L2 nodes verify the TEE signature and issue pre-confirmations to users, applying Flashblocks to their local state.
  • After 2 seconds, the sorter compiles a complete block and generates a Merkle root for submission to L1.
  • Once L1 is finally confirmed, L2 nodes update their hard state, completing the final confirmation of the block.

Although the confirmation of the entire block still takes 2 seconds, users can see the updated status within 200 milliseconds, significantly improving the user experience.

Comparison of Base, MegaETH, and Solana's Pre-confirmation Mechanisms: How are Speed and Security Balanced?

MegaETH Miniblocks

MegaETH currently plans to set the block time to 1 second.

However, they will adopt a pre-confirmation mechanism similar to Flashblocks to improve user experience.

The MegaETH sorter will output transactions in any order while building blocks.

MegaETH plans to perform pre-confirmations every 10 milliseconds, referring to this form as "Miniblocks."

Similar to Flashblocks, Miniblocks can significantly enhance user experience without increasing trust in the 1-second block.

(Note that when using Flashblocks, users also need to trust the TEE (Trusted Execution Environment) to correctly perform priority sorting.)

Comparison of Base, MegaETH, and Solana's Pre-confirmation Mechanisms: How are Speed and Security Balanced?

Solana Shreds

Solana is a pioneer in blockchain with good user experience and high-speed transactions.

The normal block time for Solana is 400 milliseconds.

However, during the block generation process, Solana's block producers split the block into smaller parts called "Shreds" and submit them to the Proof of History (PoH), then propagate these Shreds to other parts of the network.

Once other validators receive the Shreds, they can start replicating transactions and immediately send transactions after verifying the Shreds (in less than 400 milliseconds).

Comparison of Base, MegaETH, and Solana's Pre-confirmation Mechanisms: How are Speed and Security Balanced?

Now two questions arise:

  1. How secure are these "pre-confirmations" in each case?
  2. What does "block time" really mean for a rollup when transactions are only finally confirmed when batched and sent to L1?

Security of Pre-confirmations

a) Solana

Assume a Solana validator receives 2 Shreds from a block producer, but these Shreds do not become part of the final block. This could be due to two reasons:

  1. Block producer is offline: No final block is generated, and that slot is skipped. In this case, the next block producer will take over these Shreds and include them in their own block (replicating on the longest fork).
  2. Malicious behavior by the block producer: The block producer spreads different Shreds to different validators, intending to split the network.

Thus, the inclusion guarantee simply means: trust that the block producer is non-malicious or corrupt.

b) MegaETH

There is only one sorter. Therefore, the inclusion guarantee is to trust that this sorter is non-malicious.

The other two risks are:

i) Sorter is offline: In this case, when it comes back online, it will include the pre-confirmed transactions.

ii) Reorganization occurs on Ethereum L1: Any L2 transactions that are not finally confirmed will be replicated by the sorter on the new fork.

c) Base

Inclusion guarantees similar to MegaETH.

The inclusion guarantee here is to trust that the sorter is non-malicious and that the TEE (Trusted Execution Environment) is secure.

However, even if the TEE is hacked, the only thing that can change is the priority order of transactions.

In all cases, users can receive faster pre-confirmations, but the risk is that the block producer may be corrupt.

Since a single block producer has monopoly power over the construction of the block at any given time, it is reasonable to assume that corrupt behavior has the same probability in each block construction.

What Does Block Time Mean for L2?

L1 blockchains have consensus mechanisms, while most L2 blockchains do not.

In L1 public chains, a fixed block time can enhance consensus efficiency because validators' voting behavior is concentrated at critical time points for block generation. Validators confirm the correctness of all transactions within the entire block through voting.

Does Block Time Matter for L2?

The answer is yes.

Although L2 block time can be freely set and only represents "pre-confirmation" rather than finality, a fixed block time still has the following key values:

  • When implementing fee mechanisms similar to EIP1559, operating at the block level significantly improves execution efficiency compared to frequent sub-block/flash block levels (miniblock/flashblock).
  • If L2 plans to achieve decentralized sorting and validation processes, setting clear block boundaries can significantly enhance efficiency, as voting and validation can be concentrated within specific time windows.

As blockchain performance improves, faster sub-second pre-confirmations will become the norm.

The ultimately prevailing main chain will also ensure that the probability of corrupt behavior is effectively mitigated.

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.
ChainCatcher Building the Web3 world with innovators