Gas Golfing

什麼是 Gas Golfing？

Gas golfing 是一種透過對智能合約程式碼進行小幅且精準的修改，降低其 Gas 消耗量的做法。

這個詞源自 code golf，這是一種程式設計挑戰，開發者會嘗試用盡可能少的原始碼解決問題。

在加密貨幣開發中，目標不一定是寫出最少的字元。

目標是產生消耗較少區塊鏈資源的位元碼，同時保留合約所需的行為。

Gas golfing 最常見於 Ethereum，以及透過 Ethereum Virtual Machine 執行智能合約的其他網路。

開發者可透過減少儲存操作、簡化計算、縮短還原資料、避免不必要的記憶體複製，或選用成本較低的 EVM 指令，為合約進行 Gas golfing。

Gas golfing 通常著重於微幅最佳化，而非徹底重新設計應用程式。

因此，Gas golfing 的範圍比一般 Gas 最佳化更窄。一般 Gas 最佳化可能涵蓋合約架構、交易批次處理、部署至 Layer 2、應用程式設計及鏈下運算。

成功的 Gas golfing 修改必須維持安全性、正確性、可讀性與相容性。

若修改會造成漏洞，或使合約難以安全維護，即使能省下少量 Gas，也不值得採用。

為什麼稱為 Gas Golfing？

Golfing 一詞指的是追求較低分數的目標。

在傳統高爾夫球運動中，擊球次數越少越好。

在智能合約 Gas golfing 中，只要最佳化後的程式碼能安全地執行相同任務，通常 Gas 用量越低就越理想。

開發者可能會比較兩種實作方式的部署 Gas、執行時 Gas、位元碼大小，或合約預期生命週期內的總成本。

Gas golfing 挑戰可能要求參與者以最低 Gas 用量實作某個函式。

實際的正式環境開發更為複雜，因為 Gas 用量最低的方案未必最安全，也未必最容易稽核。

這是非正式用語，並非指 Ethereum 協議、代幣、交易類型或官方程式設計標準。

Gas Golfing 的運作方式

Ethereum 會為 Ethereum Virtual Machine 執行的每項操作指定 Gas 成本。

官方Ethereum Gas 文件說明，Gas 用來衡量執行交易與智能合約操作所需的運算量。

算術運算、記憶體使用、持久儲存、事件紀錄、合約呼叫、合約建立，以及交易資料都會影響 Gas 消耗量。

Gas golfing 會尋找成本較低、但能產生相同必要結果的操作序列。

例如，開發者可能將多次讀取儲存資料改為只讀取一次，並將讀取的值存入區域變數重複使用。

另一位開發者可能會以精簡的自訂錯誤取代冗長的 revert 字串。

使用較低階方法的開發者，可能會以專為記憶體複製設計的 EVM 指令，取代手動編寫的記憶體複製迴圈。

最終改善效果必須以編譯後的位元碼測量，因為 Solidity 程式碼視覺上較短，不代表 EVM 執行成本一定較低。

Gas Golfing 與 Gas 最佳化的差異

Gas 最佳化是降低智能合約部署與執行成本的廣泛流程。

Gas golfing 是較狹義的最佳化形式，通常著重於程式碼層級的小幅節省。

完整的 Gas 最佳化專案可能會重新設計應用程式的儲存模型、將適合的運算移至鏈下、使用 Layer 2 網路，或減少每位使用者需要執行的交易數量。

Gas golfing 則可能比較兩種迴圈結構、兩種錯誤處理方式，或兩種載入相同值的方法。

架構層級的最佳化通常能帶來比微幅最佳化更大的節省。

不過，若某項小幅節省會反覆發生，在函式執行數百萬次時仍可能相當可觀。

專業開發者應先從架構層級移除不必要的工作，再針對剩餘重要執行路徑進行 Gas golfing。

Gas Golfing 與 Code Golf 的差異

