坎昆升級即將到來，有哪些需要注意的事項及潛在風險？

2024-03-04 16:43:13

坎昆升級已分別於 1 月 17 日、1 月 30 日、2 月 7 日在以太坊 Goerli、Sepolia 和 Holesky 測試網完成升級，並計劃在 3 月 13 日在以太坊主網上激活。

分享至

撰文：Salus Insights

長話短說：坎昆升級臨近，本次升級主要包含六個 EIP 提出的執行層變更，EIP-1153、EIP-4788、EIP-4844、EIP-5656、EIP-6780 和 EIP-7516。EIP-4844 是本次升級的主角，旨在提升以太坊的可擴展性，為 L2 降低交易成本、提升交易速度。坎昆升級已分別於 1 月 17 日、1 月 30 日、2 月 7 日在以太坊 Goerli、Sepolia 和 Holesky 測試網完成升級，並計劃在 3 月 13 日在以太坊主網上激活。在升級前，Salus 整理了此次升級的重要安全注意事項，供開發者自行檢查。

EIP 提案回顧

EIP-1153

EIP-1153 引入了臨時存儲操作碼，這些操作碼用於操作狀態，其行為與存儲幾乎相同，但每筆交易結束後臨時存儲將被丟棄。這意味著，臨時存儲不會從存儲中反序列化值，也不會序列化值到存儲，因此，由於不需要磁碟訪問，臨時存儲成本更低。通過兩個新的操作碼 TLOAD 和 TSTORE（其中「T」代表「臨時」），智能合約可以訪問臨時存儲。這項提議旨在為 Ethereum 的交易執行中的多個嵌套執行框架之間的通信提供一個專用且高效的解決方案。

EIP-4788

EIP-4788 旨在將信標鏈區塊的哈希樹根暴露於 EVM 中，以允許在智能合約內部訪問這些根。這樣做可以無需信任地訪問共識層狀態，支持 staking pools、restaking 結構、智能合約橋、MEV 緩解等多種用例。該提案通過一個智能合約存儲這些根，並使用環形緩衝區來限制存儲消耗，確保每個執行區塊只需常量空間即可表示這些信息。

EIP-4844

EIP-4844 介紹了一種新的事務格式，稱為「分片 Blob 事務」，旨在以簡單、向前兼容的方式擴展以太坊的數據可用性。這項提案通過引入包含大量數據的「blob-carrying transactions」，這些數據不能被 EVM 執行訪問，但可以訪問其承諾。這種格式與將來全分片使用的格式完全兼容，為滾動式擴容提供了臨時但顯著的緩解。

EIP-5656

EIP-5656 引入了一種新的 EVM 指令 MCOPY，用於高效複製內存區域。這項提案旨在降低在 EVM 上執行內存複製操作的開銷，通過 MCOPY 指令直接實現內存之間的數據複製。MCOPY 允許源地址和目標地址重疊，其設計考慮到了向後兼容性，並旨在提升包括數據結構構建、內存對象的高效訪問和複製在內的多種場景的執行效率。

EIP-6780

EIP-6780 修改了 SELFDESTRUCT 操作碼的功能。在這個提案中，SELFDESTRUCT 只會在與合約創建相同的交易中刪除賬戶和傳輸所有以太幣，除此之外，執行 SELFDESTRUCT 時，合約將不會被刪除，只是將所有以太幣轉移到指定目標。這一改變是為了適應未來 Verkle 樹的使用，旨在簡化 EVM 實現，減少狀態變化的複雜性，同時保留 SELFDESTRUCT 的部分常用場景。

EIP-7516

EIP-7516 引入了一個新的 EVM 指令 BLOBBASEFEE，用於返回當前區塊執行中的 blob 基礎費用值。這個指令與 EIP-3198 中的 BASEFEE 操作碼相似，不同之處在於它返回的是根據 EIP-4844 定義的 blob 基礎費用。這個功能使得合約可以編程地考慮 blob 數據的氣體價格，例如，允許 rollup 合約無需信任地計算 blob 數據使用成本，或者基於此實現 blob 氣體期貨，以平滑 blob 數據成本。

官方披露的安全考量

EIP-1153

智能合約開發人員應在使用前了解瞬態存儲變量的生命周期。由於臨時存儲會在交易結束時自動清除，因此智能合約開發人員可能會試圖避免在調用過程中清除插槽以節省 Gas。然而，這可能會阻止在同一事務中與合約進行進一步的交互（例如，在重入鎖的情況下）或導致其他錯誤，因此智能合約開發人員應小心，僅在臨時存儲槽被保留時保留非零值。旨在供同一事務中的未來調用使用。SSTORE 否則，這些操作碼的行為與和完全相同 SLOAD，因此所有常見的安全注意事項都適用，特別是在重入風險方面。

智能合約開發人員也可能會嘗試使用瞬態存儲作為內存映射的替代方案。他們應該意識到，當調用返回或恢復時，臨時存儲不會像內存一樣被丟棄，並且應該在這些用例中優先選擇內存，以免在同一事務中的重入時產生意外的行為。內存上的瞬態存儲成本必然很高，這應該已經阻止了這種使用模式。內存中映射的大多數用法可以通過按鍵排序的條目列表來更好地實現，並且智能合約中很少需要內存中映射（即作者知道生產中沒有已知的用例）。

EIP-4844

此 EIP 使每個信標塊的帶寬要求最多增加約 0.75 MB。這比當今區塊的理論最大大小（30M Gas / 每個 calldata 字節 16 Gas = 1.875M 字節）大 40%，因此它不會大幅增加最壞情況下的帶寬。合併後，區塊時間是靜態的，而不是不可預測的泊松分佈，為大區塊的傳播提供了保證的時間段。

