原作者 |ヴィタリック

コンパイル | Odailyプラネットデイリー南方

良いブロックチェーンのユーザーエクスペリエンスの重要な属性の1つは、迅速なトランザクションの確認時間です。現在、イーサリアムは5年前と比べて大幅に改善されています。EIP-1559とPoSへの移行（The Merge）による安定したブロックタイムの恩恵を受けて、ユーザーはL1で送信されたトランザクションを通常5〜20秒で確認することができ、クレジットカードで支払いをするのとほぼ同じ体験です。ただし、さらなるユーザーエクスペリエンスの改善は価値があり、一部のアプリケーションでは数百ミリ秒またはそれ以下のレイテンシーが要求される場合もあります。本文では、イーサリアム（トランザクションの確認時間を改善するための）いくつかの実用的なオプションについて探求します。

現在のアイデアと技術の概要

シングルスロットのファイナリティ

現在、イーサリアムのGasperコンセンサスは、単一のスロット（Slot）とエポックの構造を使用しています。 12秒ごとに1つのスロットがあり、一部のバリデータがチェーンの先頭に投票し、32個のスロット（6.4分）内で、すべてのバリデータが1回投票する機会があります。 これらの投票は、その後、PBFTに似た共​​識アルゴリズムのメッセージとして再解釈され、2つのエポック（12.8分）後に、非常に強力な経済的保証である最終的な性質が与えられます。

過去数年間、我々は現在の方法にますます不満を抱いてきました。主な理由は2つあります。まず、この方法は非常に複雑であり、スロット対スロットの投票メカニズムとエポック対エポックの最終性メカニズムの間には多くの相互作用の誤りが存在します。また、12.8分は長すぎて、誰もそんなに待ちたくありません。

シングルスロットファイナティ（SSF）は、Tendermintの共同体に似たメカニズムによって、アーキテクチャを置き換えます。ここでは、ブロックNがブロックN+1が生成される前に最終的に確定されます。 Tendermintとの主な違いは、私たちが「非アクティブな漏洩（inactivity leak）」メカニズムを維持していることです。これにより、検証者の1/3以上がオフラインの場合、チェーンが継続して実行され、回復することができます。

シングルスロットの主な課題は、それはイーサリアムステーカーごとに12秒ごとに2つのメッセージを発行する必要があるということであり、これはチェーンにとって大きな負荷です。最近のOrbit SSF提案を含むいくつかの巧妙なアイデアが、この問題を緩和することができます。これにより、「最終性」が大幅に向上し、ユーザーエクスペリエンスが向上しますが、ユーザーが5-20秒待たなければならないという事実は変わりません。

ロールアップの事前確認

過去数年間、イーサリアムは常にロールアップを中心としたロードマップに従っており、イーサリアムのL1（エーテルの基礎層）の設計により、データの利用可能性やその他の機能をサポートし、これらの機能はL2プロトコル（ロールアップ、バリディウム、プラズマなど）で使用でき、イーサリアムと同等のセキュリティレベルをユーザーにより大規模に提供できます。

これにより、イーサリアムのエコシステム内で注目が分かれています：イーサリアムL1は、検閲に対する抵抗力、信頼性、安定性、および基礎層のコア機能の維持と改善に焦点を当てており、L2は異なる文化と技術を通じてユーザーとより直接的に接触することに注力しています。しかし、この道を進むと、避けられない問題が生じます：L2は、5〜20秒よりも速い確認をユーザーに提供したいと考えています。

これまでに、少なくとも理論的には、独自の「分散化ソーター」ネットワークを作成するのはL2の責任です。小さなグループのバリデータは、数百ミリ秒ごとにブロックに署名し、そのブロックの後ろにステークアセットを投入するかもしれません。最終的に、これらのL2ブロックのヘッダがL1に公開されます。

しかし、L2 バリデータ集合は「詐欺」を行う可能性があります：まずブロック B1 に署名し、その後衝突するブロック B2 に署名し、さらに B1 より前にそれをオンチェーンに提出することができます。しかし、それを行うと、検証され、ステーク資産を失うことになります。実際に、中央集権的なバージョンの実際の事例を見てきたが、一方で、ロールアップは分散化ソートネットワークの開発が遅れている。すべてのL2に分散化ソートを行うことを要求するのは公平ではないと言える：これはロールアップに、ほぼ新しいL1を作成するのと同じ作業を行うことを要求しているからです。そのため、Justin Drakeは常に、すべてのL2（およびL1）がイーサリアム全体で共有される基本的な事前承認メカニズムである「基礎的事前承認」を使用できるようにする方法を推進しています。

ベースライン確認

基礎的な事前確認（Based preconfirmations）の手法は、イーサリアムの提案者（Ethereum proposers）がMEVに関連する高度に複雑な参加者であると仮定しています。事前確認に基づく方法は、これらの複雑な提案者が事前確認サービスを提供する責任を受け入れることを奨励することで、この複雑さを利用します。

