イーサリアムでトランザクションをより速く確認する方法

優れたブロックチェーン UX の重要な特徴は、トランザクションの確認時間が速いことです。イーサリアムは5年前と比べて今日では大きな進歩を遂げました。 EIP-1559 とマージ後の安定したブロック時間のおかげで、L1 上のユーザーが送信したトランザクションは 5 ～ 20 秒以内に確実に確認できます。これは、クレジットカードで支払う場合の体験とほぼ同等です。ただし、ユーザー エクスペリエンスをさらに向上させることには価値があり、一部のアプリケーションでは数百ミリ秒以下の遅延が必要になります。この記事では、Ethereum の実用的なオプションをいくつか紹介します。

既存のアイデアと技術の概要

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

現在、Ethereum の Gasper コンセンサスはスロットおよびエポック アーキテクチャを使用しています。 12 秒のスロットごとに、バリデーターのサブセットがチェーン ブロック ヘッダーに投票を公開し、32 スロット (6.4 分) 以内に、すべてのバリデーターに 1 回投票する機会が与えられます。これらの投票は、2 エポック (12.8 分) 後に、ファイナリティと呼ばれる非常に厳格な経済的保証を提供する PBFT のようなコンセンサス アルゴリズムでメッセージとして再解釈されます。

過去数年間、私たちは現在のアプローチにますます不満を抱くようになりました。主な理由は次のとおりです。(i) 複雑であり、スロットごとの投票メカニズムとエポックごとのファイナリティメカニズムの間に多くの相互作用エラーが発生します。 (ii) 12.8 分は長すぎるので、誰もそんなに長く待ちたくありません。

シングルスロットファイナリティは、このアーキテクチャを、ブロック N がブロック N+1 が生成される前にファイナライズされる Tendermint コンセンサスに似たメカニズムに置き換えます。 Tendermint との主な違いは、バリデーターの 1/3 以上がオフラインの場合でもチェーンの実行を継続して回復できるようにする「非アクティブ リーク」メカニズムを保持していることです。

シングルスロットの最終設計

SSF の主な課題は、単純に言えば、すべての Ethereum ステーカーが 12 秒ごとに 2 つのメッセージを公開する必要があるということであり、これはブロックチェーンに大きな負担となります。最近の Orbit SSF 提案など、これを緩和するための巧妙なアイデアがいくつかあります。しかし、それでも、「最終性」が速まることでユーザー エクスペリエンスは大幅に向上しますが、ユーザーが 5 ～ 20 秒待つ必要があるという事実は変わりません。

ロールアップ事前確認

過去数年間、イーサリアムはロールアップ中心のロードマップをたどり、データの可用性やその他の機能をサポートすることを中心にイーサリアム ベース レイヤー (「L1」) を設計してきました。これらの機能は、ロールアップ (バリディウムやプラズマも含む) などのレイヤー 2 プロトコルで使用でき、ユーザーにイーサリアムと同じレベルのセキュリティを、より大規模に提供できます。

これにより、Ethereum エコシステムにおける関心の分離が実現します。Ethereum L1 は、検閲耐性、信頼性、安定性、および特定のコア インフラストラクチャ機能の維持と改善に重点を置くことができ、L2 は、異なる文化的および技術的なトレードオフを伴いながら、ユーザーへのより直接的なアプローチに重点を置くことができます。しかし、この道を進むと、避けられない疑問が生じます。L2 は、5 ～ 20 秒というより速い確認を求めるユーザーにサービスを提供したいと考えています。

これまでのところ、少なくとも言葉の上では、L2 は独自の「分散型順序付け」ネットワークを作成する責任を負っています。少数のバリデーターグループが、おそらく数百ミリ秒ごとにブロックに署名し、これらのブロックの背後に「ステーク」を配置します。最終的には、これらの L2 ブロックのブロック ヘッダーが L1 に公開されます。

L2 バリデータ セットは不正行為を行うことができます。つまり、最初にブロック B1 に署名し、次に競合するブロック B2 に署名して、B1 の前にチェーンに送信することができます。しかし、もしそうしたら、彼らは捕まり、賭け金を失うことになるでしょう。実際には、すでに集中型バージョンが見られますが、ロールアップでは分散型の注文ネットワークの開発が遅れています。すべての L2 に分散型の順序付けを要求するのは不公平だと言えるでしょう。ロールアップに、まったく新しい L1 を作成するのと本質的に同じ作業を要求することになります。このような理由とその他の理由から、Justin Drake は、すべての L2 (および L1) に、Ethereum 全体で共有される事前確認メカニズムに基づく事前確認へのアクセスを提供する方法を推進してきました。

事前確認に基づく

事前確認アプローチでは、Ethereum 提案者が MEV 関連の理由から非常に洗練されたアクターであると想定しています。事前確認ベースのアプローチは、これらの洗練された提案者に事前確認をサービスとして提供する責任を受け入れるようにインセンティブを与えることで、この複雑さを活用します。

基本的な考え方は、標準化されたプロトコルを作成し、それを通じてユーザーが追加料金を支払うことで、トランザクションが次のブロックに含まれ、トランザクションの実行結果に関するステートメントを受け取ることができるという即時の保証を得ることです。提案者がユーザーとの約束を破った場合、罰せられます。

前述のように、Based 事前確認メカニズムは L1 トランザクションを保護します。ロールアップが「ベース」である場合、すべての L2 ブロックは L1 トランザクションであるため、同じメカニズムを使用して任意の L2 の事前確認を提供できます。

