zkSyncはなぜ膨大な取引を伴う刻印銘文にもかかわらず、完璧にストレステストをパスできたのか？

2023.12.18

共有先

TechFlow厳選深潮セレクト

zkSyncはなぜ膨大な取引を伴う刻印銘文にもかかわらず、完璧にストレステストをパスできたのか？

長期的には、インスクリプションの出来事は、L2の性能を噂されているように原型にまで低下させたわけではなく、むしろL2のさらなる性能最適化に実践的な経験を提供した。

2023.12.18 - 06:06:03

zkSync

Web3業界の深掘り報道に専念し潮流を洞察

執筆：Haotian

導入：最近の過熱したインスクリプション（銘文）ブームは、各パブリックチェーンにとって大きな試練となった。一部のチェーンではダウンタイムが発生し、他のチェーンではガス料金が爆発的に上昇した。しかし、zkSyncはこの試練において、性能面でもGAS安定性においても見事に耐え抜いた。

おそらく疑問に思うだろう。「zkSyncはインスクリプションの影響でダウンしたのではないのか？」実際は、これはブロックチェーンエクスプローラーのフロントエンド表示に問題が生じたためであり、本稿では技術的原理から、なぜzkSyncが優れた性能を発揮し、処理するトランザクション量が増えるほどガス料金が安くなるのかを解説する。

zkSync上でインスクリプションを刻む行為により、短時間に大量の取引が殺到したことは確かにL2パブリックチェーンの性能に対する「ストレステスト」であった。だがその結果は「ダウン」ではなく、正反対にzkSyncが公開で実力を示す機会となり、TPSのピーク値やGASの安定性などすべてが見事に試練を乗り越えたのである。

一見すると直感に反するように感じるかもしれない。以下、技術的ロジックを用いて明確にしていこう。

zkSyncのブロック生成処理の仕組みは単純に言うと以下の通りである。ユーザーが取引を構築してzkSyncのSequencer（中央集約者）の順序キューに入り、Sequencerはガス料金の高さに基づいてそれらをブロックにパッケージングし、次にそのブロックをProofシステムへ送って検証し、最後にメインネットへ提出して最終確定（finality）を行う。

-ここには2つのポイントがあり、「使い勝手が悪い」という誤解を招きやすい：

1）ユーザーによる取引作成段階：多くのユーザーはMetamaskなどのウォレットを通じて取引を開始する。この場合、取引はまずRPCリモート呼び出しサーバーに入り、その後Sequencerがそれを受信してキューに並べる。この待ち時間は数秒から数分かかることがあり、ユーザーが長く待つと、Metamaskはその取引が失敗したと判断し、フロントエンドに「取引失敗」のメッセージを表示してしまう。

しかし、これは取引が実際に失敗したわけではなく、MetamaskのRPC応答時間とフィードバックロジックが、zkSyncのSequencerのキュー処理ロジックと「互換性がない」ことに起因している。そのため、Metamask上では失敗と表示された取引が、しばらく待つとバックエンドでは成功しているという現象が起こるのである。

もしユーザーがウォレット経由ではなく、直接バックエンドコードからzkSyncのRPCを呼び出せば、応答タイムアウトや失敗表示といった問題は発生せず、体験は非常にスムーズになる。これは、バックエンドコマンドを使える「科学者」たちに有利な状況を作り出すが、本質的にはウォレット側のUXの問題であり、zkSyncチェーン自体の処理能力とは無関係である。

2）Sequencerによる公平な順序付け段階：ユーザーが短時間に多数の取引をRPCキューに送信する場合、各取引はnonce値0から順に積み重ねられる。前の取引がまだキュー待ちの状態（nonce=0）で、新しい取引（nonce=1）を送信すると、zkSyncのSequencerは時刻（time）に基づいてこれらの取引にnonceを割り当て、順序を決定する。

しかし、ユーザーがMetamaskのフロントエンドで「前の取引失敗」と表示されたあとにすぐに新たな取引を送信すると、ウォレットとzkSync API間の呼び出し問題により、一部の取引が実際にはRPCのキューに正常に送信されていない可能性がある。つまり、ユーザーは多くの取引を送信したつもりでも、実際にはzkSync側が受け取ったのは一部だけであり、受け取ったものはすべて順序付け・処理される。

このように、Metamaskが「取引失敗」と表示したためユーザーが次々と新規取引を送信する行動は、多くの「失敗」を生むことになる。実際にはzkSyncのバックエンドにそもそも届いておらず、ユーザーがフロントエンド上で「送信した」と思い込んでいるだけなのだ。

要するに、MetamaskのRPC応答時間に関するロジックと、ユーザーが急いで取引を連続送信する行動が重なり、大量の取引「失敗」が発生する。zkSyncのバックエンド処理フローを理解していれば、こうしたUX上の問題を回避しやすくなる。

-以上の解説を踏まえ、「ダウン」問題についても明確にする：

zkSyncチェーン自体は「ダウン」していない。これはエクスプローラーのフロントエンド表示の問題である。エクスプローラーはzkSyncのRPCインターフェースを通じて最新データを取得するが、このインターフェースの応答には遅延が生じる。大量の新規取引によって応答速度がさらに遅くなる。

つまり、エクスプローラーのデータ同期速度が、急増する取引キューのスピードに追いつかないのが原因であり、チェーン自体の稼働とは無関係である。通常、取引の流入が落ち着けば、エクスプローラーも新データを取得できるようになり、問題は自然に解決する。

エクスプローラーが正常に動作しない場合は、別のzkSyncブロックデータを同期しているエクスプローラーで確認すればよい。例えば：https://hyperscan.xyz

-では、実際のチェーン「稼働性能」はどうなのか？

1）「ダウン」という噂が広まった後、zkSync公式スタッフのAnthony RoseはTwitterで繰り返しTPS更新の報告を行っていた。実際、zkSyncのTPSはピーク時に187.9に達し、通常50〜100程度であることを考えると、大量の取引が殺到してもしっかり耐え抜いた。これは将来、数千から数万TPSへのスケーリングに向けて、十分な「ストレステスト」になったと言える。

2）ZK-Rollup特有のメカニズムにより、処理する取引量が増えれば増えるほど、ガス料金は安くなる。実際、zkSyncのガス料金はさらに安くなっており、取引コストが分摊されているためだ。growthepieのデータによると、過去24時間でzkSyncの平均ガス料金は5.2%低下し、約0.19ドル前後となっている。個人差はあるが、チェーン全体の運営データから見れば、確かに安くなっている。これはZK-Rollupの快適な体験には、現行のユーザースケールをさらに一段階引き上げる必要があることを示している。