以太坊坎昆升級前，專案開發者必看的幾項安全檢查-網路3.0-PHP中文網

長話短說：坎昆升級臨近，本次升級主要包含六個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 必須保留至少一段時間的策略成為可能。選擇的具體值是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進行更新：