銘文のストレステストの下で、zkSyncは「オープントレーニング」を成功裏に完了しました

原作者: Haotian (X: @tmel0211)

編集者注:碑文トラックはまだ熱く、zkSyncチェーンは短期間で膨大な数のトランザクションで氾濫しており、この「ストレステスト」では、zkSyncは碑文のためにダウンしていますか、それとも完全にテストされていますか? 暗号資産研究者のHaotian氏(X:@tmel0211)は、zkSyncの「悪い体験」の錯覚と誤解を技術的な論理から明らかにし、Odaily Planet Dailyは次のように整理しました。

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

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

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

-ここには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の公式スタッフはTPSの更新をツイート@anthonykrose。 実際、zkSync TPSは187.9のピークまで急上昇しており、通常の状況ではTPSは50〜100程度に過ぎず、これは新しいトランザクションが大量に流入していることを示しており、zkSyncは実際に圧力に抵抗しています。 これにより、将来的には数万とは言わないまでも、数千のTPSに対する完全な「ストレステスト」が提供されます。

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

**-レイヤー2パブリックチェーンに対する碑文イベントの影響は?

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

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

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

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

元の記事へのリンク