Code golf 著重縮短原始碼，通常不會優先考量可讀性或長期維護。

Gas golfing 則著重降低區塊鏈執行成本。

最短的 Solidity 表達式，編譯後可能比更長且清楚的表達式產生更多指令。

編譯器最佳化也可能將多種不同的原始碼風格轉換成完全相同的位元碼。

因此，開發者應比較編譯輸出與實際測得的 Gas，而非計算原始碼字元數。

Code golf 解法或許有趣，但不適合用於控制高價值加密貨幣的合約。

正式環境中的 Gas golfing 應一律包含安全測試、文件與審查。

Gas Golfing 與降低 Gas 價格的差異

Gas golfing 會減少交易消耗的 Gas 單位數。

它不會直接降低每個 Gas 單位的市場價格。

交易手續費可表示為 Gas Charged × Effective Gas Price。

Gas golfing 修改的目標是這個公式中的 Gas Charged 部分。

網路需求、協議基本費用，以及使用者的優先費用會影響有效 Gas 價格。

即使合約已高度最佳化，網路嚴重壅塞時仍可能需要較高成本才能使用。

最佳化不佳的合約，即使 Gas 價格暫時較低，仍可能浪費資源。

開發者為何進行 Gas Golfing？

若智能合約函式經常被呼叫，Gas golfing 可降低每位互動使用者支付的成本。

較低的交易成本可提升去中心化金融、代幣轉帳、區塊鏈遊戲、NFT 操作與治理系統的可及性。

若最佳化能減少初始化工作或執行時位元碼大小，Gas golfing 也能降低合約部署成本。

自動化加密貨幣策略可能特別重視微幅節省 Gas，因為交易手續費會直接降低預期報酬。

即使每項改善都很小，會反覆執行大量內部操作的協議仍可能節省可觀成本。

降低 Gas 用量也能為其他交易釋出更多區塊容量。

不過，最佳化應以預期使用情況為依據，而非為不切實際的測試案例追求最低基準數值。

進行 Gas Golfing 前先測量

開發者在嘗試微幅最佳化前，應先測量 Gas 用量。

現有編譯器可能已移除看似不必要的操作。

在較舊 Solidity 版本中能降低 Gas 的修改，在目前的編譯器上可能毫無效益。

另一項修改可能降低執行時 Gas，卻增加合約部署成本。

Gas 測試應涵蓋使用者最常執行的函式。

測試也應涵蓋最小輸入、支援的最大輸入、成功執行及失敗路徑。

Solidity 編譯器文件介紹編譯器輸出選項與 Gas 估算。

若迴圈、外部呼叫或動態區塊鏈狀態會影響執行，編譯器估算可能不完整。

因此，開發者應結合編譯器輸出、實際交易測試與執行追蹤進行評估。

使用最新的 Solidity 編譯器

Solidity 編譯器會定期推出版本更新，加入最佳化、EVM 支援、語言功能與安全性修正。

官方的Solidity 0.8.36 版本公告指出，0.8.36 是 2026 年 7 月的最新版本。

此版本包含安全性修正，並進一步改進實驗性的 SSA 形式程式碼產生流程。

以某個編譯器版本得出的 Gas golfing 結果，可能與其他版本的結果不同。

開發者應固定正式環境建置所使用的編譯器版本、最佳化設定、EVM 目標與依賴項版本。

部署高價值加密貨幣合約前，也應檢視Solidity 編譯器官方錯誤清單。

若只為降低 Gas 而更新編譯器，卻未重新測試整個應用程式，可能會導致非預期行為或位元碼差異。

手動 Gas Golfing 前先使用 Solidity 最佳化器

Solidity 最佳化器可簡化表達式、移除重複操作、合併計算並縮減位元碼大小。

官方的Solidity 最佳化器文件說明，最佳化可同時降低部署大小與執行成本。

手動進行 Gas golfing 時，應將最佳化器已執行的工作納入考量。

