「エポックアンドスロット アーキテクチャは明らかに正しい答えですが、アーキテクチャとスロット ソリューションについてはまだ検討する必要があります。」
原作者 | ヴィタリック・ブテリン
編集 | 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 に事前確認を提供できます。
(日常のメモ: イーサリアムの提案者は、手数料メカニズムを使用して、一連のトランザクションをバンドルにまとめ、ブロックにパッケージ化して、トランザクションの実行と順序を確保できます。たとえば、よく知られたクリップは、特定のトランザクションの前に購入し、販売することを保証します。 Vitalik によってここで提案された計画は、概念的には同じです。このプロポーザーを使用して、トランザクションの結果を事前に固定し、実行を高速化します。)
私たちは実際に何を見ているのでしょうか？
単一スロットのファイナリティを達成すると仮定します。私たちは Orbit と同様のテクノロジーを使用して、スロットごとに署名するバリデーターの数を減らしますが、32 ETH ステーキングの最小値を減らすという重要な目標も前進できるように、あまり多くはしません。スロット時間は 16 秒に延長される場合があり、その後はロールアップ事前確認または基本事前確認を使用して、ユーザーに迅速な確認を提供します。最終的に得られるのは、エポックスロット アーキテクチャです。
エポックアンドスロットアーキテクチャが回避するのが非常に難しいように見えるのには、深い哲学的な理由があります。つまり、何かについて大まかに合意する方が、「経済的な最終性」が最も高いものについて合意に達するよりも時間がかかりません。
単純な理由はノードの数です。超最適化された BLS アグリゲーションと今後の ZK-STARK により、古い線形分散化/ファイナリティ時間/オーバーヘッドのトレードオフは現在では穏やかに見えますが、次の理由は無視できません。
「おおよそのコンセンサス」には少数のノードのみが必要ですが、経済的なファイナリティには大多数のノードが必要です。
ノードの数が一定のサイズを超えると、署名の収集により多くの時間を費やす必要があります。
現在のイーサリアムでは、12 秒のスロットは、ブロックの発行と配布、認証、および認証の集約という 3 つのサブスロットに分割されています。証明者の数が大幅に減った場合は、サブスロットを 2 つに減らし、8 秒のスロット時間を使用できます。もう 1 つの大きな要因は、ノードの「品質」です。ノードの特殊なサブセットを利用しておおよその合意に達することができれば (それでもなお完全なバリデーターのセットを使用して最終性を判断できれば)、これを約 2 秒に短縮できる可能性があります。
したがって、私の意見では、エポック アンド スロット アーキテクチャは明らかに正しいですが、すべてのエポック アンド スロット アーキテクチャが等しいわけではなく、設計領域をより完全に探索することに価値があります。さらなる研究に値する方向性は、Gasper ほど緊密に結合されていませんが、2 つのメカニズム間の懸念をより強力に分離することです。
L2はどうすればいいでしょうか？
私の意見では、L2 には現在 3 つの合理的な戦略があります。
1. 技術的にも精神的にも「基盤」がある。つまり、イーサリアムのベースレイヤーの技術的特性とその価値（高い分散性、検閲耐性など）を最適化します。最も単純な形式では、これらのロールアップは「ブランド化されたシャード」と考えることができますが、新しい仮想マシンの設計やその他の技術的改善を大幅に実験する、より野心的なものにすることもできます。
2. 「ブロックチェーン足場を備えたサーバー」になって、それを最大限に活用します。サーバーから始めて、サーバーがルールに従っていることを確認し、調整された大量引き出しを通じて、ユーザーがトランザクションを引き出したり強制したりする権利を保証するために、STARK の有効性の証明を追加する場合。変更発注者の投票、そしてあなた自身の投票 オンチェーン化の利点のほとんどは、サーバーの効率性をほとんど維持しながら得られます。 (日常の注: スキャフォールディングとは、開発者がすぐにコーディングを開始できるように、プロジェクトの基本構造とコード フレームワークを自動的に生成するツールまたは方法を指します。)
3. 中間点: 100 ノードの高速チェーンであるイーサリアムは、追加の相互運用性とセキュリティを提供します。これは、現時点での多くの L2 プロジェクトの実際のロードマップです。
一部のアプリケーション (ENS、キー ストレージ、一部の支払いプロトコルなど) では、12 秒のブロック時間で十分です。これが適用できないアプリケーションの場合、唯一の解決策はエポックアンドスロット アーキテクチャです。 3 つのケースすべてで、「エポック」はイーサリアムの SSF ですが、スロットは 3 つのケースそれぞれで異なります。
イーサリアムネイティブのエポックアンドスロットアーキテクチャ
サーバーの事前確認
委員会の事前確認
重要な質問は、カテゴリー 1 でどれだけ優れた成績を収めることができるかということです。特に本当に良くなった場合、カテゴリー3の意味はそれほど大きくなくなるような気がします。すべての「ベースの」ソリューションは血漿やバリジウムなどのオフチェーン データ L2 には適用できないため、カテゴリ 2 は常に存在します。イーサリアムネイティブのエポックアンドスロットアーキテクチャが 1 秒のスロット時間に短縮できれば、クラス 3 のスペースはさらに小さくなります。
現在、私たちはこれらの質問に対する最終的な答えには程遠いです。重要な問題は、ブロック提案者がどのように複雑になるかですが、これは依然としてかなりの不確実な領域です。 Orbit SSF のような設計は非常に斬新であるため、エポックアンドスロットの中のエポックとしての Orbit SSF などのスキームの設計空間は、依然として十分に検討する価値があります。選択肢が増えれば増えるほど、L1 と L2 のユーザーにとってより良いことができ、L2 開発者の作業が楽になります。
元のリンク
この記事はOdaily Planet Dailyの許可を得て転載しています
ソース