スケーラビリティ、セキュリティ、分散化のバランス:Polkadotのテクノロジー選択

ブロックチェーンがより高い効率を追求している今日、重要な問題が次第に明らかになっています：スケーラビリティを向上させると同時に、安全性とシステムの弾力性を犠牲にしなければならないのでしょうか？

これは技術的な面での挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、より迅速なシステムが信頼性と安全性を犠牲にして構築される場合、真の持続可能な革新を支えることは難しいことが多いです。

PolkadotはWeb3のスケーラビリティの重要な推進者として、高スループットと低遅延の目標の下で何らかの犠牲を払っているのでしょうか？そのロールアップモデルは分散化、安全性、またはネットワーク相互運用性の面で妥協をしているのでしょうか？

この記事では、これらの問題について掘り下げ、Polkadotのスケーラビリティ設計におけるトレードオフとバランスを深く分析し、他の主流のパブリックチェーンのソリューションと比較し、性能、安全性、分散化の3つの間での異なる道の選択について考察します。

Polkadot拡張機能設計の課題

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

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

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

垂直拡張のトレードオフ

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

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

Polkadotの目標は、システムの重要な特性に影響を与えずに、rollupの柔軟性とリレーチェーンのリソースの効率的な利用を維持することです。

Sequencerは信頼できますか？

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

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

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

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

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

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

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

このメカニズムは、システムが常に信頼不要かつ許可不要の属性を維持することを保証し、ソート役などの悪意のある行為者が検証位置を操作するのを防ぎ、rollupが複数のcoreを使用しても弾力性を維持できるようにします。

###セキュリティ

拡張性を追求する過程で、Polkadotは安全性を妥協していません。rollupの安全性はリレーチェーンによって保証され、誠実なオーダラーが1ついれば存続できます。

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

したがって、Polkadotのロールアップは、安全性を犠牲にすることなく真の拡張を実現できます。

###の汎用性

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

###の複雑さ

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

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

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

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

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

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

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

###相互運用性

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

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

将来的に、Polkadotはリレーチェーンをデータ面ではなくコントロール面として使用したオフチェーンメッセージングをサポートする予定です。このアップグレードにより、ロールアップ間の通信能力が柔軟に拡張され、システムの縦のスケーラビリティがさらに強化されます。

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

誰もが知っているように、性能の向上はしばしば分散化と安全性を犠牲にすることを伴います。しかし、ナカモト係数から見ると、いくつかのPolkadotの競合相手は分散化の程度が低いにもかかわらず、その性能の結果はあまり良くありません。

ソラナ

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

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

• 各エポック（約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は中心化されており（中にはシーケンサーが1つだけのものもある）、セキュリティの不足、孤立、遅延が高い（詐欺証明期間を待つ必要があり、通常は数日）などの問題があります。

ZKロールアップ

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

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

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

まとめ

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

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

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