兩個外觀不同的 Solidity 函式，最佳化後可能編譯成相同位元碼。

最佳化器的 runs 設定會影響部署程式碼較小與重複執行成本較低之間的取捨。

較低的 runs 值通常較重視部署大小。

較高的 runs 值通常較重視重複執行時的成本。

最適合的設定取決於合約部署頻率及各函式的呼叫頻率。

開發者應比較多種經過測試的設定，而不是未經測量便沿用傳統數值。

快取重複讀取的儲存資料

讀取持久儲存資料，通常比使用 EVM 堆疊或記憶體中已有的值更昂貴。

常見的 Gas golfing 技巧之一，是將儲存值讀入區域變數一次，之後重複使用。

根據 EIP-2929，Ethereum 對冷存取與暖存取採用不同成本。

交易中首次存取某個儲存槽，通常比後續再次存取同一儲存槽更昂貴。

若合約已有正確的區域副本，即使是暖存取，也可能可以省略。

開發者也可在本機計算最終結果，再寫入一次儲存資料，而非逐一寫入每個中間值。

若外部呼叫可能在快取值再次使用前改變相關狀態，快取就不安全。

採用此技巧前，必須考量重入、回呼、委派呼叫與繼承行為。

減少儲存寫入

寫入持久狀態是智能合約中常見且成本最高的操作之一。

若要求寫入的值與現有儲存值相同，合約應避免寫入。

若資訊可從現有狀態安全推導，合約應避免記錄該資訊。

在某些情況下，可用單一累計索引或帳務檢查點表示多個相關值。

函式也可先在本機進行計算，最後只將結果寫入儲存資料。

與重寫小型算術表達式相比，這些修改通常能帶來更大的節省。

開發者必須確認，簡化後的狀態模型仍能正確支援餘額、權限、歷史帳務與升級。

打包儲存變數

Ethereum 將合約儲存空間劃分為 32 位元組的儲存槽。

若變數的順序與合併大小允許，Solidity 可將多個較小的值類型變數打包至同一儲存槽。

Solidity 儲存配置文件說明變數的配置與打包方式。

在適當情況下，減少所需的儲存槽數量可降低部署與執行時 Gas。

分開儲存較小的整數類型，不會自動節省 Gas。

EVM 通常以 256 位元字組進行算術運算，因此較小類型可能需要額外的遮罩或轉換操作。

若打包的值通常會一起存取或變更，打包方式最能發揮效益。

可升級合約部署後不得重新排列儲存變數，否則新的配置可能會錯誤解讀既有資料。

使用常數與不可變值

若一般狀態變數必須從持久狀態讀取，就會產生儲存成本。

編譯時已知的值可宣告為

。

在建構期間選定、部署後固定不變的值可宣告為

。

Solidity 合約文件說明，這些值不會像可變狀態變數一樣使用一般儲存槽。

永久地址、數學常數與固定設定上限，都是常見的適用對象。

若應用程式確實需要經授權的更新流程，就不應將該值設為不可變。

為節省 Gas 而移除必要的設定彈性，可能造成昂貴或危險的營運限制。

唯讀輸入使用 Calldata

外部函式輸入若不需要修改，通常可保留在

中。

使用 calldata 可避免將大型字串、位元組序列、陣列或結構複製到記憶體。

Solidity 資料位置文件說明 calldata、memory、storage 與 transient storage 之間的差異。

此技巧最適合用於函式只讀取的動態外部輸入。

若合約必須修改值或建立新的記憶體資料，仍需要使用 memory。

開發者也應移除不必要的交易輸入，因為 calldata 位元組會增加固有 Gas 成本。

以更精簡的方式編碼值可能節省 calldata Gas，但比較時也必須計入解碼運算。

使用自訂錯誤

與冗長錯誤字串相比，自訂錯誤可減少合約位元碼與還原資料成本。

自訂錯誤使用精簡的 4 位元組選擇器，也可包含結構化參數。

