2月26日、Polygon zkEVMのメインネットの立ち上げを告知するプロモーションポスターが、「イーサリアム」に相当する用語の使用について議論を巻き起こし、Scrollの創設者であるYe Zhang氏は、Polygon zkEVMにはこの機能がないことを厳粛に指摘しました。 後から考えると、Polygon Labsの責任者であるRyan Wyatt氏は、これはチーム内のマーケターと技術者の間のコミュニケーション不足の結果であると答えました。これは些細なことではなく、その効果の程度はL1/L2のパフォーマンスとスケーラビリティに直接関係することさえありますが、ちょうど2日前、Solanaの共同開発者であるTolyは、ZK L2sはスケーラビリティを解決するための最良のソリューションではないという記事を公開しました。 2月27日、このイベントの主人公であるPolygon技術チームも、zkRollupの動作原理に積極的に対応し、zkRollupのスケーラビリティがどこを指しているのかを説明しました。3月1日には、ソラナもイーサリアムのキラーの旗印を再び掲げるための「ネットワークアップグレードを改善する計画」を発表しましたが、その運用メカニズムは度重なる障害を経て根本的に革新されておらず、どちらかというと危機後の最適化のようなもので、イーサリアムの高性能L1への置き換えにも影を落としています。この記事では、L1/L2の創業者のツイートを組み合わせて、パブリックチェーンのパフォーマンスに関する大きな議論の裏表を明らかにします。### **起源:EVMの等価性に関する議論**PolygonのzkEVMは、厳密に言えば、マッピングを通じてL2レベルでイーサリアムのメインネットと一貫性のあるzk VMの仕組みであり、zk技術の導入がzk VMと呼ばれる理由であり、非厳密な意味では、同期を維持できるのであれば、zk EVMと呼んでも無害です。しかし、Scrollの創設者であるYe Zhang氏によると、EVMの同等性はイーサリアムの同等性とまったく同じではなく、イーサリアムの同等性は少なくともデータストレージの点でイーサリアムのメインネットと一貫している必要があるとのことです。 より広い視点から見ると、現在のL2やイーサリアムのクロスチェーンブリッジはどれもイーサリアムと同等であると主張することはできず、イーサリアムのよりモジュール化された複雑なスタックは、より困難な互換性をもたらすでしょう。 この2つの違いを直感的に理解するために簡単な例を挙げると、Optimismは製品計画においてこの2つの違いを扱っています。EVMの同等性:主にdApp開発者の観点から見ると、OVMでの経験はイーサリアムのメインネットでdAppsを開発した場合と変わらないため、OVMはEVMと同等です。イーサリアムの同等性:主にプロトコル開発者の観点から、クライアント、通信層、コンセンサス層、実行層の面でイーサリアムとの高い一貫性を維持する必要があります。 EVMの同等性に関する議論に加えて、スケーラビリティをめぐる論争が現在、イーサリアムベースのL2と高性能L1の戦いの焦点となっていることにも注意する必要があります。### **先行例:ZKのスケーラビリティに対するSolanaの疑問**Polygon zkEVMトレーラーの公開2日前の2月24日、Solanaの共同開発者であるToly氏は、Solanaの運用メカニズムに対する一般の疑念を相殺するために、ZK L2がパブリックチェーンのスケーリングの問題を解決する能力に疑問を呈する投稿をTwitterに投稿しました。要点は以下の通り。*チェーンへのリアルタイムデータのアップロードには、安定したシーケンシャル実行機能が必要です。* ZKプルーフスキームは、ZKプルーフ生成時間+検証時間の合計がリアルタイム実行時間よりも短い場合に有効です。* ZKソリューションは、大量のデータをリアルタイムで処理できず、断続的な集計のみを実行できますが、オンチェーン状態のリアルタイムステータスを維持することはできません。したがって、ZKソリューションは、バッチ決済などのシングルタイムの低頻度シナリオに適していますが、Solanaはパブリックチェーンのスケーラビリティに引き続き必要です。残念ながら、Solanaは2月25日に深刻な停止に見舞われ、コミュニティ、エンジニア、バリデーターは2回の再起動後にメインネットを取り戻し、ハウスリークは一晩の雨と重なり、「善良な人」はSolanaのメカニズムに疑問を呈する機会を得て、TwitterユーザーのDBCryptoXは「Solanaでのトランザクションの90〜95%にはバリデーターメッセージとオンチェーン投票が含まれている」と主張しました。 Solanaは、自らを「Proof of History」メカニズムと呼ぶPoSコンセンサスメカニズムを使用しています。 PoHは、ノードがブロックを検証するために通信する必要がないため、ネットワークをより高速に実行することを可能にし、PoHはバリデーターが特定の時点でイベントを特定できるようにします。一方では、このメカニズムは高度な均一性をもたらし、TPSをイーサリアムのメインネットをはるかに超えていますが、他方では、多くのオンチェーンブロックスペースを占有し、何か問題が発生すると、ネットワークを復元するためのコンセンサスに達することは困難です。 少なくとも2021年から2023年にかけて、少なくとも1年に1回のメインネット停止イベントが発生しました。この停止イベントは、Solanaのスケーラビリティに否定的な教訓をもたらしました。 Solanaの共同開発者であるTolyは、ZK L2の証明者はリアルタイムで実行できないため、ZK L2の最終的なオンチェーン実行は確立された順序では行われず、ユーザーはフルノードを実行してネットワークの負担を増やすか、少数の正直なノードに頼って効率を向上させ、中央集権化することができると考えています。しかし、高性能なL1 Solanaはリアルタイム実行の問題を解決しそうになく、結局のところ、崩壊したネットワークは最終的に確立された秩序を失い、強制的に復元されたデータはネットワーク自体の自発的な状態ではなく、人工的な「コンセンサス」になってしまいます。### 結果:Polygonのスケーラビリティは決定的Polygon zkEVMは、最初にSolanaから質問を受け、その後、ウーロン茶の事件があったと発表しましたが、これは専門性に欠け、誤解を招く恐れがありました。 そこで、開発者のJordi Baylinaは、プロフェッショナリズムに挑戦し、証明者がZK L2の制限要因ではなく、本当の障害はDA(データの可用性)であることを説明することに焦点を当てました。1つ目はzkRollupの操作プロセスで、下図のように大きく3つのステップに分けることができます。ロールアップのアーキテクチャに関係なく、L2 上のデータが関係している限り、ネットワークの同期を維持するには、メッセージのバッチの有効性を証明して、最終的に L1 に返されたときに確認できるようにする必要があります。アグリゲートプルーフの生成には、並列処理によって高速化できるzkプルーフスキーム(ZKP)を使用する必要がありますが、バッチプルーフの生成自体には時間がかかります。 ネットワークのニーズに応じてネットワーク証明者の数を増減できる動的なメカニズムを設計することも可能です。ZKPが実行されると、データに対して完全なツリープルーフネットワークが生成され、さまざまなサーバーがデータを検証し、結果をL1チェーンに送信できます。2つ目はコストの問題で、最も重要なのは証明コストであり、ZK操作呼び出しのソフトウェア、ハードウェア、および時間はTX(トランザクション)料金によって計算係数に含まれ、最終的にネットワークのガス料金に反映され、STARK / SNARK / FLONKなどのさまざまなアルゴリズムにより、ネットワーク使用のコストが大幅に最適化されます。 重要な点は、並列化を容易にするためにデータの読み込みを順次実行する必要がないことです。したがって、Solanaが信じているProverはZKプルーフの動作を妨げることはできず、本当の障害はデータの可用性であり、ETH 2.0、DankSharding、EIP4844などのソリューションで解決する必要があります。 ### **結論:スケーラビリティはどこへ向かうのか**Polygon zkEVMをめぐる議論は今後も続くでしょうが、鍵となるのは、zk EVMが現在のスケーラビリティの問題をどれだけうまく解決できるかであり、これはL1/L2が大規模なdAppsやユーザーと直面する次のテストとなるでしょう。
Polygon zkEVMの発売のポスターは、パブリックチェーンの創設者の間でスケーラビリティに関する大きな議論を巻き起こしました
2月26日、Polygon zkEVMのメインネットの立ち上げを告知するプロモーションポスターが、「イーサリアム」に相当する用語の使用について議論を巻き起こし、Scrollの創設者であるYe Zhang氏は、Polygon zkEVMにはこの機能がないことを厳粛に指摘しました。 後から考えると、Polygon Labsの責任者であるRyan Wyatt氏は、これはチーム内のマーケターと技術者の間のコミュニケーション不足の結果であると答えました。
これは些細なことではなく、その効果の程度はL1/L2のパフォーマンスとスケーラビリティに直接関係することさえありますが、ちょうど2日前、Solanaの共同開発者であるTolyは、ZK L2sはスケーラビリティを解決するための最良のソリューションではないという記事を公開しました。
2月27日、このイベントの主人公であるPolygon技術チームも、zkRollupの動作原理に積極的に対応し、zkRollupのスケーラビリティがどこを指しているのかを説明しました。
3月1日には、ソラナもイーサリアムのキラーの旗印を再び掲げるための「ネットワークアップグレードを改善する計画」を発表しましたが、その運用メカニズムは度重なる障害を経て根本的に革新されておらず、どちらかというと危機後の最適化のようなもので、イーサリアムの高性能L1への置き換えにも影を落としています。
この記事では、L1/L2の創業者のツイートを組み合わせて、パブリックチェーンのパフォーマンスに関する大きな議論の裏表を明らかにします。
起源:EVMの等価性に関する議論
PolygonのzkEVMは、厳密に言えば、マッピングを通じてL2レベルでイーサリアムのメインネットと一貫性のあるzk VMの仕組みであり、zk技術の導入がzk VMと呼ばれる理由であり、非厳密な意味では、同期を維持できるのであれば、zk EVMと呼んでも無害です。
しかし、Scrollの創設者であるYe Zhang氏によると、EVMの同等性はイーサリアムの同等性とまったく同じではなく、イーサリアムの同等性は少なくともデータストレージの点でイーサリアムのメインネットと一貫している必要があるとのことです。
より広い視点から見ると、現在のL2やイーサリアムのクロスチェーンブリッジはどれもイーサリアムと同等であると主張することはできず、イーサリアムのよりモジュール化された複雑なスタックは、より困難な互換性をもたらすでしょう。
この2つの違いを直感的に理解するために簡単な例を挙げると、Optimismは製品計画においてこの2つの違いを扱っています。
EVMの同等性:主にdApp開発者の観点から見ると、OVMでの経験はイーサリアムのメインネットでdAppsを開発した場合と変わらないため、OVMはEVMと同等です。
イーサリアムの同等性:主にプロトコル開発者の観点から、クライアント、通信層、コンセンサス層、実行層の面でイーサリアムとの高い一貫性を維持する必要があります。
EVMの同等性に関する議論に加えて、スケーラビリティをめぐる論争が現在、イーサリアムベースのL2と高性能L1の戦いの焦点となっていることにも注意する必要があります。
先行例:ZKのスケーラビリティに対するSolanaの疑問
Polygon zkEVMトレーラーの公開2日前の2月24日、Solanaの共同開発者であるToly氏は、Solanaの運用メカニズムに対する一般の疑念を相殺するために、ZK L2がパブリックチェーンのスケーリングの問題を解決する能力に疑問を呈する投稿をTwitterに投稿しました。
要点は以下の通り。
*チェーンへのリアルタイムデータのアップロードには、安定したシーケンシャル実行機能が必要です。
したがって、ZKソリューションは、バッチ決済などのシングルタイムの低頻度シナリオに適していますが、Solanaはパブリックチェーンのスケーラビリティに引き続き必要です。
残念ながら、Solanaは2月25日に深刻な停止に見舞われ、コミュニティ、エンジニア、バリデーターは2回の再起動後にメインネットを取り戻し、ハウスリークは一晩の雨と重なり、「善良な人」はSolanaのメカニズムに疑問を呈する機会を得て、TwitterユーザーのDBCryptoXは「Solanaでのトランザクションの90〜95%にはバリデーターメッセージとオンチェーン投票が含まれている」と主張しました。
Solanaは、自らを「Proof of History」メカニズムと呼ぶPoSコンセンサスメカニズムを使用しています。 PoHは、ノードがブロックを検証するために通信する必要がないため、ネットワークをより高速に実行することを可能にし、PoHはバリデーターが特定の時点でイベントを特定できるようにします。
一方では、このメカニズムは高度な均一性をもたらし、TPSをイーサリアムのメインネットをはるかに超えていますが、他方では、多くのオンチェーンブロックスペースを占有し、何か問題が発生すると、ネットワークを復元するためのコンセンサスに達することは困難です。 少なくとも2021年から2023年にかけて、少なくとも1年に1回のメインネット停止イベントが発生しました。
この停止イベントは、Solanaのスケーラビリティに否定的な教訓をもたらしました。 Solanaの共同開発者であるTolyは、ZK L2の証明者はリアルタイムで実行できないため、ZK L2の最終的なオンチェーン実行は確立された順序では行われず、ユーザーはフルノードを実行してネットワークの負担を増やすか、少数の正直なノードに頼って効率を向上させ、中央集権化することができると考えています。
しかし、高性能なL1 Solanaはリアルタイム実行の問題を解決しそうになく、結局のところ、崩壊したネットワークは最終的に確立された秩序を失い、強制的に復元されたデータはネットワーク自体の自発的な状態ではなく、人工的な「コンセンサス」になってしまいます。
結果:Polygonのスケーラビリティは決定的
Polygon zkEVMは、最初にSolanaから質問を受け、その後、ウーロン茶の事件があったと発表しましたが、これは専門性に欠け、誤解を招く恐れがありました。 そこで、開発者のJordi Baylinaは、プロフェッショナリズムに挑戦し、証明者がZK L2の制限要因ではなく、本当の障害はDA(データの可用性)であることを説明することに焦点を当てました。
1つ目はzkRollupの操作プロセスで、下図のように大きく3つのステップに分けることができます。
ロールアップのアーキテクチャに関係なく、L2 上のデータが関係している限り、ネットワークの同期を維持するには、メッセージのバッチの有効性を証明して、最終的に L1 に返されたときに確認できるようにする必要があります。
アグリゲートプルーフの生成には、並列処理によって高速化できるzkプルーフスキーム(ZKP)を使用する必要がありますが、バッチプルーフの生成自体には時間がかかります。 ネットワークのニーズに応じてネットワーク証明者の数を増減できる動的なメカニズムを設計することも可能です。
ZKPが実行されると、データに対して完全なツリープルーフネットワークが生成され、さまざまなサーバーがデータを検証し、結果をL1チェーンに送信できます。
2つ目はコストの問題で、最も重要なのは証明コストであり、ZK操作呼び出しのソフトウェア、ハードウェア、および時間はTX(トランザクション)料金によって計算係数に含まれ、最終的にネットワークのガス料金に反映され、STARK / SNARK / FLONKなどのさまざまなアルゴリズムにより、ネットワーク使用のコストが大幅に最適化されます。 重要な点は、並列化を容易にするためにデータの読み込みを順次実行する必要がないことです。
したがって、Solanaが信じているProverはZKプルーフの動作を妨げることはできず、本当の障害はデータの可用性であり、ETH 2.0、DankSharding、EIP4844などのソリューションで解決する必要があります。
結論:スケーラビリティはどこへ向かうのか
Polygon zkEVMをめぐる議論は今後も続くでしょうが、鍵となるのは、zk EVMが現在のスケーラビリティの問題をどれだけうまく解決できるかであり、これはL1/L2が大規模なdAppsやユーザーと直面する次のテストとなるでしょう。