スケーラビリティのトレードオフ:PolkadotとWeb3のオプション

ブロックチェーン技術が効率の向上を追求する中で、重要な問題が次第に浮かび上がってきています：拡張性を向上させる一方で、セキュリティとシステムの弾力性を犠牲にしない方法は何か？これは技術的な課題だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、信頼とセキュリティを犠牲にして構築されたより速いシステムは、本当に持続可能な革新を支えることが難しいことが多いです。

Web3のスケーラビリティの重要な推進者として、Polkadotは高スループットと低遅延を追求する過程で何らかの妥協をしているのでしょうか？そのrollupモデルは、分散化、安全性、またはネットワークの相互運用性において譲歩をしているのでしょうか？この記事では、Polkadotのスケーラビリティ設計における選択とトレードオフを深く分析し、他の主要なパブリックチェーンのソリューションと比較して、パフォーマンス、安全性、分散化の3つの間での異なる選択肢を探ります。

Polkadot拡張機能設計の課題

弾性と分散のバランス

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

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

垂直拡張のトレードオフ

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

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

Polkadotの目標は、システムの重要な特性に影響を与えることなく、ロールアップの柔軟性とリレーチェーン資源の効果的な利用を維持することです。

Sequencerは信頼できますか？

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

しかし、Polkadotの設計理念では、sequencerに対して信頼の仮定を置くことはできません。なぜなら、システムの「信頼不要」および「許可不要」という特性を維持する必要があるからです。誰でもcollatorプロトコルを使用してrollupの状態変換リクエストを提出できるべきです。

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

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

このデザインは、弾力性と安全性の二重の保障を実現しています。Polkadotは、可用性プロセスにおいてrollupの状態遷移を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を確保します。

Polkadotのデータ可用性層に任意のrollupブロックを書き込む前に、約5人のバリデーターで構成されるグループがその合法性を最初に検証します。彼らはソーティングノードから提出された候補レシートと有効性証明を受け取り、その中にはrollupブロックと対応するストレージ証明が含まれています。これらの情報はパラレルチェーンの検証関数に処理され、リレーチェーン上のバリデーターによって再実行されます。

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

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

###セキュリティ

拡張性を追求する過程で、Polkadotは安全性を妥協していません。rollupの安全性は中継チェーンによって保証され、正直なオーダーラーが1人いれば生存が維持されます。

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

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

###の汎用性

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

###の複雑さ

より高いスループットとより低いレイテンシは、システム設計において唯一受け入れ可能なトレードオフとして複雑さを不可避的に導入します。

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

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

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

*軽量戦略:ノードmempool内の特定のトランザクション負荷を監視します。

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

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

###相互運用性

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

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

将来的には、Polkadotはオフチェーンメッセージングをサポートし、中継チェーンがコントロールプレーンとして機能し、データプレーンとしてではなくなります。このアップグレードにより、ロールアップ間の通信能力が弾力的な拡張と共に向上し、システムの垂直スケーラビリティがさらに強化されます。

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

広く知られているように、性能の向上はしばしば非中央集権性と安全性の犠牲を伴います。しかし、ナカモト係数から見ると、いくつかのポルカドットの競合他社は非中央集権性が低いにもかかわらず、その性能は期待外れです。

ソラナ

SolanaはPolkadotやEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャを用いてスケーラビリティを実現し、歴史的証明（PoH）、CPUの並列処理、リーダーに基づく合意メカニズムに依存しており、理論上のTPSは65,000に達する。

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

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

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

• すべてのブロック作成者が事前に公開されているため、ネットワークが標的型DDoS攻撃や頻繁なダウンのリスクにさらされています。

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は中央集権化されており、セキュリティの不足、孤立、および高い遅延（詐欺証明期間を待つ必要があり、通常は数日かかる）などの問題があります。

ZKロールアップ

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

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

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

まとめ

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

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

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