Solidity 中的不可變變量和常量是什麼？它們如何節省 Gas？

了解 Solidity 中的不可變變量

1. Solidity 中的不可變變量是使用immutable關鍵字聲明的，並且只能在合約構建期間賦值一次。一旦設置，它們的值就無法在合約的整個生命週期中更改。

2. 這些變量在部署時解析，允許編譯器通過將它們放置在合約的元數據中而不是放置在用於常規狀態變量的存儲槽中來優化存儲。

3. 由於不可變變量不佔用可變存儲，因此部署後無需進行 SSTORE 操作，這是以太坊中最昂貴的操作碼之一。

4. 不可變變量的值通常在構造函數內分配，這使其非常適合部署時已知但同一合約的實例之間存在差異的參數。

5. 使用不可變通過表明意圖來提高代碼清晰度——開發人員知道某些值在部署後是固定的，從而降低了意外修改的風險。

常數在氣體優化中的作用

1. 常量是使用constant關鍵字定義的，並且必須在聲明時賦值。它們的值在編譯期間被硬編碼到字節碼中。

2. 由於常量值直接嵌入到 EVM 指令中，因此讀取它們不會產生存儲訪問成本，這意味著檢索其值時不會執行 SLOAD 操作。

3. 任何使用常量的函數都會內聯該值，從而在編譯時將變量引用有效地替換為其文字值。

4. 這種內聯行為減少了執行費用和合約大小，因為不需要為這些值分配或引用持久存儲。

5. 常量最適合在所有部署中真正靜態的值，例如計算中使用的協議參數或數學係數。

不可變和常量之間的區別

1. 雖然兩者都通過避免運行時存儲成本來節省gas，但常量要求在編譯時知道它們的值，而不可變則允許在構造期間分配。

2. 常量不能依賴於任何輸入或外部狀態——它必須是編譯時常量表達式，例如數字、字符串或具有常量輸入的純函數調用的結果。

3. 不可變變量提供更大的靈活性；它們可以採用構造函數參數，使不同的合約實例具有不同的值，同時仍然受益於降低的運行時成本。

4. 從gas使用的角度來看，常量通常會提供稍微更好的優化，因為它們的值在部署之前就已經完全解析，而不可變則涉及在構建期間的一次性初始化。

5. 濫用任何一種類型（例如將經常更改的值聲明為不可變的值）都可能導致設計不靈活，因此正確的用例對齊至關重要。

天然氣節省機制解釋

1. 使用 SLOAD 從 EVM 存儲中進行的每次讀取至少消耗 2100 個 Gas，而訪問存儲在代碼空間中的值（如常量）的成本接近於零。

2. 使用 SSTORE 寫入存儲的成本甚至更高，首次寫入時花費高達 20,000 Gas，後續更新花費 5,000 Gas - 不可變在構建後完全避免了這一成本。

3. 通過將數據從存儲轉移到代碼或構造函數初始化的內存區域，常量和不可變變量都減少了智能合約的操作足跡。

4. 嚴重依賴配置值（例如費用百分比、地址允許列表或代幣上限）的合約在將這些值聲明為常量或不可變時會顯著受益。

5. 編譯器優化利用這些聲明來最大限度地減少冗餘操作，去除不必要的檢查，並生成更精簡的字節碼，進一步提高效率。

常見問題解答

構造函數運行後可以更改不可變變量嗎？不可以。一旦在構造函數中設置了不可變變量，就無法對其進行修改。任何重新分配它的嘗試都會導致編譯錯誤。

哪些類型可以聲明為常量有限制嗎？是的。只有像 uint、int、bool、address 和字符串文字（有一些限制）這樣的值類型可以是常量。數組和結構不能聲明為常量，除非它們在內聯彙編中或由較新的編譯器版本處理的特殊情況。

不可變變量會增加部署 Gas 成本嗎？由於構造函數邏輯，它們可能會稍微增加部署成本，但這可以通過交互過程中的長期節省來抵消。多次交易的淨效應通常是總 Gas 支出的顯著減少。

如果我嘗試在構造函數外部分配不可變變量，會發生什麼情況？ Solidity 編譯器會拋出錯誤。不可變變量的分配僅限於構造函數上下文，以確保其完整性和可預測性。