なぜBased RollupにPreconfsが必要なのか？

著者：LindaBell出典：chainfeeds

2020年10月、イーサPlaceの共同創設者であるVitalik氏は、「Etherのロールアップ中心のロードマップ」を発表しました。今日現在、私たちはマルチRollupエコシステムの中にいます。イーサリアムのロールアップロードマップは、ユーザーエクスペリエンスの向上など大きなメリットをもたらした一方で、新たな課題も生み出しました。例えば、開発者は多様なRollupエコシステムを扱う際、しばしば断片化や意思決定のジレンマに対処しなければなりません。さらに、一元化されたシーケンサーは、トランザクションの検閲やMEVの搾取といった問題を引き起こし、一部のユーザーにとって不公平なコストや操作体験をもたらします。

集中型ソーターの問題に対処するために、現在の主流のソリューションには、共有ソーターとベースド・ロールアップがあります。 共有ソーターは、複数のレイヤーに統一されたソートサービスを提供できますが2、サードパーティとしての信頼とインセンティブに苦しんでいます。Based RollupはイーサネットL1の提案者順序に依存することで分散化を改善するが、そのトランザクション確認時間はイーサネットL1のブロック時間（約12秒）に依存するため、高速な確認はできない。

事前確認の歴史的起源

事前確認（「プレコン」）は、「正式な確認の前の時間」と理解することができます。strong>「正式な確認の前に、信頼できる事前通知をすること」と理解できる。簡単な例として、レストランに予約の電話を入れると、レストランは予約を確認する。あなたはまだレストランに到着していないが、指定された時間に食事をする場所が保証されるという信頼できる約束をされたのだ。

事前確認は実は新しい概念ではない。ビットコインが開発された初期の頃、ビットコインをより使いやすくするために、ビットコインコミュニティは「0conf」というコンセプトを考え出しました。これは、ビットコインネットワークが完全に確認する前にトランザクションを有効とみなすことができ、その結果、トランザクションの最終確認までの待ち時間が短縮されるという考え方です。2023年、Uri Klarman氏はこのアイデアをEtherに導入し、「Chained Preconfirmations（連鎖した事前確認）」というコンセプトを導入した。核となるアイデアは、将来の事前確認者が現在の取引を事前確認できるだけでなく、以前のすべての事前確認者がすでに行った事前確認も継承できるというものです。その後、Primevはこのコンセプトをさらに探求し、「事前確認」と呼ばれる新しい入札メカニズムを提案しました。このメカニズムでは、ブロック構築者の連合が、与えられた期間内に特定の取引を含めるための最も効率的な方法をコミットすることができ、ユーザーは事前確認の入札に参加することができます。

（Primev はmev-commitを構築しています。プロバイダーは、事前確認やその他の高頻度取引戦略など、迅速な確認と執行を必要とする複雑な取引シナリオのための取引の信頼性とスピードを確保することができます)。

ジャスティン・ドレイクはこのコンセプトをさらに一歩進め、「ベースド・プレコンファメーション（Based Preconfirmations）」というアイデアを生み出しました。現在、L2は中央集中型のシーケンサーを使用しており、その最大の利点は、シーケンサーが将来のブロックに自分のトランザクションを含めることを約束したことを示す事前確認をユーザーに提供できることです。しかしこの確認は最終的なものではなく、ユーザーはトランザクションの順序が変更されたりキャンセルされたりする可能性がある。ジャスティン・ドレイクが提案する「Based preconfirmations」メカニズムは、L1が分散型ロールアップを完了できるようにしながら、即時の事前確認を提供することを目指している。

「ベースの事前確認」メカニズムの提案と最適化

「ベースのロールアップ」という概念は、2021年にVitalikが「不完全なロールアップ」という記事で初めて紹介しました。ベースドロールアップの概念は、2021年にVitalikによって発表された記事 "An Incomplete Guide to Rollups "の中で初めて紹介されました。この記事で、VitalikはTotal Anarchyというコンセプトを紹介しました。これは、誰もがいつでも何の制限もなく取引のバッチを提出できる、完全に分散化された環境を説明するものです。

2023年3月、ジャスティン・ドレイクは記事「Based rollups-superpowers from L1 sequencing」を発表し、Based Rollupの概念をさらに明確にしました。ロールアップがロールアップされるとき、ロールアップはロールアップされる。Rollupの順序付けがL1によって駆動される場合、それはBased RollupまたはL1-sequenced Rollupと言われる。このアーキテクチャでは、Rollupブロックの生成と順序付けはL1上のプロポーザを通して行われ、L1上のプロポーザはサーチャーとビルダーと協力して、Rollupブロックを直接L1ブロックに直接含めることができる。デフォルトでは、Based RollupブロックはL2ビルダーによって構築されることに注意することが重要である。したがって、Based RollupはL1バリデータの負担を増加させない。

ベースドロールアップは、トランザクションの順序付けの責任をL1に移すことで、L2のパフォーマンスを最適化しながら、L1のセキュリティとアクティビティを継承する。このメカニズムは、L2のインフラやO&Mコストの削減など、多くの利点をもたらす。しかし、Based RollupのMEV収益のほとんどがL1に流れてしまうといった課題もある。しかし、集中型Rollupの主な収益はL2のトランザクション手数料によるものであり、多くのインフラと高い維持費を必要とするMEV機会によるものであるため、これは実際には問題ではない。ベースのロールアップは、L2取引手数料を主な収益源として維持する一方、提案者の役割をL1ビルダーに委託することで、インフラとO&Mコストを削減する。もう一つの課題は、Based Rollupが迅速な取引確認を実現できないことである。Based Rollupの取引確認時間はイーサネットL1のブロック時間（現在約12秒）に完全に依存するため、集中型シーケンサーが提供する高速なソフト確認とは対照的である。

Based Rollupにおけるトランザクション確認速度の問題に対処するため、Justin Drake氏は2023年11月、スラッシュ実行によるBasedのための事前確認を提供する「Based preconfirmations」を提案しました。ロールアップ。最初のコンセプトにおいて、Justin Drakeは2つの重要な前提を提案した。それは、L1提案者は事前確認者になるために追加のペナルティをオプトインしなければならないこと（再連帯メカニズム）と、L1提案者はトランザクションを強制的にチェーンに含めることができなければならないこと（包含リスト）である。

その後ジャスティン・ドレイク氏は、ロールアップがよりシンプルに、ハードフォークなしで、共有注文と事前確認のためにイーサL1を使用できるようにシナリオを最適化しました。新しい提案では、検証者のサブセットがソーターになることを志願し、ソートを望まない検証者はトランザクションを含めることはできるがソートはしない「インクルード」となった。そして仕分け人は、インクルード者のトランザクションを並べ替えたり、さらにその中にトランザクションを挿入することもできる。ユーザーはトランザクションを提出する際に2つの選択肢がある。代替メモリ・プールにトランザクションを送り、少額の手数料を支払ってインクルーダーに自分のトランザクションを含めてもらうか、次のソーターと通信し、高い事前確認手数料を支払って事前確認を要求するかである。シーケンサーが指定されたスロット内でトランザクションを決済できなくても、インクルーダーはトランザクションを処理できる。

当初の提案とは対照的に、最適化は、L1提案者が追加ペナルティなしで自発的にシーケンサーになることを可能にすることで、イーサネットL1の経済的な安全性を直接活用し、追加インフラへの依存を減らします。