官方的Solidity 自訂錯誤文件指出，自訂錯誤是有效率的錯誤回報方式。

例如，錯誤可包含呼叫者地址與所需餘額，而不必將冗長句子嵌入執行時位元碼。

自訂錯誤不會讓成功執行路徑變成免費，因為合約仍須檢查條件。

錯誤訊息仍應清楚易懂，讓錢包、介面、稽核人員與開發者能診斷失敗的加密貨幣交易。

利用短路求值排列條件

Solidity 的布林表達式在結果已確定時可以提前停止求值。

使用邏輯 AND 的表達式，遇到第一個 false 條件後即可停止求值。

使用邏輯 OR 的表達式，遇到第一個 true 條件後即可停止求值。

若便宜的條件經常足以決定結果，將其排在昂貴條件之前，可能降低平均 Gas 用量。

採用此技巧時，應保留預期的邏輯行為，並考量可能還原或產生副作用的函式。

若條件順序會影響安全性或錯誤回報，不應盲目重新排序。

謹慎最佳化迴圈

迴圈處理大量元素時，可能消耗大量 Gas。

若集合在迴圈執行期間不會變動，開發者可快取重複存取的陣列長度。

也可快取每次迭代都會使用的儲存值。

若數學上可確定不會溢位，迴圈計數器可使用

遞增。

現代編譯器已能最佳化部分常見的遞增模式，因此必須使用選定的編譯器測量節省幅度。

「前置遞增一定比後置遞增便宜」這種常見說法，並非適用於目前最佳化 Solidity 程式碼的可靠通則。

對持續成長的儲存集合執行無界迴圈，是架構問題，而非小幅 Gas golfing 的機會。

大型工作負載應分割成有界批次，或重新設計為由使用者各自處理獨立狀態。

只有在證明安全時才使用 Unchecked 算術

Solidity 0.8 及更新版本通常會檢查整數算術是否溢位或下溢。

這些檢查會消耗一些 Gas，但可避免重要類型的程式錯誤。

區塊會移除其中操作的自動檢查。

若數學界限已證明不可能溢位，在這類情況中使用 unchecked 可節省 Gas。

有界迴圈計數器是常見例子，但具體安全論證仍取決於迴圈設計。

不應只因為預期輸入通常很小，就使用 unchecked 算術。

程式碼應包含測試與清楚文件，說明所有可能輸入為何都能維持安全。

以 Transient Storage 儲存暫時狀態

Transient storage 提供以單筆交易為範圍的狀態，交易結束時會自動清除。

Ethereum 透過 EIP-1153 引入

與 操作。

若資料需要在多次呼叫間使用、但不需要跨交易保留，Transient storage 可能比持久儲存更便宜。

重入鎖是交易範圍資訊的常見例子。

Transient storage 無法取代後續交易仍需使用的持久餘額、所有權、債務或設定資料。

開發者必須了解暫時狀態在呼叫、委派呼叫與還原中的行為。

以成本較低的 transient 實作取代經驗證的安全控制，必須經過完整測試與審查。

使用現代 EVM 指令

Ethereum 升級可能引入新指令，取代成本較高的舊操作序列。

EIP-3855 引入

，可透過精簡指令將 0 放入堆疊。

EIP-5656 引入專門用於複製記憶體的操作

。

選擇正確的 EVM 版本後，目前的 Solidity 編譯器可自動使用支援的 EVM 指令。

通常不應只為了強制使用某一指令，就以手寫組合語言取代編譯器產生的程式碼。

若合約以較新的 EVM 目標編譯，可能無法在尚未啟用所需指令的網路上執行。

因此，Gas golfing 結果必須標明測量所用的確切編譯器與 EVM 目標。

減少外部呼叫

外部合約呼叫會產生帳戶存取、參數編碼、回傳資料處理，以及被呼叫合約執行等成本。

