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