Preconf ソリューションはどのようにして Ethereum トランザクションの確認を高速化するのでしょうか?

この記事を読むのに必要な時間は 11 分

事前確認は、トランザクションがチェーンに正式にアップロードされる前にノードによって実行される一時的な確認ステータスであり、ユーザーはトランザクションが承認されたという信号をすぐに取得できるため、ユーザーエクスペリエンスが向上します。

元のタイトル：「Preconf ソリューションはどのようにして Ethereum のトランザクション確認を高速化しますか？」

元の著者：0XNATALIE、ChainFeeds

6 月 30 日、Vitalik は Ethereum のトランザクション確認速度の問題について議論する新しい記事を公開しました。Vitalik は、Ethereum は 5 年前と比較して大幅に改善されたと述べています。EIP-1559 (トランザクション手数料の動的調整) と合併後の安定したブロック生成時間のおかげで、L1 でユーザーが送信したトランザクションは通常 5 ～ 20 秒以内に確認されます。ただし、この時間はさらに改善でき、数百ミリ秒以下の遅延を明示的に必要とする一部のアプリケーションでは、確認時間をさらに短縮することが理にかなっています。この目標を達成するために、Ethereum コミュニティと研究者はいくつかの実用的なソリューションを提案しており、その 1 つが事前確認です。

事前確認とは事前確認?

事前確認 (preconf) は、トランザクションが正式に確認される前の事前確認ステータスです。具体的には、トランザクションがマイナーによってブロックに含められ、正式にチェーン上に載せられる前に、ノードによって行われる一時的な確認を指します。この一時的な確認は、複数のノードがトランザクションの有効性を検証し、一時的にメモリプールに保存することを意味します。これにより、ユーザーは取引が承認されたという信号を短時間で受け取ることができ、即座にフィードバックが得られ、待ち時間が短縮され、ユーザーエクスペリエンスが向上します。この事前確認は最終的な確認ではなく、取り消される可能性もあります (ブロックの再編成など) が、このような状況は比較的まれです。

通常、事前確認メカニズムでは、提案者が事前確認サービスを提供する役割を果たします。ユーザーは追加料金を支払うことで、自分の取引が次のブロックに含まれるという署名済みのコミットメントを取得できます。提案者が約束を果たせなかった場合、金銭的な罰則が科せられる。

具体的な実装計画: ベース事前確認

Ethereum Foundation の研究者である Justin Drake 氏は、特定のインセンティブとペナルティのメカニズムを通じて迅速なトランザクション確認を提供する、Ethereum 事前確認メカニズムの手法であるベース事前確認を推進しています。

Based preconfs メカニズムでは、さまざまな理由でトランザクションがブロックにパッケージ化されないリスクを軽減するために、追加の提案者ペナルティと必須の包含が必要です。

· 提案者スラッシング:L1 提案者は、事前確認者になるために追加のペナルティ条件を追加することを選択する必要があります。これは、再ステーキング関連のメカニズムを通じて実現できます。

· 提案者による強制的な包含: L1 提案者は、経済的に不利な場合や他の提案者が非協力的である場合でも、トランザクションをチェーンに強制的に含めることができる必要があります。これは包含リストを通じて実現できます。

L1 提案者は、次の 2 つの事前確認ペナルティ条件に参加することを選択することにより、事前確認者になります。事前確認者は、ユーザーに対して署名済みの事前確認コミットメントを発行し、指定された期間内にトランザクションをブロックに含めることを約束し、コミットメントを履行したことに対するチップをユーザーから受け取ります。

· ライブネススラッシング: 事前確認者は、指定された期間内に事前確認済みのトランザクションを含めなかった場合、罰則を受けることになります。

· セーフティスラッシング: 事前確認者のコミットメントが実際に含まれるトランザクションと一致しない場合、ペナルティが課せられます。

さらに、事前確認者は、提案者の見通しにおける位置に応じて優先順位が付けられ、事前確認されたトランザクションをより迅速に実行できるようになります。プロポーザ先読みメカニズムは、将来どのプロポーザがブロックをパッケージ化する機会を持つかを決定するためのメカニズムです。将来の各提案者には、将来のブロック提案における順序を示す位置番号が割り当てられます。事前バリデータは、提案者の先読みでの位置に従ってソートされ、位置番号が小さい事前バリデータの方が優先順位が高くなります。事前確認者 B によってトランザクションがコミットされたと仮定すると、B より前のポジション番号が小さい提案者 (事前確認者 A) はすぐにトランザクションをパッケージ化できるため、ユーザーの待ち時間が短縮され、B が提案者になる順番が来るまで待つ必要がなくなります。 B の前の提案者がトランザクションを時間内にパッケージ化できなかった場合、事前確認者 B はこれらのトランザクションが自分の期限内に含まれるようにする必要があります。そうでない場合は、ペナルティが課せられます。

上記の条件と設定により、Based preconfs は L1 に高速なトランザクション確認を提供できます。ロールアップがベースになっている場合（L2 ソートは L1 に任される）、つまり、すべての L2 ブロックが論理的に L1 トランザクションと見なされる場合、同じメカニズムを使用して L2 の事前確認を提供できます。

コミュニティの議論

Justin Drake は Based preconfirmations を提案し、事前確認メカニズムにコミュニティの注目を集めました。その後、コミュニティでは事前確認というテーマについて活発な議論が行われました。さらに注目すべきものは次のとおりです。Blockchain Capital のメンバー Jonah B は、事前確認メカニズムでユーザーがペナルティ措置をカスタマイズできるようにすることを提案しました。独立開発者の Matthew は、停電、ネットワーク中断などの外部の予期しない状況 (生存障害) によって提案者が罰せられないように、チェーン事前確認メカニズム (事前確認チェーン) を使用することを提案しました。 Primev の研究者である Christian Matt 氏は、2 つの事前確認モードを導入しました。1 つは指定されたリーダーによって提供されるモード (リーダーベース) であり、もう 1 つはリーダーがいない場合に複数の競合相手によって提供されるモード (リーダーレス) です。リーダーモードの利点は、ほぼ 100% の確認保証を提供できることです。リーダーレスモデルの競争環境は、事前に確認された価格を効率的に発見し、バリデーターの利益を最適化するのに役立ちます。 Christian Matt 氏は、リーダー型とリーダーレス型の事前確認を組み合わせたいくつかのソリューションも提案しました。 Ethereum Foundation のメンバーである potuz 氏は、ePBS フレームワークの下で事前確認メカニズムを導入する際のさまざまな課題と解決策について議論しました。