若多次呼叫會在單筆交易中回傳相同值，合約可避免重複呼叫以節省 Gas。

有時可將數次相關讀取合併成一次呼叫，並回傳結構化結果。

不過，改變呼叫結構可能影響重入、錯誤處理、可組合性與合約邊界。

仍須正確檢查回傳值與成功條件。

若呼叫雖然便宜，卻導致不安全的假設，就不算有效的最佳化。

適當情況下以事件取代儲存資料

若資訊僅供鏈下應用程式使用，事件紀錄通常比持久儲存便宜。

事件可用於支援交易歷史、分析、活動動態與使用者介面通知。

後續的智能合約執行通常無法搜尋歷史事件紀錄。

因此，餘額、權限、所有權、抵押品及其他可執行的狀態，仍必須讓合約存取。

只有在未來鏈上決策不需要讀取已移除的儲存值時，才適合透過事件進行 Gas golfing。

設計事件時，開發者也應考量索引事件主題與紀錄資料的成本。

縮減部署位元碼

部署期間儲存合約執行時位元碼時，Ethereum 會收取 Gas。

移除未使用的函式、重複邏輯、冗長的還原字串及不必要的嵌入資料，可降低部署成本。

自訂錯誤、內部函式庫、共用實作，以及經過謹慎設定的編譯器最佳化，可能有助於縮減程式碼大小。

根據 EIP-170，Ethereum 對一般部署的執行時程式碼設有上限。

初始化程式碼則依 EIP-3860 分別計量並設有上限。

合約較小不代表整個生命週期的成本一定較低，因為將程式碼拆分到多個合約可能增加重複的外部呼叫成本。

開發者應同時評估部署成本與反覆執行成本。

了解 Gas 退款的限制

較早期的 Ethereum Gas golfing 策略有時高度仰賴建立後再刪除儲存資料。

目前的 Ethereum 規則已大幅限制這種做法。

EIP-3529 降低了清除儲存資料的退款、移除過去

的退款，並將可套用的退款上限設為總 Gas 用量的 20%。

合約不應為了日後取得相同或更多退款而建立不必要的狀態。

Gas 退款會在執行後套用，無法避免因 Gas 耗盡而導致的失敗。

也不是現代的 Gas golfing 技巧，因為它不再提供退款，且其刪除行為已受到限制。

Calldata Golfing 與 EIP-7623

開發者有時會透過精簡類型、位元打包、自訂編碼或較短表示法，為交易輸入進行 Gas golfing。

減少交易位元組數可降低固有 Gas，尤其是在移除大量重複值時。

不過，Pectra 已啟用 EIP-7623，針對資料量大但執行量相對少的交易設定較高的 Gas 下限。

精簡格式所需的解碼操作也會消耗 Gas。

大量重複工作負載可能因自訂編碼而降低成本，但小型交易未必受益。

非標準編碼可能增加錢包、稽核、整合與除錯的難度。

開發者應依目前協議規則，對完整編碼與解碼流程進行基準測試。

何時適合使用 Inline Assembly？

Inline assembly 可讓開發者直接控制 EVM 指令、記憶體、儲存資料、呼叫與回傳資料。

若高階 Solidity 無法有效表達特殊操作，組合語言可能帶來 Gas 節省。

常見考量情境包括加密程序、精簡資料解析、特殊記憶體操作，以及大量重複執行的低階函式。

但它也會繞過 Solidity 提供的許多類型、記憶體與安全性保護。

組合語言錯誤可能破壞記憶體、錯誤編碼資料、處理不當的回傳值，或導致加密貨幣遭竊。

每個組合語言實作都應與清楚的高階參考實作比較。

測試應確認一般輸入、邊界輸入、惡意輸入與還原情況下的行為一致。

Gas Golfing 何時會變得危險？

當 Gas 成本的重要性凌駕合約安全性與清晰度時，Gas golfing 就會變得危險。

