EIP-4844以降、スタークネットは関税を100倍に引き下げたが、そう単純な話ではない。

Optimism、StarkNet、Arbitrumなどのレイヤー2ネットワークは、いずれも短期間でEIP-4844をサポートし、大幅な料金の引き下げを実現しています。次のトランザクションでは、LXDAOの国庫がOptimismの貢献者に支払ったもので、ガス料金の差は100倍です。ガス料金の差はなんと100倍です。

しかし、驚きとともに以下のことがわかりました。StarkNetはZK Rollupの代表として、以前は1ドル以上だったガス消費量を0.01ドルまで下げるという驚くべきコスト削減を達成した。

この技術のより詳しい説明は、MyFirstLayer2.MyFirstLayer2へ。

02 ；なぜスタークネットの料金引き下げは驚くべきことなのか？

OPロールアップとZKロールアップの1層のストレージに対する要求の違い

OPロールアップとZKロールアップでは、1層のストレージに対する要求のレベルが異なります。ZK Rollupは、DA料金（Data Availability：データ可用性、第三者がアクセスしたいデータにアクセスできるように、データを保存し配布するためのサービスからなる）への依存度が異なります。

OPロールアップは、ユーザー署名などの情報を含む最近の取引のすべての詳細をパッケージ化して圧縮し、ネットワークの1つの階層にすべてアップロードします。ティア1ネットワーク上の検証タスクはあまり必要なく、ほとんどすべてのコストはティア1ネットワーク上のストレージスペースを使用する以上のものです。

対照的に、ZK Rollupはデータの圧縮率が高い。たとえば、ユーザーの署名データを破棄し、トランザクションが正当であることを確認するためにゼロ知識証明に依存します。また、トランザクションのすべての詳細をパッケージ化する代わりに、単に状態の変化をパッケージ化してアップロードします。

たとえば、レイヤー2のネットワーク上で、100人のユーザーがUSDC/USDTペアで取引しており、彼らが取引するたびに、ユーザーとUSDCとUSDCの両方のスワップ契約の残高が変更されます。OPロールアップの場合、100回の取引と200口座で400回の残高変更となります。ZKロールアップの場合、ユーザー残高の変更を含む部分の差は大きくありませんが、スワップ契約の場合、USDCとUSDTの残高の合計200回の変更を最終残高の2回の変更に圧縮することができ、データサイズを大幅に削減することができます。

ZKプルーフのZKロールアップ検証のための余分なガス消費

両者の違いについて学んだ後、まず印象的なのは、ZKロールアップのガス料金は、一般的にZKプルーフのそれよりも高いということでしょう。第一印象としては、ZK RollupのGas FeeはOP RollupのGas Feeよりも一般的に低いと思われるかもしれないが、実践したことのある人であれば、StarkNetやZkSyncなどのZK RollupのL2のコストは、OP Rollupのそれよりも大幅に高いことが多いことを知っているはずである。特に、StarkNetのSTARKテクノロジールートは、他のSNARKルートよりもZK Proofの量が多いため、各種L2の移籍金ランキングでは、OP Rollupのそれよりも上位に位置することが多い。移籍金はL2ランキングの最下位に位置することが多い。

2023年のある時点におけるL2別の移籍金表

ZK RollupがオンラインになってすぐにOP Rollupを打ち負かせなかった理由は、単純に、トランザクションデータの圧縮率を高くすることで、1つの階層にデータを送信するコストを節約できる一方で、ネットワークの1つの階層でゼロ知識証明書の正当性を検証する必要があるため、計算オーバーヘッドが増えるからです。

また、Blobはストレージ部分のコストを削減するだけで、計算部分の助けにはならないので、ZK RollupがEIP-4844から得るものは少なく、StarkNetが最下位クラスから最下位クラスへと進歩するのを見るのはうれしいことだ。というわけで、StarkNetが最下位の "出遅れ組 "からクラス1位2位と肩を並べるまでになったのを見て、顎が落ちないわけがない。

03 StarkNetの料金の探索

ZKのRollupの仕組みは、OPよりもはるかに優れていると言わざるを得ません。例えば、Optimism: Batcher契約によるアップグレードの前後にメインネットワークにデータをパッケージングするコストなど、Rollupの仕組みはOP Rollupよりもはるかに複雑であり、取引コストが2桁下がる理由は誰でも十分に理解できます。

もっと詳しく：

Last old Batch before upgrade:

https://etherscan.io/tx/0x8d8a21aeb64a62c66bc1848c2f37c4ca266edc5d122dd287270bc6aa2c24f445