即使調用數據有限，此 EIP 的持續負載也比可降低調用數據成本的替代方案低得多，因為不需要將 Blob 存儲與執行負載一樣長的時間。這使得實現這些 blob 必須保留至少一段時間的策略成為可能。選擇的具體值是 MINEPOCHSFORBLOBSIDECARS_REQUESTS 紀元，約為 18 天，與建議的（但尚未實施）執行有效負載歷史的一年輪換時間相比，延遲要短得多。

EIP-5656

客戶端應注意其實現不使用中間緩衝區（例如 C stdlibmemmove 函數不使用中間緩衝區），因為這是潛在的拒絕服務 (DoS) 向量。大多數用於移動字節的語言內置函數 / 標準庫函數在這裡都具有正確的性能特徵。

除此之外，對拒絕服務 (DoS) 和內存耗尽攻擊的分析與其他接觸內存的操作碼相同，因為內存擴展遵循相同的定價規則。

EIP-6780

以下應用程序 SELFDESTRUCT 將被破壞，並且以這種方式使用它的應用程序不再安全：

WhereCREATE2 用於在同一位置重新部署合約，以使合約可升級。不再支持此功能，應改用 ERC-2535 或其他類型的代理合約。

如果合約依賴於通過以 SELFDESTRUCT 合約作為受益人燃燒以太幣，則合約不是在同一交易中創建的。

智能合約相關風險

EIP1153

設想使用操作碼 TLOAD 和 TSTORE 的兩種場景：

被調用合約使用該操作碼
發起調用合約使用該操作碼

風險 1：

相比於傳統的 SSTORE 和 SLOAD ，新增的瞬態存儲主要改變了數據的存儲期限，tstore 存儲的數據通過 tload 進行讀取，在一筆交易執行結束後該數據將會被釋放，而不是同 sstore 一樣寫入合約被永久性的記錄。開發者在使用該操作碼時應該認清該操作碼的特性，以免錯誤的使用導致數據不能正確的寫入到合約中而造成損失。另外，tstore 的數據屬於私有變量，僅合約本身可以訪問。如果想要外部使用該數據只能通過參數的形式進行傳遞或暫存到一個 public stroage 變量中。

風險 2：

另一個潛在風險是，如果智能合約開發人員不正確管理瞬態存儲變量的生命周期，可能導致數據在不應該的時間被清除或錯誤地保留。如果合約期望在事務的後續調用中使用存儲在瞬態存儲中的數據，但未能適當地管理這些數據的生命周期，可能會在不同調用之間錯誤地共享或丟失數據，從而導致邏輯錯誤或安全漏洞。考慮到類似於 Token 項目的 balance 或者 allowance 數據未能正確的存儲將會導致合約邏輯的錯誤，造成損失。或在對 owner 地址進行設置時使用了該操作碼將會導致特權地址不能正確的被記錄從而丟失對合約重要參數的修改。

考慮一個智能合約，該合約使用瞬態存儲來臨時記錄一個加密貨幣交易平台上的交易價格。該合約在每筆交易完成時更新價格，並允許用戶在短時間內查詢最新價格。然而，如果合約設計沒有考慮到瞬態存儲在交易結束時被自動清除的特性，那麼在一筆交易結束後到下一筆交易開始之前的這段時間內，用戶可能會得到一個錯誤或過時的價格。這不僅可能導致用戶做出基於錯誤信息的決策，還可能被惡意利用，影響平台的聲譽和用戶的資產安全。

EIP-6780

該提案改變了之前 selfdestruct 操作碼的行為，不銷毀合約，僅轉移 token，僅與自毀同一交易中創建的合約才會被銷毀。這個 EIP 的影響相對較大。

用 create2 在同一地址重新部署合約，以使合合約升級。不再支持此功能，應改用 ERC-2535 或其他類型的代理合約。（這可能會影響到使用 create2 實現可升級合約的鏈上合約的安全性）

智能合約中的 SELFDESTRUCT 操作允許合約銷毀，並將合約餘額發送給指定的目標地址。在這種情況下，合約使用 SELFDESTRUCT 銷毀以太幣，並將銷毀的以太幣發送給了合約。但是該合約僅能是在同一筆交易中創建的合約（同一筆交易中由本合約或其他合約創建的合約）。否則將僅轉帳以太而不銷毀合約（例如自毀且受益者為自毀合約，這將會不產生任何改變）。這將會影響一切依賴於 selfdestruct 進行提款或其他操作的合約。

一種類似於 1inch CHI Token 的 Gas Token 的工作原理：保持一個偏移量，始終在此偏移量處執行 CREATE2 或 SELFDESTRUCT。在此更新之後，如果當前偏移量的合約尚未正確自毀，則之後的 CREATE2 將不能成功的部署合約。

該提案實施並不能導致直接對合約進行攻擊，但會損害原有已部署的依賴 selfdestruct 操作的合約的正常邏輯（僅依賴自毀進行資金轉移的合約不受到影響，如果後續操作必須要求自毀的合約被刪除，則受到影響），導致合約非預期工作，僅對合約以及用戶而言，可能導致合約的罷工，損失資金等危害 ( 例如原本利用 create2 在原地址部署新合約，自毀原合約進行升級的合約，不再能夠成功部署 )。長遠來看，修改某項操作碼的功能可能會帶來中心化的問題。

例如現有一個金庫合約 vault 進行更新：