Gas 最佳化

什麼是 Gas 最佳化？

Gas 最佳化是減少部署或執行加密貨幣智能合約所需區塊鏈資源的過程。

在 Ethereum 上，每筆交易與 Ethereum Virtual Machine 操作都會消耗一定數量的 Gas。

交易發送者通常須依計收的 Gas 與每個 Gas 單位的有效價格支付網路費用。

基本計算方式為：交易手續費 = 計收的 Gas × 有效 Gas 價格。

Gas 最佳化會提高合約程式碼、儲存用量、交易資料與執行路徑的效率，降低計收的 Gas 數量。

它不會直接控制 Gas 價格；Gas 價格會依區塊鏈容量需求變動。

經過適當最佳化的合約可降低代幣轉帳、去中心化金融操作、治理操作、NFT 活動與其他加密貨幣交易的成本。

但 Gas 最佳化絕不能移除安全檢查，或讓合約行為變得難以理解。

目標是以安全且可驗證的方式，完成應用程式所需的最低限度鏈上工作。

Gas 最佳化如何運作

Ethereum 會對不同類型的運算與狀態相關工作收取不同數量的 Gas。

簡單計算通常成本較低；持久儲存變更、合約建立、密碼學操作與外部呼叫則可能昂貴得多。

官方 Ethereum Gas 文件說明，Gas 用來衡量處理區塊鏈交易所需的運算工作量。

Gas 最佳化的第一步，是找出消耗最多 Gas 的操作，並判斷應用程式能否在不改變預期行為的情況下減少工作量。

開發者可減少重複的儲存讀取、合併狀態變更、縮短交易資料、移除重複計算，或使用效率更高的 EVM 功能。

編譯器也能將 Solidity 原始碼轉換成效率更高的位元組碼。

有些最佳化可降低合約部署成本，另一些則可降低每次使用者互動的成本。

適合採用的方式取決於合約部署頻率與函式呼叫頻率。

Gas 最佳化與 Gas 價格最佳化

Gas 最佳化與 Gas 價格最佳化處理交易費用的不同部分。

Gas 最佳化會減少交易消耗的 Gas 單位數。

Gas 價格最佳化則是在每個 Gas 單位價格較低時提交交易。

消耗 100,000 Gas 的合約，運算成本仍高於以 60,000 Gas 完成相同安全任務的合約。

不過，網路壅塞或 ETH 價值高時，成本較低的合約仍可能產生高額國家貨幣費用。

使用者有時可等待網路需求下降以降低 Gas 價格，但開發者可透過合約與應用程式設計控制 Gas 用量。

結合兩種方式，比單獨依賴其中一種更能有效降低交易總成本。

Gas 最佳化為什麼對加密貨幣很重要

即使加密貨幣應用程式的底層服務很實用，交易成本過高仍可能阻礙使用者使用。

若同一函式執行數千或數百萬次，即使些微的 Gas 降幅，也會帶來顯著的經濟效益。

降低 Gas 用量可提升資產餘額較少使用者的使用便利性。

也有助於有時效性的交易競爭區塊納入機會，而不必支付過高的總費用。

對自動化加密貨幣策略而言，Gas 效率尤其重要，因為執行成本可能高於交易或強制平倉的預期獲利。

高效率合約也會減少有限區塊容量的使用量，讓網路可用資源能容納更多交易。

因此，最佳化可同時使個別使用者與整體區塊鏈生態系受益。

修改程式碼前先測量 Gas

開發者應先測量 Gas 消耗，再決定合約中哪些部分需要最佳化。

看似效率低落的原始碼，可能已經由編譯器簡化。

原始碼層級的簡寫也可能產生比清楚實作更昂貴的位元組碼。

Gas 報告應涵蓋合約部署、成功交易、回復交易、最大規模輸入與少見執行分支。

對單一使用者而言成本不高的函式，處理大型陣列或大量儲存項目時可能變得難以負擔。

自動化 Gas 快照可比較不同軟體版本的成本，並偵測意外增加。

執行追蹤可找出成本高昂的操作碼、儲存欄位、記憶體擴展與外部合約呼叫。

