# ブロックチェーンの拡張性のトレードオフ：PolkadotとWeb3エコシステムの探求ブロックチェーンがより高い効率を追求する今日、1つの重要な問題が徐々に明らかになっています：拡張性を高めつつ、どのようにして安全性とシステムの弾力性を犠牲にせずに済むか？これは技術的な挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。特にWeb3エコシステムにとって、より速いシステムが信頼と安全性を犠牲にして構築される場合、真の持続可能なイノベーションを支えることは難しいことが多いです。Web3のスケーラビリティにおける重要な推進者として、Polkadotは高スループットと低遅延を目指す中で、何らかの犠牲を払ったのでしょうか？そのロールアップモデルは、非中央集権性、安全性、またはネットワークの相互運用性において妥協があったのでしょうか？この記事では、これらの問題を中心に、Polkadotのスケーラビリティ設計における妥協とバランスについて深く掘り下げ、他の主要なパブリックチェーンのソリューションと比較し、パフォーマンス、安全性、分散化の3つの間の異なる道の選択について探討します。## Polkadot拡張機能設計の課題### 弾性と分散化のバランスPolkadotのアーキテクチャは、バリデーターネットワークと中継チェーン（Relay Chain）に依存していますが、これが何らかの面で中央集権的なリスクを引き起こす可能性がありますか？単一障害点や制御が形成される可能性があり、それがその分散型特性に影響を与えることはありますか？Rollupの運用は、中継チェーンのソーサ（sequencer）に依存しており、その通信にはcollatorプロトコルと呼ばれるメカニズムが使用されます。このプロトコルは完全に許可不要で、信頼不要であり、ネットワーク接続がある人なら誰でも利用でき、少数の中継チェーンノードに接続し、rollupの状態遷移要求を提出できます。これらの要求は、中継チェーンのコアによって検証され、前提条件を満たす必要があります：それは有効な状態遷移でなければならず、そうでなければそのrollupの状態は進行しません。### 垂直拡張のトレードオフRollupは、Polkadotのマルチコアアーキテクチャを利用して垂直スケーリングを実現できます。この新しい機能は「弾性拡張」（Elastic Scaling）機能によって導入されました。設計プロセスの中で、rollupブロックの検証が特定のコアに固定されていないため、柔軟性に影響を与える可能性があることがわかりました。中継チェーンにブロックを提出するプロトコルは許可不要で信頼不要であるため、誰でもrollupに割り当てられた任意のcoreにブロックを提出して検証を行うことができます。攻撃者はこれを利用して、以前に検証された合法的なブロックを異なるcoreに繰り返し提出し、悪意を持ってリソースを消費し、rollupの全体的なスループットと効率を低下させる可能性があります。Polkadotの目標は、システムの重要な特性に影響を与えずに、ロールアップの柔軟性とリレーチェーンリソースの有効利用を維持することです。### Sequencerは信頼できますか？簡単な解決策は、プロトコルを「許可された」に設定することです：例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼できるオーダーラーが悪意のある行動をしないことを前提とし、rollupの活性を保証します。しかし、Polkadotの設計理念の中では、シーケンサーに対して信頼の仮定を行うことはできません。なぜなら、システムの「信頼不要」と「許可不要」という特性を維持するためです。誰でもコレーター プロトコルを使用してロールアップの状態遷移リクエストを提出できるべきです。## Polkadot:妥協のないソリューションPolkadotが最終的に選択した方案は：問題を完全にrollupの状態遷移関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できる情報源であるため、出力においてどのPolkadotコアで検証を実行すべきかを明示的に宣言する必要があります。このデザインは、弾力性と安全性の二重の保証を実現しています。Polkadotは、可用性プロセスの中でrollupの状態遷移を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を確保します。ポルカドットのデータ可用性層（DA）にrollupブロックが書き込まれる前に、約5人のバリデーターで構成されたグループがその合法性を検証します。彼らは、ソートチェイナーが提出した候補レシート（candidate receipt）と有効性証明（PoV）を受け取り、そこにはrollupブロックと対応するストレージ証明が含まれています。これらの情報はパラチェーンの検証関数によって処理され、中継チェーン上のバリデーターによって再実行されます。検証結果には、どのコアでブロックを検証するかを指定するためのコアセレクターが含まれています。バリデーターは、そのインデックスが自分が担当しているコアと一致するかどうかを比較します。一致しない場合、そのブロックは破棄されます。このメカニズムは、システムが常に信頼不要で許可不要の特性を維持し、ソーターなどの悪意のある行為者による検証位置の操作を回避し、rollupが複数のcoreを使用しても弾力性を保持できることを保証します。### セキュリティスケーラビリティを追求する過程で、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や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のコア暗号経済セキュリティプロトコルの約2x10^6倍です。さらに、ZKロールアップのデータ可用性の問題は、その欠点を悪化させる可能性があります。誰もが取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存しており、コストとユーザー料金をさらに押し上げることになります。## まとめスケーラビリティの限界は、妥協であるべきではない。他のパブリックチェーンと比較して、Polkadotは中央集権を性能と交換したり、事前に信頼を効率と交換したりする道を歩んでいません。代わりに、弾力的なスケーラビリティ、許可なしのプロトコル設計、統一されたセキュリティ層、および柔軟なリソース管理メカニズムを通じて、セキュリティ、分散化、高性能の多次元的なバランスを実現しました。より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラストスケーラビリティ」が、Web3の長期的な発展を支える真の解決策かもしれません。
Polkadotの弾力的なスケーリング: 妥協のないWeb3の高性能への道
ブロックチェーンの拡張性のトレードオフ：PolkadotとWeb3エコシステムの探求
ブロックチェーンがより高い効率を追求する今日、1つの重要な問題が徐々に明らかになっています：拡張性を高めつつ、どのようにして安全性とシステムの弾力性を犠牲にせずに済むか？
これは技術的な挑戦だけでなく、アーキテクチャ設計の深い選択でもあります。特にWeb3エコシステムにとって、より速いシステムが信頼と安全性を犠牲にして構築される場合、真の持続可能なイノベーションを支えることは難しいことが多いです。
Web3のスケーラビリティにおける重要な推進者として、Polkadotは高スループットと低遅延を目指す中で、何らかの犠牲を払ったのでしょうか？そのロールアップモデルは、非中央集権性、安全性、またはネットワークの相互運用性において妥協があったのでしょうか？
この記事では、これらの問題を中心に、Polkadotのスケーラビリティ設計における妥協とバランスについて深く掘り下げ、他の主要なパブリックチェーンのソリューションと比較し、パフォーマンス、安全性、分散化の3つの間の異なる道の選択について探討します。
Polkadot拡張機能設計の課題
弾性と分散化のバランス
Polkadotのアーキテクチャは、バリデーターネットワークと中継チェーン（Relay Chain）に依存していますが、これが何らかの面で中央集権的なリスクを引き起こす可能性がありますか？単一障害点や制御が形成される可能性があり、それがその分散型特性に影響を与えることはありますか？
Rollupの運用は、中継チェーンのソーサ（sequencer）に依存しており、その通信にはcollatorプロトコルと呼ばれるメカニズムが使用されます。このプロトコルは完全に許可不要で、信頼不要であり、ネットワーク接続がある人なら誰でも利用でき、少数の中継チェーンノードに接続し、rollupの状態遷移要求を提出できます。これらの要求は、中継チェーンのコアによって検証され、前提条件を満たす必要があります：それは有効な状態遷移でなければならず、そうでなければそのrollupの状態は進行しません。
垂直拡張のトレードオフ
Rollupは、Polkadotのマルチコアアーキテクチャを利用して垂直スケーリングを実現できます。この新しい機能は「弾性拡張」（Elastic Scaling）機能によって導入されました。設計プロセスの中で、rollupブロックの検証が特定のコアに固定されていないため、柔軟性に影響を与える可能性があることがわかりました。
中継チェーンにブロックを提出するプロトコルは許可不要で信頼不要であるため、誰でもrollupに割り当てられた任意のcoreにブロックを提出して検証を行うことができます。攻撃者はこれを利用して、以前に検証された合法的なブロックを異なるcoreに繰り返し提出し、悪意を持ってリソースを消費し、rollupの全体的なスループットと効率を低下させる可能性があります。
Polkadotの目標は、システムの重要な特性に影響を与えずに、ロールアップの柔軟性とリレーチェーンリソースの有効利用を維持することです。
Sequencerは信頼できますか？
簡単な解決策は、プロトコルを「許可された」に設定することです：例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼できるオーダーラーが悪意のある行動をしないことを前提とし、rollupの活性を保証します。
しかし、Polkadotの設計理念の中では、シーケンサーに対して信頼の仮定を行うことはできません。なぜなら、システムの「信頼不要」と「許可不要」という特性を維持するためです。誰でもコレーター プロトコルを使用してロールアップの状態遷移リクエストを提出できるべきです。
Polkadot:妥協のないソリューション
Polkadotが最終的に選択した方案は：問題を完全にrollupの状態遷移関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できる情報源であるため、出力においてどのPolkadotコアで検証を実行すべきかを明示的に宣言する必要があります。
このデザインは、弾力性と安全性の二重の保証を実現しています。Polkadotは、可用性プロセスの中でrollupの状態遷移を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を確保します。
ポルカドットのデータ可用性層（DA）にrollupブロックが書き込まれる前に、約5人のバリデーターで構成されたグループがその合法性を検証します。彼らは、ソートチェイナーが提出した候補レシート（candidate receipt）と有効性証明（PoV）を受け取り、そこにはrollupブロックと対応するストレージ証明が含まれています。これらの情報はパラチェーンの検証関数によって処理され、中継チェーン上のバリデーターによって再実行されます。
検証結果には、どのコアでブロックを検証するかを指定するためのコアセレクターが含まれています。バリデーターは、そのインデックスが自分が担当しているコアと一致するかどうかを比較します。一致しない場合、そのブロックは破棄されます。
このメカニズムは、システムが常に信頼不要で許可不要の特性を維持し、ソーターなどの悪意のある行為者による検証位置の操作を回避し、rollupが複数のcoreを使用しても弾力性を保持できることを保証します。
セキュリティ
スケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップのセキュリティはリレーチェーンによって保証されており、誠実なオーダーラーが1人いれば生存性を維持できます。
ELVESプロトコルを利用することで、Polkadotはその安全性をすべてのrollupに完全に拡張し、コア上のすべての計算を検証し、使用するコアの数に対して制限や仮定を必要としません。
したがって、Polkadotのロールアップはセキュリティを犠牲にすることなく真のスケーラビリティを実現できます。
###の汎用性
弾性拡張はrollupのプログラマビリティを制限しません。PolkadotのrollupモデルはWebAssembly環境でチューリング完全な計算を実行することをサポートしており、単一の実行は2秒以内に完了する必要があります。弾性拡張のおかげで、6秒ごとの周期内で実行可能な総計算量が増加しますが、計算タイプには影響を与えません。
###の複雑さ
より高いスループットとより低い遅延は、避けられない複雑性を引き起こします。これは、システム設計において唯一受け入れられるトレードオフの方法です。
RollupはAgile Coretimeインターフェースを通じてリソースを動的に調整し、一貫したセキュリティレベルを維持できます。また、さまざまな使用シーンに適応するために、部分的にRFC103の要件を実装する必要があります。
具体的複雑性はrollupのリソース管理戦略に依存し、これらの戦略はオンチェーンまたはオフチェーンの変数に依存する可能性があります。例えば：
*軽量戦略:ノードmempool内の特定のトランザクション負荷を監視します。
自動化の方法はより効率的ですが、実現とテストのコストも著しく上昇します。
###相互運用性
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のコア暗号経済セキュリティプロトコルの約2x10^6倍です。
さらに、ZKロールアップのデータ可用性の問題は、その欠点を悪化させる可能性があります。誰もが取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存しており、コストとユーザー料金をさらに押し上げることになります。
まとめ
スケーラビリティの限界は、妥協であるべきではない。
他のパブリックチェーンと比較して、Polkadotは中央集権を性能と交換したり、事前に信頼を効率と交換したりする道を歩んでいません。代わりに、弾力的なスケーラビリティ、許可なしのプロトコル設計、統一されたセキュリティ層、および柔軟なリソース管理メカニズムを通じて、セキュリティ、分散化、高性能の多次元的なバランスを実現しました。
より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラストスケーラビリティ」が、Web3の長期的な発展を支える真の解決策かもしれません。