為節省 Gas 而移除存取控制檢查，可能讓未授權使用者控制合約。

移除重入防護，可能使餘額暴露於重複外部呼叫的風險。

移除滑點限制或期限，可能使使用者面臨不利的加密貨幣交易結果。

將多個值合併至一個打包字組，可能造成位元遮罩與轉換錯誤。

以自訂格式取代標準編碼，可能造成簽章、重放或解析漏洞。

若一項最佳化只節省 100 Gas，卻帶來使用者資金可能損失的風險，就沒有實際價值。

已過時的 Gas Golfing 建議

Solidity 與 EVM 改變後，Gas golfing 建議可能會過時。

編譯器可能開始自動最佳化過去必須手動改寫的程式模式。

網路升級可能改變操作碼成本，或新增效率更高的指令。

在目前的 Ethereum 上，使用

取得退款的舊建議已不再適用。

某種遞增方式一定較便宜的說法，可能不適用於現代最佳化位元碼。

若沒有進行儲存打包，使用非常小的整數類型可能不會節省 Gas。

採用任何 Gas golfing 技巧前，開發者都應要求提供最新基準測試與可重現的編譯器設定。

如何評估 Gas Golfing 修改

最佳化後的實作必須先確認能產生與原始實作相同的必要行為。

開發者應比較部署 Gas、成功路徑 Gas、失敗路徑 Gas，以及預期生命週期總成本。

應記錄測試使用的編譯器、最佳化設定、EVM 版本與區塊鏈狀態。

單元測試應驗證一般函式行為。

模糊測試應探索非預期輸入與邊界條件。

不變量測試應確認重要的帳務與安全性屬性仍然成立。

執行追蹤應確認節省來自預期操作，而非意外略過必要流程。

人工審查者應判斷修改後的程式碼是否仍易於理解與維護。

正式合約中的 Gas Golfing

正式合約中的 Gas golfing 應著重於經常使用的函式，以及經測量確認的瓶頸。

若某個函式執行數百萬次，即使每次只節省少量 Gas，也可能值得投入心力實作。

若類似的節省只出現在一次性的管理函式中，可能不值得以增加複雜度為代價。

除非最佳化屬於規劃中的協議升級，否則公開介面與預期行為應維持穩定。

可升級合約必須維持原有儲存配置與授權模型。

進行重大低階最佳化後，高價值合約應接受獨立的安全性審查。

已部署的位元碼應能依已發布的原始碼與建置設定重現。

常見的 Gas Golfing 錯誤

常見錯誤之一是比較原始碼長度，而非編譯後的 Gas 用量。

另一個錯誤是測試時沒有啟用正式環境使用的相同最佳化設定。

開發者可能只測量成功交易，忽略成本特別高的還原路徑。

他們可能最佳化很少使用的函式，卻忽略每筆交易都會重複執行的儲存寫入。

他們可能使用較小的整數類型，卻沒有取得任何儲存打包效益。

他們可能尚未確認編譯器產生的程式碼確實昂貴，就以組合語言取代清晰的 Solidity 程式碼。

他們可能依賴已無法反映目前 EVM 的舊 Gas 費用表。

最嚴重的錯誤，是沒有證明最佳化版本具備相同且安全的行為，就接受較低的 Gas 結果。

常見問題

簡單來說，什麼是 Gas golfing？

Gas golfing 是透過小幅程式碼修改降低智能合約的 Gas 用量，同時不改變預期行為。

Gas golfing 和 Gas 最佳化一樣嗎？

不一樣。Gas golfing 通常是範圍較窄的微幅最佳化；Gas 最佳化也涵蓋架構、儲存設計、鏈下運算、批次處理與網路選擇。

Gas golfing 是 Ethereum 協議功能嗎？

不是。這是開發者使用的非正式用語，並非官方操作碼、交易類型或 Ethereum 標準。

Solidity 程式碼越短，Gas 用量一定越低嗎？

