# ブロックチェーンの拡張性のトレードオフ：PolkadotとWeb3の選択ブロックチェーンが効率向上を追求する中で、1つの重要な問題が次第に浮かび上がってきています：パフォーマンスを拡張する一方で、どのように安全性とシステムの弾力性を犠牲にしないようにするのか？これは技術的な挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、単により高速なシステムを追求し、信頼と安全性を無視することは、本当に持続可能なイノベーションを支えることが難しいです。Web3のスケーラビリティの重要な推進者として、Polkadotは高スループットと低遅延を追求する中で、何らかの妥協をしているのでしょうか？そのrollupモデルは分散化、安全性、またはネットワーク相互運用性において妥協しているのでしょうか？この記事では、これらの問題を中心に議論し、Polkadotの拡張性設計におけるトレードオフを深く分析し、他の主流のブロックチェーンのソリューションと比較して、性能、安全性、分散化の三者の違う選択肢について探ります。## Polkadot拡張機能設計の課題### 弾力性と非中央集権のバランスPolkadotのアーキテクチャはバリデーターネットワークとリレーチェーンに依存しており、これが何らかの点で中央集権的リスクを引き起こす可能性はありますか？単一障害点や制御が形成される可能性があり、それがその非中央集権的特性に影響を与えることはありますか？Rollupの実行は、リレーチェーンのソート者に依存しており、その通信はcollatorプロトコルメカニズムを使用しています。このプロトコルは完全に許可が不要で、信頼も不要であり、ネットワーク接続がある人なら誰でも使用でき、少数のリレーチェーンノードに接続し、rollupの状態変換リクエストを提出できます。これらのリクエストは、リレーチェーンのいずれかのコアによって検証され、満たさなければならない前提条件は1つだけです：有効な状態変換でなければなりません。さもなければ、そのrollupの状態は進行しません。### 垂直拡張のトレードオフRollupは、Polkadotのマルチコアアーキテクチャを活用することで垂直スケーリングを実現できます。この新しい能力は「弾性スケーリング」機能によって導入されました。設計プロセスで、rollupブロックの検証が特定のコアに固定されて実行されないため、これが弾性に影響を与える可能性があることが判明しました。中継チェーンにブロックを提出するプロトコルは、許可不要で信頼不要であるため、誰でもrollupに割り当てられた任意のcoreにブロックを提出して検証することができます。攻撃者はこれを悪用して、以前に検証された合法的なブロックを異なるcoreに繰り返し提出し、リソースを悪意で消費することで、rollupの全体的なスループットと効率を低下させる可能性があります。Polkadotの目標は、システムの重要な特性に影響を与えずに、ロールアップの弾力性とリレーシェーンのリソースの有効利用を維持することです。### Sequencerは信頼できますか？簡単な解決策は、プロトコルを「許可されたもの」と設定することです：例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼されたオーダーが悪意のある行動をとらないことを保証することで、ロールアップの活動を確保します。しかし、Polkadotの設計理念においては、私たちはsequencerに対して信頼の仮定を行うことはできません。なぜなら、システムの「信頼不要」と「許可不要」の特性を維持する必要があるからです。誰でもcollatorプロトコルを使用してrollupの状態変化リクエストを提出できるべきです。## Polkadot: 妥協しないソリューションPolkadotが最終的に選択したソリューションは：問題を完全にrollupの状態変換関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できるソースであるため、出力においてどのPolkadotコアで検証を実行するべきかを明確に声明する必要があります。このデザインは、弾力性と安全性の二重保障を実現しています。Polkadotは、可用性プロセスの中でrollupの状態遷移を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を保証します。Polkadotのデータ可用性層に書き込まれる前に、約5人のバリデーターで構成されるグループがその合法性を先に検証します。彼らは、オーダラーが提出した候補レシートと有効性証明を受け取り、その中にはrollupブロックとそれに対応するストレージ証明が含まれています。これらの情報は、パラチェーンの検証関数によって処理され、中継チェーン上のバリデーターによって再実行されます。検証結果には、ブロックをどのコアで検証するかを指定するためのcore selectorが含まれています。検証者は、そのインデックスが自分が担当するコアと一致するかどうかを比較します。一致しない場合、そのブロックは破棄されます。このメカニズムは、システムが常に信頼不要かつ許可不要の特性を維持し、オーダラーなどの悪意のある行為者が検証位置を操作するのを防ぎ、rollupが複数のコアを使用しても弾力性を維持できることを保証します。###セキュリティスケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップの安全性はリレーチェーンによって保証されており、誠実なオーダラーが一人いれば存続が可能です。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やEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャによってスケーラビリティを実現し、履歴証明（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のバリデーターはランダムに割り当てられ、遅れて公開されるため、攻撃者はバリデーターの身元を事前に知ることができず、攻撃はすべてのコントロールを賭ける必要があります。1人の誠実なバリデーターが異議を唱えれば、攻撃は失敗し、攻撃者は質権を失うことになります。### アバランチAvalancheはメインネット + サブネットアーキテクチャを使用して拡張を行い、メインネットはX-Chain（送金、~4,500 TPS）、C-Chain（スマートコントラクト、~100-200 TPS）、P-Chain（バリデーターとサブネットの管理）で構成されています。各サブネット理論TPSは約5,000に達することができ、Polkadotの考え方に似ています：単一のシャードの負荷を減らして拡張を実現します。しかし、Avalancheはバリデーターがサブネットへの参加を自由に選択できるようにし、サブネットは地理的要件やKYCなどの追加要件を設定できますが、分散化と安全性を犠牲にしています。Polkadotでは、すべてのrollupが統一されたセキュリティ保障を共有しています。一方、Avalancheのサブネットはデフォルトのセキュリティ保証がなく、一部は完全に中央集権化される可能性があります。セキュリティを向上させたい場合、パフォーマンスで妥協する必要があり、決定的なセキュリティの約束を提供することは困難です。### イーサリアムイーサリアムの拡張戦略は、基礎層で直接問題を解決するのではなく、ロールアップ層の拡張性に賭けています。この方法は本質的に問題を解決しているわけではなく、問題をスタックの上層に渡しているだけです。#### オプティミスティックロールアップ現在、ほとんどのOptimistic rollupは中央集権的であり（中にはシーケンサーが1つだけのものもあります）、セキュリティ不足、孤立、遅延（詐欺証明期間を待つ必要があり、通常は数日かかります）などの問題が存在します。#### ZKロールアップZKロールアップの実装は、単一の取引で処理できるデータ量の制限を受けています。ゼロ知識証明を生成するための計算要求は非常に高く、「勝者総取り」メカニズムはシステムの中央集権化を引き起こす可能性があります。TPSを保証するために、ZKロールアップは通常、各バッチの取引量を制限し、高需要時にはネットワークの混雑やガス代の上昇を引き起こし、ユーザー体験に影響を与えることがあります。対照的に、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済安全プロトコルの約2x10^6倍です。さらに、ZKロールアップのデータ可用性の問題は、その欠点を悪化させる可能性があります。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存し、コストとユーザー料金をさらに引き上げます。## まとめ拡張性の限界は、妥協であるべきではない。他のパブリックチェーンと比較して、Polkadotは中央集権による性能向上や事前信頼による効率化の道を選択しておらず、弾力的な拡張、許可不要のプロトコル設計、統一されたセキュリティレイヤー、柔軟なリソース管理メカニズムを通じて、安全性、分散化、高性能の多次元的なバランスを実現しています。より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラスト拡張性」が、Web3の長期的な発展を支える真のソリューションかもしれません。
Polkadotの妥協のないスケーラビリティ：Web3エコシステムの新しい選択肢
ブロックチェーンの拡張性のトレードオフ：PolkadotとWeb3の選択
ブロックチェーンが効率向上を追求する中で、1つの重要な問題が次第に浮かび上がってきています：パフォーマンスを拡張する一方で、どのように安全性とシステムの弾力性を犠牲にしないようにするのか？
これは技術的な挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。Web3エコシステムにとって、単により高速なシステムを追求し、信頼と安全性を無視することは、本当に持続可能なイノベーションを支えることが難しいです。
Web3のスケーラビリティの重要な推進者として、Polkadotは高スループットと低遅延を追求する中で、何らかの妥協をしているのでしょうか？そのrollupモデルは分散化、安全性、またはネットワーク相互運用性において妥協しているのでしょうか？
この記事では、これらの問題を中心に議論し、Polkadotの拡張性設計におけるトレードオフを深く分析し、他の主流のブロックチェーンのソリューションと比較して、性能、安全性、分散化の三者の違う選択肢について探ります。
Polkadot拡張機能設計の課題
弾力性と非中央集権のバランス
Polkadotのアーキテクチャはバリデーターネットワークとリレーチェーンに依存しており、これが何らかの点で中央集権的リスクを引き起こす可能性はありますか？単一障害点や制御が形成される可能性があり、それがその非中央集権的特性に影響を与えることはありますか？
Rollupの実行は、リレーチェーンのソート者に依存しており、その通信はcollatorプロトコルメカニズムを使用しています。このプロトコルは完全に許可が不要で、信頼も不要であり、ネットワーク接続がある人なら誰でも使用でき、少数のリレーチェーンノードに接続し、rollupの状態変換リクエストを提出できます。これらのリクエストは、リレーチェーンのいずれかのコアによって検証され、満たさなければならない前提条件は1つだけです：有効な状態変換でなければなりません。さもなければ、そのrollupの状態は進行しません。
垂直拡張のトレードオフ
Rollupは、Polkadotのマルチコアアーキテクチャを活用することで垂直スケーリングを実現できます。この新しい能力は「弾性スケーリング」機能によって導入されました。設計プロセスで、rollupブロックの検証が特定のコアに固定されて実行されないため、これが弾性に影響を与える可能性があることが判明しました。
中継チェーンにブロックを提出するプロトコルは、許可不要で信頼不要であるため、誰でもrollupに割り当てられた任意のcoreにブロックを提出して検証することができます。攻撃者はこれを悪用して、以前に検証された合法的なブロックを異なるcoreに繰り返し提出し、リソースを悪意で消費することで、rollupの全体的なスループットと効率を低下させる可能性があります。
Polkadotの目標は、システムの重要な特性に影響を与えずに、ロールアップの弾力性とリレーシェーンのリソースの有効利用を維持することです。
Sequencerは信頼できますか？
簡単な解決策は、プロトコルを「許可されたもの」と設定することです：例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼されたオーダーが悪意のある行動をとらないことを保証することで、ロールアップの活動を確保します。
しかし、Polkadotの設計理念においては、私たちはsequencerに対して信頼の仮定を行うことはできません。なぜなら、システムの「信頼不要」と「許可不要」の特性を維持する必要があるからです。誰でもcollatorプロトコルを使用してrollupの状態変化リクエストを提出できるべきです。
Polkadot: 妥協しないソリューション
Polkadotが最終的に選択したソリューションは：問題を完全にrollupの状態変換関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できるソースであるため、出力においてどのPolkadotコアで検証を実行するべきかを明確に声明する必要があります。
このデザインは、弾力性と安全性の二重保障を実現しています。Polkadotは、可用性プロセスの中でrollupの状態遷移を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を保証します。
Polkadotのデータ可用性層に書き込まれる前に、約5人のバリデーターで構成されるグループがその合法性を先に検証します。彼らは、オーダラーが提出した候補レシートと有効性証明を受け取り、その中にはrollupブロックとそれに対応するストレージ証明が含まれています。これらの情報は、パラチェーンの検証関数によって処理され、中継チェーン上のバリデーターによって再実行されます。
検証結果には、ブロックをどのコアで検証するかを指定するためのcore selectorが含まれています。検証者は、そのインデックスが自分が担当するコアと一致するかどうかを比較します。一致しない場合、そのブロックは破棄されます。
このメカニズムは、システムが常に信頼不要かつ許可不要の特性を維持し、オーダラーなどの悪意のある行為者が検証位置を操作するのを防ぎ、rollupが複数のコアを使用しても弾力性を維持できることを保証します。
###セキュリティ
スケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップの安全性はリレーチェーンによって保証されており、誠実なオーダラーが一人いれば存続が可能です。
ELVESプロトコルを利用することで、Polkadotはそのセキュリティをすべてのrollupに完全に拡張し、コア上のすべての計算を検証でき、使用するコアの数に制限や仮定を設ける必要がありません。
したがって、Polkadotのロールアップは、安全性を犠牲にすることなく真のスケーラビリティを実現できます。
###の汎用性
弾性拡張はrollupのプログラマビリティを制限しません。Polkadotのrollupモデルは、WebAssembly環境でチューリング完全な計算を実行することをサポートしており、一度の実行が2秒以内に完了する限り問題ありません。弾性拡張により、6秒ごとのサイクル内で実行可能な総計算量が増加しますが、計算の種類には影響を与えません。
###の複雑さ
より高いスループットとより低い遅延は、必然的に複雑さをもたらし、これはシステム設計における唯一受け入れ可能なトレードオフの方法です。
RollupはAgile Coretimeインターフェイスを通じてリソースを動的に調整し、一貫した安全レベルを維持できます。また、さまざまな使用シナリオに適応するために、部分的にRFC103の要件を実装する必要があります。
具体的複雑性は、rollupのリソース管理戦略に依存し、これらの戦略はオンチェーンまたはオフチェーンの変数に依存する可能性があります。例えば：
自動化の方法はより効率的ですが、実現とテストのコストも著しく上昇します。
###相互運用性
Polkadotは異なるrollup間の相互運用性をサポートしており、弾力的なスケーラビリティはメッセージ送信のスループットに影響を与えません。
クロスロールアップのメッセージ通信は、基盤となるトランスポート層によって実現され、各ロールアップの通信ブロックスペースは固定されており、割り当てられたコアの数には依存しません。
未来、Polkadotはオフチェーンメッセージングをサポートし、リレーチェーンがコントロールプレーンとして機能し、データプレーンではありません。このアップグレードにより、ロールアップ間の通信能力が弾力的に拡張され、システムの垂直スケーラビリティがさらに強化されます。
他のプロトコルのトレードオフ
誰もが知っているように、パフォーマンスの向上はしばしば分散化と安全性の犠牲を伴います。しかし、ナカモト係数から見ると、いくつかのPolkadotの競合他社は分散化の程度が低いにもかかわらず、そのパフォーマンスは満足のいくものではありません。
ソラナ
SolanaはPolkadotやEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャによってスケーラビリティを実現し、履歴証明（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では、すべてのrollupが統一されたセキュリティ保障を共有しています。一方、Avalancheのサブネットはデフォルトのセキュリティ保証がなく、一部は完全に中央集権化される可能性があります。セキュリティを向上させたい場合、パフォーマンスで妥協する必要があり、決定的なセキュリティの約束を提供することは困難です。
イーサリアム
イーサリアムの拡張戦略は、基礎層で直接問題を解決するのではなく、ロールアップ層の拡張性に賭けています。この方法は本質的に問題を解決しているわけではなく、問題をスタックの上層に渡しているだけです。
オプティミスティックロールアップ
現在、ほとんどのOptimistic rollupは中央集権的であり（中にはシーケンサーが1つだけのものもあります）、セキュリティ不足、孤立、遅延（詐欺証明期間を待つ必要があり、通常は数日かかります）などの問題が存在します。
ZKロールアップ
ZKロールアップの実装は、単一の取引で処理できるデータ量の制限を受けています。ゼロ知識証明を生成するための計算要求は非常に高く、「勝者総取り」メカニズムはシステムの中央集権化を引き起こす可能性があります。TPSを保証するために、ZKロールアップは通常、各バッチの取引量を制限し、高需要時にはネットワークの混雑やガス代の上昇を引き起こし、ユーザー体験に影響を与えることがあります。
対照的に、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済安全プロトコルの約2x10^6倍です。
さらに、ZKロールアップのデータ可用性の問題は、その欠点を悪化させる可能性があります。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存し、コストとユーザー料金をさらに引き上げます。
まとめ
拡張性の限界は、妥協であるべきではない。
他のパブリックチェーンと比較して、Polkadotは中央集権による性能向上や事前信頼による効率化の道を選択しておらず、弾力的な拡張、許可不要のプロトコル設計、統一されたセキュリティレイヤー、柔軟なリソース管理メカニズムを通じて、安全性、分散化、高性能の多次元的なバランスを実現しています。
より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラスト拡張性」が、Web3の長期的な発展を支える真のソリューションかもしれません。