calldata 壓縮實驗

來源| l2fees.info

作者| David Mihal

從2020 年起，以太坊的擴容路線圖已經以“rollup” 為方向：rollup 是一種使用證明（零知識證明或是optimistic 欺詐證明）來繼承以太坊安全性的獨立執行環境。

在經過多年的開發後，rollup 最終被部署到以太坊上並且逐漸得到採用。這項技術的佼佼者Arbitrum 的optimistic rollup 已上線近一年，它的橋接上存著價值27 億美元以上的資產，而緊隨其後的是Optimism。

我們已經能看到如Loopring 和dYdX 等應用專用型零知識證明rollup 有了大量的採用，並且有很多具有競爭性的通用型零知識證明rollup 會在接下來幾個月發布。

儘管rollup 領域擴容進展十分快速，但有人就費用還是過於高昂表達了擔憂。

事實上，Arbitrum 和Optimism 上的交易費依舊比Solana 和Polygon 等“低費用”鏈要高得多。

所以，是什麼阻礙了這些rollup?

為了了解交易費，我們首先需要分解一筆區塊鏈交易會產生的不同開銷：

執行開銷

這是網絡中所有的節點執行交易並驗證結果有效性所需的開銷（比如，驗證你確實持有要進行轉賬的代幣）。

狀態/儲存開銷

這是一個區塊鏈的“數據庫”更新數值的開銷（比如，在代幣轉出之後，發出者的餘額會減少而接收者的餘額會增多）。

數據可用性開銷

為了確保所有人都保持區塊鏈的去信任和可驗證，一條區塊鏈就必須確保與所有網絡的參與者公開共享交易的所有相關數據。

根本上，這是在保證處於這個世界的所有人都可以看見你的交易。沒有這些保證，可能會出現各種攻擊（所謂的數據扣留攻擊）。

我們會看到，數據可用性是當前區塊鏈的關鍵瓶頸之一。

rollup 主要的進展來自於將區塊鏈的執行和儲存轉至“鏈下”的能力，讓有限的節點群體來做執行和儲存。以太坊網絡中的每個節點不需要執行所有的交易或儲存每一次的更新數據，我們可以將這個任務委託給rollup 的運行者。

等等，信任一個小的運行者群體？這不是中心化的嗎？

好問題！

Rollup 旨在通過對各種證明類型的使用繼承以太坊一樣的安全性。 Optimistic rollup 考慮到單個誠實個體會舉報一個行為不當/作惡的定序者，讓他們提交“欺詐證明”並獲得獎勵，而ZK rollup 則使用零知識證明（翻譯：花式加密學）來證明L2 的鏈已進行了正確的更新。

將執行遷移出主鍊是考慮到大幅減少執行和狀態儲存開銷。然而，rollup 依舊必須將他們的數據發送至L1 的鏈上以保證數據可用性。

基本上，rollup 的支出很便宜：L2 有執行和儲存的開銷，但也必須支付其發送數據至L1 的費用。

這可以在區塊鏈瀏覽器ArbiScan 裡任何交易的“Advanced TxInfo” 標籤上看到。這個交易費被分解成發送calldata 至L1 的開銷、L2 上使用的計算開銷以及L2 儲存開銷。並且，幾乎在所有交易中，L1 的calldata 將會是費用的主要驅動因素。

簡單地說：發送數據至L1 是rollup 最主要的費用瓶頸。

當數據可用性成為了rollup 當前的瓶頸，我們期待它會隨著時間而得到緩解。

如Proto-Danksharding 和最終的完整Danksharding 等以太坊升級，將會大幅降低發送數據至以太坊的開銷。

此外，像Celetia 等項目旨在供給獨立的鏈，專門建來提供便宜的數據可用性。

長期來看，如Danksharding 和Celetia 等系統將會讓數據可用性變得低廉、豐富，數據可用性的瓶頸將會轉移到執行上。

但是，這些解決方案需要時間才能達到成熟的程度：距離Celetia 上線主網還有好幾個月，而在以太坊通過Proto-Danksharding 升級添加數據可用性之前，可能還需要一年以上的時間。

數據壓縮是一個比計算機更古老的領域！摩斯代碼發明於在1838 年，它是最早為人所知的數據壓縮案例。但是，計算機加速了數據壓縮的研究，如Huffman 編碼等算法在上世紀50 年代發明了出來。

由於rollup 的執行開銷非常便宜，但數據可用性開銷卻高昂，所以這些rollup 團隊一直致力於將數據壓縮算法集成至他們的協議也就不足為奇了。

Optimism 已將Zlib 的壓縮算法集成至自己的rollup 中，（閱讀更多關於他們篩選算法的過程），而Arbitrum 剛剛完成的Nitro 升級則是使用brotli 的壓縮算法。

請注意：這個實驗可能會在Nitro 發布之前匆忙推出的，以便在未壓縮的Arbitrum 的calldata 上進行實驗。 （請注意：這個實驗是在Nitro 升級發布前做的，現在升級已完成）?

數據壓縮算法在幫助減少calldata 的開銷上無疑是十分有用工具。可是，壓縮區塊鏈交易是一項艱難的任務：通過找到共同的模式並縮短它們從而進行數據壓縮工作。

然而，交易中充滿了地址、哈希和簽名，對於這些壓縮算法來說，這些數據本質上都是“隨機數據”。

當開發者開始留心如何最小化他們應用程序中的calldata ，它的開銷才會真的減少。 2020 年至2021 年的天價gas 費迫使開發者優化代碼，以將執行和狀態儲存的開銷減到最低限度。

因為我們過渡到一個L2 的世界，這裡的calldata 從最低廉的資源變成最昂貴的資源，所以開發者必須再次學習這些新的優化。

