3月13日主網激活，坎昆升級會帶來哪些潛在風險與安全問題？

閱讀本文需 17 分鐘

坎昆升級計畫於3月13日在以太坊主網上激活，本文整理了此次升級的重要安全注意事項，供開發者自行檢查。

原文來源：salus security

長話短說：坎昆升級臨近，本次升級主要包含六個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 提案回顧

1.EIP-1153

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

2.EIP-4788

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

3.EIP-4844

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

4.EIP-5656

EIP-5656 引進了一種新的EVM 指令MCOPY，用於高效複製記憶體區域。這項提案旨在降低在 EVM 上執行記憶體複製操作的開銷，透過 MCOPY 指令直接實現記憶體之間的資料複製。 MCOPY 允許來源位址和目標位址重疊，其設計考慮到了向後相容性，並旨在提升包括資料結構建構、記憶體物件的高效存取和複製在內的多種場景的執行效率。

5.EIP-6780

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

6.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 必須保留至少一段時間的策略成為可能。選擇的具體值是 MIN_EPOCHS_FOR_BLOB_SIDECARS_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 進行更新：

● ; create2 臨時儲存合約用來臨時儲備vault 的資金

● 自毀vault 合約，資金轉帳到臨時合約（僅轉移了資金而沒有銷毀合約）

● 在原地址create2 新的vault 合約（失敗，因為原有vault 合約沒有被銷毀）

● ;自毀臨時合約將資金還給vault（資金損失，vault 合約沒有被創建）