This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Polkadotの弾性的拡張：Web3エコシステムにおける拡張性と安全性のトレードオフ
スケーラビリティとトレードオフ：PolkadotとWeb3エコシステムの技術的選択
ブロックチェーン技術がより高い効率を追求する中で、重要な問題が次第に明らかになっています。それは、拡張性能を向上させる一方で、セキュリティとシステムの弾力性をどのように両立させるかということです。これは技術的な挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、信頼とセキュリティを犠牲にして単により速いシステムを追求することは、真に持続可能なイノベーションを支えることは難しいのです。
Web3のスケーラビリティにおける重要な推進者として、Polkadotは高スループットと低遅延を追求する際に、何らかの犠牲を払っているのでしょうか？そのrollupモデルは、分散化、安全性、またはネットワーク相互運用性において妥協しているのでしょうか？この記事では、これらの問題を中心に、Polkadotのスケーラビリティ設計におけるトレードオフとバランスを深く分析し、他の主要なブロックチェーンのソリューションと比較しながら、パフォーマンス、安全性、分散化の三者間の異なる選択肢について探ります。
Polkadot拡張機能設計の課題
柔軟性と非中央集権のバランス
Polkadotのアーキテクチャは、バリデーターネットワークとリレーチェーンに依存していますが、これが何らかの面で中央集権的なリスクをもたらす可能性はありますか？単一障害点や制御が形成される可能性があり、それがその非中央集権的な特性に影響を与えることはありますか？
Rollupの運用は、中継チェーンのオーダラーに依存しており、その通信にはコラレータープロトコルメカニズムが使用されます。このプロトコルは完全にパーミッションレスで、信頼不要であり、ネットワーク接続を持つ誰でも利用でき、少数の中継チェーンノードに接続し、rollupの状態遷移リクエストを提出できます。これらのリクエストは、中継チェーンのあるコアによって検証され、1つの前提条件を満たす必要があります：それは有効な状態遷移である必要があり、さもなければそのrollupの状態は進行しません。
垂直拡張のトレードオフ
Rollupは、Polkadotのマルチコアアーキテクチャを活用することで垂直スケーリングを実現できます。この新しい機能は「弾力的なスケーリング」機能によって導入されました。設計プロセスの中で、rollupブロックの検証が特定のコアに固定されていないため、弾力性に影響を与える可能性があることがわかりました。
中継チェーンにブロックを提出するプロトコルは、許可不要で信頼不要であるため、誰でもロールアップに割り当てられた任意のコアにブロックを提出して検証することができます。攻撃者はこれを利用して、以前に検証された合法的なブロックを異なるコアに繰り返し提出し、悪意を持ってリソースを消費することで、ロールアップの全体的なスループットと効率を低下させる可能性があります。
Polkadotの目標は、システムの重要な特性に影響を与えずに、ロールアップの柔軟性と中継チェーンリソースの効率的な利用を維持することです。
シーケンサーの信頼性の問題
簡単な解決策は、プロトコルを「許可された」に設定することです：例えばホワイトリストメカニズムを採用するか、デフォルトで信頼されたオーダーラーが悪意のある行動を取らないことを保証し、ロールアップの活動を確保します。
しかし、Polkadotの設計理念では、シーケンサーに対して信頼の仮定を行うことはできません。なぜなら、システムの「信頼不要」と「許可不要」の特性を維持する必要があるからです。誰でもコレータープロトコルを使用してロールアップの状態変換要求を提出できるべきです。
ポルカドット: 妥協のないソリューション
Polkadotが最終的に選択した解決策は、問題を完全にrollupの状態遷移関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できるソースであるため、出力内でどのPolkadotコア上で検証が実行されるべきかを明確に宣言する必要があります。
このデザインは、弾力性と安全性の二重保証を実現しています。Polkadotは、可用性プロセスでrollupの状態遷移を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を確保します。
ポルカドットのデータ可用性層（DA）に任意のロールアップブロックを書き込む前に、約5人の検証者で構成されたグループがその合法性を先に検証します。彼らは、ロールアップブロックおよび対応するストレージ証明を含む候補レシートと有効性証明をソータから受け取ります。これらの情報は、パラチェーン検証関数によって処理され、リレーチェーン上の検証者によって再実行されます。
検証結果には、どのコアでブロックを検証するかを指定するためのコアセレクターが含まれています。バリデーターは、そのインデックスが自分が担当するコアと一致するかどうかを比較します。一致しない場合、そのブロックは破棄されます。
このメカニズムは、システムが常に信頼不要かつ許可不要の特性を維持し、ソート者などの悪意のある行為者が検証位置を操作することを防ぎ、ロールアップが複数のコアを使用しても弾力性を保つことを保証します。
セキュリティ
スケーラビリティの追求において、Polkadotはセキュリティを妥協していません。ロールアップのセキュリティはリレーチェーンによって保障されており、1つの誠実なオーダラーが生存を維持するだけで済みます。
ELVESプロトコルを利用して、Polkadotはすべてのrollupにそのセキュリティを完全に拡張し、コア上のすべての計算を検証し、使用するコアの数に対して制限や仮定を行う必要がありません。
したがって、Polkadotのロールアップは、セキュリティを犠牲にすることなく真のスケーラビリティを実現できます。
###の汎用性
弾性拡張はrollupのプログラマビリティを制限しません。Polkadotのrollupモデルは、WebAssembly環境でチューリング完全な計算を実行することをサポートしており、単一の実行が2秒以内に完了する限り可能です。弾性拡張により、6秒のサイクル内で実行可能な総計算量が増加しますが、計算の種類には影響を与えません。
###の複雑さ
より高いスループットとより低いレイテンシは避けられない複雑性をもたらし、これはシステム設計において唯一受け入れ可能なトレードオフの方法です。
RollupはAgile Coretimeインターフェースを介してリソースを動的に調整し、一貫したセキュリティレベルを維持できます。また、さまざまな使用シーンに適応するために、部分的にRFC103の要件を実装する必要があります。
具体的複雑性は、rollupのリソース管理戦略に依存し、これらの戦略はオンチェーンまたはオフチェーンの変数に依存する可能性があります。例えば：
自動化方式はより効率的ですが、実現とテストのコストも著しく上昇します。
###相互運用性
Polkadotは異なるロールアップ間の相互運用性をサポートしており、弾力的なスケーラビリティはメッセージ伝達のスループットに影響を与えません。
クロスロールアップのメッセージ通信は、基盤となるトランスポートレイヤーによって実現され、各ロールアップの通信ブロックスペースは固定されており、割り当てられたコアの数には関係ありません。
将来、Polkadotはオフチェーンメッセージングをサポートし、リレーチェーンが制御面として機能し、データ面ではなくなります。このアップグレードにより、ロールアップ間の通信能力は弾力的に拡張され、システムの縦のスケーラビリティがさらに強化されます。
他のプロトコルのトレードオフ
誰もが知っているように、パフォーマンスの向上はしばしば非中央集権性と安全性を犠牲にすることで達成されます。しかし、ナカモト係数の観点から見ると、いくつかのPolkadotの競合他社は、非中央集権性の程度が低いにもかかわらず、そのパフォーマンスはあまり良くありません。
あるパブリックチェーンA
あるパブリックチェーンAは、PolkadotやEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャでスケーラビリティを実現し、歴史的証明、CPUの並列処理、およびリーダーベースのコンセンサスメカニズムに依存しており、理論的なTPSは65,000に達する可能性があります。
重要な設計は、その事前に公開され、検証可能なリーダースケジューリングメカニズムです：
歴史は、並行処理がハードウェアに非常に高い要求を課すことを証明しており、それが検証ノードの集中化を引き起こしています。ステーキングを行うノードが多いほどブロック生成の機会が増え、小さなノードはほとんどスロットを持たず、さらに集中化が進み、攻撃を受けた後のシステムダウンのリスクも高まります。
あるパブリックチェーンAはTPSを追求するために、非中央集権性と攻撃耐性を犠牲にし、そのNakamoto係数はわずか20で、Polkadotの172を大きく下回っています。
特定のブロックチェーンB
あるパブリックチェーンBはTPSが104,715に達すると主張していますが、この数字はプライベートテストネット、256のノード、理想的なネットワークおよびハードウェア条件下で実現されたものです。一方、Polkadotは分散型パブリックネットワークで128K TPSを達成しています。
あるパブリックチェーンBのコンセンサスメカニズムには安全上の懸念が存在します：シャーディング検証ノードのアイデンティティが事前に露出する可能性があります。あるパブリックチェーンBのホワイトペーパーでも明確に指摘されており、これは帯域幅を最適化できるものの、悪用される可能性もあります。「ギャンブラー破産」メカニズムが欠如しているため、攻撃者は特定のシャードを完全に制御するまで待機するか、DDoS攻撃を通じて誠実な検証者を阻止し、状態を改ざんすることが可能です。
対照的に、Polkadotのバリデーターはランダムに割り当てられ、遅延して公開されるため、攻撃者は事前にバリデーターの身分を知ることができず、攻撃には全てを賭けて成功する必要があります。誠実なバリデーターが争議を提起すれば、攻撃は失敗し、攻撃者はステーキングの損失を被ります。
ある公链C
あるパブリックチェーンCは、メインネット+サブネットアーキテクチャを用いて拡張を行っています。メインネットはX-Chain（送金、~4,500 TPS）、C-Chain（スマートコントラクト、~100-200 TPS）、P-Chain（バリデーターとサブネットの管理）で構成されています。
各サブネットの理論TPSは約5,000に達することができ、Polkadotの考え方に似ています：単一のシャードの負荷を減らして拡張を実現します。しかし、ある公チェーンCでは、バリデーターが自由にサブネットへの参加を選択でき、サブネットに地理的、KYCなどの追加要件を設定できるため、分散化と安全性が犠牲になっています。
Polkadotでは、すべてのロールアップが統一されたセキュリティ保証を共有しています。一方、ある公链Cのサブネットにはデフォルトのセキュリティ保証がなく、一部は完全に中央集権的でさえあります。セキュリティを向上させるためには、依然としてパフォーマンスに妥協が必要で、確定的なセキュリティの約束を提供することは困難です。
あるパブリックチェーンD
あるパブリックチェーンDのスケーリング戦略は、基盤層で直接問題を解決するのではなく、ロールアップ層のスケーラビリティに賭けることです。この方法は本質的に問題を解決するものではなく、問題をスタックの上のレイヤーに渡すことになります。
オプティミスティックロールアップ
現在、多くのOptimistic rollupは中央集権的であり（中には1つのシーケンサーしかないものもあります）、安全性が不十分で、孤立していて、遅延が高い（詐欺証明期間を待つ必要があり、通常は数日）などの問題があります。
ZKロールアップ
ZKロールアップの実装は、単一トランザクションで処理できるデータ量に制限されています。ゼロ知識証明を生成するための計算要求は非常に高く、"勝者総取り"メカニズムはシステムの中央集権化を引き起こしやすいです。TPSを保証するために、ZKロールアップはしばしばバッチごとのトランザクション量を制限し、高需要時にはネットワークの混雑やガスの上昇を引き起こし、ユーザーエクスペリエンスに影響を与えます。
それに比べて、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済セキュリティプロトコルの約2×10^6倍です。
さらに、ZKロールアップのデータ可用性の問題は、その欠点を悪化させる可能性があります。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存しており、コストとユーザー料金をさらに押し上げることになります。
まとめ
スケーラビリティの限界は、妥協であるべきではない。
他のパブリックブロックチェーンと比較して、Polkadotは集中化による性能向上や事前信頼による効率化の道を選んでいません。むしろ、弾力的なスケーラビリティ、許可不要のプロトコル設計、統一されたセキュリティレイヤー、柔軟なリソース管理メカニズムを通じて、安全性、非中央集権、高性能の多次元的なバランスを実現しています。
今日、より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラストの拡張性」が、Web3の長期的な発展を支える本当の解決策であるかもしれません。