意見：イーサリアムはスケーラビリティのためにPoSに切り替えるリスクを冒すべきではない

原題：「意見 | イーサリアムのロードマップは変更されるべきか？」
執筆者: Ajian

「ロールアップ中心のイーサリアムロードマップ」（中国語訳）の公開以来、コミュニティ全体がイーサリアム（特にイーサリアム 2.0）のロードマップに疑問を抱いています。

2020年11月18日、イーサリアム財団のEth2.0研究チームの第5回AMAイベント（中国語抜粋翻訳）で、ヴィタリック氏はロードマップが変更されたことを明確に述べました。（1）フェーズ2の重要性は当面強調されなくなりました。フェーズ 1 では、ロールアップ方式で使用するためのデータ シャーディングを実現することに取り組んでいます。 （２）ビーコンチェーンには実行機能があり、Eth1-Eth2の合併後、ビーコンチェーンブロックには直接トランザクションが含まれる。 （３）フェーズ０の実施後の３つの主要タスクであるライトクライアントサポート、データシャーディング、マージは並行して推進され、準備が整い次第、各モジュールがリリースされる。

この記事の目的は、当初の 3 段階のロードマップを擁護することではありません。代わりに、この記事では、3 段階のロードマップは夢物語であり、新しいロードマップは不十分であり、Eth2.0 に関連するロードマップはどれも、Ethereum の現在の運用モデルを放棄して PoS ベースのシステムに移行する価値がないと主張しています。

ここでは、まず、当初の 3 段階のロードマップの論点と技術的な難しさについて説明します。次に、新しいロードマップのスケーラビリティを分析します。最後に、新しいロードマップのスケーラビリティの利点は、イーサリアムの PoS へのリスクの高い移行を正当化するには小さすぎると主張されています。

Eth2.0の3段階のロードマップ

過去 2 年間にわたり、広く流通している Eth2.0 ロードマップでは、3 つのコンポーネントを順番に実装することが計画されています。

• フェーズ0: PoSコンセンサスメカニズムを備えたビーコンチェーン

• フェーズ 1: 複数のシャード チェーン

• フェーズ2: すべてのシャードに実行機能を追加する

このロードマップから、Ethereum 2.0 の本来の目標は「シャード実行」システムを作成することであることが明確にわかります。つまり、各シャードには独自の状態があり、これらの状態は各シャードの状態遷移ルール​​に従って変化します。変更された状態はビーコン チェーンによって確定されます。したがって、Ethereum 2.0 は、複数のシャードがトランザクションを並行して処理できるシステムになります。これは、Ethereum 2.0 が「コンセンサス」と「トランザクション処理（検証）」が分離されたシステムであることを意味します。各シャードに割り当てられたバリデータは、トランザクションと状態の正確性を検証する責任を負います。ただし、これらの状態の確定はビーコン チェーンのエポック確定メカニズムに依存し、2 つのプロセスは完全に同期されません。

この「PoS ビーコン チェーン + マルチシャード」アーキテクチャは、PoS アルゴリズム自体の特性をうまく利用しているようです。「何も賭けていない」問題 (PoS ブロック生成には計算作業が必要ないため、ブロック生成の対象となるアカウントは同時に異なるフォークでブロックを生成しようとし、システムが崩壊する) を解決するために、Ethereum 2.0 で使用される Casper アルゴリズムでは、ユーザーがブロック生成の資格を得る前にデポジットの一部をデポジットする必要があります。バリデーターがブロック生成資格を乱用した場合（たとえば、同時に 2 つのフォークをサポートする場合）、デポジットは没収されます。その結果、Casper のようなアルゴリズムは、実際にブロックチェーン上に相互に通信可能でありながら独立して変化する 2 つの状態を作成します。1 つは一般ユーザーの状態で、もう 1 つはバリデーターのブロック重みの状態です。コンセンサス プロセスはブロックの重み状態に基づいており、コンセンサスに達するとブロックの重み状態も変更されます。したがって、コンセンサス プロセスは本質的にユーザー トランザクションの検証から独立しており、切り離すことができます。あらゆるトランザクション バッチと結果状態について、コンセンサス プロセスを「ファイナリティ ファイナライズ メカニズム」に抽象化することができ、論理的にはマルチシャード並列実行が可能になります。