この方法の基本的なアイデアは、ユーザーが追加の料金を支払って即時の保証付きで次のブロックに取引が含まれることを保証し、その取引結果の実行に対する声明をするための標準化されたプロトコルを作成することです。提案者がユーザーに対して行った約束に違反した場合、彼らはスラッシングの対象となる可能性があります。

如所述，基于预确认为 L1 交易提供保证。如果ロールアップが“基于”である場合、すべての L2 ブロックは L1 トランザクションであるため、同じメカニズムが任意の L2 に対して先行確認を提供するために使用できます。

我々は実際に何を見ていますか？

仮に単一のスロットの最終性を達成したとします。Orbitのような技術を使用して、各スロットで署名する検証者の数を減らしますが、あまり多くは減らさず、同時に32 ETHのステークの最低限度を削減することも重要です。スロット時間は16秒に増加する可能性があり、その後、ロールアップの事前確認または基本的な事前確認を使用して、ユーザーに迅速な確認を提供します。最終的に得られるものは何でしょうか：エポックスロットアーキテクチャです。

epoch-and-slotアーキテクチャが避けられないように見える深い哲学的理由があります：あることについて最大限の「経済的最終性」の合意に達することは、おおよそ同意に達するために必要な時間よりも少ないです。

簡単な理由の1つは、ノード数です。超最適化されたBLS集約とまもなく登場するZK-STARKsのため、古い線形分散/最終性時間/コストのバランスは今や穏やかに見えますが、以下の理由を無視できません。

*「近似コンセンサス」は少数のノードしか必要としませんが、経済的ファイナリティはほとんどのノードを必要とします。

• ノードの数が一定の規模を超えると、署名を収集するのにより多くの時間がかかります。

今日のイーサリアムでは、12秒のスロットは3つのサブスロットに分割されます：ブロックの発行と配布、プルーフ、プルーフの集約。証明者の数が大幅に減少した場合、2つのサブスロットに減らして8秒のスロット時間を使用することができます。もう1つの現実的で大きな要素は、ノードの「品質」です。もう1つの大きな要素は、ノードの「品質」です。専門化されたノードのサブセットに頼ることで、近似プロトコルを達成することも可能です（そして、完全なバリデータセットを使用して最終性を決定します）。これにより、約2秒に短縮することができます。

私にとって、エポックとスロットのアーキテクチャは明らかに正しいですが、すべてのエポックとスロットの体系が平等であるわけではありません。より多くのデザイン空間を探索することは価値があります。Gasperのように密接に結合するのではなく、2つのメカニズムの間により強力なフォーカス分離がある方向に向かうことが探究する価値があります。

L2はどうすべきですか？

私の見解では、L2 には現在、合理的な戦略が3つあります：

• 技術的にも精神的にも「based」している。つまり、彼らはイーサリアムの基礎技術属性およびその価値観（高度な分散化、検閲に対する耐性など）を最適化しています。最も単純な形式では、これらのロールアップを「ブランドのシャーディング」と見なすことができますが、彼らは新しい仮想マシンの設計やその他の技術改善に多くの実験を行うこともできます。
• サーバーにブロックチェーンフレームワークを組み込み、それを十分に活用します。サーバーから始めて、それにSTARK 有効性証明を追加してサーバーが規則に従っていることを確認します。ユーザーの退出や強制取引の権利を保証します。集団選択の自由を持ち、大規模な退出をコーディネートするか、またはオーソライザーの投票を変更することで、ほとんどのブロックチェーンの利点を得ることができ、同時にサーバーの効率の大部分を保持します。
• 折衷方法：100個のノードを持つ高速チェーンがあり、イーサリアムは追加の相互運用性とセキュリティを提供しています。これは多くのL2プロジェクトの現実的なロードマップです。

一部のアプリケーション（例えばENS、キーマネージメント、一部の支払いプロトコル）には、12秒のブロック時間が十分です。これらの適用されないアプリケーションに対しては、唯一の解決策はepoch-and-slotアーキテクチャです。3つの場合すべてで、「epoch」はEthereumのSSFですが、slotはそれぞれ異なります。

• Ethereumのネイティブのepoch-and-slotアーキテクチャ
• サーバープリコンファーム
• 委員会は事前に確認します

重要な問題は、私たちは第1カテゴリでどの程度うまくやれるかですか？特に、それが非常に良くなった場合、第3カテゴリの意義があまり大きくなくなると感じられるためです。 'based'のすべてのスキームは、プラズマやバリディアムなどのオフチェーンデータL2には適用されないため、第2カテゴリは永遠に存在します。 Ethereumネイティブのepoch-and-slotアーキテクチャが1秒のスロット時間に低減できる場合、第3カテゴリのスペースははるかに小さくなります。

今日、私たちはこれらの問題の最終的な答えからはまだ遠いです。重要な問題の1つは、ブロック提案者がどれほど複雑になるかですが、これは依然としてかなりの不確定性が存在する領域です。Orbit SSFのような設計は非常に革新的ですので、例えばOrbit SSFをepoch-and-slotのepochなどの設計空間として十分に探求する価値があります。私たちが持つ選択肢が多ければ多いほど、L1およびL2のユーザーに対してより良いことができ、L2の開発者の作業を簡素化することができます。