原題：「How Proof of Stake Ethereum Works」パトリック・マッコリー著

原文の翻訳: 0x フェリックス

原文校正：Franci, ECN

イーサリアムは、待望のマイルストーンの 1 つである合併を達成しました。これは非常に重要な瞬間です。 7 年間の努力の末、イーサリアム コミュニティは、プルーフ オブ ワーク メカニズムをプルーフ オブ ステーク コンセンサス プロトコルに置き換えることに成功しました。即座の効果は、ネットワークのエネルギー消費量を 99.95% 削減することですが、これは世界の電力消費量のわずか 0.02% にすぎません。これは祝うに値する結果です。

さらに、アップグレードによってもたらされる多くの技術的な利点がありますが、コミュニティのほとんどは明確ではありません。プルーフ・オブ・ステークがどのように機能するのか、なぜそれが重要なのか、そしてどのようなエキサイティングな機能が登場するのかについて、よりアクセスしやすい資料が必要な時期が来ています。特にプルーフ・オブ・ステークが数千億ドルの資産を保護している今では。

この取り組みをサポートするために、私たちは、このテクノロジーに興味のある研究者、開発者、エンド ユーザーを対象として、プルーフ オブ ステーク プロトコルを説明する一連の記事を用意しました。 2 週間にわたって、次の記事を公開し、関連リンクを更新します。

- モジュラー設計と 2 つのブロックチェーン、

- エポック、スロット、ビーコンブロック、

- 検証者の証人および投票プロトコル、

- 補償と罰、

- イーサリアムのプルーフ・オブ・ステークはその目標を達成しましたか?

さらに、次のトピックの一部についても説明します。

- 登録と退会のプロセス、

- 滞納罰金、

- アグリゲーターと分科会の役割、

- スイング攻撃（未公開）、

- 同期ボード (未公開)。

これらの記事がプルーフ オブ ステーク プロトコルの仕組みを理解し、開発中にコンセンサス クライアント コードに取り組む前の前提知識として役立つことを願っています。

私の質問に辛抱強く答えてくれた Teku チーム、特に Ben Edington と Mikhail Kalinin に感謝します。

モジュラー設計と 2 つのブロックチェーン

ブロックサイズ戦争は最終的には分散化のための戦いです - できるだけ手頃な価格であるべきでしょうか?それとも可能な限り検証可能であるべきでしょうか？

ブロックチェーンのスケーラビリティの追求により、コミュニティは過去 10 年間にいくつかの野心的な提案を提案してきましたが、問題の中心には、次のような基本的なトレードオフがあります。

- 手頃な価格: ネットワーク上で取引できるユーザーの数のサイズ。

- 検証可能性: トランザクションの整合性をリアルタイムで検証するためのハードウェアや帯域幅などの厳しい要件を持つユーザーの数。

最新のブロックチェーン システムの多くは、ネットワーク オペレーターがこれを実現するために最善を尽くすつもりであれば、何よりも手頃な価格と最大ユーザー数を優先します。オペレーターは一生懸命働くべきだというこの前提は、オペレーターとして参加できる人の数を減らすため、ブロックチェーンシステムを集中化する傾向があります。特に、オペレーターが承認されたメーカーからハードウェアを購入する必要があるネットワークの場合はそうです。

最新のブロックチェーンの設計が間違っているというわけではありませんが、どちらも今のところビットコインやイーサリアムほどの注目を集めていません。私たちの意見では、顕著な理由の 1 つは、この基本的なトレードオフです。これはビットコインのブロックサイズに関する議論の中心であり、コミュニティは最終的に、長期的な手頃な価格よりもネットワークの完全性を誰が検証できるかを優先することを決定しています。

イーサリアムと同じように、ライトニングネットワーク、サイドチェーン、またはロールアップによって手頃な価格を別のレベルに押し上げることができれば幸いです。イーサリアムのコミュニティ、ロードマップ、価値観はすべて同じ背景から生まれています。唯一の違いは、イーサリアムには社会契約が根付いており、コミュニティがこのジレンマを克服するために基礎となるプラットフォームを実際に変更できることです。

Proof of Stake とは関係のない唯一の教訓があるとすれば、それは、分散型ネットワークのコンテキストでは TPS メトリクスが無意味であるということです。スケーラビリティは、いかなるコストを払ってでもスループットを向上させることだけを意味するものではなく、次のように定義する必要があります。

「完全に検証するノードを実行するために必要な同じコンピューティング、帯域幅、ストレージ要件を遵守しながら、トランザクションのスループットを向上させます。」

読者としては、この議論は奇妙に思えるかもしれません。なぜブロックチェーンのスケーラビリティについて話しているのでしょうか?これはプルーフ・オブ・ステークとどのように関係しますか?さらに、アップグレードによってトランザクションのスループットがすぐに有意義に向上するわけではないため、この議論はさらに論点から外れているように思えます。その理由は、このアップグレードが将来のスケーラビリティ ソリューションの基礎を築く能力において過小評価されてきたためです。

モノリシックブロックチェーンからモジュラーブロックチェーンへ

新しいメンタル モデル - コンセンサス参加者はすべての大変な作業を行う必要はなく、作業が正しいことを確認して同意するだけです。

数年を早送りして、ブロック サイズ戦争の後を見てみましょう。このジレンマがブロックチェーン システム、つまりモノリシック ブロックチェーンまたはモジュラー設計の設計にどのような影響を与えるかについて、より適切な用語が得られました。

