Preconf ソリューションはどのようにイーサリアムのトランザクション確認を高速化しますか?

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

事前確認とは何ですか?

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

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

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

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

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

• プロポーザー スラッシュ: L1 プロポーザル 申請者は追加を追加することを選択する必要があります。事前付与となるためのペナルティ条件。これは、ヘビーステーキング関連のメカニズムを通じて実現できます。

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

L1 提案者は、以下の 2 つの事前確認ペナルティ条件をオプトインすることで事前確認者になります。プレバリデーターは、署名済みの事前確認コミットメントをユーザーに発行し、指定された期間内にトランザクションをブロックに含めることを約束し、コミットメントを履行するためのヒントをユーザーから受け取ります。

• Liveness Slashing: 事前確認者は、指定された期間内に事前確認済みのトランザクションを含めることができなかった場合、ペナルティを受けることになります。

• 安全性の低下: 事前確認者は、その約束が実際に含まれる取引と矛盾している場合、罰則を受けることになります。

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

上記の条件と設定により、Based preconfs は L1 に高速なトランザクション確認を提供できます。ロールアップに基づく場合 (L2 の順序付けは L1 に委ねられる)、つまりすべての L2 ブロックが論理的に L1 トランザクションとみなされる場合、同じメカニズムを使用して L2 に事前確認を提供できます。

커뮤니티 토론

Justin Drake는 사전 확인 메커니즘에 대한 커뮤니티의 관심을 끌었던 기반 사전 확인을 제안했습니다. 그 후, 커뮤니티는 사전 확인 주제를 중심으로 풍부한 토론을 시작했습니다. 그중에서도 주목할만한 내용은 다음과 같습니다: Blockchain Capital의 회원인 Jonah B는 사용자가 사전 확인 메커니즘에서 처벌 조치를 맞춤 설정할 수 있도록 제안했습니다. Matthew는 정전, 네트워크 중단 등(활동 실패)과 같은 외부 예상치 못한 상황으로 인해 제안자가 처벌받지 않도록 보호하기 위해 체인 사전 확인 메커니즘(preconf chaining)을 사용할 것을 제안했습니다. Primev 연구원 Christian Matt는 두 가지 사전 확인 모드를 도입했습니다. : 하나는 지정된 리더(리더 기반)에 의한 사전 확인을 제공하는 것이고, 다른 하나는 리더가 없는 경우 여러 경쟁자(리더 없음)가 사전 확인을 제공하는 것입니다. 리더 모드의 장점은 거의 100% 확인 보장을 제공할 수 있다는 것입니다. 리더가 없는 경쟁 환경에서 사전 확정된 가격을 효과적으로 발견하고 검증자의 수익을 최적화하는 데 도움이 됩니다. Christian Matt는 또한 리더와 리더가 없는 사전 확인을 결합한 여러 솔루션을 제안했으며, Ethereum Foundation 회원인 potuz는 ePBS 프레임워크에서 사전 확인 메커니즘을 도입하기 위한 다양한 과제와 솔루션에 대해 논의했습니다.

以上がPreconf ソリューションはどのようにイーサリアムのトランザクション確認を高速化しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。