Web3 のスケーラビリティのトレードオフ：Polkadot の解決策

ブロックチェーンがより高い効率を追求する今日、重要な問題が徐々に浮かび上がってきました：パフォーマンスを拡張しながら、安全性とシステムの弾力性をどのように両立させるか？

これは技術的な課題だけでなく、アーキテクチャ設計における深い選択でもあります。Web3エコシステムにとって、信頼性と安全性を犠牲にして構築されたより速いシステムは、真の持続可能なイノベーションを支えることが難しいことがよくあります。

PolkadotはWeb3のスケーラビリティの重要な推進者として、そのロールアップモデルが分散化、安全性、またはネットワークの相互運用性で妥協をしているのかどうかを考察します。本稿では、Polkadotのスケーラビリティ設計におけるトレードオフとバランスを深く分析し、他の主要なパブリックチェーンのソリューションと比較し、パフォーマンス、安全性、分散化の三者の間での異なる選択肢を探ります。

Polkadotのスケーリング設計の課題

弾性と分散化のバランス

Polkadotのアーキテクチャは、バリデーターのネットワークとリレーチェーンに依存していますが、これは何らかの形で中央集権的なリスクを引き起こす可能性がありますか？単一障害点や制御が形成される可能性はありますか？その結果、分散化の特性に影響を与えることはありますか？

Rollupの運用は、リレーチェーンに接続されたオーダラーに依存しており、その通信にはcollatorプロトコルと呼ばれるメカニズムが使用されます。このプロトコルは完全に許可不要で、信頼不要であり、ネットワーク接続を持っている人なら誰でも使用でき、少数のリレーチェーンノードに接続し、rollupの状態変換要求を提出できます。これらの要求は、リレーチェーンのいずれかのコアによって検証され、1つの前提条件を満たす必要があります：有効な状態変換でなければならない、さもなくばそのrollupの状態は進められません。

垂直拡張のトレードオフ

Rollupは、Polkadotのマルチコアアーキテクチャを利用することで垂直スケーリングを実現できます。この新しい能力は「弾性スケーリング」機能によって導入されました。設計過程で、rollupブロックの検証が特定のコアで固定されていないため、弾性に影響を与える可能性があることがわかりました。

リレーチェーンにブロックを提出するプロトコルは、許可不要で信頼不要であるため、誰でもロールアップに割り当てられた任意のコアにブロックを提出して検証できます。攻撃者はこれを利用して、以前に検証された合法的なブロックを異なるコアに繰り返し提出し、悪意を持ってリソースを消費し、ロールアップの全体的なスループットと効率を低下させる可能性があります。

Polkadotの目標は、システムの重要な特性に影響を与えることなく、ロールアップの弾力性と中継チェーンリソースの有効活用を維持することです。

Sequencerは信頼できますか？

簡単な解決策は、プロトコルを「許可制」に設定することです。例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼されるオーダーラーが悪意のある行動を取らないことを保証することで、ロールアップの活性を確保します。

しかし、Polkadotの設計理念では、シーケンサーに対して信頼の仮定をすることはできません。なぜなら、システムの「信頼不要」および「許可不要」という特性を維持するためです。誰でもコレータープロトコルを使用して、ロールアップの状態変換リクエストを提出できるべきです。

Polkadot: 妥協しないソリューション

Polkadot が最終的に選択した解決策は、問題を完全に rollup の状態遷移関数（Runtime）に委ねることです。Runtime はすべてのコンセンサス情報の唯一の信頼できるソースであるため、出力においてどの Polkadot コア上で検証を実行すべきかを明示的に記載する必要があります。

この設計は、柔軟性と安全性の二重保障を実現しています。Polkadot は、可用性プロセスの中でロールアップの状態遷移を再実行し、ELVES 暗号経済プロトコルを通じてコアの配分の正確性を保証します。

ポルカドットのデータ可用性層（DA）にロールアップブロックを書き込む前に、約5名のバリデーターからなるグループがその合法性を確認します。彼らは、順序付けされた者が提出した候補レシートと有効性証明を受け取り、それにはロールアップブロックとそれに対応するストレージ証明が含まれています。これらの情報は、パラチェーンの検証関数によって処理され、中継チェーン上のバリデーターによって再実行されます。

検証結果には、どのコアでブロックを検証するかを指定するためのコアセレクターが含まれています。バリデーターは、このインデックスが自分が担当しているコアと一致するかを比較します。一致しない場合、そのブロックは破棄されます。

このメカニズムは、システムが常に信頼不要かつ許可不要の特性を維持し、オーダーラーなどの悪意のある行為者が検証位置を操作するのを防ぎ、複数のコアを使用してもロールアップが弾力性を保つことを保証します。

###セキュリティ

スケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップのセキュリティはリレーチェーンによって保証されており、正直なオーダラーが1人いれば存続が可能です。

ELVESプロトコルを活用することで、Polkadotはすべてのロールアップにそのセキュリティを完全に拡張し、コア上のすべての計算を検証します。コアの数に対する制限や仮定は一切必要ありません。

したがって、Polkadotのロールアップは、安全性を犠牲にすることなく真のスケーラビリティを実現できます。

###の汎用性

弾性拡張はロールアップのプログラマビリティを制限しません。Polkadotのロールアップモデルは、WebAssembly環境でチューリング完全な計算を実行することをサポートしており、単一の実行が2秒以内に完了する限り可能です。弾性拡張のおかげで、6秒ごとのサイクル内で実行可能な総計算量が増加しますが、計算の種類には影響を与えません。

