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