スケーラビリティに関しては、イーサリアムのシャーディング技術の名前である「Quadratic sharding」がヒントを与えてくれます。シャード上のトランザクションの実行の複雑さをブロック ヘッダーの検証と同じ難易度にまで下げることができると仮定すると、シャード実行アーキテクチャは、参加ノードの処理能力が直線的に増加するにつれて、システム全体の処理能力を 2 乗的に増加させることができます。簡単に言えば、ネットワークに参加しているノードが一定期間内に（平均して）4 つのブロック ヘッダーを検証できる場合、シャードに参加しているノードは同じ時間内に 4 つのトランザクションを検証できることを意味します。このとき、システム全体の処理能力は 4 シャード × 4 トランザクション/シャード = 16 トランザクションです。ノードの処理能力が 8 (2 倍) になると、処理能力は 64 トランザクション (4 倍) になります。

素晴らしいように聞こえますが、この「二次展開」の議論には次の仮定が含まれています。

（１）シャードトランザクションの検証をブロックヘッダーの検証と同じ難易度にまで簡素化できる技術がある。

（２）シャード間のトランザクションは存在しない。つまり、各シャード内のトランザクションは互いに完全に独立している。クロスシャードトランザクションには、ビーコンチェーンの処理能力だけでなく、複数のシャードの処理能力も必要となり、スケーラビリティが大幅に低下します。

（１）に関しては、この仮定は満たされる。無国籍というのはまさにそういう技術です。そのアイデアは、トランザクション (またはブロック) を伝播するときに、トランザクション アクセス ステータスの証拠を提供することです。これにより、トランザクション検証者は、トランザクション実行時の状態データを保持することなく、トランザクションの有効性を検証できるようになります。これは極めて重大です。ステートレスでない場合、シャード検証に参加するバリデータはシャードの状態を保存する必要があります。これは、バリデータが継続的に異なるシャード チェーンに割り当てられるため、すべてのシャードの状態を保存する必要があるためです。実際には、これはすべてのシャードからブロックを継続的にダウンロードしてトランザクションを処理する必要があることを意味し、システム全体が大きなブロック システムに崩壊します (例: 16 のトランザクションを処理するために 16 のトランザクションを処理できるリソースを投資する)。残念ながら、現在のところ、Ethereum 1.0 では十分に軽量なステートレス メソッドがまだ開発されていません。

（２）に関しては、あまり言うことはありません。シャード間のトランザクションを実現できない場合、各シャードは独立して動作するため、シャード実行システムは意味がありません。システムが引き続き ETH に基づくことができるように、ETH は各シャード上に存在できる必要があります。これまでのところ、ビーコン チェーンの処理能力を増やさずにこれを実現できるクロスシャード トランザクション ソリューションは存在しません。その理由は非常に単純です。どのシャード A についても、並列処理のため、どのシャード B でどのようなトランザクションが発生しているか、またこのシャードの状態を書き換える必要があるかどうかは不明です。そのため、シャード A の状態を書き換えようとするトランザクションがシャード B で発生したことを確実に証明するための通信層が必要です。ただし、ビーコン チェーンにトランザクションを処理する機能が必要になると、二次拡張の効果が失われます。 （ちなみに、この信頼できる通信層のニーズを満たすチェーンが事実上のレイヤー 1 となり、その他のシャードが事実上のレイヤー 2 となり、これは「レイヤー 1 + レイヤー 2」に非常に似ています。）

