ブロックチェーンの拡張性のトレードオフ:PolkadotとWeb3のバランスの道

ブロックチェーンがより高い効率を追求する今日、1つの重要な問題が徐々に浮かび上がってきています:拡張性能を追求する中で、安全性とシステムの弾力性を犠牲にする必要があるのか？これは単なる技術的な課題にとどまらず、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、より速いシステムが信頼と安全性を犠牲にして構築される場合、真の持続可能なイノベーションを支えることは難しいことが多いです。

PolkadotはWeb3のスケーラビリティの重要な推進者として、そのロールアップモデルが非中央集権、安全性、またはネットワークの相互運用性において妥協を強いられているのか？この記事では、Polkadotのスケーラビリティ設計における選択肢とトレードオフを深く掘り下げ、他の主流のパブリックチェーンのソリューションと比較し、パフォーマンス、安全性、非中央集権の三者間の異なる道の選択について探ります。

Polkadot拡張機能設計の課題

弾性と分散化のバランス

Polkadotのアーキテクチャは、バリデータネットワークおよび中継チェーン(Relay Chain)に依存していますが、これは何らかの面で中央集権的なリスクをもたらす可能性がありますか？単一障害点やコントロールの形成が可能であり、それがその非中央集権特性に影響を与える可能性はありますか？

Rollupの運用は、中継チェーンのソート担当者(sequencer)に依存しています。その通信は、collatorプロトコルと呼ばれるメカニズムを使用します。このプロトコルは完全に無許可で、信頼を必要とせず、ネットワーク接続を持つ誰でも使用でき、少数の中継チェーンノードに接続してrollupの状態遷移リクエストを提出できます。これらのリクエストは、中継チェーンのいずれかのcoreによって検証され、1つの前提条件を満たす必要があります:有効な状態遷移でなければならず、そうでない場合はそのrollupの状態は進行しません。

垂直拡張のトレードオフ

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

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

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

Sequencerは信頼できますか？

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

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

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

Polkadotが最終的に選択した方案は: 問題を完全にrollupの状態変換関数(Runtime)に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できるソースであるため、出力においてどのPolkadot coreで検証を実行するべきかを明示的に示さなければなりません。

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

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

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

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

###セキュリティ

スケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップのセキュリティはリレーチェーンによって保証されており、1つの誠実なオーダラーが生存性を維持するだけで済みます。

ELVESプロトコルを利用することで、Polkadotはすべてのrollupにその安全性を完全に拡張し、コア上のすべての計算を検証し、使用するコアの数に対して制限や仮定を行う必要がありません。

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

###の汎用性

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

###の複雑さ

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

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

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

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

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

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

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

###相互運用性

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

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

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

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

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

) ソラナ

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

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

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

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

• すべての出ブロック者が事前に公表されているため、ネットワークがターゲットDDoS攻撃を受けたり、頻繁にダウンするリスクが増加しています。

PoHと並列処理はハードウェアに非常に高い要求をし、検証ノードの集中化を招いています。質権を多く持つノードはブロック生成の機会が増え、小さなノードはほとんどスロットがなく、さらなる集中化を助長し、攻撃を受けた後のシステムの麻痺リスクを高めています。

SolanaはTPSを追求するために、非中央集権性と攻撃耐性を犠牲にしており、そのナカモト係数は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の長期的な発展を支える真の解決策かもしれません。