現在一起在Arbitrum 上做個實驗：我們可以將單筆代幣轉賬需要的calldata 壓縮到什麼程度？這些優化又能減少多少交易費？

我們也已經構建了一個簡單的UI，所以你可以自己試著做這個實驗：

（注意：你的錢包中必須有Arbitrum Dai、Arbitrum USDC、Arbitrum 測試網的Dai 或者Arbitrum 測試網的UNI)）

（譯者註：控制案例即對照案例，以下所做的實驗均以控制案例作為對照）

為了運行我們的實驗，我們將要構建一個簡單的智能合約，它會從一個交易發出者那轉出1 個代幣到任何地址。

這個智能合約樣本會要求用戶在可以發送真實的測試交易之前發送approve() 的交易。因為這個局限，任何用戶都不會真的想要用這個系統來轉賬代幣。

但是，實驗中使用的這項節約開銷的技術可以適用於其他合約（比如，一個優化過的Uniswap 路由器）。

為了開始這項實驗，我們會發送一筆“控制案例”交易從而得出一個開銷基準。這個交易會調用一個簡單Solidity 函數，傳達代幣地址、接受者地址以及代幣轉賬數量的信息。

我們的測試交易使用了576,051 ArbiGas，開銷為0.43 美元。

看看控制案例使用的calldata，我們可以看到這裡有很多不必要的數據可以剝離。

首先，將所有作為留白（padding）加入的0 字節刪除。 0 字節比非0 字節更便宜，但是它們還是會產生開銷，所以，讓我們一起刪掉它們。

開頭還有一個4 字節的函數簽名，這是我們想要調用的Solidity 函數的標識符。我們可以刪除這個數據，並讓我們的代碼簡單地推斷出我們想要採取什麼行動。

這兩個優化讓我們將字節碼從100 字節刪減至43 字節。我們的測試交易使用了494,485 字節（減少了14%），開銷為0.37 美元。

我們calldata 中的大部分數據由兩個地址組成：一個是我們將會轉出代幣的地址，另一個則是轉賬接收者的地址。

但我們可以設想，大多數用戶轉著相同的幾種類型的代幣（WETH、Dai、USDC）。我們可以從calldata 中刪除整個代幣地址的方式是為所轉的代幣部署一個特殊的“helper” 合約。

現在我們可以發送交易給這個helper，完全避免了打包代幣地址的需要。

這讓我們可以將數據字節碼減少至23 字節。我們的測試交易使用了457,546 字節（比控制案例減少了21%），開銷為0.34 美元。

實驗的上一個階段是使用“helper 合約”以刪除calldata 中一個地址，但是還有另一個地址在我們的calldata 中。

那麼，還有其他技術可以更持續地用於“壓縮”地址嗎？

幸好，Arbitrum 有一個內置合約稱作“Address Table Registry”（地址表登記），我們可以用它來縮減自己的calldata。

本質上，這個合約是一本“電話簿”，將20 字節的以太坊地址映射為簡單的整數。

想像一下，你的朋友有一本早期風格的電話簿：你不用將整段電話號碼讀出來給他們，只需要告訴他“我的號碼是電話簿第200 頁的第4 個號碼”，然後讓他們查找你的號碼。

所以我們能做的就是製作一份合約，它會接收“地址索引”來替代完整的地址，然後在內部查找完整的地址。

通過替換“代幣”地址和“接受者”地址，我們可以將calldata 減少至9 字節。

我們的測試交易使用了428,347 字節（比控制案例減少了26%），開銷為0.32 美元。

最後，讓我們一起結合所有的技術：

• 刪除補白和函數選擇器

• 使用已確定的helper 合約以刪除共同的地址

• 使用Arbitrum 的地址表縮短其他地址

總而言之，我們的calldata 大小現在只有6 字節！最後的測試交易使用了426,529 字節（也是比控制案例是減少了26%，稍微低於前一個測試案例），開銷為0.32 美元。

我們所涵蓋的壓縮技術已經成為了“無損壓縮”的案例，即壓縮後輸出數據包含著與所有原本輸出一樣的數據。

但就像照片和視頻文件使用“有損壓縮”算法來刪除不必要信息一樣，我們同樣可以刪除大多數案例中的不必要數據。

它的第一個例子應該是縮短數字以去除不必要的精準性。比如，一般ERC-20 代幣會精確到小數點後的18 位數，但多數用戶只在乎小數點後的4 位數左右。我們可以構建一個合約，它會默認接受小數點後的8 位數並乘以10^10，並為需要更多精準度的用戶提供一個輔助的函數。

同樣地，日期一般顯示為“自1970 年1 月1 日後的秒數”（也稱為Unix 時間）。合約可以採納分鐘、小時或者天數的時間單位以減少這個日期整數的大小，它們也可以設置自己的“epoch”，比如自2015 年1 月1 日起的epoch。

總結：calldata 已經從以太坊L1 上最便宜的資源，變成以太坊rollup 最昂貴的資源。像Proto-Danksharding 和Celetia 等數據可用性技術最終將會緩解這種價格瓶頸，但兩個項目都還沒有發布，數據可用性很可能還需要幾年的時間才能變得便宜和豐富。

因此，區塊鏈開發者需要留心他們的交易所需的calldata 數量，因為這些會極大地影響終端用戶的交易費。

這篇文章強調了很多可以用於減少calldata 的技術，然而，隨著“optimizooors” 把焦點轉向L2，我希望會有更多技術推出。

點擊“閱讀原文”獲取文章內部鏈接！

原文鏈接：https://l2fees.info/blog/rollup-calldata-compression

ECN的翻譯工作旨在為中國以太坊社區傳遞優質資訊和學習資源，文章版權歸原作者所有，轉載須註明原文出處以及ETH中文站。若需長期轉載，請聯繫eth@ecn.co進行授權。