# 拡張性とトレードオフ：PolkadotがWeb3エコシステムでバランスを求める方法ブロックチェーンがより高い効率を追求している今日、重要な問題が徐々に明らかになっています：パフォーマンスを拡張する一方で、セキュリティやシステムの弾力性を犠牲にしない方法は？これは技術的な課題だけでなく、アーキテクチャ設計における深い選択でもあります。Web3エコシステムにとって、信頼とセキュリティを犠牲にして構築されたより速いシステムは、持続可能なイノベーションを支えることが難しいことが多いです。PolkadotはWeb3のスケーラビリティの重要な推進者として、高スループットと低遅延の目標において何らかの妥協をしたのでしょうか？そのrollupモデルは、非中央集権、安全性、またはネットワーク相互運用性において妥協をしていますか？この記事では、これらの問題を中心に、Polkadotのスケーラビリティ設計における選択とトレードオフを深く分析し、他の主流のパブリックチェーンのソリューションと比較し、性能、安全性、非中央集権の三者の間での異なる道の選択について探ります。## Polkadot拡張機能設計の課題### 弾性と分散化のバランスPolkadotのアーキテクチャは、バリデーターネットワークと中央集権的なリレーチェーンに依存していますが、これは何らかの面で中央集権リスクを引き起こす可能性がありますか？単一障害点や制御が形成され、分散型特性に影響を与えることはあり得ますか？Rollupの運用は、リレーチェーンに接続されたオーダーラーに依存しており、その通信にはcollatorプロトコルと呼ばれるメカニズムを使用します。このプロトコルは完全にパーミッションレスで、信頼なしに、ネットワーク接続を持つ誰もが利用でき、少数のリレーチェーンノードに接続し、rollupの状態遷移要求を提出することができます。これらの要求は、リレーチェーンのあるコアによって検証され、1つの前提を満たす必要があります：有効な状態遷移でなければならず、そうでなければそのrollupの状態は進行しません。### 垂直拡張のトレードオフRollupは、Polkadotのマルチコアアーキテクチャを利用することで垂直スケーリングを実現できます。この新しい機能は「弾力的スケーリング」機能によって導入されました。設計過程で、rollupブロックの検証が特定のコアに固定されていないため、これがその弾力性に影響を与える可能性があることがわかりました。中継チェーンにブロックを提出するプロトコルは許可不要で信頼不要であるため、誰でもrollupに割り当てられた任意のコアにブロックを提出して検証を行うことができます。攻撃者はこれを利用して、以前に検証された合法的なブロックを異なるコアに繰り返し提出し、悪意を持ってリソースを消費させ、rollupの全体的なスループットと効率を低下させる可能性があります。Polkadotの目標は、システムの重要な特性に影響を与えずに、rollupの弾力性と中継チェーンリソースの有効利用を維持することです。### Sequencerは信頼できますか？簡単な解決策の一つは、プロトコルを「許可制」に設定することです：例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼されるソーターが悪意のある行動をしないことを保証することで、ロールアップのアクティビティを確保します。しかし、Polkadotの設計理念において、私たちはsequencerに対していかなる信頼仮定も行うことができません。なぜなら、システムの「信頼不要」と「許可不要」という特性を維持する必要があるからです。誰もがcollatorプロトコルを使用してrollupの状態変換リクエストを提出できるべきです。## Polkadot:妥協のないソリューションPolkadotが最終的に選択した方案は、問題を完全にrollupの状態変換関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できる情報源であるため、出力においてどのPolkadotコアで検証を実行するべきかを明示的に宣言する必要があります。このデザインは、弾力性と安全性の二重の保障を実現しています。Polkadotは、可用性プロセス内でrollupの状態変換を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を保証します。ポルカドットのデータ可用性層（DA）に、任意のロールアップブロックが書き込まれる前に、約5人のバリデーターで構成されるグループがその合法性を検証します。彼らは、順序付け者が提出した候補レシートと有効性証明を受け取り、その中にはロールアップブロックおよび対応するストレージ証明が含まれています。これらの情報はパラレルチェーンの検証関数によって処理され、リレーチェーン上のバリデーターによって再実行されます。検証結果には、どのコアでブロックを検証するかを指定するためのコアセレクターが含まれています。検証者は、そのインデックスが自分が担当しているコアと一致するかどうかを照合します。一致しない場合、そのブロックは破棄されます。このメカニズムは、システムが常に信頼不要かつ許可不要の特性を維持し、ソートアーなどの悪意のある行為者が検証位置を操作することを防ぎ、複数のコアを使用するロールアップであっても柔軟性を維持できることを保証します。### セキュリティスケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップのセキュリティは中継チェーンによって保証されており、1つの誠実なオーダーラーが生存性を維持するだけで済みます。ELVESプロトコルを活用することで、Polkadotはすべてのロールアップにそのセキュリティを完全に拡張し、コア上のすべての計算を検証し、使用するコアの数に対する制限や仮定を一切必要としません。したがって、Polkadotのロールアップは、安全性を犠牲にすることなく真のスケーラビリティを実現できます。###の汎用性弾性拡張はrollupのプログラム可能性を制限しません。Polkadotのrollupモデルは、WebAssembly環境でチューリング完全な計算を実行することをサポートしており、単一の実行が2秒以内に完了する限り可能です。弾性拡張のおかげで、6秒ごとのサイクル内で実行可能な総計算量が増加しますが、計算の種類には影響しません。###の複雑さより高いスループットとより低いレイテンシは避けられない複雑さを引き起こしますが、これはシステム設計において唯一受け入れ可能なトレードオフの方法です。RollupはAgile Coretimeインターフェースを通じてリソースを動的に調整し、一貫した安全レベルを維持できます。また、さまざまな使用シーンに適応するために、部分的にRFC103の要件を実装する必要があります。具体的複雑性はrollupのリソース管理戦略に依存し、これらの戦略はオンチェーンまたはオフチェーンの変数に依存する可能性があります。例えば：* シンプルな戦略：常に固定数のcoreを使用するか、オフチェーンで手動で調整する；* 軽量戦略：ノードのmempoolで特定のトランザクション負荷を監視する；* 自動化戦略：歴史データとXCMインターフェースを通じて、coretimeサービスのリソースを事前に呼び出して構成します。自動化の方法はより効率的ですが、実現とテストのコストも大幅に上昇します。###相互運用性Polkadotは異なるロールアップ間の相互運用性をサポートしており、弾力的なスケーリングはメッセージングのスループットに影響を与えません。クロスロールアップのメッセージ通信は、基盤となるトランスポート層によって実現され、各ロールアップの通信ブロックのスペースは固定されており、割り当てられたコアの数には関係ありません。将来的には、Polkadotはオフチェーンメッセージングもサポートし、リレーチェーンがコントロールプレーンとして機能し、データプレーンではなくなります。このアップグレードにより、ロールアップ間の通信能力が弾力的に拡張され、システムの縦の拡張能力がさらに強化されます。## 他のプロトコルはどのようなトレードオフを行いましたか？誰もが知っているように、性能の向上はしばしば分散化と安全性の犠牲を伴います。しかし、ナカモト係数の観点から見ると、一部のPolkadotの競合他社は分散化の程度が低いにもかかわらず、その性能は期待に応えないものです。### ソラナSolanaはPolkadotやEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャを用いてスケーラビリティを実現しています。歴史的証明（PoH）、CPUの並列処理、リーダーベースのコンセンサスメカニズムに依存しており、理論的TPSは65,000に達する可能性があります。重要な設計の一つは、事前に公開され、検証可能なリーダースケジューリングメカニズムです：* 各エポック（約2日または432,000スロット）の開始時に、ステーク量に基づいてスロットが割り当てられます；* ステーキングが多いほど、配分も多くなります。たとえば、1%のバリデーターをステーキングすると、約1%のブロック生成の機会を得ることになります。* すべてのブロック制作者が事前に公開されているため、ネットワークが標的型DDoS攻撃や頻繁なダウンのリスクにさらされています。PoHと並列処理はハードウェアの要件が非常に高く、検証ノードの集中化を引き起こします。ステーキングが多いノードはブロック生成の機会が増え、小さなノードはほとんどスロットを持たず、さらに集中化を悪化させ、攻撃を受けた際のシステムダウンのリスクを高めます。ソラナはTPSを追求するために、分散化と耐攻撃能力を犠牲にしており、そのナカモト係数はわずか20で、ポルカドットの172を大きく下回っています。### トンあるブロックチェーンプロジェクトは、TPSが104,715に達すると主張していますが、この数字はプライベートテストネット、256のノード、理想的なネットワークおよびハードウェア条件下で達成されたものです。一方、Polkadotは分散型パブリックネットワークで128K TPSに達しています。このプロジェクトのコンセンサスメカニズムにはセキュリティ上のリスクがあります：シャーディング検証ノードのアイデンティティが事前に暴露されます。そのホワイトペーパーでも明確に指摘されていますが、これは帯域幅を最適化することができますが、悪意ある利用の可能性もあります。"ギャンブラー破産"メカニズムが欠如しているため、攻撃者は特定のシャードが完全に制御されるのを待つか、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ロールアップの実装は、1回の取引で処理可能なデータ量の制限を受けています。ゼロ知識証明を生成するための計算要求は非常に高く、「勝者総取り」のメカニズムはシステムの中央集権化を引き起こしやすいです。TPSを保証するために、ZKロールアップはしばしば各バッチの取引量を制限し、高需要時にはネットワークの混雑やガスの上昇を引き起こし、ユーザー体験に影響を与えます。比較すると、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済安全プロトコルの約2x10^6倍です。さらに、ZKロールアップのデータ可用性の問題は、その欠点をさらに悪化させることになります。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存し、コストとユーザー手数料をさらに引き上げます。## まとめスケーラビリティの限界は、妥協であるべきではない。他のパブリックチェーンと比較して、Polkadotは中央集権化による性能向上や、事前に信頼を置くことによる効率化の道を選ぶことはありませんでした。代わりに、弾力的なスケーラビリティ、許可不要のプロトコル設計、統一されたセキュリティレイヤー、柔軟なリソース管理メカニズムを通じて、安全性、分散化、高性能の多次元的なバランスを実現しました。より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラスト拡張性」は、Web3の長期的な発展を支える真の解決策かもしれません。
Polkadotのトレードオフ：Web3エコシステムにおける妥協のないスケーラビリティ
拡張性とトレードオフ：PolkadotがWeb3エコシステムでバランスを求める方法
ブロックチェーンがより高い効率を追求している今日、重要な問題が徐々に明らかになっています：パフォーマンスを拡張する一方で、セキュリティやシステムの弾力性を犠牲にしない方法は？これは技術的な課題だけでなく、アーキテクチャ設計における深い選択でもあります。Web3エコシステムにとって、信頼とセキュリティを犠牲にして構築されたより速いシステムは、持続可能なイノベーションを支えることが難しいことが多いです。
PolkadotはWeb3のスケーラビリティの重要な推進者として、高スループットと低遅延の目標において何らかの妥協をしたのでしょうか？そのrollupモデルは、非中央集権、安全性、またはネットワーク相互運用性において妥協をしていますか？この記事では、これらの問題を中心に、Polkadotのスケーラビリティ設計における選択とトレードオフを深く分析し、他の主流のパブリックチェーンのソリューションと比較し、性能、安全性、非中央集権の三者の間での異なる道の選択について探ります。
Polkadot拡張機能設計の課題
弾性と分散化のバランス
Polkadotのアーキテクチャは、バリデーターネットワークと中央集権的なリレーチェーンに依存していますが、これは何らかの面で中央集権リスクを引き起こす可能性がありますか？単一障害点や制御が形成され、分散型特性に影響を与えることはあり得ますか？
Rollupの運用は、リレーチェーンに接続されたオーダーラーに依存しており、その通信にはcollatorプロトコルと呼ばれるメカニズムを使用します。このプロトコルは完全にパーミッションレスで、信頼なしに、ネットワーク接続を持つ誰もが利用でき、少数のリレーチェーンノードに接続し、rollupの状態遷移要求を提出することができます。これらの要求は、リレーチェーンのあるコアによって検証され、1つの前提を満たす必要があります：有効な状態遷移でなければならず、そうでなければそのrollupの状態は進行しません。
垂直拡張のトレードオフ
Rollupは、Polkadotのマルチコアアーキテクチャを利用することで垂直スケーリングを実現できます。この新しい機能は「弾力的スケーリング」機能によって導入されました。設計過程で、rollupブロックの検証が特定のコアに固定されていないため、これがその弾力性に影響を与える可能性があることがわかりました。
中継チェーンにブロックを提出するプロトコルは許可不要で信頼不要であるため、誰でもrollupに割り当てられた任意のコアにブロックを提出して検証を行うことができます。攻撃者はこれを利用して、以前に検証された合法的なブロックを異なるコアに繰り返し提出し、悪意を持ってリソースを消費させ、rollupの全体的なスループットと効率を低下させる可能性があります。
Polkadotの目標は、システムの重要な特性に影響を与えずに、rollupの弾力性と中継チェーンリソースの有効利用を維持することです。
Sequencerは信頼できますか？
簡単な解決策の一つは、プロトコルを「許可制」に設定することです：例えば、ホワイトリストメカニズムを採用するか、デフォルトで信頼されるソーターが悪意のある行動をしないことを保証することで、ロールアップのアクティビティを確保します。
しかし、Polkadotの設計理念において、私たちはsequencerに対していかなる信頼仮定も行うことができません。なぜなら、システムの「信頼不要」と「許可不要」という特性を維持する必要があるからです。誰もがcollatorプロトコルを使用してrollupの状態変換リクエストを提出できるべきです。
Polkadot:妥協のないソリューション
Polkadotが最終的に選択した方案は、問題を完全にrollupの状態変換関数（Runtime）に委ねることです。Runtimeはすべてのコンセンサス情報の唯一の信頼できる情報源であるため、出力においてどのPolkadotコアで検証を実行するべきかを明示的に宣言する必要があります。
このデザインは、弾力性と安全性の二重の保障を実現しています。Polkadotは、可用性プロセス内でrollupの状態変換を再実行し、ELVES暗号経済プロトコルを通じてcoreの配分の正確性を保証します。
ポルカドットのデータ可用性層（DA）に、任意のロールアップブロックが書き込まれる前に、約5人のバリデーターで構成されるグループがその合法性を検証します。彼らは、順序付け者が提出した候補レシートと有効性証明を受け取り、その中にはロールアップブロックおよび対応するストレージ証明が含まれています。これらの情報はパラレルチェーンの検証関数によって処理され、リレーチェーン上のバリデーターによって再実行されます。
検証結果には、どのコアでブロックを検証するかを指定するためのコアセレクターが含まれています。検証者は、そのインデックスが自分が担当しているコアと一致するかどうかを照合します。一致しない場合、そのブロックは破棄されます。
このメカニズムは、システムが常に信頼不要かつ許可不要の特性を維持し、ソートアーなどの悪意のある行為者が検証位置を操作することを防ぎ、複数のコアを使用するロールアップであっても柔軟性を維持できることを保証します。
セキュリティ
スケーラビリティを追求する過程で、Polkadotはセキュリティを妥協していません。ロールアップのセキュリティは中継チェーンによって保証されており、1つの誠実なオーダーラーが生存性を維持するだけで済みます。
ELVESプロトコルを活用することで、Polkadotはすべてのロールアップにそのセキュリティを完全に拡張し、コア上のすべての計算を検証し、使用するコアの数に対する制限や仮定を一切必要としません。
したがって、Polkadotのロールアップは、安全性を犠牲にすることなく真のスケーラビリティを実現できます。
###の汎用性
弾性拡張はrollupのプログラム可能性を制限しません。Polkadotのrollupモデルは、WebAssembly環境でチューリング完全な計算を実行することをサポートしており、単一の実行が2秒以内に完了する限り可能です。弾性拡張のおかげで、6秒ごとのサイクル内で実行可能な総計算量が増加しますが、計算の種類には影響しません。
###の複雑さ
より高いスループットとより低いレイテンシは避けられない複雑さを引き起こしますが、これはシステム設計において唯一受け入れ可能なトレードオフの方法です。
RollupはAgile Coretimeインターフェースを通じてリソースを動的に調整し、一貫した安全レベルを維持できます。また、さまざまな使用シーンに適応するために、部分的にRFC103の要件を実装する必要があります。
具体的複雑性はrollupのリソース管理戦略に依存し、これらの戦略はオンチェーンまたはオフチェーンの変数に依存する可能性があります。例えば：
シンプルな戦略：常に固定数のcoreを使用するか、オフチェーンで手動で調整する；
軽量戦略：ノードのmempoolで特定のトランザクション負荷を監視する；
自動化戦略：歴史データとXCMインターフェースを通じて、coretimeサービスのリソースを事前に呼び出して構成します。
自動化の方法はより効率的ですが、実現とテストのコストも大幅に上昇します。
###相互運用性
Polkadotは異なるロールアップ間の相互運用性をサポートしており、弾力的なスケーリングはメッセージングのスループットに影響を与えません。
クロスロールアップのメッセージ通信は、基盤となるトランスポート層によって実現され、各ロールアップの通信ブロックのスペースは固定されており、割り当てられたコアの数には関係ありません。
将来的には、Polkadotはオフチェーンメッセージングもサポートし、リレーチェーンがコントロールプレーンとして機能し、データプレーンではなくなります。このアップグレードにより、ロールアップ間の通信能力が弾力的に拡張され、システムの縦の拡張能力がさらに強化されます。
他のプロトコルはどのようなトレードオフを行いましたか？
誰もが知っているように、性能の向上はしばしば分散化と安全性の犠牲を伴います。しかし、ナカモト係数の観点から見ると、一部のPolkadotの競合他社は分散化の程度が低いにもかかわらず、その性能は期待に応えないものです。
ソラナ
SolanaはPolkadotやEthereumのシャーディングアーキテクチャを採用せず、単層の高スループットアーキテクチャを用いてスケーラビリティを実現しています。歴史的証明（PoH）、CPUの並列処理、リーダーベースのコンセンサスメカニズムに依存しており、理論的TPSは65,000に達する可能性があります。
重要な設計の一つは、事前に公開され、検証可能なリーダースケジューリングメカニズムです：
各エポック（約2日または432,000スロット）の開始時に、ステーク量に基づいてスロットが割り当てられます；
ステーキングが多いほど、配分も多くなります。たとえば、1%のバリデーターをステーキングすると、約1%のブロック生成の機会を得ることになります。
すべてのブロック制作者が事前に公開されているため、ネットワークが標的型DDoS攻撃や頻繁なダウンのリスクにさらされています。
PoHと並列処理はハードウェアの要件が非常に高く、検証ノードの集中化を引き起こします。ステーキングが多いノードはブロック生成の機会が増え、小さなノードはほとんどスロットを持たず、さらに集中化を悪化させ、攻撃を受けた際のシステムダウンのリスクを高めます。
ソラナはTPSを追求するために、分散化と耐攻撃能力を犠牲にしており、そのナカモト係数はわずか20で、ポルカドットの172を大きく下回っています。
トン
あるブロックチェーンプロジェクトは、TPSが104,715に達すると主張していますが、この数字はプライベートテストネット、256のノード、理想的なネットワークおよびハードウェア条件下で達成されたものです。一方、Polkadotは分散型パブリックネットワークで128K TPSに達しています。
このプロジェクトのコンセンサスメカニズムにはセキュリティ上のリスクがあります：シャーディング検証ノードのアイデンティティが事前に暴露されます。そのホワイトペーパーでも明確に指摘されていますが、これは帯域幅を最適化することができますが、悪意ある利用の可能性もあります。"ギャンブラー破産"メカニズムが欠如しているため、攻撃者は特定のシャードが完全に制御されるのを待つか、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ロールアップの実装は、1回の取引で処理可能なデータ量の制限を受けています。ゼロ知識証明を生成するための計算要求は非常に高く、「勝者総取り」のメカニズムはシステムの中央集権化を引き起こしやすいです。TPSを保証するために、ZKロールアップはしばしば各バッチの取引量を制限し、高需要時にはネットワークの混雑やガスの上昇を引き起こし、ユーザー体験に影響を与えます。
比較すると、チューリング完全なZKロールアップのコストは、Polkadotのコア暗号経済安全プロトコルの約2x10^6倍です。
さらに、ZKロールアップのデータ可用性の問題は、その欠点をさらに悪化させることになります。誰でも取引を検証できるようにするためには、完全な取引データを提供する必要があります。これは通常、追加のデータ可用性ソリューションに依存し、コストとユーザー手数料をさらに引き上げます。
まとめ
スケーラビリティの限界は、妥協であるべきではない。
他のパブリックチェーンと比較して、Polkadotは中央集権化による性能向上や、事前に信頼を置くことによる効率化の道を選ぶことはありませんでした。代わりに、弾力的なスケーラビリティ、許可不要のプロトコル設計、統一されたセキュリティレイヤー、柔軟なリソース管理メカニズムを通じて、安全性、分散化、高性能の多次元的なバランスを実現しました。
より大規模なアプリケーションの実現を追求する中で、Polkadotが掲げる「ゼロトラスト拡張性」は、Web3の長期的な発展を支える真の解決策かもしれません。