疑わしいスケーラビリティに加えて、シャード実行はいくつかの興味深い経済的な問題を提起します。たとえば、シャード間のトランザクションの処理時間がシャード内のトランザクションの処理時間を超える場合 (必然的にそうなる)、異なるシャード上の ETH の値は同じではなくなることを意味します。アメリカの 1 ドルとアメリカ国外での 1 ドルは実際には同じではないのと同じです。シャードがいくつあっても、少なくとも 2 つの ETH 価格が存在します。 1 つは、最も繁栄している金融アプリケーションを持つシャード (つまり、Eth1 シャード) 上の ETH の価格です。もう 1 つは、他のシャード上の ETH の価格です。後者は前者と交換するために一定の料金を支払い、一定の時間を費やす必要があるため、前者には何らかの割引があるはずです。同様に、各シャードにユニスワップがあっても、異なるシャード上の市場のトランザクション スリップは確実に異なります。最終的には、全員が 1 つのシャードに収束します。全員が集まると、流動性が最も豊富になり、資本効率が最高になるからです。ある意味では、シャード間のトランザクションの必要性は最小限であると言えますが、これは他のシャード上のアイドル状態のトランザクション処理能力がまったく意味がないことも意味します。

シャード実行システムの技術的な難しさについては、ここでは詳しく説明しません。興味のある人は、シャード実行システムがどのように取引手数料を支払うかについて考えてみましょう。しかし、ここで私が言いたいのは、シャード実行システムの設計コンセプトは、すべての人の実際のニーズや物事の発展の法則に反しているということです。グローバル状態 (構成可能性) は問題ではありませんが、誰もが必要とするものです。イーサリアムは、あらゆる金融アプリケーションを瞬時に統合し、摩擦なく価値が流れる空間を作り出すことができるため、世界を変える可能性を秘めています。プロトコル層で価値の流れに摩擦を生み出すことは自滅的です。優れた基本レイヤーができたら、それを維持する方法を見つけ、残りはユーザーに選択させて、エコシステムが独自に進化するようにする必要があります。デザインによってエコシステムを設計できると考えないでください。過剰なデザインは、すべての人にコストを課すだけです。

シャード実行の一時停止 (フェーズ 2) は、間接的に、関連する困難さを確認します。近い将来、このパスでは満足のいく結果は得られません。それにもかかわらず、Eth2.0 の研究者が 3 段階のロードマップを完全に放棄したとは思いません。ヴィタリック氏はまた、変更されたロードマップはフェーズ 2 と完全に互換性があるが、フェーズ 2 はもはや優先されないことを強調しました。

しかし実際には、シャード実行を放棄することが、イーサリアムが選択すべき道です。

実行可能なビーコンリンクライン図

Ethereum 2.0 の新しいロードマップで最も注目すべき点は、ビーコン チェーン ブロックにマージされた Eth1 シャードからのトランザクションが含まれることです。つまり、ビーコン チェーンには実行機能があるということです。他のシャードにはデータを保存する機能のみがあります。

実際、新しいロードマップにおける「データシャーディング」の位置付けは、「Rollup のデータ可用性レイヤー」です。

実行ベースのシャーディングがなければ、二次スケーリングは不可能です。では、この「PoS レイヤー 1 + ロールアップ + ロールアップ データはメイン チェーン ブロックのスペースを占有しない」アーキテクチャのスケーラビリティはどの程度でしょうか?

この質問に答えるために、まず、Rollup ソリューションとメイン チェーン間の相互作用モードを見てみましょう。

まず、Rollup システムはステートレス コントラクトとして理解できます。この契約の内部状態 (どのユーザーがいくらお金を持っているか) は外部からは見えません。ただし、契約内で発生するすべてのトランザクションのデータは定期的に公開され、メインチェーンに公開されるため、第三者はこのデータを入手した後、契約の内部状態を再構築できます。

