イーサリアム 10周年 — トライレマを超える時

電力網やワールドワイドウェブのような分散型システムは、通信ボトルネックを解決することで拡張されました。ブロックチェーンは分散型設計の勝利であり、同じパターンに従うべきですが、初期の技術的制約により、多くの人々が分散化を非効率性や鈍いパフォーマンスと同一視するようになりました。

今年の7月でイーサリアムは10周年を迎え、開発者の遊び場からオンチェーンファイナンスの基盤へと進化しました。ブラックロックやフランクリン・テンプルトンといった機関がトークン化ファンドを立ち上げ、銀行がステーブルコインを展開する中、今の疑問は、重い作業負荷とミリ秒単位の応答時間が重要なグローバルな需要に応じてスケールできるかどうかです。

このすべての進化において、まだ1つの仮定が残っています。それは、ブロックチェーンは分散化、スケーラビリティ、およびセキュリティの間でトレードオフしなければならないということです。この「ブロックチェーンの三重苦」は、イーサリアムのジェネシスブロック以来、プロトコル設計を形作ってきました。

トライレマは物理学の法則ではなく、私たちがようやく解決方法を学んでいるデザインの問題です。

スケーラブルなブロックチェーンの状況

イーサリアムの共同創設者であるヴィタリック・ブテリンは、ブロックチェーンのパフォーマンスに関する3つの特性を特定しました:分散化(多くの自律的ノード)、セキュリティ(悪意のある行為への回復力)、そしてスケーラビリティ(取引速度)。彼は「ブロックチェーンのトライレマ」を導入し、2つを強化すると通常は3つ目が弱まることを示唆しました、特にスケーラビリティにおいて。

この枠組みがEthereumの道を形作った: エコシステムは分散化とセキュリティを優先し、数千のノードにわたる堅牢性とフォールトトレランスのために構築された。しかし、パフォーマンスは遅れをとっており、ブロックの伝播、コンセンサス、ファイナリティに遅延が発生している。

分散化を維持しながらスケーリングするために、Ethereum上のいくつかのプロトコルはバリデーターの参加を減少させたり、シャーディングネットワークの責任を分散させたりします。オプティミスティックロールアップは、実行をオフチェーンに移し、詐欺証明に依存して整合性を維持します。レイヤー2デザインは、何千ものトランザクションをメインチェーンにコミットされた単一のトランザクションに圧縮することを目指し、スケーラビリティの圧力を軽減しますが、信頼されたノードへの依存関係を導入します。

セキュリティは最重要であり、財務的なリスクが高まっています。失敗はダウンタイム、共謀、またはメッセージ伝播エラーから生じ、コンセンサスが停止したり、二重支出を引き起こします。しかし、ほとんどのスケーリングはプロトコルレベルの保証ではなく、ベストエフォートのパフォーマンスに依存しています。バリデーターは計算能力を向上させたり、高速ネットワークに依存するようにインセンティブを受けていますが、トランザクションが完了する保証はありません。

これは、Ethereumおよび業界にとって重要な質問を提起します: 負荷の下で、すべての取引が確定することに自信を持てるでしょうか? 確率的アプローチは、グローバル規模のアプリケーションをサポートするのに十分でしょうか?

物語は続くイーサリアムがその第二の10年に入るにあたり、これらの質問に答えることは、ブロックチェーンに依存する開発者、機関、そして数十億のエンドユーザーにとって重要になるだろう。

分散化は制限ではなく強み

分散化は、イーサリアムの遅いユーザーエクスペリエンスの原因ではなく、ネットワークの調整が原因でした。適切なエンジニアリングによって、分散化はパフォーマンスの利点となり、スケールの触媒となります。

中央集権的なコマンドセンターが完全に分散されたものよりも優れていると感じるのは直感的です。ネットワークを監視する全知のコントローラーを持つことが、どうして良くないのでしょうか?ここでこそ、私たちは仮定を解明したいと思っています。

続きを読む: マーチン・バーゲル - なぜ「高価な」イーサリアムが機関投資家のDeFiを支配するのか

この信念は数十年前にMITのメダード教授の研究室で始まり、分散型通信システムを証明可能な最適化を目指しました。今日、ランダム線形ネットワークコーディング(RLNC)を使用することで、そのビジョンはついに大規模に実装可能です。

