超越去重與壓縮：合約代碼存儲空間可進一步減少 30%

我的初步研究顯示，在合約去重（deduplication）和存儲時壓縮代碼的基礎上，合約代碼的存儲空間還有望進一步減少 30%。

Solidity 編譯器以及所有其他編譯器，必然會生成帶有操作碼（opcode）模式的字節碼。當壓縮單個合約時，理想的壓縮算法會在這些模式於該合約中出現一次後學習到它們，隨後在合約的其餘部分以縮寫方式引用。

然而，這意味著壓縮算法對於單個合約中首次出現的模式總是感到「驚訝」，因為算法不知道這些模式在許多智能合約中都很常見，因此只能從它正在處理的單個合約中學習。

大多數壓縮算法庫都內置了針對此問題的解決方案——你可以提供一個預先訓練的小型「字典」，其中編碼了在歷史數據中已見過的常見模式。這使得新數據中的常見模式在第一次出現時就能立即被壓縮。

第二個好處是，當使用預訓練字典時，它還能記住那些過度代表的垃圾（spam）合約中的大型模式。對於那些被重複發布數萬次且僅有微小變化的垃圾合約，字典可以將其縮減至原始大小的個位數百分比。

以下是結果：

使用截至 2025 年初部署的所有合約字節碼的 zelliac 數據集，共有 1,539,858 個去重後的已部署字節碼集。

使用 Zstandard 壓縮庫的默認快速壓縮級別（級別 3），並對每個獨立的字節碼集進行壓縮，總大小從原始的 100% 降至 41.8%。加入一個 100KB 的字典（以默認壓縮級別設置進行訓練），字節碼佔用的空間降至原始大小的 29.3%，這比單純壓縮後的大小又減少了 30%。

增加壓縮字典的大小或提高壓縮級別可以進一步縮小最終大小。我將其保持在針對速度優化的狀態。通過進一步調整字典訓練參數，很有可能獲得更小的體積。

不同大小的合約字節碼所需的總存儲空間：

所有合約中從最差到最好的表現：

最後說明：

• 如果在客戶端中使用此方案，我預計會存儲一個字節來標識合約是否被壓縮，以及使用了哪個字典/算法。這將允許未來平滑升級到更好的字典，同時避免壓縮那些壓縮後反而變大的文件。

• 我使用 zstandard 作為壓縮庫純粹是因為我過去對它有良好的使用經驗。目前我尚未比較不同的壓縮庫或算法。

        1 則貼文 - 1 位參與者
  
        [閱讀完整話題](https://ethresear.ch/t/30-reduction-in-stored-contract-code-size-beyond-deduplication-and-compression/24659)