###の複雑さ

より高いスループットと低いレイテンシは、必然的に複雑さをもたらし、これはシステム設計において唯一受け入れ可能なトレードオフの方法です。

RollupはAgile Coretimeインターフェースを通じてリソースを動的に調整し、一貫したセキュリティレベルを維持します。また、異なる使用シナリオに適応するために、一部のRFC103要件を実装する必要があります。

具体的複雑性は、rollupのリソース管理戦略に依存し、これらの戦略はオンチェーンまたはオフチェーンの変数に依存する可能性があります。例えば：

• シンプルな戦略：常に固定数のコアを使用するか、オフチェーンで手動調整する。

• 軽量戦略：ノードのmempoolで特定のトランザクション負荷を監視する；

• 自動化戦略：歴史データと XCM インターフェースを通じて、coretime サービスのリソースを事前に呼び出す。

自動化方式はより効率的ですが、実現とテストのコストも著しく上昇します。

###相互運用性

Polkadotは異なるロールアップ間の相互運用性をサポートしており、弾力的なスケーラビリティはメッセージングのスループットに影響を与えません。

クロスロールアップのメッセージ通信は、基盤となるトランスポート層によって実現されており、各ロールアップの通信ブロックスペースは固定されており、割り当てられたコアの数には関係ありません。

将来的には、Polkadotはオフチェーンメッセージングもサポートし、リレーチェーンが制御面として機能し、データ面ではないようになります。このアップグレードにより、ロールアップ間の通信能力が弾力的に拡張され、システムの縦の拡張能力がさらに強化されます。

他のプロトコルはどのようなトレードオフを行いましたか？

広く知られているように、性能向上はしばしば非中央集権性と安全性の犠牲を伴います。しかし、Nakamoto係数から見ると、一部のPolkadotの競合他社は非中央集権性の程度が低いにもかかわらず、その性能の表现はあまり良くありません。

あるパブリックチェーンA

あるパブリックチェーンAは、PolkadotやEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャでスケーラビリティを実現しています。歴史的証明、CPUの並列処理、リーダーベースのコンセンサスメカニズムに依存しており、理論上のTPSは65,000に達する可能性があります。

重要な設計は、その事前公開および検証可能なリーダーのスケジューリングメカニズムです：

• 各エポック（約2日または432,000スロット）の開始時に、ステーキング量に応じてスロットを割り当てます；

• ステーキングが多いほど、配分も多くなります。例えば、1%のバリデーターをステーキングすると、約1%のブロック生成の機会を得ることができます；

• すべてのブロック生成者が事前に公開されることで、ネットワークがターゲット型DDoS攻撃や頻繁なダウンのリスクにさらされることが増加しました。

歴史は、並列処理がハードウェアに非常に高い要求をすることを証明しており、これが検証ノードの集中化を引き起こしています。ステーキングが多いノードはブロックを生成する機会が増え、小さなノードはほとんどスロットを持たず、さらに集中化を加速させ、攻撃を受けた後のシステムのダウンリスクも高まります。

あるパブリックチェーンAはTPSを追求するために、非中央集権性と攻撃耐性を犠牲にし、その中本係数は20で、ポルカドットの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のサブネットはデフォルトのセキュリティ保証がなく、一部は完全に中央集権化される可能性もあります。セキュリティを向上させるためには、性能に妥協する必要があり、決定的なセキュリティの約束を提供することは難しいです。

イーサリアム

イーサリアムの拡張戦略は、基盤レイヤーで問題を直接解決するのではなく、ロールアップ層のスケーラビリティに賭けています。この方法は本質的に問題を解決するものではなく、問題をスタックの上のレイヤーに移すことになります。

オプティミスティックロールアップ

現在、大多数のOptimistic Rollupは中央集権的であり（中にはシーケンサーが1つしかないものもある）、セキュリティが不十分であり、孤立しており、遅延が大きい（詐欺証明期間を待つ必要があり、通常は数日かかる）などの問題があります。

ZKロールアップ

ZKロールアップの実装は、単一の取引で処理できるデータ量の制限を受けます。ゼロ知識証明を生成する計算要求は非常に高く、「勝者総取り」メカニズムはシステムの中央集権化を引き起こしやすいです。TPSを確保するために、ZKロールアップはしばしば各バッチの取引量を制限し、高需要時にはネットワークの混雑やガスの高騰を引き起こし、ユーザー体験に影響を与えます。

それに対して、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済セキュリティプロトコルの約2x10^6倍です。

さらに、ZKロールアップのデータ可用性の問題は、その欠点を悪化させます。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存しており、コストとユーザー料金をさらに引き上げます。

まとめ

スケーラビリティの限界は、妥協であってはならない。

他のパブリックブロックチェーンと比較して、Polkadotは中央集権による性能向上や事前信頼による効率向上の道を選んでいません。代わりに、弾力的なスケーラビリティ、許可不要のプロトコル設計、統一されたセキュリティレイヤー、柔軟なリソース管理メカニズムを通じて、安全性、非中央集権、高性能の多次元的なバランスを実現しています。

より大規模なアプリケーションの実現を追求する今日、Polkadotが掲げる「ゼロトラストの拡張性」は、Web3の長期的な発展を支える真のソリューションであるかもしれません。