単一タイプのブロックチェーン。これは、トランザクションの実行方法、データのブロードキャスト方法、データベースの保存方法など、すべてのハードウェアのボトルネックに対する一般的な解決策を見つけようとするブロックチェーン プロトコルおよび実装メカニズムです。参加するネットワーク オペレータはすべての面倒な作業を行い、モノリシック実装全体を実行する必要があるため、コンセンサス プロトコルに参加できる人が大幅に制限されます。

モジュラー設計によりリソースがレイヤーに再定義され、チームが各レイヤーで問題を解決するソフトウェアを構築できるようになります。

リソースはレイヤーを形成します。イーサリアムのプルーフ・オブ・ステーク設計とその長期ロードマップの背後にある大きな力の 1 つは、各リソースを新しい階層として定義することです。レイヤーであることにより、問題を分離して独立させることができ、チームがそれぞれの特定の問題を解決するための新しいソフトウェア クライアントを構築できるようになります。これはモジュール式ブロックチェーン設計として知られています。

おそらく、モジュラーアプローチについて最も重要な理解は、それがコンセンサス参加者の認識をどのように変えるかということです。もはや、彼らに仕事量を最優先させる必要はありません。代わりに、以下に焦点を当てます。

「ブロック提案者が行う必要がある最小限の作業量は何ですか? 不必要な労力をすべて他の場所で行うことは可能でしょうか?」

答えははいです

バリデータはライトクライアントとして機能します。ブロックチェーン プロトコルは、もはやネットワーク オペレーターの仕事を最大化することを中心に設計されていません。実際にはその逆が当てはまり、ネットワーク オペレーター (バリデーター) はライト クライアントである必要があり、他の場所で行われた作業をチェックして検証するだけで十分です。

そういうわけで、私は個人的に「validator」という名前が気に入っています。彼らの唯一の仕事は、イーサリアムデータベースに保存されているすべてのユーザー資産を検証し、合意（コンセンサス）に達し、最終的に安全にすることです。長期的には、参加には市販のハードウェアと良好なインターネット接続のみが必要となります。

さらに、バリデーターを軽量クライアントにすることで、実行中のノード ソフトウェアの利他的な性質に最終的に対処できる可能性があります。ユーザーは最終的に、ブロックチェーンを検証し、リアルタイムでその整合性をチェックすることで報酬を受け取ることができるようになります。また、彼らが仕事をしているかどうかを確認することもできます。

2つのブロックチェーン

この合併は、イーサリアム仕様をモジュラー設計に移行させる最初のマイルストーンです。

これにより、トランザクションの順序に関する世界的なコンセンサスと、最終的なトランザクションの実行が切り離されます。同時に、次の 2 つの新しいブロックチェーンが導入されます。

1) ブロックチェーンを実装します。ユーザー生成のトランザクションとスマート コントラクトの実行を処理するオリジナルのイーサリアム ブロックチェーン。 ETH 1 ブロックチェーンと呼ばれることもあります。

2) コンセンサスブロックチェーン。コンセンサス層専用のブロックチェーン。ブロックチェーンを実行する正規チェーンを決定し、プルーフ・オブ・ステークの転写を記録する責任があります。ビーコンブロックチェーンと呼ばれることもあります。

2 つのソフトウェア クライアント。 Proof-of-Work PoW モジュール、および通常、正規チェーン上の決定を処理するコードは、元の Ethereum ノード ソフトウェアから削除できます。実行環境全体はそのまま残り、現在は実行クライアントと呼ばれています。正規の実行チェーンを取得するために、新しいブロックのコンセンサス層を処理するソフトウェア クライアント (「コンセンサス クライアント」) をポーリングします。

実装されているブロックチェーンとクライアントはほとんど変わっていないため、この記事ではプルーフ・オブ・ステーク・プロトコルのコンセンサス層の実装に焦点を当てます。

マルチクライアントのエコシステム。上記の分離の結果、コンセンサスや実行の問題を独立して解決しようとするいくつかのチームが出現しました。もちろん、どちらの場合も一般的な仕様に従う必要がありますが、実装の詳細は自由に実験できます。現在、繁栄している (そして驚くほど資金が潤沢な) マルチクライアント エコシステムがあります。たとえば、コンセンサス クライアントには Teku や Prysm が含まれ、実行クライアントには Geth、Erigon、Nethermind が含まれます。

バリデーターは、コンセンサスクライアントと実行クライアントをさまざまに組み合わせて実行することをお勧めします。これは、同じバグが複数の独立した実装間で複製されないことを期待して、コンセンサスレベルのバグに対する防御の第一線です。このソフトウェア エンジニアリングの実践は、「N バージョン」プログラミングと呼ばれます。

最後に書きます

最後に書きます

注意深い読者は、ここでデータの可用性、実行、決済レイヤーが使用されていることに気づいたかもしれませんが、プルーフ・オブ・ステークのイーサリアムがコンセンサス層と実行レイヤーの基盤を築きます。

長期的なロードマップは次のとおりです。

コンセンサス → データの可用性。すべてのバリデーターはデータの順序付けについて合意に達し、プロトダンクシャーディングはこの役割を強化するのに役立ちます。

ロールアップ → 実行層。ロールアップは実行層の役割を引き受けます。

ETH1→決済層。オリジナルのイーサリアム ブロックチェーンは、ユーザー定義のすべての資産を保護する信頼の基盤です。

この命名法は、イーサリアム プロトコルの将来の反復によっては混乱を招く可能性があります。実装され展開されているため、現在では単にコンセンサス層と強制層と呼んでいます。