前言
EIP-4844 作為The Merge 之後以太坊最大的升級，吸引了全網足夠的目光。這次升級引入的Blob 臨時儲存空間，相當於在為以太坊這列火車增加了側掛車廂，在不影響火車原有運行狀態的前提下，提供了更便宜的數據可用性空間。
Optimism、StarkNet、Arbitrum 等Layer 2 網路都在短時間內支援了EIP-4844，並獲得了顯著的降費效果，以下是LXDAO 國庫在Optimism 上為貢獻者發工資的交易，前後的Gas 費竟然相差了100 倍。
但在驚喜的同時，我們發現StarkNet 作為ZK Rollup 的代表，居然也獲得了驚人的降費效果，從以前Gas 消耗動不動就超過1$ 的水平，也下降到了0.01$ 。
想了解更詳細的技術原理，歡迎大家進入MyFirstLayer2 學習。
註：MyFirstLayer2 是一個由以太坊基金會支持、LXDAO 發起的Web3 教育項目，旨在透過各種吸引人的教學方法，如文字、圖片、動畫和交互，幫助新人理解Layer 2的發展歷史和基本概念。
為什麼StarkNet 的降費令人感到驚訝？
OP Rollup 與ZK Rollup 對一層儲存空間需求的不同
因為OP Rollup 和ZK Rollup 對DA 費用（Data Availability：資料可用性，包含對資料的儲存和分發服務，以便讓第三方取得希望取得的資料）的依賴程度不同。
OP Rollup 將近期交易的所有細節，包括用戶簽名等訊息，打包壓縮後全部上傳到一層網路。它不需要在一層網路進行太多的驗算任務，幾乎所有的成本都在使用一層網路的儲存空間之上。
ZK Rollup 相比之下，對資料有更高的壓縮率。例如它可以拋棄用戶簽名數據，依靠零知識證明來確保交易合法；並且不需要打包所有交易細節，只需將狀態的變化打包上傳。
舉個例子，在二層網路上，有100 個用戶在USDC / USDT 交易對進行了交易，每次交易用戶以及Swap 合約裡的USDC、USDC兩種餘額都會發生變化。對OP Rollup 來說，就是100 條交易、200個帳戶的400 次餘額變動；而對ZK Rollup 來說，涉及用戶餘額變化部分的差異不大，但對Swap 合約來說，它的USDC、USDT 餘額共200 次的變化就可以壓縮為2 次最終餘額的變化，大大減少了資料體積。
ZK Rollup 驗證ZK Proof 消耗的額外Gas
在了解了兩者差異之後，大家的第一印像也許是ZK Rollup 的Gas 費會普遍比低，但實操過的同學們應該都知道，諸如StarkNet、ZkSync 等ZK Rollup 的L2，其費用往往是顯著高於OP Rollup 的，特別是StarkNet 的STARK 技術路線比其他SNARK 路線的ZK Proof 體積更大，在各L2 轉帳費用的排名裡常常處於墊底位置。
ZK Rollup 沒有一條上線就將OP Rollup 打得滿地找牙的原因很簡單，是因為它雖然對交易數據有更高的壓縮率，節省了向一層傳輸數據的費用，但它需要在一層網路上驗證零知識證明的合法性，增加了計算的費用。
而Blob 只能降低儲存部分的費用，對計算部分是沒有任何幫助的，因此ZK Rollup 能在EIP-4844 上獲得的好處是更少的，所以看到StarkNet 從排名倒數的「後進生」進步到與全班第一名第二名同一水平線上，很難不讓人驚掉下巴。
StarkNet 費用的探索
不得不說ZK Rollup 的機制要遠比OP Rollup 的複雜，例如透過Optimism: Batcher 合約在升級前後向主網打包資料的費用中，任何人都完全能理解為什麼它的交易費用下降了兩個數量級。
點選藍字了解更多：
升級前最後一筆舊Batch。
升級後第一筆新Batch（包含Blob 費用共0.0011 ETH）：
6 個Blob 的費用（總計0.00078 ETH）
但在探索StarkNet Gas 費用的過程中，筆者卻經歷了相當大的困難，甚至遇到了多次劇情反轉，這個探索的過程本身也極具啟發性，讓我們一起隨著文章來重溫一遍。
消失的L1DA
因為有了探索Optimism 降費秘密的經驗，我們很自然就想到，只需找到當初StarkNet 向主網提交數據的合約就可以了，這種重要合約肯定一度在Etherscan 的Gas 消耗榜榜上有名，應該是不難找的，還沒適配Blob 的Scroll 至今仍名列前茅掛在耀眼的頂端呢。
當我們搜尋StarkNet 關鍵字之後，會找到Operator、Core Contract、Memory Page Fact Registry 3個相關合約，但第三個看起來和儲存空間相關的合約，在接近兩年前就已經停止使用了。
於是我們只能看到Operator 不斷地和Core Contract 交互，不斷地更新最新的狀態。
而如果我們翻到適配Blob 的前後，發現Operator 的Update State 交易確實進行了升級，但都只是指向另一個資料包的雜湊。甚至於後來的updateStateKzgDA ，消耗的Gas 反而變多了，這完全不能解釋StarkNet 降費的原因。
後來的這個更新，只是一個KZG 多項式承諾，用來證明Blob 裡的資料和它對應的Batch 的資料包是對應的，也只是一個「狀態根（State Root）」。這個狀態根對應著記錄著二層網路所有合約所有狀態的“小帳本”，這個小帳本理論上也是存在於一層網路上的。
那麼問題來了，為啥只剩個根？那厚厚的小帳本上哪去了呢？
第一次挫敗後的分析
雖然第一次探索不太成功，但我們仍然能得到一些推論和猜想。看過MyFirstLayer2 的小夥伴一定知道Rollup 探討的核心問題就是DA 問題（數據可用性），而它們採用的方案都是將關鍵數據上傳到主網來解決數據可用性的問題，讓所有人都能輕鬆訪問到需要的數據。
-
OP Rollup 其實是簡單粗暴地把每一筆交易都壓縮打包上傳一層網絡，那麼其他人就可以通過解壓之後，Replay 每一筆交易來獲取到二層小賬本的全貌，以檢驗交易是否被正確執行。
-
ZK Rollup 則不需要上傳全部交易細節，只需上傳State Diff（每個批次狀態變化的部分）即可，由零知識證明來確保所有交易已經在二層被正確執行。而其他人則可以透過Replay 多次狀態變化的結果，來還原二層小帳本的全貌。
而且我們知道Blob 裡的數據對一層來說只是一串二進製文本，一層只保護Blob 裡數據的準確性而不驗證其合法性，一層的智能合約也無法讀取並驗證Blob 裡的內容，因此如果仍由一層來驗證ZK Proof，那麼ZK Proof 本身肯定不能放在Blob 裡，所以StarkNet 能夠有一定的降費效果，一定是把每個批次的State diff 放到Blob 中了。
所以我們下面的任務顯然就是搞清楚，StarkNet 到底把State diff 放在哪裡了？過去是放在哪裡的，現在究竟是不是放Blob 裡面了。
此外，只能找到一個狀態根的現實也不禁讓人懷疑，是不是很早以前StarkNet 就悄悄把向主網上傳狀態變化的數據，改為由自己的DAC （數據可用性委員會）負責了，如果真的是這樣，那之前StarkNet 高昂的收費就完全沒有道理，只能解釋為…
相關連結：
https://layer2.myfirst.io/zh#2.4-rollup
SHARP 系統
所幸和@0xYandhii討論之後迎來了新的曙光，StarkNet 在通用型主網上線之前，第一個產品其實是StarkEX，包括去中心化衍生品交易所DYDX 也是那個時期的產物。在主網上線之後，原先的產品沒有被放棄，而是轉而與主網共享一個驗證系統。
也就是SHARP: Shared Proving and Verifying System 系統，然後我們找到了SHARP Blockchain Writer、Starkware: SHARP Verifier 等相關合約。
開啟區塊瀏覽器查詢相關交易，可以發現SHARP Blockchain Writer 進行了以下4類操作：
-
Verify Merkle：驗證梅克爾樹
-
Verify FRI：Fast Reed-Solomon Interactive Oracle Proof of Proximity，用於確保提交的資料或計算結果遵循特定的規則或約束，而不需要揭示資料本身的內容。
-
Register Continuous Memory Page：在一個週期內上傳一百多次，註冊連續的記憶體空間，疑似是寫入資料到一層網路的部分。
-
Verify Proof And Register：一個週期一次，快則十分鐘，慢則一兩個小時，應該是攢夠足夠多的交易進行一個批次的驗證。
不難看出1、2、4 個步驟是與零知識證明相關的步驟，而第3 個步驟註冊記憶體空間顯然是向一層網路寫入資料的步驟，是最有可能存放State diff 的地方。
合理推測是那三個驗證步驟的費用在Blob 升級前後沒有顯著變化，而第3 個步驟的費用，應該能解釋StarkNet 前後兩個數量級的降費效果。
於是筆者繼續翻區塊瀏覽器，在EIP-4844 前倒數第二個舊版本、倒數第一個版本，已經升級後的最新版本3 個時期各取一個驗證週期，統計4 個步驟消耗的Gas 如何。
結果如下，令人撓頭。
內存費用有下降一半，但從其在一整輪ZK Proof 驗證過程中的費用佔比來說，這個DA 下降的水平說明不了任何問題。
探索走到這裡幾乎就到了山窮水盡的一部，筆者感覺自己就像三體世界裡坐在大型粒子對撞機前的物理學家，每個腦細胞都在尖叫著：This doesn’t make sense ! 我甚至去StarkNet 社群發了一篇貼文詢問，但也許是因為問題涉及太過複雜，英文社群也遲遲沒有人回應。
SHARP 系統GasUsed 探索
至此，我們還剩最後一個小Trick ，之前下載的交易數據csv 裡面，只有Gas 費消耗的ETH ，沒有Gaslimit 等信息，所以無法排除Gas 單價波動對統計的影響。於是筆者寫了腳本將之前涉及的每一筆交易實際消耗的GasUsed（Gaslimit 裡被使用掉的部分）統計了出來。
終於，曙光出現！可以看到在升級之前，註冊記憶體空間的交易其實是2 筆一組發送的，一筆Gas 是最低的5 萬，而另一筆一般在30 萬左右。
而升級之後，則幾乎所有的註冊記憶體交易都變成了5 萬的低消耗交易。
上一次的奇怪結論很可能是我們取的樣本太少，正好那一次升級後的驗證週期裡，趕上了大段的主網Gas 暴漲的時期，使得維持時間比較久的上百次Register Continuous Memory Page 交易都花了更高的Gas，讓統計出來的結果產生了偏差。
依照這個思路我們重新整理了3 個時刻的GasUsed 數據，這回合理了許多。至此可以證實Memory Page 確實在升級之後體積顯著縮小，這應該是存放State Diff 狀態變化數據的地方，而升級之後這部分數據則轉移至了Blob。
而後續我們在l2beat.com 上找到了StarkNet 的技術示意圖，可以發現State diff 確實如我們所料，是存放在Memory Page 中的。
那麼最終，我們根據GasUsed 的數量計算（以目前隨機抽取的較小樣本量來廣泛估計），實際對StarkNet 來說L1DA 的費用大概有4 – 10 倍的縮小空間，略低於一個數量級。這也符合理論推演：在EIP-4844 升級中，ZK Rollup 獲得的好處並不如OP Rollup 那麼多。
總結
經過以上的探索，我們終於釐清了StarNet 降費的原因與程度，其結論還是有點耐人尋味的。
L1DA 費用大降，但解釋不了兩個數量級的下降
可以明確StarNet 之前是把每一批狀態變化的資料寫入一層網路的，現在則是將這部分資料放在了Blob 中，因此在註冊記憶體空間的行為中可以獲得略小於一個數量級的降費效果。
但StarkNet 從之前倒數第一第二的水平，躋身到與OP 系尖子生們一個水平的降費效果，從相對進步程度來說甚至吊打了全體OP Rollup，這麼顯然是不可能的。
那麼唯一合理的解釋就是──之前確實「心黑」收太高了。在STRK 代幣發行之前，StarkNet的所有開發，社區激勵都需要資金，除了燒投資人的錢之外，設置更高的L2 L1 Gas 差價可能是他們維系開發的方式之一，才造成了此前StarNet令人尷尬的Gas 費局面。
而現在STRK 代幣發行為他們帶來了足夠的流動資金和生態激勵手段，也就是時候讓Gas 回到合理的水平了，趁著這波Blob 升級把綁在腳上的沙袋一起拆下，其展現出的降費效果確實驚艷了許多人。
ZK 的OP 化
OP Rollup 在升級之後，將原本儲存在以太坊主網Calldata 裡的資料轉移到暫存區之後，其實犧牲了一點點的安全性。
在先前，Calldata 空間的數據是永久儲存的，這意味著任何人都能從以太坊主網取得足夠的數據，來還原OP L2 上目前的所有狀態。
但升級之後，Blob 的數據將會過期，如果全網沒有任何一個實體保存過去的Blob 數據，那麼OP L2 的歷史交易記錄有可能會遺失。雖然目前最新的二層網路狀態仍然能被保護－因為Blob 的保質期超過OP 的7-14 天挑戰期，所以每個Blob 在即將過期之前，它所對應的二層狀態仍然是可信的，這最新的十幾天的交易記錄滾動地維護著OP L2 的安全性。
ZK Rollup 如果希望享受Blob 帶來的好處，同樣需要把重要的二層狀態數據，從永久的Calldata 空間轉移到Blob 空間。這意味著在一段時間後，我們也不再能像以前一樣，依靠一層網路提供的資料來Replay 二樓的狀態。
也許這將成為一種新常態，今後所有的二層網絡，都依靠Blob 維護最新狀態的安全，而每一條L2 也需要自己另外想辦法解決歷史交易資料的可用性，如此在安全與效率之間取得更好的平衡。
OP 與ZK 的融合趨勢
過去，第一代的OP Rollup 率先上線，而第一代的ZK Rollup 上線後沒有帶來更具競爭力的Gas 費用。到後續OP Stack、Polygon SDK 出現帶來的模組化風潮，OP Stack 甚至計劃在將來引入ZK 技術來降低挑戰期。
這無疑都指向一個事實：OP 與ZK 兩種技術路線並不是你死我活的競爭，他們會互相借鑒，有融合的趨勢，只不過這一次是「高貴」的ZK 向「簡單粗暴」的OP 學習的一次。
很難想像二層網路的技術在短短兩三年之間演化到如此的地步，也許這就是區塊鏈世界的魅力。
參考資料：
[1] FeedTheFed. Data availability with EIP4844[EB/OL]. (2024-02-11)[2024-04-16]. https://community.starknet.io/t/data-availability-with-eip4844/113065.
[2] L2BEAT research team. Starknet[EB/OL]. [2024-04-16]. https://l2beat.com/scaling/projects/starknet?selectedChart=activity#contracts.