著者:シヴァ
編集：ティム、PANews
Base、MegaETH、Solana の事前確認メカニズムは、それぞれ Flashblocks、Miniblocks、Shreds です。
一番速いのは誰ですか？
最も安全なのは誰でしょうか?
誰が勝つでしょうか？
知っておくべきことはすべてここにあります:
要約:
- フラッシュブロック、ミニブロック、シュレッドは、それぞれ Base、MegaETH、Solana チェーン上の「事前確認」メカニズムです。
- 事前確認メカニズムは、ユーザーに、そのトランザクションが次のブロックに含まれるという「包含保証」を提供します。
- 事前確認メカニズムはユーザーエクスペリエンスを向上させることができますが、ブロックプロデューサーが誠実で信頼できるとユーザーが一時的に信じることが必要になります。
ベースフラッシュブロック
Base での現在のブロック確認時間は 2 秒です。
ブロックブラウザ、RPC、ウォレットなどのすべてのツールは、2秒ごとにブロックとデータベースのステータス更新を取得し、ユーザーと共有します。
上記の状態更新には「最終性」（不変性）はありませんが、ソーターによって「事前確認」されています。
ユーザーはより高速な速度に慣れているため、2 秒の更新遅延では良好なユーザー エクスペリエンスは得られません。
Flashblocks は、事前確認時間を 200 ミリ秒に短縮することで、このユーザー エクスペリエンスの問題に直接対処します。
- ソーターは信頼できる実行環境 (TEE) で実行され、優先手数料に基づいてトランザクションをソートします。
- ソーターは 200 ミリ秒ごとに子ブロック (Flashblock) を作成し、それを L2 ノードにブロードキャストします。
- L2 ノードは TEE 署名を検証し、ユーザーに事前確認を発行し、ローカル状態に Flashblocks を適用します。
- 2 秒後、ソーターは完全なブロックをコンパイルし、L1 に送信するための Merkle ダイジェストを生成します。
- L1 が確定すると、L2 ノードはハード ステートを更新してブロックを確定します。
ブロック全体の確認にはまだ 2 秒かかりますが、ユーザーは 200 ミリ秒以内に更新されたステータスを確認できるため、ユーザー エクスペリエンスが大幅に向上します。
MegaETH ミニブロック
MegaETHは現在、ブロック時間を1秒に設定する予定です。
ただし、ユーザーエクスペリエンスを向上させるために、Flashblocks に似た事前確認メカニズムを採用する予定です。
MegaETH シーケンサーは、ブロックが構築されるとトランザクションを出力します (トランザクションの順序は任意)。
MegaETH は 10 ミリ秒ごとに事前確認を実行することを計画しており、この形式を「ミニブロック」と呼んでいます。
Flashblocks と同様に、Miniblocks は 1 秒ブロックの信頼性を高めることなく、ユーザー エクスペリエンスを大幅に向上させることができます。
(Flashblocks を使用する場合、優先順位付けを正しく実行するために、ユーザーは TEE (Trusted Execution Environment) も信頼する必要があることに注意してください。)
ソラナシュレッド
Solana は、優れたユーザー エクスペリエンスと高速トランザクションを備えたブロックチェーンの先駆者です。
Solana の通常のブロック時間は 400 ミリ秒です。
ただし、ブロック生成プロセス中に、Solana ブロックプロデューサーはブロックを「Shreds」と呼ばれる小さな部分に分割し、それらを履歴証明 (PoH) に送信し、それがネットワークの残りの部分に伝播されます。
他のバリデータは、シュレッドを受信するとすぐにトランザクションの複製を開始し、シュレッドを検証した後すぐに（400 ミリ秒未満で）トランザクションを送信できます。
ここで 2 つの問題が発生します。
- それぞれのケースにおいて、これらの「事前確認」はどの程度安全でしょうか?
- トランザクションがバッチ処理されて L1 に送信されるまで確定されない場合、ロールアップの「ブロック時間」は実際には何を意味しますか?
事前確認済みの安全性
a) ソラナ
Solana バリデーターがブロックプロデューサーから 2 つの Shred を受け取ったが、これらの Shred が最終ブロックの一部にならないとします。これには 2 つの理由が考えられます:
- ブロックプロデューサーはオフラインです。最終ブロックは生成されず、スロットはスキップされます。この場合、次のブロックプロデューサーはこれらのシュレッドをピックアップし、独自のブロックに含めます（最長のフォークにコピーします）。
- ブロック プロデューサーによる悪意のある行為: ブロック プロデューサーは、ネットワークを分割する目的で、異なるシュレッド (細切れのブロック) を異なるバリデーターに伝播します。
したがって、包含保証は単に、ブロック生成者が悪意を持っていなかったり不正を行っていないことを信頼することを意味します。
b) メガETH
シーケンサーは1つだけです。したがって、包括的な保証は、ソーターが悪意を持っていないことを信頼することです。
他の 2 つのリスクは次のとおりです。
i) ソーターがオフラインの場合: この場合、オンラインに戻ると、事前確認済みのトランザクションが含まれます。
ii) Ethereum L1 の再編成が行われます。未確定の L2 トランザクションは、新しいフォークのソーターによって複製されます。
c) ベース
MegaETH と同様の包含保証。
ここでの包括的な保証は、ソーターが悪意のあるものではなく、TEE (Trusted Execution Environment) が安全であることを信頼することです。
しかし、TEE がハッキングされたとしても、変更できるのはトランザクションの優先順位だけです。
いずれの場合も、ユーザーはより速い事前確認を得ることができますが、ブロック生成者が不正になるリスクがあります。
単一のブロック生成者が常にブロックの構築を独占しているため、各ブロック構築において不正行為が発生する確率は同じであると想定するのが妥当です。
L2 ブロック時間とはどういう意味ですか?
L1 ブロックチェーンにはコンセンサス メカニズムがありますが、ほとんどの L2 ブロックチェーンにはコンセンサス メカニズムがありません。
L1 パブリック チェーンでは、バリデーターの投票動作がブロック生成の重要な時間ノードに集中するため、固定ブロック時間によってコンセンサス効率が向上します。バリデーターは投票を通じてブロック全体のすべてのトランザクションの正確性を確認します。
L2 ブロック時間は意味がありますか?
答えはイエスです。
L2 ブロック時間は自由に設定され、最終性ではなく「事前確認」のみを表しますが、固定ブロック時間には次の重要な値があります。
- EIP1559 に似た料金メカニズムを実装する場合、ブロック レベルで操作すると、頻繁に使用されるミニブロック/フラッシュブロック レベルと比較して実行効率が大幅に向上します。
- L2 が分散型のソートおよび検証プロセスを実装する予定の場合、明確なブロック境界を設定すると、投票と検証アクティビティを特定の時間枠内で完了できるため、効率が大幅に向上します。
ブロックチェーンのパフォーマンスが向上するにつれて、1 秒未満の事前確認がより高速化することが標準になります。
最終的に勝利するメインチェーンは、腐敗の可能性が効果的に阻止されることも保証します。