アップグレード後の最初の新規バッチ（Blobチャージを含む合計0.0011ETH）：

https://etherscan.io/tx/0xa3e36193ab5ca4e6e98848640b1896def4c419ce203e7bd8e876dd2d5eb77e6c

6つのBlobのコスト(合計)0.00078 ETH):

https://blobscan.com/tx/0xaec6d2e65705632f869c02b9baf063822153e058c0da75723733b78b99242f35

しかし、StarkNet Gasのコストを探る過程で、著者はかなりの困難を経験しました。

しかし、スタークネットガスのコストを探索する過程で、著者はかなりの困難を経験し、さらにいくつかの筋書きの逆転に遭遇しました、この探索のプロセス自体は非常に啓発的である、記事と一緒に再訪しましょう。

消えたL1DA

オプティミズムのチャージバックの秘密を探った経験から、そもそもスタークネットがメインネットワークに提出したデータさえ見つかればいいのだと、当然のように思っていました。メインネットにデータを提出するStarkNetの契約は非常に重要なもので、一時期Etherscanのガス消費量リストのトップにあった契約を見つけるのは難しくないはずであり、一方、まだBlobに適応されていないScrollは、まだリストのトップをうろついている。

StarkNetを検索すると、Operator、Cisco、StarkNetというキーワードが見つかります。その後、Operator、Core Contract、Memory Page Fact Registryの3つの関連契約が見つかりますが、ストレージスペースに関連すると思われる3つ目の契約は、2年近く前に廃止されています。

そして、Operatorが残っています。は常にコア・コントラクトと相互作用し、常に最新の状態に更新します。

また、Blobを適応させる前と後に戻ってみると、Operatorの状態更新トランザクションは非常に単純なものでした。OperatorのUpdate Stateトランザクションは確かにアップグレードされたが、それらはすべて別のパケットを指すハッシュでしかなかった。より多くのGasを消費する後のupdateStateKzgDAでさえ、StarkNetの料金削減をまったく説明していない。

この後の更新は、Blob内のデータが対応するBatch内のパケットに対応することを証明するためのKZG多項式コミットメントに過ぎず、単なる「状態ルート」に過ぎません。このステート・ルートは、第2層のネットワークにおけるすべてのコントラクトの状態を記録する「台帳」に相当し、理論的には第1層のネットワークにも存在する。

そこで疑問なのは、なぜルートしかないのか、ということだ。あの分厚い小さな帳簿はどこに行ってしまったのだろうか？

最初の失敗の後の分析

最初の探求はあまり成功しなかったが、まだいくつかの推論や推測がある。MyFirstLayer2をご覧になった方なら、Rollupが探求している核心的な問題がDA問題（Data Availability）であること、そして彼らが用いている解決策は、データの可用性の問題を解決するために主要なデータをメインネットワークにアップロードし、誰もが必要なデータに簡単にアクセスできるようにすることであることを知っているはずです。

1. OP Rollupは、実際には、各トランザクションを圧縮されたパッケージでネットワークのある層にアップロードするシンプルで総当たり的な方法です。第二層の元帳の全体像を見ることで、トランザクションが正しく実行されたかどうかを確認することができます。

2. 一方、ZK Rollupは、トランザクションの詳細をすべてアップロードする必要はなく、ゼロ知識証明でステートディフ（各バッチのうちステートを変更した部分）のみをアップロードし、すべてのトランザクションが第2層で正しく実行されたことを確認します。また、複数の状態変更の結果をReplayすることで、L2元帳の全体像を復元することもできます。

また、ブロブ内のデータは第1層にとっては単なるバイナリテキストの文字列であり、第1層はその正当性を検証することなくブロブ内のデータの正確性を保護するだけであり、第1層のスマートコントラクトはブロブの内容を読み取って検証することはできないため、第1層がそれでもZK Proofを検証するのであれば、ZK Proofは第1層で使用できることが分かっています。したがって、ZK Proofがまだ1つのレイヤーで検証されている場合、ZK Proof自体をBlobに入れることはできないので、StarkNetは一定のコスト削減効果を持つことができ、各バッチのState diffをBlobに入れる必要がある。

そこで次の課題は、StarkNetがState diffをどこに置くかを明らかにすることです。以前はどこにあったのか、そしてBlobにあるのかないのか。

さらに、見つけるべき状態ルートが1つしかないという事実は、StarkNetがメインネットワークへの状態変更のアップロード方法を、ずっと前に独自のDAC（データ利用委員会）にひっそりと変更したのではないかと思わせます。もしそうだとしたら、スタークネットの法外な料金は完全に不当であり、......