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