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

CN
PANews
Follow
7 days ago

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 win?

Here’s everything you need to know:

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

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.
  • The pre-confirmation mechanism can enhance user experience, but it requires users to temporarily trust that the block producer is honest and reliable.

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

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 are 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; they also apply 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 block's final confirmation.

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 to Balance Speed and Security?

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 to Balance Speed and Security?

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 validating the Shreds (in less than 400 milliseconds).

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

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 the block producer, but these Shreds do not become part of the final block. This could happen for two reasons:

  1. The 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 the sorter is non-malicious.

The other two risks are:

i) The 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

The inclusion guarantee is similar to that of MegaETH.

Here, the inclusion guarantee 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 a monopoly 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's 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 actions can be concentrated within specific time windows.

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

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

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink