以太坊坎昆升級前，項(xiàng)目開發(fā)者必看的幾項(xiàng)安全檢查
長話短說：坎昆升級臨近，本次升級主要包含六個 EIP 提出的執(zhí)行層變更，EIP-1153、EIP-4788、EIP-4844、EIP-5656、EIP-6780 和 EIP-7516 。EIP-4844 是本次升級的主角，旨在提升以太坊的可擴(kuò)展性，為L2降低交易成本、提升交易速度?？怖ド壱逊謩e于 1 月 17 日、 1 月 30 日、 2 月 7 日在以太坊 Goerli、Sepolia 和 Holesky 測試網(wǎng)完成升級，并計劃在 3 月 13 日在以太坊主網(wǎng)上激活。在升級前，Salus 整理了此次升級的重要安全注意事項(xiàng)，供開發(fā)者自行檢查。
EIP 提案回顧
EIP-1153
EIP-1153 引入了臨時存儲操作碼，這些操作碼用于操作狀態(tài)，其行為與存儲幾乎相同，但每筆交易結(jié)束后臨時存儲將被丟棄。這意味著，臨時存儲不會從存儲中反序列化值，也不會序列化值到存儲，因此，由于不需要磁盤訪問，臨時存儲成本更低。通過兩個新的操作碼 TLOAD 和 TSTORE（其中“T”代表“臨時”），智能合約可以訪問臨時存儲。這項(xiàng)提議旨在為 Ethereum 的交易執(zhí)行中的多個嵌套執(zhí)行框架之間的通信提供一個專用且高效的解決方案。
EIP-4788
EIP-4788 旨在將信標(biāo)鏈區(qū)塊的哈希樹根暴露于 EVM 中，以允許在智能合約內(nèi)部訪問這些根。這樣做可以無需信任地訪問共識層狀態(tài)，支持 staking pools、restaking 結(jié)構(gòu)、智能合約橋、MEV 緩解等多種用例。該提案通過一個智能合約存儲這些根，并使用環(huán)形緩沖區(qū)來限制存儲消耗，確保每個執(zhí)行區(qū)塊只需常量空間即可表示這些信息。
EIP-4844
EIP-4844 介紹了一種新的事務(wù)格式，稱為"分片 Blob 事務(wù)"，旨在以簡單、向前兼容的方式擴(kuò)展以太坊的數(shù)據(jù)可用性。這項(xiàng)提案通過引入包含大量數(shù)據(jù)的"blob-carrying transactions"，這些數(shù)據(jù)不能被 EVM 執(zhí)行訪問，但可以訪問其承諾。這種格式與將來全分片使用的格式完全兼容，為滾動式擴(kuò)容提供了臨時但顯著的緩解。
EIP-5656
EIP-5656 引入了一種新的 EVM 指令 MCOPY，用于高效復(fù)制內(nèi)存區(qū)域。這項(xiàng)提案旨在降低在 EVM 上執(zhí)行內(nèi)存復(fù)制操作的開銷，通過 MCOPY 指令直接實(shí)現(xiàn)內(nèi)存之間的數(shù)據(jù)復(fù)制。MCOPY 允許源地址和目標(biāo)地址重疊，其設(shè)計考慮到了向后兼容性，并旨在提升包括數(shù)據(jù)結(jié)構(gòu)構(gòu)建、內(nèi)存對象的高效訪問和復(fù)制在內(nèi)的多種場景的執(zhí)行效率。
EIP-6780
EIP-6780 修改了 SELFDESTRUCT 操作碼的功能。在這個提案中，SELFDESTRUCT 只會在與合約創(chuàng)建相同的交易中刪除賬戶和傳輸所有以太幣，除此之外，執(zhí)行 SELFDESTRUCT 時，合約將不會被刪除，只是將所有以太幣轉(zhuǎn)移到指定目標(biāo)。這一改變是為了適應(yīng)未來 Verkle 樹的使用，旨在簡化 EVM 實(shí)現(xiàn)，減少狀態(tài)變化的復(fù)雜性，同時保留 SELFDESTRUCT 的部分常用場景。
EIP-7516
EIP-7516 引入了一個新的 EVM 指令 BLOBBASEFEE，用于返回當(dāng)前區(qū)塊執(zhí)行中的 blob 基礎(chǔ)費(fèi)用值。這個指令與 EIP-3198 中的 BASEFEE 操作碼相似，不同之處在于它返回的是根據(jù) EIP-4844 定義的 blob 基礎(chǔ)費(fèi)用。這個功能使得合約可以編程地考慮 blob 數(shù)據(jù)的氣體價格，例如，允許 rollup 合約無需信任地計算 blob 數(shù)據(jù)使用成本，或者基于此實(shí)現(xiàn) blob 氣體期貨，以平滑 blob 數(shù)據(jù)成本。
官方披露的安全考量
EIP-1153
智能合約開發(fā)人員應(yīng)在使用前了解瞬態(tài)存儲變量的生命周期。由于臨時存儲會在交易結(jié)束時自動清除，因此智能合約開發(fā)人員可能會試圖避免在調(diào)用過程中清除插槽以節(jié)省 Gas。然而，這可能會阻止在同一事務(wù)中與合約進(jìn)行進(jìn)一步的交互（例如，在重入鎖的情況下）或?qū)е缕渌e誤，因此智能合約開發(fā)人員應(yīng)小心，僅在臨時存儲槽被保留時保留非零值。旨在供同一事務(wù)中的未來調(diào)用使用。SSTORE 否則，這些操作碼的行為與和完全相同 SLOAD，因此所有常見的安全注意事項(xiàng)都適用，特別是在重入風(fēng)險方面。
智能合約開發(fā)人員也可能會嘗試使用瞬態(tài)存儲作為內(nèi)存映射的替代方案。他們應(yīng)該意識到，當(dāng)調(diào)用返回或恢復(fù)時，臨時存儲不會像內(nèi)存一樣被丟棄，并且應(yīng)該在這些用例中優(yōu)先選擇內(nèi)存，以免在同一事務(wù)中的重入時產(chǎn)生意外的行為。內(nèi)存上的瞬態(tài)存儲成本必然很高，這應(yīng)該已經(jīng)阻止了這種使用模式。內(nèi)存中映射的大多數(shù)用法可以通過按鍵排序的條目列表來更好地實(shí)現(xiàn)，并且智能合約中很少需要內(nèi)存中映射（即作者知道生產(chǎn)中沒有已知的用例）。
EIP-4844
此 EIP 使每個信標(biāo)塊的帶寬要求最多增加約 0.75 MB。這比當(dāng)今區(qū)塊的理論最大大小（30 M Gas / 每個 calldata 字節(jié) 16 Gas = 1.875 M 字節(jié)）大 40% ，因此它不會大幅增加最壞情況下的帶寬。合并后，區(qū)塊時間是靜態(tài)的，而不是不可預(yù)測的泊松分布，為大區(qū)塊的傳播提供了保證的時間段。
即使調(diào)用數(shù)據(jù)有限，此 EIP 的持續(xù)負(fù)載也比可降低調(diào)用數(shù)據(jù)成本的替代方案低得多，因?yàn)椴恍枰獙?Blob 存儲與執(zhí)行負(fù)載一樣長的時間。這使得實(shí)現(xiàn)這些 blob 必須保留至少一段時間的策略成為可能。選擇的具體值是 MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS 紀(jì)元，約為 18 天，與建議的（但尚未實(shí)施）執(zhí)行有效負(fù)載歷史的一年輪換時間相比，延遲要短得多。
EIP-5656
客戶端應(yīng)注意其實(shí)現(xiàn)不使用中間緩沖區(qū)（例如 C stdlibmemmove 函數(shù)不使用中間緩沖區(qū)），因?yàn)檫@是潛在的拒絕服務(wù) (DoS) 向量。大多數(shù)用于移動字節(jié)的語言內(nèi)置函數(shù)/標(biāo)準(zhǔn)庫函數(shù)在這里都具有正確的性能特征。
除此之外，對拒絕服務(wù) (DoS) 和內(nèi)存耗盡攻擊的分析與其他接觸內(nèi)存的操作碼相同，因?yàn)閮?nèi)存擴(kuò)展遵循相同的定價規(guī)則。
EIP-6780
以下應(yīng)用程序 SELFDESTRUCT 將被破壞，并且以這種方式使用它的應(yīng)用程序不再安全：
WhereCREATE 2 用于在同一位置重新部署合約，以使合約可升級。不再支持此功能，應(yīng)改用 ERC-2535 或其他類型的代理合約。
如果合約依賴于通過以 SELFDESTRUCT 合約作為受益人燃燒以太幣，則合約不是在同一交易中創(chuàng)建的。
智能合約相關(guān)風(fēng)險
EIP 1153
設(shè)想使用操作碼 TLOAD 和 TSTORE 的兩種場景：
被調(diào)用合約使用該操作碼
發(fā)起調(diào)用合約使用該操作碼
風(fēng)險 1 ：
相比于傳統(tǒng)的 SSTORE 和 SLOAD ，新增的瞬態(tài)存儲主要改變了數(shù)據(jù)的存儲期限，tstore 存儲的數(shù)據(jù)通過 tload 進(jìn)行讀取，在一筆交易執(zhí)行結(jié)束后該數(shù)據(jù)將會被釋放，而不是同 sstore 一樣寫入合約被永久性的記錄。開發(fā)者在使用該操作碼時應(yīng)該認(rèn)清該操作碼的特性，以免錯誤的使用導(dǎo)致數(shù)據(jù)不能正確的寫入到合約中而造成損失。另外，tstore 的數(shù)據(jù)屬于私有變量，僅合約本身可以訪問。如果想要外部使用該數(shù)據(jù)只能通過參數(shù)的形式進(jìn)行傳遞或暫存到一個 public stroage 變量中。
風(fēng)險 2 ：
另一個潛在風(fēng)險是，如果智能合約開發(fā)人員不正確管理瞬態(tài)存儲變量的生命周期，可能導(dǎo)致數(shù)據(jù)在不應(yīng)該的時間被清除或錯誤地保留。如果合約期望在事務(wù)的后續(xù)調(diào)用中使用存儲在瞬態(tài)存儲中的數(shù)據(jù)，但未能適當(dāng)?shù)毓芾磉@些數(shù)據(jù)的生命周期，可能會在不同調(diào)用之間錯誤地共享或丟失數(shù)據(jù)，從而導(dǎo)致邏輯錯誤或安全漏洞。考慮到類似于 Token 項(xiàng)目的 balance 或者 allowance 數(shù)據(jù)未能正確的存儲將會導(dǎo)致合約邏輯的錯誤，造成損失?；蛟趯?nbsp;owner 地址進(jìn)行設(shè)置時使用了該操作碼將會導(dǎo)致特權(quán)地址不能正確的被記錄從而丟失對合約重要參數(shù)的修改。
考慮一個智能合約，該合約使用瞬態(tài)存儲來臨時記錄一個加密貨幣交易平臺上的交易價格。該合約在每筆交易完成時更新價格，并允許用戶在短時間內(nèi)查詢最新價格。然而，如果合約設(shè)計沒有考慮到瞬態(tài)存儲在交易結(jié)束時被自動清除的特性，那么在一筆交易結(jié)束后到下一筆交易開始之前的這段時間內(nèi)，用戶可能會得到一個錯誤或過時的價格。這不僅可能導(dǎo)致用戶做出基于錯誤信息的決策，還可能被惡意利用，影響平臺的信譽(yù)和用戶的資產(chǎn)安全。
EIP-6780
該提案改變了之前 selfdestruct 操作碼的行為，不銷毀合約，僅轉(zhuǎn)移 token，僅與自毀同一交易中創(chuàng)建的合約才會被銷毀。這個 EIP 的影響相對較大。
用 create 2 在同一地址重新部署合約，以使合合約升級。不再支持此功能，應(yīng)改用 ERC-2535 或其他類型的代理合約。（這可能會影響到使用 create 2 實(shí)現(xiàn)可升級合約的鏈上合約的安全性）
智能合約中的 SELFDESTRUCT 操作允許合約銷毀，并將合約余額發(fā)送給指定的目標(biāo)地址。在這種情況下，合約使用 SELFDESTRUCT 銷毀以太幣，并將銷毀的以太幣發(fā)送給了合約。但是該合約僅能是在同一筆交易中創(chuàng)建的合約（同一筆交易中由本合約或其他合約創(chuàng)建的合約）。否則將僅轉(zhuǎn)賬以太而不銷毀合約（例如自毀且受益者為自毀合約，這將會不產(chǎn)生任何改變）。這將會影響一切依賴于 selfdestruct 進(jìn)行提款或其他操作的合約。
一種類似于 1inch CHI Token 的 Gas Token 的工作原理：保持一個偏移量，始終在此偏移量處執(zhí)行 CREATE 2 或 SELFDESTRUCT。在此更新之后，如果當(dāng)前偏移量的合約尚未正確自毀，則之后的 CREATE 2 將不能成功的部署合約。
該提案實(shí)施并不能導(dǎo)致直接對合約進(jìn)行攻擊，但會損害原有已部署的依賴 selfdestruct 操作的合約的正常邏輯（僅依賴自毀進(jìn)行資金轉(zhuǎn)移的合約不受到影響，如果后續(xù)操作必須要求自毀的合約被刪除，則受到影響），導(dǎo)致合約非預(yù)期工作，僅對合約以及用戶而言，可能導(dǎo)致合約的罷工，損失資金等危害(例如原本利用 create 2 在原地址部署新合約，自毀原合約進(jìn)行升級的合約，不再能夠成功部署)。長遠(yuǎn)來看，修改某項(xiàng)操作碼的功能可能會帶來中心化的問題。
例如現(xiàn)有一個金庫合約 vault 進(jìn)行更新：
create 2 臨時存儲合約用來臨時儲備 vault 的資金
自毀 vault 合約，資金轉(zhuǎn)賬到臨時合約（僅轉(zhuǎn)移了資金而沒有銷毀合約）
在原地址 create 2 新的 vault 合約（失敗，因?yàn)樵?nbsp;vault 合約沒有被銷毀）
自毀臨時合約將資金還給 vault（資金損失，vault 合約沒有被創(chuàng)建）
擴(kuò)展閱讀
坎昆升級將進(jìn)一步增強(qiáng)以太坊的競爭優(yōu)勢。但此次升級對核心智能合約層的改動帶來了風(fēng)險，這會影響現(xiàn)有的 DApps 的安全運(yùn)行。在進(jìn)行智能合約開發(fā)的過程中，這些改變以及可能引發(fā)的風(fēng)險同樣需要被高度關(guān)注。您可以與Salus聯(lián)系獲得風(fēng)險檢查或?qū)徲嬛С?，也可以通過進(jìn)一步閱讀相關(guān)內(nèi)容以了解變化。
Cancun Network Upgrade Specification
你可能感興趣的文章
-
以太坊坎昆升級后需數(shù)個月審計！閃電記賬系統(tǒng)
Uniswap基金會宣布，隨著坎昆升級確認(rèn)在3月啟動，v4版本將暫定在最快在今年第三季上線以太坊主網(wǎng)，而在3月坎昆升級后，v4仍將歷經(jīng)數(shù)月的的全面代碼審計過程,更多詳細(xì)資訊請…
2024-02-17 -
以太坊坎昆升級最后測試網(wǎng)Holesky今晚啟動！Dencun三月上線主網(wǎng)
最后一個在以太坊主網(wǎng)之前升級的公共以太坊測試網(wǎng)Holesky將在今（7）日北京時間大約晚間7:30啟動，成功啟動后，以太坊核心團(tuán)隊(duì)也會確認(rèn)主網(wǎng)上線日期，目前預(yù)計落在三月初到…
2024-02-08 -
以太坊坎昆升級在Sepolia測試網(wǎng)啟動！以太坊叩關(guān)2400美元
以太坊的重大升級Dencun繼17日于Goerli測試網(wǎng)成功上線后，今晨Sepolia測試網(wǎng)也順利完成了該升級，為下周（2/7）Holesky測試網(wǎng)的升級鋪路,更多詳細(xì)資訊請看下面正文…
2024-02-01 -
以太坊Sepolia和Holesky測試網(wǎng)2月初啟動坎昆升級！主網(wǎng)最快2月底
以太坊基金會今日宣布，繼1月17日Goerli測試網(wǎng)完成Dencun升級后，Sepolia和Holesky測試網(wǎng)將如期在1月30日和2月7日激活坎昆升級，如這兩個測試網(wǎng)后續(xù)升級皆順利，下一個就輪…
2024-01-26 -
以太坊坎昆升級，利好了哪些項(xiàng)目？
此次升級最大的目的就是對以太坊主鏈進(jìn)行擴(kuò)容，增強(qiáng)以太坊網(wǎng)絡(luò)的可擴(kuò)展性、安全性和可用性，提高主鏈的 TPS 和降低 Gas 費(fèi)，那么，坎昆升級，利好了哪些項(xiàng)目？下面一起來看…
2024-01-25 -
以太坊Dencun坎昆升級出狀況！上線Goerli測試網(wǎng)發(fā)生兩大問題
以太坊的Dencun升級如期于今日在Goerli測試網(wǎng)上啟動，但遇到了一些挑戰(zhàn)。核心開發(fā)者Tim Beiko指出，雖然升級已實(shí)施，但參與的驗(yàn)證者數(shù)量不多，且出現(xiàn)了分叉（Chain Split）…
2024-01-18 -
以太坊坎昆升級勢在必行！V神認(rèn)同部分產(chǎn)品使用Validiums而非Rollups
以太坊創(chuàng)辦人Vitalik Buterin剛剛于推特上回復(fù)社群意見，明確表達(dá)自身對于Validium的定義…
2024-01-17 -
以太坊坎昆升級日期已定 測試網(wǎng)1月17日激活
以太坊在去年4月中旬完成上海升級之后，驗(yàn)證者得以將質(zhì)押已久的ETH從信標(biāo)鏈中提出，以太坊開發(fā)者隨即籌備下一次的重大升級——坎昆升級(Dencun升級),更多詳細(xì)資訊請看下面…
2024-01-05 -
以太坊預(yù)計2024年1月坎昆升級！Layer2板塊OP、ARB、IMX急漲
以太坊坎昆升級出現(xiàn)新進(jìn)展，據(jù)7日召開的以太坊執(zhí)行層核心開發(fā)者會議（ACDE）記錄，開發(fā)者已做好了測試網(wǎng)的分叉升級準(zhǔn)備，Goerli測試網(wǎng)預(yù)計將在明年1月啟動坎昆升級，受此消…
2023-12-09 -
以太坊坎昆升級因測試網(wǎng)共識問題再延2024年！原定2023年底
以太坊繼上海升級后，將迎來重要的坎昆升級，今年6月時，以太坊核心開發(fā)者原先預(yù)期，坎昆升級將在今年底前啟動，不過以太坊客戶端開發(fā)者周四表示，坎昆升級不會在2023年底…
2023-10-27