Solidity 編譯器文件說明可用的編譯器輸出、最佳化設定與 Gas 估算。

開發者應將估算值視為參考，因為動態迴圈與外部呼叫可能使確切 Gas 用量取決於區塊鏈狀態。

最佳化智能合約架構

最大幅度的 Gas 節省通常來自變更合約架構，而不是重寫個別運算式。

儲存不必要資訊的合約，即使算術運算經過高度最佳化，成本仍然偏高。

開發者應判斷哪些資訊必須在鏈上強制執行，哪些可以在合約外計算或建立索引。

重要餘額、權限、所有權紀錄與抵押品資料，通常需要持久鏈上狀態。

若未來合約執行不需讀取，顯示資訊、歷史活動與分析資料可能適合記錄在事件日誌中。

開發者也應考慮能否用單一累積值或帳務索引表示多個狀態更新。

較簡單的狀態模型通常需要較少儲存操作，也更容易稽核。

減少持久儲存寫入

持久儲存是 Ethereum 智能合約可用資源中成本最高的項目之一。

交易完成後，儲存資料仍會保留在 Ethereum 狀態中。

網路節點必須處理並維護每個新增或變更的儲存值。

合約應避免寫入能從現有狀態安全計算的資訊。

如果目標數值已儲存，也應避免再次寫入。

完成所有計算後，有時可用一次最終儲存寫入取代多次中間更新。

除非重複儲存可帶來必要的安全或效能效益，否則開發者不應保存同一資料的多份副本。

減少儲存寫入通常比微調小型算術運算節省更多成本。

快取重複的儲存讀取

若執行期間數值維持不變，重複載入相同儲存值會浪費 Gas。

合約通常可將數值載入本地變數一次，再用於後續計算。

依據 EIP-2929，Ethereum 對冷狀態存取與暖狀態存取採用不同費用。

交易期間首次存取帳戶或儲存欄位，通常比之後再次存取同一位置更昂貴。

不過，即使是暖儲存讀取，成本也可能高於使用現有堆疊或記憶體值。

若外部呼叫可能在使用快取值前變更相關合約狀態，就應避免快取。

狀態值若在外部互動前後快取，應檢查重入與回呼行為。

打包狀態變數

Ethereum 儲存空間分成 32 位元組的欄位。

若變數大小與排列順序允許，Solidity 可將多個較小的值類型變數放入同一欄位。

官方 Solidity 儲存布局文件說明變數如何配置至儲存欄位。

妥善安排變數順序，可能降低合約所需的欄位數量。

例如，數個較小的整數或布林值可能放入同一欄位，而非各占一個欄位。

使用較小整數不會自動降低執行時 Gas，因為 EVM 通常以 256 位元字執行算術運算。

多個打包值經常一起讀取或寫入時，打包效果最好。

只更新打包欄位中的一個值，可能需要額外遮罩與組合操作。

可升級合約不得重新排列既有儲存變數，否則可能破壞先前儲存的資料。

使用常數與不可變變數

永不變更的數值不應以一般可變狀態變數儲存。

Solidity 允許使用

關鍵字宣告編譯時數值。

在合約建構期間選定且之後固定的數值，通常可使用

關鍵字。

常數與不可變變數的值會內嵌或透過合約位元組碼存取，因此可避免一般儲存讀取。

Solidity 常數與不可變變數文件說明這些宣告之間的差異。

常見例子包括永久地址、固定上限、數學值，以及部署後不能變更的設定。

若應用程式確實需要治理或授權管理者更新變數，就應維持可變。

選擇正確的資料位置

Solidity 資料可依使用方式儲存在 storage、memory、calldata 或 transient storage。

Storage 會跨交易持續保存，通常是成本最高的資料位置。

Memory 是暫存資料，只在目前執行期間可用。

Calldata 包含隨交易或合約呼叫提供的唯讀外部輸入。

Transient storage 可在單筆交易中的呼叫間保留資料，交易結束後會自動清除。

選用不必要的高成本資料位置，會在沒有增加功能的情況下提高交易成本。

Solidity 資料位置文件說明這些位置如何影響複製、可變性與存續時間。

唯讀外部輸入使用 calldata

不需修改的外部函式參數，通常可保留在 calldata 中。

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

函式只需檢查傳入值時，這有助於降低 Gas。

合約必須修改輸入或建立新的記憶體值時，則適合使用 memory。

開發者也應減少不必要的交易資料，因為 calldata 的每個位元組都會增加交易內含 Gas 成本。

若合約已儲存完整設定，有時可將重複值改為精簡識別碼。

應仔細測量壓縮效果，因為解碼所需運算可能高於節省的成本。

納入目前的 Calldata 定價考量

Ethereum 的 Pectra 升級於 2025 年 5 月 7 日啟用，其中包含影響資料量大交易經濟效益的變更。

EIP-7623為攜帶大量 calldata、但 EVM 執行量相對較少的交易設立較高 Gas 下限。

這項規則旨在限制資料量大區塊的最大規模，並提高網路韌性。

開發者不應假設運算量少的交易一定便宜；若交易包含大量 calldata，費用仍可能很高。

傳送證明、簽章、批次資料或壓縮交易資訊的應用程式，應測試目前協議行為。

新的網路升級可能改變 calldata、運算、儲存及其他資源的相對成本。

暫時性狀態使用 Transient Storage

Transient storage 適用於必須在單筆交易中持續可用、但交易結束後不需保存的資訊。

Ethereum 透過 EIP-1153導入

與 操作碼。

交易結束時，暫存值會自動清除。

由於資料不必永久保存，Transient storage 比持久儲存便宜。

常見用途是在同一筆交易中的多次內部或外部呼叫間共用重入鎖。

Transient storage 也可用於暫時帳務、回呼與交易範圍內的權限。

它不能取代必須在後續交易中保留的餘額或資訊儲存。

在可組合的加密貨幣應用程式中使用前，開發者必須了解它在一般呼叫與委派呼叫中的行為。

使用 Solidity 最佳化器

Solidity 最佳化器可簡化運算式、移除不必要操作、合併計算並縮減位元組碼大小。

Solidity 官方最佳化器文件說明產生的程式碼會經過多個最佳化階段。

最佳化器可降低部署 Gas、執行時 Gas，或兩者皆降低。

其 runs 設定代表預期部署後的程式碼會執行多少次。

較低的 runs 值通常著重縮小部署位元組碼。

較高的 runs 值通常會以較大的部署規模，換取重複執行時較低的成本。

沒有任何 runs 設定適合所有智能合約。

開發者應依合約實際的部署與使用預期比較各種設定。

以 IR 為基礎的編譯流程可能與舊流程產生不同結果，因此應透過完整測試評估。

使用目前且經驗證的編譯器

Solidity 編譯器版本可能包含 Gas 改良、新 EVM 支援、錯誤修正與安全性修補。

選擇正式部署使用的編譯器前，開發者應查看 Solidity 官方網站。

除非專案有特定相容性理由，Solidity 文件通常建議使用目前正式發布的編譯器。

開發者也應查看Solidity 編譯器已知錯誤官方清單。

建置流程應固定編譯器版本與最佳化設定。

以不同編譯器重新編譯相同原始碼，可能產生不同位元組碼與 Gas 表現。

使用自訂錯誤

自訂錯誤通常比冗長的回復字串更省 Gas。

回復字串會增加部署位元組碼，並在交易失敗時產生編碼文字。

自訂錯誤使用精簡的選擇器，並可包含結構化參數。

Solidity 自訂錯誤文件說明合約如何定義並回傳自訂錯誤。

錯誤仍應提供足夠資訊，讓錢包、使用者與開發者了解失敗原因。

為了省下極少 Gas 而移除有用的失敗資訊，可能讓應用程式更難支援與稽核。

最佳化迴圈

若迴圈次數取決於沒有嚴格上限、且可能持續增長的集合，成本可能高得危險。

無上限迴圈最終可能超出單筆交易可提供的 Gas。

可行時，應將大型工作拆分為可預測的批次。

若快取的資訊在執行期間不會改變，迴圈可快取陣列長度或重複使用的值。

只要能以數學方式證明不會溢位，開發者有時可對迴圈計數器使用 unchecked 運算。

Unchecked 程式碼應搭配測試與明確的安全說明。

現代編譯器已最佳化許多常見迴圈模式，因此手動修改前應先測量，不應假設一定更便宜。

減少外部合約呼叫

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

若安全呼叫一次就能取得所需數值，合約應避免反覆呼叫相同外部函式。

有時可將數個相關操作合併至一次呼叫或一筆交易。

但批次處理可能增加 calldata、執行複雜度，並提高其中一步失敗時回復的工作量。

外部呼叫也會帶來重入、惡意回傳資料、Gas 消耗與意外失敗等安全考量。

Gas 最佳化絕不能移除回傳值檢查或安全的互動模式。

適當時以事件取代儲存

事件可記錄區塊鏈活動，供鏈下錢包、介面、分析系統與索引器使用。

與將相同資訊儲存為持久合約狀態相比，事件通常成本較低。

若未來智能合約執行不需讀取或強制執行該資訊，就適合使用事件。

交易歷史、活動通知與描述性中繼資料，可能適合記錄在日誌中。

餘額、權限、債務、抵押品與所有權不應只記錄在事件中，因為一般 EVM 執行無法搜尋歷史日誌。

合約必須在可存取狀態中保存未來決策所需的資訊。

降低合約部署成本

部署合約時，初始化邏輯與儲存執行時位元組碼都會消耗 Gas。

未使用函式、重複程式碼、內嵌資料與冗長錯誤訊息都可能增加部署成本。

開發者應移除無法觸及的程式碼，且只需大型函式庫一小部分時，避免匯入整個函式庫。

函式庫可減少多個合約間重複的位元組碼，但外部函式庫呼叫也會產生執行成本與相依關係。

需要部署許多相似合約實例時，工廠與 clone 模式可降低部署成本。

Proxy 模式也可共用實作程式碼，但會引入委派呼叫開銷、升級權限與儲存布局風險。

選擇架構時應考量安全與生命週期需求，而非只看部署 Gas。

指定正確的 EVM 版本

Solidity 編譯器會依選定的 EVM 版本產生不同位元組碼。

較新的 EVM 版本可能支援效率更高的指令，但舊網路無法執行。

例如，EIP-3855導入精簡的

指令，可將 0 放入堆疊。

EIP-5656導入

，用於更有效率地複製記憶體。

設定正確網路時，目前的編譯器可自動使用受支援的指令。

若網路尚未啟用所需升級，以較新 EVM 編譯的合約可能無法執行。

因此，開發者必須選擇與目標部署鏈相容的 EVM 目標版本。

了解 Gas 退款

符合資格的儲存操作可能產生 Gas 退款，降低最終計收的 Gas。

Ethereum 現行規則將協議層級退款限制為總 Gas 用量的 20%。

EIP-3529調降了清除符合資格儲存資料的退款，並取消先前針對

的退款。

清除儲存資料仍可能帶來有限效益，但不代表建立與刪除狀態不需成本。

開發者不應只為之後領取退款而寫入不必要資料。

退款會在執行後套用，因此無法避免 Gas 耗盡錯誤。

不是現代 Gas 最佳化方法，且其行為受 EIP-6780限制。

謹慎考慮批次處理

將多個操作合併至單筆交易，可避免重複支付交易開銷。

批次處理也可減少錢包確認次數，改善使用者體驗。

但每個操作仍會消耗其本身所需的運算與狀態變更 Gas。

大型批次可能接近交易 Gas 上限，或造成昂貴的全有全無式失敗。

應用程式應定義子操作失敗時，是回復整個批次，還是允許部分完成。

必須妥善設計授權，因為範圍廣泛的批次簽章可能允許超出使用者預期的操作。

Pectra 的 EIP-7702讓外部擁有帳戶可將執行委派給智能合約程式碼，支援批次處理與 Gas 贊助等錢包功能。

委派帳戶邏輯的審查應與任何其他控制加密貨幣的合約同樣謹慎。

使用 Layer 2 網路進一步節省成本

智能合約最佳化可降低應用程式所需運算量。

部署至適當的 Layer 2 網路，可進一步降低使用者為運算與相關資料支付的價格。

Rollup 會在 Ethereum 主網外處理交易，再將資料或證明發布回 Ethereum。

Dencun 升級透過 EIP-4844 導入 Blob，為 Rollup 建立獨立的暫時資料市場。

Layer 2 費用較低，並不代表不必最佳化 Gas；同一網路上的低效率合約仍會浪費容量，且成本高於高效率合約。

開發者也必須評估跨鏈橋安全性、提領規則、流動性、最終性與網路特定費用計算方式。

避免過早進行低階最佳化

在測量一般 Solidity 程式碼之前，開發者不應先使用內嵌組合語言或複雜位元操作。

編譯器可能已能從清楚的高階實作產生有效率的位元組碼。

組合語言有時可降低特定操作的 Gas，但會繞過數項語言層級的防護。

組合語言錯誤可能造成記憶體損毀、編碼錯誤、不安全呼叫或使用者資金損失。

低階最佳化應搭配易讀的參考實作與測試，證明行為一致。

若組合語言處理餘額、簽章、權限或外部呼叫，獨立安全審查尤其重要。

切勿為節省 Gas 犧牲安全性

若攻擊者能竊取合約中的加密貨幣，成本再低的合約也沒有用。

不得只為降低 Gas 用量而移除存取控制、輸入驗證、防重入保護、滑點檢查、期限檢查與帳務檢查。

只有在所有可行條件下都不可能溢位或下溢時，才應使用 unchecked 運算。

壓縮儲存可節省 Gas，卻可能提高位元層級錯誤的風險。

Proxy 可能降低部署成本，卻會帶來集中式升級控制或儲存衝突問題。

鏈下簽章可能省下一筆交易，但會增加 Nonce、到期時間、重放攻擊與網域分隔等要求。

最佳化決策應從安全性、可讀性、可升級性與營運風險等方面審查。

Gas 最佳化測試

每項最佳化都應與原始實作比較測試。

功能測試應確認兩個版本產生相同的狀態變更與輸出。

Gas 測試應測量平均用量、支援的最大用量與失敗條件。

模糊測試可探索不尋常輸入，找出成本高昂或錯誤的執行路徑。

不變量測試可確認最佳化後的重要帳務與安全屬性仍然成立。

開發者也應使用正式環境預定採用的確切編譯器版本、最佳化設定與 EVM 目標進行測試。

應保留 Gas 快照，避免後續開發在未察覺的情況下抵銷改善。

常見的 Gas 最佳化錯誤

常見錯誤之一，是假設每種較小整數類型都能降低 Gas。

另一個錯誤是沒有功能需求，卻將唯讀外部資料從 calldata 複製至 memory。

開發者也可能對儲存集合建立無上限迴圈，導致應用程式擴大後無法執行。

有些團隊最佳化很少使用的函式，卻忽略每筆使用者交易都會重複發生的小額成本。

另一些團隊未測試部署與執行間的取捨，就選擇最佳化器設定。

也有人在找出實際高成本操作前，就加入手寫組合語言。

開發者也可能在 Ethereum 升級重新調整操作成本後，仍依賴過時的 Gas 計價方式。

最危險的錯誤，是為了產生亮眼的 Gas 基準測試結果而移除必要的安全檢查。

如何制定 Gas 最佳化策略

Gas 最佳化策略應從明確定義合約行為與安全要求開始。

開發團隊應在修改實作前建立完整測試。

接著在貼近實際情況的條件下測量部署與交易成本。

優先處理成本最高的儲存操作、迴圈、calldata 負載與外部呼叫。

進行低階程式碼重寫前，應先考慮簡化架構。

應測試並記錄編譯器設定與目標 EVM 版本。

每項最佳化都應通過功能、Gas 與安全性審查。

最終部署應使用固定工具與相依版本，產生可重現的位元組碼。

常見問題

簡單來說，什麼是 Gas 最佳化？

Gas 最佳化是減少安全執行智能合約所需的區塊鏈運算、儲存與交易資料。

Gas 最佳化會降低 Gas 價格嗎？

不會。它會降低 Gas 用量；Gas 價格則由網路需求與交易費用設定決定。

最有效的 Gas 最佳化方法是什麼？

減少不必要的持久儲存操作並簡化合約架構，通常能帶來最大幅度的節省。

Storage 比 memory 貴嗎？

是。持久儲存通常較昂貴，因為交易結束後資料仍會保留在區塊鏈狀態中。

Calldata 比 memory 便宜嗎？

唯讀外部輸入使用 calldata 可能較便宜，因為不必將完整值複製到記憶體。

小整數類型一定能節省 Gas 嗎？

不一定。通常只有多個值能打包至同一個儲存欄位時，才會顯著節省儲存成本。

什麼是 Transient Storage？

Transient storage 是交易範圍內的 EVM 儲存資料，會自動清除，可降低暫時合約狀態的成本。

Solidity 最佳化器一定會降低成本嗎？

不一定。最佳化器設定可能降低執行時 Gas，卻增加部署成本，因此應測量每種設定。

最佳化器的 runs 是什麼意思？

runs 設定會影響編譯器在縮小部署位元組碼與降低重複執行成本之間的取捨。

自訂錯誤比回復字串便宜嗎？

通常是。自訂錯誤使用精簡選擇器與編碼參數，而非冗長文字字串，效率較高。

事件可以取代儲存嗎？

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

清除儲存資料會產生 Gas 退款嗎？

清除符合資格的儲存資料可能產生有限退款，但退款有上限，無法取回原始儲存成本的全部金額。

Gas 退款可以避免 Gas 耗盡錯誤嗎？

不行。Gas 退款會在執行後計算，無法在交易執行期間提供額外 Gas。

批次處理一定能節省 Gas 嗎？

不一定。批次處理可減少重複交易開銷，但可能增加 calldata、複雜度與失敗風險。

開發者應使用內嵌組合語言進行最佳化嗎？

只有在測量確認存在效能瓶頸時才應使用，因為內嵌組合語言可能帶來嚴重安全與維護風險。

Layer 2 網路可以取代 Gas 最佳化嗎？

不行。Layer 2 網路可能降低費用，但同一網路上的低效率合約仍會比最佳化合約消耗更多資源。

Gas 成本為什麼會隨時間改變？

Ethereum 升級可能新增操作碼、重新調整既有操作的費用、改變 calldata 規則，或擴充網路容量。

開發者如何測量 Gas 用量？

開發者可使用 Gas 報告、交易收據、執行追蹤、編譯器輸出、自動化快照與貼近實際情況的測試。

Gas 用量最低的實作一定最好嗎？

不一定。合約安全性、正確性、可讀性與可維護性，比小幅節省 Gas 更重要。

使用者可以在不修改合約的情況下最佳化 Gas 嗎？

使用者可選擇需求較低的時段或適當網路，但只有合約開發者能改變應用程式底層的執行效率。

結論

Gas 最佳化是降低加密貨幣智能合約與交易所消耗資源的工程流程。

它能降低 Gas 用量，但不會直接改變每個 Gas 單位的市場價格。

最有效的最佳化通常來自更簡單的架構、更少的儲存操作、適當的資料位置、有上限的迴圈，以及減少外部呼叫。

編譯器最佳化、常數、不可變值、自訂錯誤、變數打包、Transient Storage 與適當的批次處理，也能進一步節省成本。

開發者應使用目前版本的編譯器、查看已知編譯器錯誤，並指定正確的 EVM 版本。

每項最佳化都必須針對成功交易、失敗、大型輸入與不尋常執行路徑進行測試。

絕不能只為降低 Gas 報告數值而移除安全控制。

經過妥善最佳化的合約，只執行提供安全、透明且可靠加密貨幣功能所需的鏈上工作。