ブロックチェーンの拡張性のトレードオフと課題：Polkadotのソリューション

ブロックチェーン技術がより高い効率を追求している今日、1つの重要な問題が徐々に明らかになってきています：性能を向上させる一方で、安全性とシステムの弾力性を犠牲にしない方法は？これは技術的な側面の挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、より速いシステムが信頼と安全性を犠牲にして築かれる場合、真に持続可能なイノベーションを支えることは難しいのです。

PolkadotはWeb3のスケーラビリティにおいて重要な推進者として、そのrollupモデルが分散化、安全性、またはネットワーク相互運用性において妥協をしているのか？この記事では、Polkadotのスケーラビリティ設計における選択とトレードオフを深く分析し、他の主流のパブリックチェーンのソリューションと比較し、性能、安全、分散化の3つの要素間での異なる道の選択について探ります。

Polkadot拡張機能設計の課題

弾力性と分散化のバランス

Polkadotのアーキテクチャは、バリデーターネットワークとリレーチェーン（Relay Chain）に依存しており、これがいくつかの点で中央集権的リスクを引き入れる可能性があります。Rollupの運用は、リレーチェーンに接続されたシーケンサー（sequencer）に依存しており、その通信はコレーター（collator）プロトコルメカニズムを使用します。このプロトコルは完全に許可不要で、信頼不要であり、ネットワーク接続がある人なら誰でも使用でき、少数のリレーチェーンノードに接続し、rollupの状態変換リクエストを提出することができます。

垂直拡張のトレードオフ

Rollupは、Polkadotのマルチコアアーキテクチャを利用して垂直スケーリングを実現できます。この新しい機能は「弾性拡張」（Elastic Scaling）機能によって導入されました。しかし、rollupのブロック検証が特定のコアで固定されていないため、これがその弾性に影響を与える可能性があります。攻撃者はこれを悪用して、以前に検証された正当なブロックを異なるコアに繰り返し提出し、悪意を持ってリソースを消費させることで、rollupの全体的なスループットと効率を低下させる可能性があります。

Sequencer の信頼の問題

単純な解決策の一つは、プロトコルを「許可制」に設定し、ホワイトリストメカニズムを採用するか、デフォルトで信頼できるシーケンサーが悪意のある行動をとらないと仮定することです。しかし、Polkadotの設計理念では、シーケンサーに対して信頼の仮定を行うことはできません。なぜなら、システムの「信頼不要」と「許可不要」の特性を維持する必要があるからです。

Polkadotのソリューション

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

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

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

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

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

###セキュリティ

スケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。rollupのセキュリティはリレーチェーンによって保証され、正直なオーダラーが1人いれば生存性を維持できます。ELVESプロトコルを利用することで、Polkadotはそのセキュリティをすべてのrollupに完全に拡張し、コア上のすべての計算を検証します。コアの使用数についての制限や仮定を行う必要はありません。

###の汎用性

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

###の複雑さ

より高いスループットとより低いレイテンシは、システム設計において唯一受け入れ可能なトレードオフとして不可避的に複雑さを導入します。RollupはAgile Coretimeインターフェースを通じてリソースを動的に調整し、一貫したセキュリティレベルを維持します。また、異なる使用シーンに適応するために、部分的にRFC103の要件を実装する必要があります。

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

• シンプルな戦略：常に固定数のcoreを使用するか、オフチェーンで手動で調整する；
• 軽量戦略：ノードのmempoolで特定のトランザクション負荷を監視する；
• 自動化戦略：歴史データとXCMインターフェースを通じて、coretimeサービスのリソースを事前に呼び出して設定します。

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

###相互運用性

Polkadotは異なるrollup間の相互運用性をサポートしており、弾力的なスケーラビリティはメッセージ伝達のスループットに影響を与えません。クロスrollupのメッセージ通信は基盤となるトランスポート層によって実現されており、各rollupの通信ブロックスペースは固定されており、割り当てられたコア数には依存しません。

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

他のプロトコルのトレードオフ

