碑文マニアはレイヤー2に伝わりますが、なぜzkSyncは高値取引のストレステストに合格できるのですか?

執筆者:Haotian

zkSyncチェーンに刻まれた碑文と短期的な高値トランザクションの流入は、確かにレイヤー2パブリックチェーンのパフォーマンスの「ストレステスト」ですが、結果は「ダウンタイム」ではなく、逆にzkSyncの公開トレーニングであり、その結果、TPSピークとGASの安定性が完全にテストされたことになります。

一見すると、少し直感に反しているように聞こえませんか? 次に、技術的なロジックで、明確にしましょう。

zkSyncパッケージングブロックの動作原理は、簡単に言うと、ユーザーがzkSync Sequencerのソートシーケンスにトランザクションを構築し、Sequencerがガス料金ランキングに従ってブロックにパックし、ブロックをProofシステムに渡して検証し、最後にメインネットに送信してファイナリティステータスの確認を完了するというものです。

ここには、「悪い体験」の錯覚を簡単に作り出す可能性のある2つの重要なポイントがあります。

1)ユーザーがトランザクションを構築する:ほとんどのユーザーはMetamaskなどのウォレットを介してトランザクションを開始し、ウォレットを介してzkSyncにトランザクションを送信し、トランザクションは最初にRPCリモートコールサーバーに入り、次にSequencerがこれらのトランザクションを受信してキューシーケンスに入ります。 ここでの待ち時間は、最短で数秒から数分までで、長時間待機すると、MetaMaskはトランザクションが失敗したと見なし、フロントエンドはトランザクションが失敗したというメッセージを返します。

ただし、これはトランザクションが実際に失敗したことを意味するのではなく、MetamaskのRPC応答時間とフィードバックロジックと、zkSyncのSequencerのキューイングおよびパッキングトランザクションロジックの間に「非互換性」があるためです。 そのため、しばらく待った後、バックエンドサーバーには、MetaMaskが失敗したと表示する一部のトランザクションが表示されます。

ユーザーがウォレットパイプラインを経由せず、バックエンドコードを直接使用してzkSyncのRPCを呼び出すと、応答時間のタイムアウトやプロンプトの失敗は発生せず、エクスペリエンスは比較的スムーズになります。 これは、バックエンドのコード命令を使用できる一部の「科学者」に利点をもたらしますが、本質的にはウォレットエクスペリエンス側の問題であり、zkSyncチェーンの処理能力とは関係ありません。

2)シーケンサーの公正な順序付けリンク:ユーザーがRPCキューにトランザクションを短時間送信すると、各トランザクションは0のナンス値から重ね合わされ、前のトランザクションがまだキュー状態にある場合、ノンスが0の場合、ユーザーは1のノンスで新しいトランザクションを開始し、zkSyncのシーケンサーは時間に応じてこれらのトランザクションにノンスを割り当て、順番に並べ替えます。

ただし、MetaMaskの前のセクションで前のトランザクションが失敗したことを確認した後、ユーザーが同時に新しいトランザクションを送信した場合、ウォレット側とzkSync APIインターフェイス呼び出しの問題により、新しく送信されたトランザクションの一部がRPCキューに正常に送信されない可能性があります。 ユーザーは多くのトランザクションが送信されていると考えていますが、実際にはzkSyncはそれらの一部しか受け取っておらず、それらを受け取るとすぐにそれらを並べ替えます。

このように見ると、ユーザーはMetaMaskがトランザクションの失敗を報告し、zkSyncチェーンのバックエンドへの送信がまったくないのにフロントエンドで送信したと思うため、常に新しいトランザクションを送信する動作も多数のトランザクションの失敗を引き起こします。

全体として、MetaMaskウォレットのRPC応答時間ロジックと、ユーザーがチェーン上にトランザクションを急いでオーバーレイすると、多数のトランザクション「失敗」が発生し、zkSyncのバックグラウンドトランザクション処理ワークフローを明確にしていれば、これらの最適化エクスペリエンスの問題を比較的簡単に回避できます。

上記のポピュラーサイエンスに基づいて、「ダウンタイム」の問題を明確にしましょう。

zkSyncチェーンは「ダウン」しているわけではなく、ブラウザがzkSyncのRPCインターフェイスを介して最新のデータを取得するため、ブラウザのフロントエンドの表示の問題にすぎませんが、インターフェイスの応答に遅延が発生し、多数の新しいトランザクションが応答を遅くします。

要するに、ブラウザのプルデータ同期の速度は、ブラウザのフロントエンドの問題であり、チェーンの動作とは関係のない、キューに入れられたトランザクションの急増の速度に追いつくことができません。 通常、トランザクション速度が適切に遅くなり、ブラウザが新しいデータをキャプチャできるようになると、問題は解決します。

ブラウザが機能しない場合は、zkSync ブロック データ情報を同期する他のブラウザを使用して相互検証できます。

実際のチェーンの「運用パフォーマンス」とは何ですか?

1)いわゆる停止の噂が流れた後、zkSyncの公式スタッフであるAnthony Roseは、TPSの更新レポートを頻繁にツイートしました。 実際、zkSync TPSは187.9のピークまで急上昇しており、通常の状況ではTPSは50〜100程度に過ぎず、これは新しいトランザクションの大量流入があることを示しており、zkSyncは実際に圧力に抵抗しています。 これは確かに、将来の数千または数万のTPSにとって十分な「ストレステスト」です。

2)ZK-Rollupの特別なメカニズムは、処理されるトランザクション量が多いほどガス料金が安くなると判断し、実際には、トランザクションコストも配分されるため、zkSyncのガス料金は確かに安く、growthepieのデータによると、過去24時間で、zkSyncの平均ガスも5.2%減少し、平均は約0.19ドルで、このデータはすべての人にとって同じではないかもしれませんが、統合されたチェーンの運用データは確かに安価です。 これは、ZK-Rollupのよりスムーズなエクスペリエンスのためには、既存のユーザー規模を桁違いに増やす必要があることを証明しています。

碑文イベントがレイヤー2パブリックチェーンに及ぼす影響は?

砂丘のデータによると、Syncの刻印鋳造は14時間で5Mの取引を追加し、65,575人の保有者が参加しました。 前述したように、zkSyncの関係者は、このコミュニティ主導の「ストレステスト」を認識しており、zkSyncチェーンが整然と運営されていることを確認するための緊急措置を講じています。

このデータは確かにzkSyncの優れたストレステスト実験であり、そのプラスの効果はマイナスを上回ります。 長い目で見れば、この碑文事件は噂にならず、むしろレイヤー2のさらなるパフォーマンス最適化のための実践的な経験を提供しました。

しかし、私の知る限り、Sync以外にも碑文が作られており、Syncほどではないが、このストレステストの火に油を注いでいる。

いずれにせよ、結果は概ね良好で、zkSyncバックエンドがブロックを選別する技術的なロジックを明確にしてから、「悪い経験」という誤解を解くと、すべてがうまく動いていることがわかるはずで、レイヤー2にもう少し自信を持たせる必要があります。