不一定。原始碼長度無法可靠預測編譯後 EVM 位元碼的大小或執行成本。

Solidity 最佳化器可以自動進行 Gas golfing 嗎？

最佳化器會執行許多類似轉換，但開發者仍須設計有效率的儲存、資料流與合約架構。

最有效的 Gas golfing 技巧是什麼？

最有價值的技巧通常取決於合約本身，不過減少重複存取儲存資料，通常比修改小型算術表達式更有幫助。

較小的整數一定比較便宜嗎？

不一定。只有在較小整數能讓多個值共用同一儲存槽時，通常才最有用。

Calldata 一定比 memory 便宜嗎？

對唯讀外部輸入而言，calldata 通常較便宜，因為不需要複製資料；但正確位置仍取決於資料的使用方式。

自訂錯誤為什麼有助於 Gas golfing？

自訂錯誤使用精簡的選擇器與參數，不必嵌入並回傳冗長的 revert 字串。

快取儲存值一定能節省 Gas 嗎？

若值在使用期間仍然有效，快取可能節省 Gas；但若外部呼叫可能改變狀態，快取就可能不安全。

Unchecked 算術是一種安全的最佳化嗎？

只有在開發者能證明所有可能輸入都不會溢位或下溢時，才是安全的。

Gas golfing 應該使用 Inline Assembly 嗎？

Inline assembly 應限於經測量確認的瓶頸，因為它可能導致嚴重的記憶體、編碼與安全性錯誤。

前置遞增一定比後置遞增便宜嗎？

不一定。目前的編譯器最佳化可能產生等效程式碼，因此必須測量實際結果。

事件可以取代合約儲存資料嗎？

只有在未來智能合約執行不需要讀取或強制執行該資訊時，事件才可取代儲存資料。

Gas golfing 可以讓交易免費嗎？

不行。依照網路費用規則，每筆交易仍須支付必要執行、資料與狀態使用成本。

Gas golfing 會降低 Gas 價格嗎？

不會。它會降低 Gas 用量；Gas 價格則會隨網路需求與交易費用設定而變化。

Gas 退款是一種 Gas golfing 方法嗎？

符合條件的儲存清除操作可獲得有限退款，但目前規則設有退款上限，也不再支援過去高度依賴退款的策略。

Gas golfing 會造成安全風險嗎？

會。若未經仔細審查，激進壓縮、unchecked 算術、組合語言與移除驗證都可能造成漏洞。

應如何測試 Gas golfing 結果？

應使用固定的編譯器設定、合理的輸入、執行追蹤、模糊測試、不變量測試與安全性審查進行測試。

何時值得進行 Gas golfing？

當安全的修改能降低使用者或自動化系統頻繁執行之函式的成本時，最值得進行。

結論

Gas golfing 是透過精準修改智能合約，降低部署或執行 Gas 的做法。

它與 Gas 最佳化相關，但通常著重於較小的程式碼層級改善，而非徹底重新設計應用程式。

常見的 Gas golfing 方法包括快取儲存讀取、減少儲存寫入、打包變數、使用 calldata、自訂錯誤、簡化迴圈，以及採用現代 EVM 功能。

各種方法的效果取決於編譯器版本、最佳化設定、EVM 目標、輸入值與區塊鏈狀態。

在較早期 Ethereum 環境中能省下成本的建議，在目前的編譯器與協議規則下可能已不再有效。

開發者應測量編譯後的位元碼，而非根據 Solidity 原始碼的外觀或長度判斷效率。

通常應先考慮架構改善，再進行低階微幅最佳化。

Inline assembly 與 unchecked 操作應限於節省效果可測量且安全性可證明的情況。

每項 Gas golfing 修改都必須維持合約行為、安全性、可讀性與相容性。

最佳的 Gas golfing 結果不只是最低的 Gas 數值，而是在安全前提下，以最低成本提供所需的加密貨幣功能。