有効性証明を使用するロールアップ (ZK ロールアップなど) の特徴は、契約がトランザクション データを開示するたびに、これらのトランザクションが正しく実行されたこと、したがって新しい状態ルートが XXX であることを示す「計算整合性証明」が付随することです。証明が契約の検証に合格した場合、契約は状態ルートを更新します。証明が検証に合格できない場合、契約は更新を拒否します。

不正証明を使用するロールアップ スキーム (Optimistic Rollup など) はその逆です。つまり、誰かが契約のトランザクション データを開示するたびに、デポジットを預けて、契約の新しい状態ルートが YYY であると主張する必要があります。その後の一定期間内であれば、誰でも保証金を預け入れ、詐欺の証拠を発行してその主張に異議を唱えることができます。不正証明は、トランザクションのバッチに欠陥があること、またはトランザクションが処理された後の新しい状態ルートが YYY ではないことを証明します。異議申し立てが成功した場合、誤った主張を行った者は保証金を失うことになります。一定期間誰もチャレンジしない場合、コントラクトは状態ルートを YYY に更新します。

どちらのソリューションもチェーン上でデータを公開する必要があるため、オンチェーンのスペースを占有します。さらに、オンチェーン空間のサイズによって、ロールアップシステムの単位時間あたりの処理量（TPS）が決まります。さらに深く考えると、これらのトランザクションデータを、データ量の制約がより少ない場所、つまりレイヤー1ブロックのスペースを占有せずに公開することができれば、処理能力を2倍にすることができます。そういった場所が多ければ、相乗効果を生み出すことができます。

これは、「データ シャーディング」と「ロールアップ中心のロードマップ」の概念です。ロールアップ ソリューションによって、すべてのトランザクション データをシャード ブロックに格納します。処理能力はシャードの数に応じて何倍にも増加できます。現在の Ethereum ブロックのデータ量は約 20 ～ 30 KB であり、明らかに安全です。シャードが 64 個ある場合、15 秒ごとに 64*30 = 1920 KB = 1.9 MB のデータを供給できます。また、ユーザー側にこのような大きなデータスループットを提供しますが、必要に応じてこのデータをダウンロードでき、不要であればダウンロードする必要がないため、フルノードに負担をかけることはありません（これが「シャーディング」の意味です）。あなたも私も少しダウンロードしますが、ノードにかかる負荷は依然として非常に軽いです。いずれにせよ、これらのロールアップ契約のステータスを確認するために、ロールアップのすべての履歴トランザクションデータを持っている必要はありません。イーサリアムの状態は安全なままです。

それは合理的に思えますが、やはり楽観的すぎるし、仮定が多すぎます。

（1）この「ダウンロードしたいときはダウンロードし、ダウンロードしたくないときはダウンロードしない」という方法は、ZK Rollupではまったく機能しません。ZK Rollupが状態ルートを更新する場合、ZK Rollupコントラクト更新操作の検証者（つまり、レイヤー1のフルノード）は、証明を受け入れるときに、証明に対応するトランザクションデータも取得する必要があります。そうしないと、検証に合格しません。 (トランザクション データを提供する必要がなく、コントラクト状態ルートを進めるための証明のみを検証するソリューションもあり、これは Validium と呼ばれますが、これは Rollup ではありません)。つまり、ZK Rollup のみを考慮すると、「データ シャーディング」方式は帯域幅の点では大きなブロックと変わりません。データが元々誰に送信されたか、どこに保存されていたかに関係なく、フルノードはそれをダウンロードする必要があります。

