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