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