ここで実際に何を見ているのでしょうか?

シングルスロットのファイナリティが達成されると仮定します。私たちは、Orbit と同様の技術を使用して、各スロットに署名するバリデーターの数を減らしますが、あまり減らさないことで、32 ETH の最小ステークを減らすという主要目標の達成にも貢献できます。その結果、スロット時間は徐々に 16 秒まで増加する可能性があります。次に、ロールアップ事前確認またはベース事前確認を使用して、ユーザーに迅速な保証を提供します。今何があるでしょうか?エポックアンドスロットアーキテクチャ。

「同じ図だ」というミームはこの時点で使い古されているので、数年前に描いた古い図と L2 事前確認図を組み合わせて、Gasper のスロットとエポックのアーキテクチャを説明し、これで要点が伝わればと思います。

エポック アンド スロット アーキテクチャの使用を避けるのが難しいと思われるのには、深い哲学的理由があります。それは、何かについてのおおよその合意に達するのにかかる時間は、何かについて最大限に強制された「経済的最終性」の合意に達するのにかかる時間よりも本質的に短いからです。

1 つの単純な理由は、ノードの数です。超最適化された BLS 集約と近い将来の ZK-STARK のおかげで、古い線形分散化 / ファイナリティ / オーバーヘッドのトレードオフは今でははるかに緩和されているように見えますが、以下の点は基本的に依然として真実です。

1. 「近似的なコンセンサス」には少数のノードのみが必要ですが、経済的な最終性には全ノードの大部分が必要です。

2. ノード数が一定のサイズを超えると、署名の収集にさらに時間をかける必要が生じます。

現在、イーサリアムでは、12 秒のスロットは、(i) ブロックの公開と配布、(ii) 証明、(iii) 証明の集約の 3 つのサブスロットに分割されています。証明者の数を大幅に減らすと、これを 2 つのサブスロットに減らし、スロット時間を 8 秒に短縮できます。実際にもっと重要なもう 1 つの要素は、ノードの「品質」です。おおよその合意に達するために特殊なノードのサブセットにも依存できる場合（そして、最終決定のために完全なバリデータ セットを使用する場合）、これを約 2 秒まで短縮できます。

したがって、私は、(i) スロット アンド エポック アーキテクチャは明らかに正しいが、(ii) すべてのスロット アンド エポック アーキテクチャが同じように作成されるわけではなく、設計空間をより完全に調査することには価値があると主張します。特に、Gasper ほど密接に絡み合っていないが、2 つのメカニズム間の関心をより強く分離するオプションを検討する価値があります。

L2は何をすべきでしょうか?

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

1. 技術的なものであれ精神的なものであれ、それは「根拠」がなければなりません。つまり、これらは、イーサリアムのベースレイヤーの技術的特性とその価値（高度な分散化、検閲耐性など）の導管となるように最適化されています。最も単純な形では、これらのロールアップは「ブランド シャーディング」と考えることができますが、新しい VM 設計やその他の技術的な改善を多数試すことで、それよりもはるかに野心的なものになることもあります。

2. 「ブロックチェーンの足場を持つサーバー」であることに誇りを持ち、それを最大限活用する。サーバーから始めて、(i) サーバーがルールに従っていることを確認するための STARK 有効性証明、(ii) ユーザーがトランザクションを終了または強制する権利の保証、および潜在的に (iii) 協調的な大量終了またはソーター変更の投票機能による集団選択の自由を追加すれば、サーバーの効率性の多くを維持しながら、オンチェーンの多くの利点を得ることができます。

3. 妥協案: 100 個のノードを持つ高速チェーン。Ethereum により相互運用性とセキュリティがさらに強化されます。これは、多くの L2 プロジェクトの事実上の現在のロードマップです。

一部のアプリケーション（ENS、キーストア、一部の支払いなど）では、12 秒のブロック時間で十分です。これでは不十分なアプリケーションの場合、唯一の解決策はスロットとエポックのアーキテクチャです。これら 3 つのケースすべてにおいて、「エポック」は Ethereum の SSF です (おそらく、この頭字語を「シングル スロット」以外の意味に再定義することもできます。たとえば、「Secure Speedy Finality」などです)。しかし、上記の 3 つのケースでは、「スロット」が異なります。

1. イーサリアムのネイティブスロット＆エポックアーキテクチャ

2. サーバーの事前確認

3. 委員会の事前確認

重要な質問は、カテゴリー（1）でどれだけうまくできるかということです。特に、本当に良くなると、カテゴリ（3）はそれほど意味をなさなくなるようです。カテゴリー（2）は常に存在します。少なくとも、PlasmaやvalidiumのようなオフチェーンデータL2では「ベース」のものは機能しないためです。しかし、イーサリアムのネイティブスロットアンドエポックアーキテクチャを「スロット」（事前確認）時間を1秒に短縮できれば、カテゴリ（3）の余地ははるかに小さくなります。

今日、私たちはこれらの質問に対する最終的な答えを得るには程遠い状況にあります。 1 つの重要な疑問、つまりブロック提案者がどの程度洗練されるかは、依然として大きな不確実性を抱えた領域です。 Orbit SSF のような設計は非常に新しいため、Orbit SSF のようなスロットおよびエポック設計の設計空間はまだ十分に調査されていないことが示唆されます。選択肢が多ければ多いほど、L1 と L2 のユーザーにとってより良いサービスを提供でき、L2 開発者の作業も楽になります。