**執筆者:Haotian**最近、@zksync Boojumのアップグレードを完了しましたが、zkSyncがOperation SYNC Inscriptionのストレステストに耐えたのは、この前提でした。 しかし、Boojumは市場から過小評価されています。Boojumはどのようなパフォーマンスの向上をもたらしますか? 批判されている分散型金融の安定性の問題は解決できるのか? 次に、私の理解についてお話ししましょう。1) Boojumのアップグレードは、簡単に理解すると、zkSyncがSNARKからSTARKプルーフへの移行を完了することを可能にします。 ワークフローは大まかに次のようになります。バッチがカプセル化されると、これらのトランザクションは複数の特定の回路に分割され、並列かつ高速に処理されて多数のSTARKが生成され、最終的にSTARKプルーフに集約されます。 最後に、STARKプルーフはSNARKプルーフにカプセル化され、検証のためにメインネットに提出されます。このようにSTARKとSNARKを組み合わせることで、大量のトランザクションを効率的に処理すると同時に、メインネットに送信されるデータのサイズを小さくし(SNARKはよりシンプルです)、メインネットとの互換性を高めています。2つのプルーフを同時に使用することは、Proverシステムの高度な圧縮技術、ハードウェアアクセラレーション技術、アルゴリズムの最適化、バッチ処理の集約効率、メモリとストレージの最適化により、パフォーマンスが大幅に向上することを意味します。2)@0xtaetaehohoツイートによると、Boojumアップデート前は1トランザクションあたりの平均データ量が211バイトだったが、アップグレード後は約68バイトに減らすことができ、圧縮技術の向上により、レイヤー2の各バッチのトランザクション量が直接大幅に増加し、TPS(約450)が大幅に増加し、1トランザクションのガスコストが低下(約65%)するとのことです。この原理を理解するのは難しくなく、レイヤー2はメインネット上のストレージデータが限られているため、ステータスデータの証明をメインネットコールデータに送信し、レイヤー2のSTARK並列処理機能とSNARKプルーフ圧縮処理技術により、単一のバッチで処理できるトランザクション量とガスレベルを決定します。3)以前は、ZK-Rollupは低頻度の分散型金融トランザクションの処理に不安定な問題があり、その本来の傾向は分散型金融の安定性を助長しませんでした。 たとえば、分散型金融の変動価格には複数のOracle価格フィードが必要であり、2つのトランザクションが同じ状態にバッチ処理されない場合、結果として生じるトランザクションの摩耗が増加します。これで、レイヤー 2 の 1 つのバッチのトランザクション量が大幅に増加し、ブロック内でより多くの Oracle データステータスの更新に対応できるようになりました。 分散型金融の安定性の問題も効果的に解決されます。zkSyncの公式@anthonykrose述べられているように、ブロックにOracle Machineの更新がいくつ含まれていても、ブロック状態全体を全体として処理および記録でき、1つの状態書き込みのコストを支払うだけで済みます。 これは、ZK-Rollupチェーン上の分散型金融アプリケーションの低手数料、高効率、安定性にとって有益です。Boojumのアップグレードは、zkSyncのマイルストーンと見なされるのは当然のことです。一方では、ZKシステムの取引量が多いほどガス代が安くなるという推論を検証し、他方では、オフチェーンのProverシステムの圧縮技術やハードウェアアクセラレーションなどのコンピューティングリソースの効率的な適用と性能向上が、ZKシステムに無限の想像力をもたらすことを証明しています。カンクンのアップグレード後、EthereumMainnet blob Block Sizeはレイヤー2バッチトランザクションのコストを低下させると予想されていましたが、ZKシステム自体の技術的な最適化により、ZKシリーズのロールアップとOPシリーズのロールアップが同じレベルになりました。要するに、ZK-Rollup は OP-Rollup よりもはるかに "アクティブ" です。 ZK-Rollupテクノロジーの利点は、Boojumのアップグレード後に完全に証明されました。参考:ZKハードウェアアクセラレーション、計算能力の最適化などについては、以下の研究レポートを参照してください。
碑文の圧力に抵抗する最大の貢献者:BoojumアップグレードによるzkSyncの改善について
執筆者:Haotian
最近、@zksync Boojumのアップグレードを完了しましたが、zkSyncがOperation SYNC Inscriptionのストレステストに耐えたのは、この前提でした。 しかし、Boojumは市場から過小評価されています。
Boojumはどのようなパフォーマンスの向上をもたらしますか? 批判されている分散型金融の安定性の問題は解決できるのか? 次に、私の理解についてお話ししましょう。
バッチがカプセル化されると、これらのトランザクションは複数の特定の回路に分割され、並列かつ高速に処理されて多数のSTARKが生成され、最終的にSTARKプルーフに集約されます。 最後に、STARKプルーフはSNARKプルーフにカプセル化され、検証のためにメインネットに提出されます。
このようにSTARKとSNARKを組み合わせることで、大量のトランザクションを効率的に処理すると同時に、メインネットに送信されるデータのサイズを小さくし(SNARKはよりシンプルです)、メインネットとの互換性を高めています。
2つのプルーフを同時に使用することは、Proverシステムの高度な圧縮技術、ハードウェアアクセラレーション技術、アルゴリズムの最適化、バッチ処理の集約効率、メモリとストレージの最適化により、パフォーマンスが大幅に向上することを意味します。
2)@0xtaetaehohoツイートによると、Boojumアップデート前は1トランザクションあたりの平均データ量が211バイトだったが、アップグレード後は約68バイトに減らすことができ、圧縮技術の向上により、レイヤー2の各バッチのトランザクション量が直接大幅に増加し、TPS(約450)が大幅に増加し、1トランザクションのガスコストが低下(約65%)するとのことです。
この原理を理解するのは難しくなく、レイヤー2はメインネット上のストレージデータが限られているため、ステータスデータの証明をメインネットコールデータに送信し、レイヤー2のSTARK並列処理機能とSNARKプルーフ圧縮処理技術により、単一のバッチで処理できるトランザクション量とガスレベルを決定します。
3)以前は、ZK-Rollupは低頻度の分散型金融トランザクションの処理に不安定な問題があり、その本来の傾向は分散型金融の安定性を助長しませんでした。 たとえば、分散型金融の変動価格には複数のOracle価格フィードが必要であり、2つのトランザクションが同じ状態にバッチ処理されない場合、結果として生じるトランザクションの摩耗が増加します。
これで、レイヤー 2 の 1 つのバッチのトランザクション量が大幅に増加し、ブロック内でより多くの Oracle データステータスの更新に対応できるようになりました。 分散型金融の安定性の問題も効果的に解決されます。
zkSyncの公式@anthonykrose述べられているように、ブロックにOracle Machineの更新がいくつ含まれていても、ブロック状態全体を全体として処理および記録でき、1つの状態書き込みのコストを支払うだけで済みます。 これは、ZK-Rollupチェーン上の分散型金融アプリケーションの低手数料、高効率、安定性にとって有益です。
Boojumのアップグレードは、zkSyncのマイルストーンと見なされるのは当然のことです。
一方では、ZKシステムの取引量が多いほどガス代が安くなるという推論を検証し、他方では、オフチェーンのProverシステムの圧縮技術やハードウェアアクセラレーションなどのコンピューティングリソースの効率的な適用と性能向上が、ZKシステムに無限の想像力をもたらすことを証明しています。
カンクンのアップグレード後、EthereumMainnet blob Block Sizeはレイヤー2バッチトランザクションのコストを低下させると予想されていましたが、ZKシステム自体の技術的な最適化により、ZKシリーズのロールアップとOPシリーズのロールアップが同じレベルになりました。
要するに、ZK-Rollup は OP-Rollup よりもはるかに “アクティブ” です。 ZK-Rollupテクノロジーの利点は、Boojumのアップグレード後に完全に証明されました。
参考:ZKハードウェアアクセラレーション、計算能力の最適化などについては、以下の研究レポートを参照してください。