（２）楽観的ロールアップの場合、より楽観的な仮定をとる場合は、もちろんそうすることができます。通常の状況では、トランザクション データをまったくダウンロードせず、最終確認のために最新のステータス ルートのみを保持することができます。紛争が発生した場合にのみ、関連する取引データをダウンロードします。フルノードの観点からは、契約ステータスを確認する能力は失われていません。しかし、ユーザーの視点から見ると、状況はまったく異なります。いつでもステータスを再構築して引き出しを完了できるかどうかが不安になります。つまり、ユーザーは Optimistic Rollup と Plasma のどちらを使用しているか確認できなくなります。もともと、Optimistic Rollup ソリューションは、すべてのフルノードが履歴トランザクションのバックアップを保持することを保証するため、ユーザーは自分のステータスを簡単に再構築し、ステータス証明 (またはアサーション) を送信して引き出しを完了できます。しかし、この保証が失われると、ステータスを再構築できるかどうかはわかりません。 Optimistic Rollup のセキュリティも影響を受けます。セキュリティの前提は、トランザクション データを取得する人の少なくとも 1 人がプロトコルに準拠することです。データ シャーディング モードでは、トランザクション データのこの部分を要求する人数がわかりません。

要約すると、「データ シャーディング」モードを ZK Rollup と組み合わせると、帯域幅の点でより大きなスケーラビリティを提供することはできませんが、ブロック スペースを拡張するのと同じ効果があります。 Optimistic Rollup と組み合わせると、大きなブロックに対するスケーラビリティの利点はチャレンジの頻度に反比例します。さらに深刻なことに、Optimistic Rollup がプラズマに退化するリスクがあります (定義上、Optimistic Rollup は存在せず、Optimistic Rollup とプラズマの間にある別の名前を使用してこれを指す必要があります)。

結論は

Rollup ソリューションは、実際には、Layer-2 の開発中に学んだ厳しい教訓から生まれた不死鳥です。その最大の特徴は、ユーザーの財務上の安全性を完全に保護することです。トランザクション データを取得すると誰でも状態を再構築でき、ブロックチェーンによってこれらのトランザクション データの永続的なデータ可用性が保証されるため、Rollup ソリューションはレイヤー 2 ソリューションの中で最高のユーザー保護を提供できます。このようなソリューションがあれば、ユーザーはそれを実際に使用したいと思うでしょう。この利点を放棄し、パフォーマンスを最大化するという楽観的な仮定に基づいてシステムを設計すると、ユーザーが使用しようと思わないものを設計することになります。

Rollup が本質的にはコントラクト設計パターンであることを理解すれば、「PoS + データ シャーディング + Rollup はより大きなスループットを提供できる」という神話は一目でわかります - Rollup はコンセンサスに関係なく同じスケーラビリティを提供でき、データ シャーディングはより多くのスケーラビリティを提供できますが、他のセキュリティの仮定が導入されたため、Rollup はスループットと引き換えにセキュリティを犠牲にしています - 問題は、Rollup よりもセキュリティが弱く、スケーラビリティが高いこのようなコントラクトが以前にも登場しており、それらを pow チェーン上で設計できないが、設計しても誰も使用していないことです。

2017 年以来、Ethereum コミュニティは実用的なニーズに応える安全なスケーラビリティ ソリューションを見つけるのに苦労してきました。 「PoS + シャーディング」は強力なスケーラビリティを提供できると多くの人が信じているかもしれませんが、それは「シャーディングされた実行システム」であり、独自の問題を抱えています。私たちの目の前にある「実行可能なビーコン リンク」は、スループットと引き換えに契約自体のプロパティを犠牲にしているに過ぎません。今のところ、スケーラビリティのために Ethereum が PoS を採用すべきだという証拠はありません。

結局のところ、ユーザーのニーズを満たすパフォーマンスの向上だけが、真に意味のあるパフォーマンスの向上となります。ユーザーの実際のニーズから始めず、技術的な美しさやパフォーマンスの最大化という仮定から始めてしまうと、空中楼閣しか設計できません。可能であれば、ユーザーに自分で決定させましょう。プロトコル層を過度に心配すると、摩擦が生じることがよくあります。

イーサリアムのロードマップは変更されるべきでしょうか?もちろん、こうした非現実的な空想は捨てて、ユーザーが何を必要としているのかをもう一度自問してみる必要があります。