在本文中，LXDAO的作者0xSamo透過對EtherScan進行靈活運用，對Starknet的鏈上核心組件、optimistic/zk rollup手續費結構、EIP-4844的blob機制、SHARP系統的費率進行了探索，向大家昭示了Starknet手續費下降99%的真相：坎昆升級降低DA手續費只是輔助原因，真實原因是Starknet發幣後國庫有了其他收入來源，不必再依賴於手續費創收，所以大幅度下調了L2 Gas Price基準。
前言
EIP-4844作為The Merge之後以太坊最大的升級，吸引了足夠的關注。這次升級引入的Blob臨時儲存空間，相當於為以太坊這列火車增加了側掛車廂，在不影響火車原有運行狀態的前提下，提供了更便宜的DA空間。
Optimism、StarkNet、Arbitrum等Layer2專案都在短時間內支援了EIP-4844，並獲得了顯著的降費效果，以下是LXDAO國庫在Optimism上為貢獻者發放工資時產生的交易，在EIP-4844前後的Gas費竟然相差了100倍。
但在驚喜的同時，我們發現StarkNet作為ZK Rollup的代表，居然也獲得了驚人的降費效果，從以前動不動就超過1美元的gas水準，下降到了0.01美元。
Starknet的手續費為何能降這麼多
OP Rollup與ZK Rollup對一層DA空間的需求不同
這兩者對DA空間的依賴程度是極為不同的。 OP Rollup會將近期交易的所有細節，包括用戶簽章等數據，打包壓縮後全部上傳到一層網路。它不需要在一層網路進行太多的驗算任務，幾乎所有的成本都在使用一層網路的DA空間上。
相比之下，ZK Rollup對上鍊的資料擁有更高的壓縮率。例如，它可以不上傳Layer2交易的數位簽名，僅依靠ZK Proof來確保交易有效；並且，ZK Rollup不需要打包所有交易細節，只需將狀態的變化結果打包上鍊。
舉個例子，在二層網路上，有100個用戶在USDC/USDT交易對進行了交易，每次交易後，資產合約裡的USDC、USDT的餘額都會改變。對OP Rollup來說，這些交易行為背後產生的DA數據，就是100筆交易、200個帳戶的400次餘額變動；
而對ZK Rollup來說， 資產合約共發生的200次變化，可以壓縮為2次最終的狀態總和變更，大幅減少了DA資料的體積。
ZK Rollup驗證ZKP消耗的額外Gas
了解了兩者差異之後，大家的第一印像也許是ZK Rollup的Gas費會比較低，但實操過的同學們應該都知道，在EIP-4844之前，StarkNet、ZkSync等ZK Rollup，其費用顯著高於OP Rollup，特別是StarkNet，因為採用了STARK演算法，其零知識證明的尺寸更大， 轉帳費用往往高於其他Layer2。
（2023年某時刻各L2費用表格）
ZK Rollup沒有一上線就將OP Rollup碾壓的原因很簡單：它雖然對交易數據有更高的壓縮率，節省了向一層傳輸數據的費用，但它要在一層網絡上驗證零知識證明，增加了計算費用。
Blob只能降低DA費用，對計算部分沒有太多幫助，相比於OP Rollup，ZK Rollup在EIP-4844上獲得的好處更少，所以當我們看到Starknet從手續費死貴的狀態，快速實現了美分等級gas費後，很難不讓人驚訝。
探索Starknet的手續費組成
ZK Rollup往往比OP Rollup更複雜。下圖是Optimism排序器向一層網路發布DA資料時，產生的交易記錄，任何人都能理解為什麼EIP-4844落地後，OP的交易費用下降了兩個數量級。
但在調查Starknet手續費來源時，本文作者經歷了相當大的困難，因為Starknet不同組件之間的互動關係要更為複雜。下面讓我們來重溯這整個流程。
消失的一層DA
因為有了探索Optimism手續費結構的經驗，我們很自然想到，找到Starknet向主網提交資料的合約地址就可以了，這種關鍵合約肯定在Etherscan的Gas消耗榜榜上有名，應該是不難找的，例如還沒適合EIP-4844的Scroll，其合約至今仍掛在Gas消耗榜的頂端。
當我們搜尋Starknet關鍵字之後，會在EtherScan上找到Operator、Core Contract、Memory Page Fact Registry3個相關元件，但第三個看起來和DA相關的合約，在接近兩年前就停止使用了。
目前我們可以看到Starkent的Operator不斷和Core Contract交互，不斷地呼叫「Update State」函數。
如果我們翻到坎昆升級啟動前後的鏈上記錄，會發現Operator的「Update State」行為確實產生了細節變化，首先函數名稱更改為「UpdateStateKzgDA」 ，其次，舊的狀態更新函數會向Core Contract傳送ProgramOutput、onchainDataHash和onchainDataSize，而新版函數中上傳的是ProgramOutput和KzgProof。
這裡的KzgProof，俗稱KZG承諾，扮演的角色類似Blob的datahash，和Blob中存放的資料有著對應關係。值得注意的是，新版本的狀態更新函數，消耗的gas比舊版本的更多。那麼問題來了，Starknet到底為何能夠把手續費降得這麼低？原因到底是什麼？
更多資料參考LXDAO旗下的Layer2科普網站MyFirstLayer2：
https://layer2.myfirst.io/zh#3.3-optimistic-rollup
第一次挫敗後的分析
雖然第一次探索不太成功，但我們仍然能得到一些推論和猜想。看過MyFirstLayer2的小夥伴一定知道Rollup的核心問題就是DA問題（數據可用性），而它們都是將關鍵數據上傳到主網，來解決數據可用性問題，這樣一來，所有人都能輕鬆訪問到需要獲取的數據。
-
我們回溯一下，OP Rollup簡單粗暴地把所有交易指令壓縮匯總，打包上傳到一層網絡，其他人可以下載這些壓縮後的數據，然後再解壓，Replay每一條交易來知曉二層網絡的狀態變更。
-
ZK Rollup則不需要上傳完整的交易細節，只需上傳State Diff（每個Batch執行前後的狀態變化量）。 ZKRollup由ZKP來確保State Diff是有效無誤的，其他人則可以直接在Prev_GlobalState之上疊加State Diff，知曉二層網路的最新狀態。
我們都知道，Blob裡的資料只是一串亂碼一樣的二進位文本，而一層網路只保證Blob資料上傳後不被某些惡意節點篡改，但不負責驗證這些資料的內容，當然，一層部署的智能合約也無法直接讀取Blob裡的內容。
因此，如果仍由一層來驗證ZK Proof，那ZK Proof肯定不能放在Blob裡，所以我們可以判斷，Starknet能夠有如此顯著的降費效果，與ZKP的關係不大，一定是因為State diff的存放位置變更所致。
下面的任務顯然就是確認，Starknet到底把State diff放在哪裡了？過去是放在哪裡的，現在究竟是不是放Blob裡面。
此外，只能在UpdateState函數的輸入參數裡找到一個StateRoot也不禁讓人懷疑，Starknet是否把原本應該直接上傳至主網的數據，改為發送至自己的鏈下DAC （數據可用性委員會）來，如果真的是這樣，那之前Starknet高昂的收費就完全沒有道理，只能解釋為…
SHARP系統
所幸和@0xYandhii 討論之後，讓我醍醐灌頂，Starknet在通用型主網上線之前，第一個產品其實是StarkEX，包括去中心化衍生品交易所dYdX也是那個時期的產物。
在主網上線後，原先的產品沒有被放棄，而是轉而與主網共享一個驗證器合約，即SHARP: Shared Proving and Verifying System系統，然後我們找到了SHARP Blockchain Writer、SHARP Verifier等相關合約。
開啟區塊瀏覽器查詢相關交易，可以發現SHARP Blockchain Writer進行了以下4類操作：
-
1. VerifyMerkle：驗證梅克爾樹
-
2. VerifyFRI：用於確保提交的資料或計算結果遵循特定規則，不需要揭示資料的原像。
-
3. Register Continuous Memory Page：疑似是向一層網路寫入資料時所呼叫的功能。
-
4. Verify Proof And Register：快則十分鐘被調用一次，慢則一兩個小時，應該是Starknet攢夠足夠大量的交易後，統一對這些交易的ZKP進行有效性驗證。
不難看出1、2、4是與ZKProof相關的函數，而第3個函數，顯然是向一層網路寫入資料的步驟，是最有可能與State diff上傳相關的功能。
我們推測，1、2、4三個函數的呼叫手續費，在Blob升級前後沒有顯著變化，而第3個函數的使用成本，應該顯著的降低了，這樣就能解釋Starknet為何降費效果如此顯著。
於是筆者繼續翻閱區塊瀏覽器，在EIP-4844前倒數第二個舊版本、倒數第一個版本，已經升級後的最新版本3個時段各取一個驗證週期，統計4個函數每次調用時，各自消耗的Gas究竟如何。
結果如下，令人撓頭。
第3個和數據發布相關的函數，其費用有下降一半，但從其在一整輪ZK Proof驗證過程中的費用佔比來說，這個DA費用下降水平證明不了我們前面提出的假設。
探索走到這裡幾乎就到了山窮水盡的一步，筆者感覺自己就像三體世界裡坐在大型粒子對撞機前的物理學家，每個腦細胞都在尖叫著：This doesn’t make sense !我甚至去Starknet社群發了一篇貼文詢問，但也許是因為問題太複雜，英文社群遲遲沒有人回應。
SHARP系統GasUsed探索
至此，我們還剩最後一個小Trick ，之前下載的交易數據csv裡面，只有Gas費消耗的ETH ，沒有GasPrice、Gaslimit等信息，所以無法排除Gas單價波動對統計結果的影響。於是筆者寫了腳本將之前涉及的每一筆交易實際消耗的GasUsed（Gaslimit 裡被使用掉的部分）統計了出來。
這次我們終於發現了端倪。可以看到在坎昆升級之前，那個名叫Register Continuous Memory Page的函數，在每次DA資料上傳時會觸發2次，一次消耗5萬的gas，另一次消耗30萬gas。
而坎昆升級之後，幾乎所有呼叫Register Continuous Memory Page函數的交易，都只消耗5萬gas。
之前我們取的樣本太少，正好那一次升級後，正是主網Gas費暴漲的時期，這影響了我們的統計結果，導致我們認為，Register Continuous Memory Page函數的調用成本，在坎昆升級前後都沒發生什麼變化，而當我們對統計數據進行更廣泛的採納時，很快就發現了問題所在。
依照這個思路我們重新整理了3 個時刻的GasUsed 數據，這回合理了許多。至此可以證實，與DA數據上傳相關的Register Continuous Memory Page函數，確實在坎昆升級後手續費顯著降低，這應該就是原本存放State Diff的步驟，而坎昆升級後，DA數據轉移至了Blob中。
後續我們在L2beat網站上找到了Starknet的產品結構示意圖，可以發現，State diff確實是透過上述函數來存放到以太坊鏈上的。
（圖源：L2BEAT）
最終，我們根據GasUsed的數量計算（以目前隨機抽取的較小樣本量來寬泛估計），得出結論：Starknet在坎昆升級之後，DA費用大概有4~10倍的變化，略低於一個數量級。
這也符合我們最開始的猜測：在EIP-4844升級後，ZK Rollup獲得的好處並不如OP Rollup那麼多。
總結
經過以上探索，我們終於理清了Starnet手續費大幅下降的原因，其結論還是有點耐人尋味。
DA費用大降，但解釋不了兩個數量級的降幅
可以明確，Starnet之前是把每個Batch中包含的狀態變化數據，直接上傳到一層網絡中的，現在則是將這部分數據放在了Blob中，因此可以在DA數據這部分手續費中，獲得略小於一個數量級的降費效果。
但該如何解釋Starknet手續費下降99%這個結果？單純靠DA降費顯然遠遠不夠。唯一合理的解釋就是：Starknet在坎昆升級前，確實「心黑」向用戶收取了太多手續費。在STRK發幣前，Starknet的所有活動、社區激勵都需要資金，除了燒投資人的錢之外，在向用戶收取的ETH和實際消耗的ETH之間設置剪刀差，可能是Starknet維繫運營的方式之一，這才使得先前Starknet的Gas費如此之高。
現在，STRK代幣發行為Starknet帶來了足夠的資金，是時候讓Gas回到合理的水準了，趁著坎昆升級把綁在腳上的沙袋一起拆下，展現出的降費效果確實驚艷了許多人。
Rollup歷史資料遺失問題
OP Rollup在升級之後，將原本儲存在交易Calldata裡的數據，轉移到Blob這個臨時儲存區後，其實犧牲了一點去信任性。
在先前，Calldata空間的數據是永久儲存的，這意味著任何人都能從以太坊主網下載到足夠的歷史數據，來驗證和同步OPR當前的狀態。
但坎昆升級之後，Blob的數據有過期淘汰的設定，如果全網沒有任何一個實體保存過去的Blob數據，那麼OPR的歷史交易記錄有可能會遺失。
雖然目前最新的二層網路狀態仍然能被保護－因為Blob的保質期超過OP的7-14天挑戰期，所以每個Blob在即將過期之前，它所對應的二層狀態仍然是可信的，這最新的十幾天的交易記錄滾動地維護著OPR的安全性。
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.h
[2] L2BEAT research team. Starknet[EB/OL]. [2024-04-16]. https://l2beat.com/scaling/projects/starknet?selectedChart=activity#contracts.