How does the Preconf solution speed up Ethereum's transaction confirmation?

On June 30, Vitalik published a new article discussing Ethereum’s problems with transaction confirmation speed. Vitalik mentioned that Ethereum has been greatly improved compared to five years ago. Thanks to EIP-1559 (dynamic adjustment of transaction fees) and the stable block generation time after the merger, transactions sent by users on L1 are usually within 5 -Confirmed within 20 seconds. However, this time can be improved further, and for some applications that explicitly require latency of a few hundred milliseconds or even less, further reducing the acknowledgment time makes a lot of sense. To achieve this goal, the Ethereum community and researchers have proposed some practical solutions, one of which is Preconfirmations.

What is pre-confirmation?

Preconfirmations (preconf) is a pre-confirmation state of a transaction before it is officially confirmed. Specifically, it refers to a temporary confirmation by the node before the transaction is included in the block by the miner and officially put on the chain. This temporary confirmation means that multiple nodes verify the validity of the transaction and temporarily store it in in the memory pool. This allows users to get a signal that the transaction has been accepted in a short period of time, thereby obtaining immediate feedback to reduce waiting time and improve user experience. This pre-confirmation is not the final confirmation and may still be revoked (such as block reorganization), but this situation is relatively rare.

Normally, in the pre-confirmation mechanism, the proposer plays the role of providing pre-confirmation services. For an additional fee, users can obtain a signature commitment that their transactions will be included in the next block. If proposers fail to live up to their commitments, they face financial penalties.

Specific implementation plan: Based Preconfirmations

Ethereum Foundation researcher Justin Drake has been promoting a method of Ethereum’s pre-confirmation mechanism: Based preconfirmations, which provide fast transaction confirmation through specific incentive and penalty mechanisms.

In order to reduce the risk of transactions failing to be packaged into blocks due to various reasons in the Based preconfs mechanism, additional proposer penalties and forced inclusion are required:

• Proposer slashing: L1 proposal Applicants must choose to add additional penalty conditions to become a preconfer. This can be achieved through heavy staking related mechanisms.

• Proposer forced inclusions: L1 proposers must be able to force transactions to be included on the chain, even when economics are low or other proposers are uncooperative. This can be achieved through inclusion lists.

L1 proposer becomes a pre-confirmer by opting in to the following two pre-confirmation penalty conditions. Pre-validators issue signed pre-confirmation commitments to users, promising to include transactions in blocks within a specified time period, and receive tips from users for fulfilling their commitments.

• Liveness slashing: Pre-confirmers will face penalties if they fail to include pre-confirmed transactions within the specified time period.

• Safety slashing: Pre-confirmers will face penalties if their commitments are inconsistent with the transactions actually included.

In addition, pre-confirmers will be prioritized based on their position in the proposer’s lookahead to execute pre-confirmed transactions faster. The proposer look-ahead mechanism is a mechanism used to determine which proposers will have the opportunity to package blocks in the future. Each future proposer will be assigned a position number, which represents their position in future block proposals. order. The pre-confirmers are further sorted according to their position in the proposer's look-ahead. The smaller the position number, the higher the priority of the pre-confirmor. Assume that a transaction is committed by pre-confirmor B, then the proposer with a smaller position number before B (pre-confirmor A) can immediately package the transaction, reducing the user's waiting time and not having to wait for B's turn. That time period as the proposer. If the previous proposer of B fails to package transactions in time, pre-confirmor B needs to ensure that these transactions are included within its time period, otherwise it will face penalties.

With the above conditions and settings, Based preconfs can provide L1 with faster transaction confirmation. If the rollup is based (the ordering of L2 is left to L1), that is, all L2 blocks are logically regarded as L1 transactions, then the same mechanism can be used to provide pre-confirmation for L2.

コミュニティディスカッション

Justin Drake が Based preconfirmations を提案し、事前確認メカニズムにコミュニティの注目を集めました。その後、コミュニティは事前確認のトピックを中心に豊富な議論を開始しました。その中でも特に注目に値するのは次のとおりです。Blockchain Capital のメンバーである Jonah B は、ユーザーが事前確認メカニズムの懲罰的措置をカスタマイズできるようにすることを提案しました。 Matthew は、停電やネットワーク中断などの外部の予期せぬ状況 (アクティビティ障害) による罰則から提案者を保護するためにチェーン事前確認メカニズム (preconf チェーン) を使用することを提案しました。Primev 研究者の Christian Matt は 2 つの事前確認モードを導入しました。 : 1 つは指定されたリーダーによる事前確認 (リーダーベース) であり、もう 1 つはリーダーがいない場合に複数の競技者による事前確認 (リーダーレス) です。リーダーモードの利点は、ほぼ100%の確定を保証できることです。リーダーのいない競争環境では、事前確認された価格を効果的に発見し、バリデーターの収益を最適化するのに役立ちます。 Christian Matt 氏は、リーダーとリーダーレスの事前確認を組み合わせたいくつかのソリューションも提案し、イーサリアム財団メンバーのポトゥズ氏は、ePBS フレームワークの下で事前確認メカニズムを導入するためのさまざまな課題と解決策について議論しました。

The above is the detailed content of How does the Preconf solution speed up Ethereum's transaction confirmation?. For more information, please follow other related articles on the PHP Chinese website!