広く知られているように、パフォーマンスの向上はしばしば分散化と安全性の犠牲を伴います。しかし、ナカモト係数の観点から見ると、いくつかのPolkadotの競合他社は分散化の程度が低いにもかかわらず、そのパフォーマンスの結果はあまり満足のいくものではありません。

ソラナ

Solanaは単層の高スループットアーキテクチャを採用してスケーラビリティを実現しており、歴史的証明（PoH）、CPUの並列処理およびリーダーに基づく合意メカニズムに依存しており、理論的なTPSは65,000に達します。その重要な設計は、事前に公開され、検証可能なリーダースケジューリングメカニズムです。

しかし、PoHと並行処理はハードウェアに非常に高い要求をし、検証ノードの集中化を引き起こします。ステークが多いノードはブロック生成の機会が大きく、小さなノードはほとんどスロットがなく、さらに集中化を進め、攻撃を受けた際のシステムダウンのリスクも高まります。SolanaはTPSを追求するために、非中央集権性と攻撃耐性を犠牲にしており、そのナカモト係数はわずか20で、Polkadotの172を大きく下回っています。

###トン

TONはTPSが104,715に達すると主張していますが、この数字はプライベートテストネット、256のノード、理想的なネットワークとハードウェア条件下で実現されたものです。一方、Polkadotは分散型パブリックネットワークで128K TPSに達しています。

TONのコンセンサス機構にはセキュリティ上の懸念があります：シャーディング検証ノードの身元が事前に暴露される可能性があります。TONホワイトペーパーでも明確に指摘されているように、これにより帯域幅を最適化できる一方で、悪用される可能性もあります。"ギャンブラー破産"メカニズムが欠如しているため、攻撃者は特定のシャードを完全に制御するのを待つか、DDoS攻撃を通じて誠実な検証者を妨害し、状態を改ざんすることができます。

対照的に、Polkadotのバリデーターはランダムに割り当てられ、遅延開示されます。攻撃者は事前にバリデーターの身元を知ることができず、攻撃には成功するために全てを賭ける必要があります。誠実なバリデーターが1人でも異議を唱えれば、攻撃は失敗し、攻撃者はステーキングを失うことになります。

アバランチ

Avalancheはメインネット+サブネットのアーキテクチャを使用してスケーリングを行い、メインネットはX-Chain（送金、~4,500 TPS）、C-Chain（スマートコントラクト、~100-200 TPS）、P-Chain（バリデーターとサブネットの管理）で構成されています。各サブネットの理論TPSは~5,000に達する可能性があり、Polkadotの考え方に似ています：単一のシャードの負荷を軽減してスケーリングを実現します。

しかし、Avalancheはバリデーターが自由にサブネットへの参加を選択できるようにしており、サブネットは地理的要件やKYCなどの追加要件を設定できるため、分散化と安全性が犠牲にされています。一方、Polkadotでは、すべてのロールアップが統一されたセキュリティ保障を共有しています。しかし、Avalancheのサブネットにはデフォルトのセキュリティ保証がなく、一部は完全に中央集権化される可能性があります。安全性を高めるには、依然としてパフォーマンスの妥協が必要であり、確定的な安全性の約束を提供することは困難です。

イーサリアム

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

オプティミスティックロールアップは現在、大多数が中央集権化されており、安全性が不足している、互いに孤立している、高遅延（詐欺証明期間を待つ必要があり、通常は数日）などの問題があります。

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

対照的に、チューリング完全ZKロールアップのコストは、Polkadotのコア暗号経済安全プロトコルの約2x10^6倍です。また、ZKロールアップのデータ可用性の問題もその欠点を悪化させます。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存し、コストとユーザー料金をさらに押し上げることになります。

まとめ

スケーラビリティの限界は妥協であるべきではありません。他のパブリックチェーンと比較して、Polkadotは中央集権で性能を交換し、事前に信頼を置いて効率を交換する道を選んでいません。むしろ、柔軟なスケーリング、許可不要のプロトコル設計、統一されたセキュリティレイヤー、および柔軟なリソース管理メカニズムを通じて、安全性、分散化、高性能の多次元的バランスを実現しています。

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