スケーラビリティのトレードオフ: PolkadotとWeb3の選択

ブロックチェーンがより高い効率を追求する中で、1つの重要な問題が徐々に明らかになってきました。それは、パフォーマンスを拡張しつつ、セキュリティとシステムの弾力性をどのように確保するかということです。これは技術的な挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、信頼とセキュリティを犠牲にして構築されたより速いシステムは、真に持続可能なイノベーションを支えることが難しいことが多いです。

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

Polkadot拡張機能設計の課題

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

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

Rollupの運用は、中継チェーンのオーダラーに依存しており、その通信にはcollatorプロトコルと呼ばれるメカニズムが使用されます。このプロトコルは完全にパーミッションレスで、信頼を必要とせず、ネットワーク接続がある人は誰でも使用でき、少数の中継チェーンノードに接続し、rollupの状態遷移リクエストを提出できます。これらのリクエストは、中継チェーンのいずれかのコアによって検証されますが、満たすべき前提は1つだけです：有効な状態遷移でなければならず、そうでなければそのrollupの状態は進行しません。

垂直拡張のトレードオフ

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

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

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

Sequencerは信頼できますか?

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

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

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

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

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

Polkadotのデータ可用性レイヤー(DA)にロールアップブロックが書き込まれる前に、約5人のバリデーターからなるグループがその合法性を検証します。彼らは、ロールアップブロックとそれに関連するストレージ証明を含む候補レシートと有効性証明をオーダーラーから受け取ります。これらの情報は、パラチェーン検証関数によって処理され、リレーチェーン上のバリデーターによって再実行されます。

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

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

セキュリティ

スケーラビリティを追求する過程で、Polkadotは安全性を妥協していません。ロールアップの安全性はリレーチェーンによって保証され、正直なオーダーラーが1人いれば生存が維持されます。

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

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

###の汎用性

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

###の複雑さ

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

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

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

• シンプルな戦略: 常に固定数の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は中央集権化されており、安全性の不足、互いに孤立していること、高い遅延(詐欺証明期間を待たなければならず、通常は数日)などの問題があります。

ZKロールアップ

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

比較すると、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済セキュリティプロトコルの約2×10^6倍です。

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

まとめ

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

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

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