Base vs Solana vs MegaETH, Who Is the Fastest Chain?

Original Author: @ShivanshuMadan, crypto writer
Original Translation: zhouzhou, BlockBeats

Editor's Note: Base, MegaETH, and Solana provide different forms of pre-confirmation through Flashblocks, Miniblocks, and Shreds to enhance user experience. Base relies on TEE for pre-confirming transactions every 200ms; MegaETH uses Miniblocks to confirm every 10ms; Solana completes transaction confirmation within 400ms through Shreds. These mechanisms optimize interaction speed but trust relies on their respective sequencers or validators. L2 lacks a consensus mechanism, but fixed block times still aid in the execution of mechanisms like EIP1559 and decentralized sequencing. In the future, sub-second pre-confirmation will become an industry standard, and guarding against collusion will be crucial.

Below is the original content (slightly rephrased for better readability):

Base vs. MegaETH vs. Solana, Flashblocks vs. Miniblocks vs. Shreds, who's the fastest? Who's the most secure? Who will prevail?

Flashblocks, Miniblocks, and Shreds are each blockchain producer's form of "pre-confirmation." Pre-confirmation is the "trusted assurance" users receive to ensure their transactions will be included in the next block. This optimizes user experience but adds a temporary trust assumption on the block producer.

BASE FLASHBLOCKS

Base's block time currently stands at 2 seconds. Every 2 seconds, all tools (block explorers, RPC, wallets, etc.) fetch the block, update their database, and sync the state to the user. This state is not final (immutable) but is "pre-confirmed" by the sequencer. However, a 2-second update speed does not provide an ideal user experience, as users are accustomed to faster internet response times.

Flashblocks directly address this issue by shortening the pre-confirmation time to 200 milliseconds:

·The Sorter runs in a trusted execution environment 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, issue pre-acknowledgments to users, and apply the Flashblock to local state.

·After 2 seconds, the Sorter compiles a full block, generates a Merkleized summary, and submits it to L1.

·Upon confirmation by L1, nodes update the hard state, eventually finalizing the block.

While a full block still takes 2 seconds, users can see updated state within 200 milliseconds, greatly enhancing the user experience.

MEGAETH MINIBLOCKS

MegaETH plans to set the block time to 1 second. However, they will adopt a pre-acknowledgment strategy similar to Flashblocks to optimize user experience. The ME Sorter will continuously provide transaction confirmations (in no specific order) during the block-building process. ME plans to release pre-acknowledgments every 10 milliseconds in the form of "Miniblocks." Similar to Flashblocks, Miniblocks significantly enhance user experience without increasing the trust assumptions beyond the 1-second block time.

(It is noteworthy that while Flashblocks rely on TEE for correct execution of priority sorting, Miniblocks do not require this trust assumption.)

SOLANA SHREDS

Solana is a pioneer in high-quality user experience and high-speed chains. Solana's standard block time is 400 milliseconds. During block generation, Solana's leader (block producer) splits the block into smaller "Shreds," submits them to the Proof of History (POH), and propagates them throughout the network.

Upon receiving the Shred, other validators can start replicating transactions and immediately send transaction acknowledgments upon validating the Shred (in less than 400 milliseconds).

Now there are two questions worth exploring:

1. How secure are these "preconsents" in different scenarios?

2. In the Rollup system, the final confirmation of transactions depends on batch submission to L1, so what does "block time" actually mean?

Security of Preconsents

a) Solana

Suppose a Solana validator receives two Shreds from the leader, but these Shreds are ultimately not included in the final block; there could be two scenarios:

1. Leader downtime: The final block fails to be produced, and the slot is skipped. In this case, the next leader will take over these Shreds and include them in their block (replicated onto the heaviest fork).

2. Leader malfeasance: The leader propagates different Shreds to different validators, attempting to split the network.

Therefore, the only guarantee that a transaction will be included is trusting that the leader will not act maliciously or corruptly.

b) MegaETH

MegaETH has only one sequencer, so the only assurance that transactions can be included is that the sequencer does not act maliciously.

Additionally, there are two risks:

· Sequencer downtime: Upon recovery, it will re-include previously preconfirmed transactions.

· Ethereum L1 reorg: Any L2 transactions not yet finalized will be duplicated onto the new chain by the sequencer.

c) Base

Base's preconsent mechanism is similar to MegaETH but further relies on the security of a Trusted Execution Environment (TEE).

Even if the TEE is attacked, the only thing that can be altered is the priority order of transactions, not whether they are included in the end.

In all cases, users can benefit from quicker preconsent, but this is contingent on the leader (sequencer) not acting maliciously. Since each block's leader has a monopoly on constructing the block, it is reasonable to assume that the probability of malfeasance (P) is consistent in each block construction.

What Does L2 Block Time Mean?

L1 relies on a consensus mechanism, while (most) L2 does not have a traditional consensus mechanism. On L1, the existence of block time is to improve consensus efficiency, as voting occurs at the block boundaries, and validators will vote on the correctness of the entire block's transactions.

But in consensus-less L2, do we still need block time?

The answer is yes.

Although block time in L2 can be arbitrarily chosen and only represents "pre-finality" rather than finality, setting a fixed block time is still very helpful in many ways, including:

• Implementing mechanisms like EIP-1559 at the block level is more efficient than at a more frequent mini-block/lightning block level.
• If L2 plans for decentralized ordering and proving, well-defined block boundaries aid in the voting and proving processes.

With the improvement in blockchain performance, sub-second pre-finality will become the norm. The winning chains will also ensure a significant penalty for P (corruption), serving as a strong disincentive.

Source: "Original Post Link"