テクニカルな話をしましょう。

スケーラビリティに対処するためには、まずレイテンシがどこで発生するかを理解する必要があります:ブロックチェーンシステムでは、各ノードは初期状態からの状態変化の同じシーケンスを観察するために、同じ操作を同じ順序で観察する必要があります。これはコンセンサスを必要とします—すべてのノードが単一の提案された値に同意するプロセスです。

イーサリアムやソラナのようなブロックチェーンは、ノードが合意に達しなければならない事前に定められた時間スロットを持つリーダーベースのコンセンサスを使用しています。これを「D」と呼びましょう。Dを大きくしすぎると決定性が遅くなり、逆に小さくしすぎるとコンセンサスが失敗します。これにより、パフォーマンスにおける持続的なトレードオフが生まれます。

イーサリアムのコンセンサスアルゴリズムでは、各ノードはゴシップ伝播を介して一連のメッセージ交換を通じて他のノードに自分のローカル値を伝えようとします。しかし、ネットワークの乱れ、例えば混雑、ボトルネック、バッファオーバーフローなどにより、一部のメッセージが失われたり遅延したり、または重複したりする可能性があります。

そのようなインシデントは情報の伝播にかかる時間を増加させ、それによってコンセンサスに達することは必然的に大きなDスロットをもたらします。特に大規模なネットワークでは。スケールするために、多くのブロックチェーンは分散化を制限しています。

これらのブロックチェーンは、各コンセンサスラウンドにおいて、一定の閾値の参加者、例えば全体の三分の二のステークからの認証を必要とします。スケーラビリティを達成するためには、メッセージの伝播効率を向上させる必要があります。

ランダムネットワーク線形符号化(RLNC)を使用して、プロトコルのスケーラビリティを向上させることを目指しており、現在の実装によって課せられる制約に直接対処しています。

スケールを拡大するための分散化:RLNCの力

ランダム線形ネットワークコーディング (RLNC) は、従来のネットワークコードとは異なります。それはステートレスで代数的、そして完全に分散型です。トラフィックを細かく管理しようとする代わりに、各ノードは独立して符号化されたメッセージを混合します。それでも、中央コントローラーがネットワークを調整しているかのように最適な結果を達成します。この方法が中央集権的なスケジューラーよりも優れていることは数学的に証明されています。これはシステム設計では一般的ではなく、このアプローチを非常に強力にしている要因です。

生のメッセージを中継する代わりに、RLNC対応ノードは有限体上の代数方程式を使用してメッセージデータを符号化された要素に分割し、送信します。RLNCにより、ノードはこれらの符号化された部分のサブセットのみを使用して元のメッセージを復元でき、すべてのメッセージが到着する必要はありません。

各ノードが受け取ったものをリアルタイムで新しい独自の線形結合に混合できるため、重複を回避します。これにより、すべての交換がより情報豊富になり、ネットワークの遅延や損失に対して耐性を持つようになります。

Ethereumのバリデーターは、Kiln、P2P.org、Everstakeを含むOptimumP2Pを通じてRLNCをテストしています。このシフトはもはや仮説ではありません。すでに進行中です。

次に、RLNCを活用したアーキテクチャとpub-subプロトコルが、他の既存のブロックチェーンに接続され、スループットを向上させ、遅延を低減するのに役立ちます。

新しい業界ベンチマークの呼びかけ

イーサリアムがその第二の10年でグローバル金融の基盤として機能するためには、時代遅れの仮定を超える必要があります。未来はトレードオフによって定義されるのではなく、証明可能なパフォーマンスによって定義されます。トリレンマは自然の法則ではなく、古い設計の制約であり、私たちはそれを克服する力を持っています。

現実世界での採用の要求に応えるためには、スケーラビリティを第一の原則として設計されたシステムが必要であり、妥協ではなく、証明可能なパフォーマンス保証に裏打ちされる必要があります。RLNCは前進の道を提供します。分散環境における数学的に裏付けられたスループット保証を備えたそれは、より高性能で応答性の高いEthereumのための有望な基盤です。

続きを読む: ポール・ブロディ - イーサリアムはすでに勝利した

コメントを見る

ETH-2.42%
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)