原著者: @ShivanshuMadan、暗号ライター
原文翻訳: zhouzhou、BlockBeats

編集者注: Base、MegaETH、Solana は、ユーザー エクスペリエンスを向上させるために、Flashblocks、Miniblocks、Shreds を通じてさまざまな形式の事前確認を提供しています。 Base は TEE を使用して 200 ミリ秒ごとにトランザクションを事前確認します。MegaETH は Miniblocks を使用して 10 ミリ秒ごとに確認します。Solana は Shreds を通じて 400 ミリ秒以内にトランザクションの確認を完了します。これらのメカニズムは相互作用の速度を最適化しますが、信頼はそれぞれのソーターまたは検証者に依存します。 L2 にはコンセンサス メカニズムはありませんが、固定ブロック時間は、EIP1559 などのメカニズムの実行と分散順序付けに役立ちます。将来的には、1 秒未満の事前確認が業界標準となり、不正行為を防止するために重要になります。

以下は原文です（読みやすく理解しやすいように原文を再編成しています）:

Base vs MegaETH vs Solana、Flashblocks vs Miniblocks vs Shreds、どれが一番速いでしょうか？最も安全なのは誰でしょうか?誰が勝つでしょうか？

Flashblocks、Miniblocks、および Shreds はすべて、それぞれのブロック プロデューサーによる「事前確認」です。事前確認は、ユーザーが取得する「信頼できる保証」であり、ユーザーのトランザクションが次のブロックに含まれることを保証します。これにより、ユーザー エクスペリエンスが向上しますが、ブロック プロデューサーに対する信頼の想定が一時的に増加します。

BASE フラッシュブロック

Base のブロック時間は現在 2 秒です。 2 秒ごとに、すべてのツール (ブロック エクスプローラー、RPC、ウォレットなど) がブロックを取得し、データベースを更新し、ステータスをユーザーに同期します。この状態は確定（不変）されていませんが、シーケンサーによって「事前確認」されています。しかし、2 秒の更新レートでは理想的なユーザー エクスペリエンスは提供されず、ユーザーはより高速なインターネット応答速度に慣れています。

Flashblocks は、事前確認時間を 200 ミリ秒に短縮することで、この問題を直接最適化します。

·ソーターは信頼できる実行環境で実行され、優先手数料に基づいてトランザクションをソートします。

·200 ミリ秒ごとに、ソーターは子ブロック (Flashblock) を作成し、それを L2 ノードにブロードキャストします。

·L2 ノードは TEE 署名を検証し、ユーザーに事前確認を発行し、Flashblock をローカル状態に適用します。

·2 秒後、ソーターは完全なブロックをコンパイルし、L1 に送信する Merkle サマリーを生成します。

·L1 確認後、ノードはハード ステートを更新し、ブロックを確定します。

ブロックが完了するまでにはまだ 2 秒かかりますが、ユーザーは 200 ミリ秒以内に更新されたステータスを確認できるため、ユーザー エクスペリエンスが大幅に向上します。

MEGAETH MINIBLOCKS

MegaETH はブロック時間を 1 秒に設定する予定です。ただし、ユーザー エクスペリエンスを最適化するために、Flashblocks と同様の事前確認戦略を採用します。 ME シーケンサーは、ブロックを構築する際に、トランザクション確認を継続的に提供します (順序は特に決まっていません)。 ME は、「ミニブロック」の形式で 10 ミリ秒ごとに事前確認を発行する予定です。 Flashblocks と同様に、Miniblocks は 1 秒ブロックを超えて信頼の想定を増やすことなく、ユーザー エクスペリエンスを大幅に向上させます。

(Flashblocks は優先順位付けを正しく実行するために TEE にも依存していますが、Miniblocks はこの信頼できる前提を必要としないことに注意してください。)

SOLANA SHREDS

Solana は、高品質のユーザー エクスペリエンスと高速チェーンの先駆者です。 Solana の標準ブロック時間は 400 ミリ秒です。ブロック生成プロセス中、Solana のリーダー (ブロック プロデューサー) はブロックを小さな「シュレッド」に分割し、POH (履歴証明) に送信して、ネットワーク全体に伝播します。

他のバリデータは、Shred を受け取った後にトランザクションのコピーを開始し、Shred を検証した後すぐに (400 ミリ秒未満) トランザクション確認を送信できます。

ここで、議論する価値のある 2 つの質問があります。

1. さまざまな状況でこれらの「事前確認」はどの程度安全ですか?

2. ロールアップ システムでは、トランザクションの最終確認は L1 へのバッチ送信に依存しますが、「ブロック時間」とは何を意味しますか?

事前確認セキュリティ

a) Solana

Solana バリデーターがリーダーから 2 つの Shred を受け取ったが、これらの Shred は最終的に最終ブロックに含まれないと仮定します。次の 2 つのケースが考えられます。

1. リーダーがオフライン: 最終ブロックを生成できず、タイムスロットがスキップされます。この場合、次のリーダーがこれらのシュレッドを引き継ぎ、それを自身のブロックに含めます (最も重いフォークにコピーします)。

2. リーダーが悪事を働く: リーダーはネットワークを分割しようとして、異なる Shred を異なるバリデーターに配布します。

したがって、取引が履行される唯一の保証は、リーダーが悪事を働いたり腐敗したりしないという信頼です。

b) MegaETH

MegaETH にはソーターが 1 つしかないため、トランザクションを含めることができる唯一の保証は、ソーターが悪意を持って動作しないことです。

さらに、次の 2 つのリスクがあります。

· ソーターがオフラインになる: オンラインに戻ると、事前確認済みのトランザクションが再び含まれるようになります。

· Ethereum L1 の再編成が行われます。確定されていない L2 トランザクションは、ソーターによって新しいチェーンにコピーされます。

c) Base

Base の事前確認メカニズムは MegaETH に似ていますが、さらに TEE (Trusted Execution Environment) のセキュリティに依存しています。

TEE が攻撃された場合でも、変更できるのはトランザクションの優先順位のみであり、最終的なトランザクションの組み込みには影響しません。

いずれの場合も、ユーザーはより迅速な事前確認を得ることができますが、それはリーダー (ソーター) が悪意を持って行動していない場合に限られます。各ブロックのリーダーはブロックの構築を独占しているため、各ブロックの構築において P (悪事を行う確率) は同じであると想定するのが妥当です。

L2 ブロック時間とはどういう意味ですか?

L1 はコンセンサス メカニズムに依存していますが、(ほとんどの) L2 には従来のコンセンサス メカニズムがありません。 L1 では、ブロックの境界で投票が行われ、バリデーターがブロック全体のトランザクションの正しさに投票するため、ブロック時間はコンセンサスの効率を向上させるために存在します。

しかし、コンセンサスのない L2 でも、ブロック時間は必要ですか?

答えは「はい」です。

L2 のブロック時間は任意に選択でき、最終性ではなく「事前確認」のみを表しますが、ブロック時間を固定することは、次のようないくつかの理由で役立ちます。

• EIP1559 のようなメカニズムを実装すると、より頻繁なミニブロック/ライトニング ブロック レベルよりもブロック レベルで効率的になります。 • L2 が順序付けと認証を分散化することを計画している場合、明確に定義されたブロック境界によって投票と認証が容易になります。

ブロックチェーンのパフォーマンスが向上するにつれて、1 秒未満の事前確認が標準になります。勝利の連鎖により、P (腐敗) に対する罰則も非常に大きくなり、強力な抑止力として機能します。

「元のリンク」

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia