如何編寫 Gas-Efficient 且優化的 Solidity 代碼？

了解天然氣消耗模式

1. 以太坊虛擬機中的每個操作都會消耗一定量的 Gas，從簡單的算術到存儲寫入。

2. 與固定大小的結構相比，內存分配和動態數組調整大小會引發不成比例的高天然氣成本。

3. 外部函數調用由於消息傳遞、堆棧複製和 EVM 上下文切換而產生開銷。

4. SLOAD 和 SSTORE 操作仍然是最昂貴的指令之一，特別是在重複修改存儲槽時。

5. 如果循環迭代包含沒有適當邊界檢查的存儲讀取或寫入，則循環迭代會成倍增加氣體使用量。

優化存儲佈局

1. 將多個小變量打包到單個 256 位存儲槽中，減少了 SSTORE 調用，並節省了部署和運行時的 Gas。

2. 按大小降序聲明狀態變量（uint256、uint128、uint64）可以實現更緊密的打包並避免隱式填充間隙。

3. 對在構造函數中初始化一次的常量使用不可變可以完全消除部署後的存儲寫入。

4. 在不發生傳輸的情況下，用純地址替換應付地址可以消除不必要的類型轉換開銷。

5. 避免在不考慮對齊的情況下使用混合大小字段的結構會導致空間浪費和每次訪問的氣體增加。

最小化運行時計算

1. 在鏈外計算循環邊界或將它們緩存在內存中可以防止迭代內重複存儲查找。

2. 使用未經檢查的 { ... }進行數學上不可能溢出的算術運算會跳過安全檢查，並且每次操作最多可減少 40% 的 Gas 消耗。

3. 優先使用require()而不是assert()可確保在無效輸入時更早失敗並降低 Gas 成本。

4. 將復雜的邏輯移入庫並使用 delegatecall 可以避免跨合約複製字節碼。

5. 手動內聯小型輔助函數可以減少調用開銷，儘管編譯器優化可能會在更高的優化級別自動處理此問題。

編譯器和工具鏈的利用

1. 使用--optimize --optimize-runs=200啟用 Solidity 優化器，通過不斷折疊和跳轉重新排序，顯著減少部署的字節碼大小和運行時 Gas。

2. 使用最新的編譯器版本（例如 0.8.24）可以解鎖舊版本中不可用的內置檢查和更積極的內聯策略。

3. 使用solc --asm等工具分析生成的操作碼，揭示隱藏的低效率問題，例如冗餘 DUP 或不必要的 SWAP。

4. 集成 Foundry 的偽造檢查有助於識別測試期間的存儲槽衝突和意外的內存分配。

5. 通過forge test --gas-report運行 Gas 快照會在主網部署之前暴露熱點。

常見問題解答

問：使用視圖函數是否可以消除調用者的所有 Gas 成本？答：不會。雖然視圖函數在通過 RPC 外部調用時不消耗 Gas，但在同一事務中從非視圖函數內部調用時仍然會消耗 Gas。

問：我可以在內部邏輯中安全地將 require(msg.sender == Owner) 替換為 msg.sender == Owner 嗎？答：不安全。刪除require會消除顯式恢復，從而導致靜默故障或意外行為，而不是受控錯誤處理。

問：發出事件或將數據存儲在映射中以進行鏈外索引更好嗎？答：事件比存儲寫入便宜，並且足以用於索引目的。除非需要鏈上訪問，否則在事件和狀態變量中存儲相同的數據會浪費gas，而且不會帶來任何額外的好處。

問：為什麼使用 delete arr[i] 刪除數組元素不會降低總合約 Gas 成本？ A： delete關鍵字只是重置值，不會縮小數組長度，也不會回收存儲槽位。動態陣列保留容量，並且需要手動移動或使用推/彈出模式來實現真正的清理。