原作者 |ヴィタリック
編集 | Odaily Planet Daily Nan Zhi
優れたブロックチェーン ユーザー エクスペリエンスの重要な特性の 1 つは、トランザクション確認時間が速いことです。現在、イーサリアムは 5 年前と比べて大幅に改善されています。 EIP-1559 と PoS (The Merge) への切り替え後の安定したブロック時間のおかげで、 L1 でユーザーが送信したトランザクションは通常 5 ～ 20 秒以内に確認できます。これは、クレジット カードでの支払いとほぼ同等です。ただし、ユーザー エクスペリエンスをさらに向上させることには価値があり、一部のアプリケーションでは数百ミリ秒以下の遅延が必要な場合もあります。この記事では、イーサリアムでのトランザクション確認時間を改善するためのいくつかの実用的なオプションを検討します。
既存のアイデアと技術の概要
シングルスロットのファイナリティ
現在、イーサリアムの Gasper コンセンサスは単一スロット (スロット) とエポック アーキテクチャを使用しています。スロットごとに 12 秒ごとに、バリデーターのサブセットがチェーンの先頭に投票し、32 スロット (6.4 分) ごとに、すべてのバリデーターが 1 回投票する機会があります。これらの投票は、PBFT と同様のコンセンサス アルゴリズムでメッセージとして再解釈され、2 エポック (12.8 分) 後にファイナリティと呼ばれる非常に強力な経済的保証が与えられます。
（日々メモ：具体的な原理の詳細については、「イーサリアムPOSの動作原理の詳細説明：エポック、スロット、ビーコンブロック」を参照してください）
ここ数年、私たちは現在のアプローチにますます不満を抱くようになりました。これには主な理由が 2 つあります。1 つ目は、方法が複雑で、スロット間の投票メカニズムとエポック間のファイナリティ メカニズムの間に多くの相互作用のバグがあること、2 つ目は、12.8 分は長すぎて誰もやりたがらないことです。それくらい待ってください。
シングル スロット ファイナリティ (SSF) は、このアーキテクチャを Tendermint コンセンサスと同様のメカニズムに置き換えます。ブロック N+ 1 が生成される前にブロック N がファイナライズされます。 Tendermint との主な違いは、「非アクティビティ リーク」メカニズムを保持していることです。これにより、バリデーターの 1/3 以上がオフラインの場合でもチェーンの実行と回復が可能になります。
(日々のメモ: 非アクティブリークは、長期間非アクティブなバリデーターを罰するために設計された PoS のメカニズムです。一度非アクティブとしてマークされると、ステーキングされた ETH は引き続きペナルティを受けます。
Tendermint は、効率的で安全なビザンチンのフォールトトレラント コンセンサス アルゴリズムであり、迅速なトランザクション確認を可能にし、一部のノードが悪意のあるノードやオフラインの場合でもブロックチェーン システムが正常に動作できることを保証します。 ）
シングルスロット ファイナリティの主な課題は、各イーサリアム ステーカーが 12 秒ごとに 2 つのメッセージを発行する必要があり、チェーンに大きな負荷がかかることです。最近の Orbit SSF 提案など、この問題を軽減するための賢いアイデアがいくつかあります。これにより「ファイナリティ」が大幅に高速化され、ユーザー エクスペリエンスが向上しますが、ユーザーが 5 ～ 20 秒待つ必要があるという事実は変わりません。
(日常のメモ: ファイナリティと、ブロックにパッケージ化されて確認されるトランザクションは同じイベントではありません。トランザクションが確認されてもファイナリティが達成されない場合、フォークまたはロールバックが発生する可能性があります。)
ロールアップの事前確認
イーサリアムは過去数年間、ロールアップ中心のロードマップに従っており、データ可用性とその他の機能をサポートするイーサリアムベースレイヤー (L1) を設計しており、その後、ロールアップ、バリディウム、プラズマなどの L2 プロトコルで利用できるようになります。イーサリアムと同じレベルのセキュリティを大規模にユーザーに提供します。
これにより、イーサリアム エコシステム内で懸念事項が分離されます。イーサリアム L1 は、検閲耐性、信頼性、安定性、特定のベース レイヤーのコア機能の維持と向上に重点を置いているのに対し、L2 は、さまざまな文化やテクノロジーを介したより直接的なコミュニケーションに重点を置いています。ユーザーへ。しかし、この道をたどると、避けられない問題が発生します。L2 は、5 ～ 20 秒よりも速い確認をユーザーに提供したいと考えています。
これまでのところ、少なくとも理論上は、独自の「分散型発注者」ネットワークを構築するのが L2 の責任でした。少数のバリデーターのグループが数百ミリ秒ごとにブロックに署名し、それらのブロックの背後に賭け金を賭けることがあります。最終的に、これらの L2 チャンクのヘッダー ファイルは L1 に公開されます。
しかし、L2 バリデーター セットは「不正」を犯す可能性があります。最初にブロック B 1 に署名し、次に競合するブロック B 2 に署名して、B 1 の前にチェーンにコミットすることができます。しかし、もしそうした場合、彼らは発見され、担保されている資産を失うことになります。実際に集中版の実践例を見てきましたが、一方でロールアップは分散型仕分けネットワークの開発が遅れていました。すべての L2 を分散化することを要求するのは不公平であると主張する人もいるでしょう。私たちはロールアップに、完全に新しい L1 を作成するのとほぼ同じ仕事をするよう求めています。したがって、Justin Drake は、すべての L2 (および L1) がイーサリアム全体で共有される事前確認メカニズム、つまり基本的な事前確認を使用する方法を推進してきました。
基本的な事前確認
Based preconfirmation のアプローチでは、イーサリアムの提案者が MEV に関連する高度に洗練された参加者であることを前提としています。事前確認ベースのアプローチは、複雑な提案者に事前確認サービスを提供する責任を引き受けるよう促すことで、この複雑さを利用します。
このアプローチの基本的な考え方は、ユーザーが追加料金を提供して、トランザクションが次のブロックに含まれることを即時に保証し、そのトランザクションの実行結果についての請求を保証できる標準化されたプロトコルを作成することです。提案者がユーザーとの約束を破った場合、その約束は打ち切られる可能性があります。
前述したように、L1 トランザクションは事前確認に基づいて保証されます。ロールアップが「ベース」の場合、すべての L2 ブロックは L1 トランザクションとなるため、同じメカニズムを使用して任意の L2 に事前確認を提供できます。
(日々のメモ: イーサリアムの提案者は、手数料メカニズムを使用して、一連のトランザクションを 1 つのバンドルにまとめてブロックにパッケージ化し、トランザクションの実行と順序を確保できます。たとえば、よく知られたクリップを使用すると、購入前に確実に購入できるようになります。ここで Vitalik によって提案された計画は概念的に一貫しており、実行を迅速化するために、トランザクションの結果はこの提案者を通じて事前にロックされます。)
私たちは実際に何を見ているのでしょうか？
単一スロットのファイナリティを達成すると仮定します。私たちは Orbit と同様のテクノロジーを使用して、スロットごとに署名するバリデーターの数を減らしますが、32 ETH ステーキングの最小値を減らすという重要な目標も前進できるように、あまり多くはしません。スロット時間は 16 秒に延長される場合があり、その後はロールアップ事前確認または基本事前確認を使用して、ユーザーに迅速な確認を提供します。最終的に得られるのは、エポックスロット アーキテクチャです。
エポックアンドスロットアーキテクチャが回避するのが非常に難しいように見えるのには、深い哲学的な理由があります。つまり、何かについて大まかに合意する方が、「経済的な最終性」が最も高いものについて合意に達するよりも時間がかかりません。
単純な理由はノードの数です。超最適化された BLS アグリゲーションと今後の ZK-STARK により、古い線形分散化/ファイナリティ時間/オーバーヘッドのトレードオフは現在では穏やかに見えますが、次の理由は無視できません。
「おおよそのコンセンサス」には少数のノードのみが必要ですが、経済的なファイナリティには大多数のノードが必要です。
ノードの数が一定のサイズを超えると、署名の収集により多くの時間を費やす必要があります。
現在のイーサリアムでは、12 秒のスロットは、ブロックの発行と配布、認証、および認証の集約という 3 つのサブスロットに分割されています。証明者の数が大幅に減った場合は、サブスロットを 2 つに減らし、8 秒のスロット時間を使用できます。もう 1 つの、より現実的で大きな要素は、ノードの「品質」です。もう 1 つの大きな要因は、ノードの「品質」です。ノードの特殊なサブセットを利用しておおよその合意に達することができれば (それでもなお完全なバリデーターのセットを使用して最終性を判断できれば)、これを約 2 秒に短縮できる可能性があります。
したがって、私の意見では、エポック アンド スロット アーキテクチャは明らかに正しいですが、すべてのエポック アンド スロット アーキテクチャが等しいわけではなく、設計領域をより完全に探索することに価値があります。さらなる研究に値する方向性は、Gasper ほど緊密に結合されていませんが、2 つのメカニズム間の懸念をより強力に分離することです。
L2はどうすればいいでしょうか？
私の意見では、L2 には現在 3 つの合理的な戦略があります。
技術的にも精神的にも「ベース」です。つまり、イーサリアムのベースレイヤーの技術的特性とその価値（高い分散性、検閲耐性など）を最適化します。最も単純な形式では、これらのロールアップは「ブランド化されたシャード」と考えることができますが、新しい仮想マシンの設計やその他の技術的改善を大幅に実験する、より野心的なものにすることもできます。
「ブロックチェーン足場を備えたサーバー」になって、それを最大限に活用してください。サーバーから始めて、サーバーがルールに従っていることを確認するために STARK の有効性証明を追加する場合、調整された大量引き出しまたは注文者の変更によって、ユーザーが取引を引き出したり強制したりする権利を確保します。サーバーの効率をほとんど維持しながら、アップリンクの利点のほとんどを実現します。
(日常の注: スキャフォールディングとは、開発者がすぐにコーディングを開始できるように、プロジェクトの基本構造とコード フレームワークを自動的に生成するツールまたは方法を指します。)
中間点: 100 ノードの高速チェーンであるイーサリアムは、さらなる相互運用性とセキュリティを提供します。これは、多くの L2 プロジェクトの現在の事実上のロードマップです。
一部のアプリケーション (ENS、キー ストレージ、一部の支払いプロトコルなど) では、12 秒のブロック時間で十分です。これが適用できないアプリケーションの場合、唯一の解決策はエポックアンドスロット アーキテクチャです。 3 つのケースでは、「エポック」はイーサリアムの SSF ですが、スロットは上記の 3 つのケースそれぞれで異なります。
イーサリアムネイティブのエポックアンドスロットアーキテクチャ
サーバーの事前確認
委員会の事前確認
重要な質問は、カテゴリー 1 でどれだけ優れた成績を収めることができるかということです。特に本当に良くなった場合、カテゴリー3の意味はそれほど大きくなくなるような気がします。すべての「ベースの」ソリューションは血漿やバリジウムなどのオフチェーン データ L2 には適用できないため、カテゴリ 2 は常に存在します。イーサリアムネイティブのエポックアンドスロットアーキテクチャを 1 秒のスロット時間に短縮できれば、タイプ 3 のスペースははるかに小さくなります。
現在、私たちはこれらの質問に対する最終的な答えには程遠いです。重要な問題は、ブロック提案者がどのように複雑になるかですが、これは依然としてかなりの不確実な領域です。 Orbit SSF のような設計は非常に斬新であるため、エポック アンド スロットの中の 1 つのエポックとしての Orbit SSF などのスキームの設計空間は、依然として完全に探索する価値があります。選択肢が増えれば増えるほど、L1 および L2 ユーザーにとってより良いことができ、L2 開発者の作業が楽になります。
