十大DeFi安全最佳實踐方式（下）

上周CertiK發布了幹貨分享 | 十大DeFi安全最佳實踐方式（上），為大家分享DeFi安全10個最佳實踐的前3個實踐方式，今天將為大家帶來剩余的7個實踐內容，進一步助力各位讀者保障自身應用程序的安全。

超長幹貨，建議先收藏再看哦！

4. 避免常見問題

這一點對 Solidity 來說是一個總括性的問題——如果希望合約安全，就需要在構建它時依次核實所有的DeFi安全准則。而要編寫真正可靠的Solidity，就必須了解它的內部工作原理。否則，可能會容易受到以下攻擊：

上溢出/下溢出（Overflows/Underflows）

在Solidity 中，uint256和int256被 "包裹"了。

這意味着，如果你在uint256中擁有一個最大的數，然後將其添加到其中，它將變成可能存在的最小數字。

這一點務必需要檢查與核實，在0.8之前的Solidity版本中，可以使用類似safemath[1]的庫來解決這一問題。

在Solidity 0.8.x中，默認情況下會檢查算術運算操作。這意味着x+y將在溢出時拋出異常。因此，請確認你正在使用的Solidity版本。

循環gas限制（Loops Gas Limit）

當編寫動態大小的循環時，需要注意它的極限規模大小。一個循環的規模可以很容易地超過最大塊限制，並使合約在回滾時失效。

避免使用'tx.origin'

`tx.origin`可能會導致類似釣魚的攻擊[2]，因此不應該被用於智能合約的身份驗證。

代理存儲衝突（Proxy Storage Collision） 

對於採用代理實現模式的項目，可以通過更改代理合約中的實現合約地址來更新實現。

通常，代理合約中有一個特定的變量存儲實現合約地址。如果這個變量的存儲位置是固定的，而在執行合約中恰好有另一個變量具有相同的存儲位置索引/偏移量，那么就會發生存儲衝突。

要觸發存儲衝突，可以在Remix中執行以下步驟：

①部署實現合約；

②部署代理合約，將實現合約的部署地址作為其構造參數；

③在代理合約的部署地址上運行實現合約；

④調用myAddress()函數。它將返回一個非零地址，該地址是存儲在代理合約中 otherContractAddress 變量中的部署地址。

在上述四個步驟中發生了什么？

1. 部署實現合約並生成其部署地址；

2. 代理合約使用實現合約的部署地址進行部署，其中代理合同的構造函數被調用，並將otherContractAddress變量賦值為實現合約的部署地址；

3. 在步驟③中，實現合同與代理存儲進行交互，即部署的實現合約中的變量可以讀取部署的代理合約中相應的哈希碰撞變量的值。

4. myAddress()函數的返回值就是部署的實現合約中myAddress變量的值，它與部署的代理合約中的otherContractAddress變量產生衝突，隨即可以在那裏獲得otherContractAddress變量的值。

為了避免代理存儲衝突，我們建議开發者通過為存儲變量選擇僞隨機槽來實現非結構化存儲代理。

一種常見的做法是為項目採用一種可靠的代理模式。最廣泛採用的代理模式是通用可升級代理標准（UUPS）[3]和透明代理模式[4]。它們都提供了具體的存儲 "偏移"，以避免在代理合同和實現合同中使用相同的存儲槽。

下面是一個使用透明代理模式實現隨機存儲的例子?

保證代幣轉移計算的准確性

通常情況下，對於普通的ERC20代幣，收到的代幣數量應該等於用函數調用的原始數量。

例如——參見下方函數retrieveTokens()?

然而，如果代幣是通縮的，即每次轉移都有費用，那么實際收到的代幣數量將少於最初要求轉移的代幣數量。

在如下所示的修改後的函數retrieveTokens(uint256 amount)中，`amount'是根據轉账操作前後的余額重新計算的。不管代幣轉移機制如何，這都將准確地計算出被轉移到`address(this)'的代幣數量。

正確刪除數據

有很多場景需要移除合約中不再需要的某個對象或值。

在像Java這樣的標准語言中，有一個垃圾收集機制可以自動和安全地處理刪除數據的問題。然而，在Solidity中，开發者必須手動處理 "垃圾"。因此，垃圾處理不當可能會給智能合約帶來安全問題。

例如，當用delete（即`delete array[member]'）從數組中刪除單個成員時，`array[member]'仍將存在，但根據`array[member]'的類型重置為一個默認值。开發者應該要么跳過這個成員，要么重新組織數組並減少其長度。

比如?

這些只是需要注意的一些漏洞，查看審計師Sigma Prime關於Solidity常見漏洞的文章[5]可以幫助你深入了解Solidity以及避免這些 "陷阱"。

5. 函數的可見性和修飾符

在Solidity語言的設計中，有四種類型的函數可見性：

• private：該函數只在當前合約中可見。

• internal：該函數在當前合約和派生合約中是可見的。

• external：該函數只對外部調用可見。

• public：該函數對內部和外部的調用都是可見的。

可見性是指針對特定功能的上述四種可見性中的一種用於限制某一組用戶的訪問。 

修飾符則指的是專門為訪問限制目的而編寫的自定義代碼段。

可見性和修飾符結合起來，可以為特定功能設置適當的訪問權限。例如，在ERC20實現的函數`_mint()`中：

函數_mint()的可見性被設置為internal，這正確地保護了它不被外部調用。為了給mint功能設置一個適當的訪問權限，可以使用下方的代碼段：

函數mint()只允許合約的所有者鑄造，require()語句則可以防止所有者鑄造過多的代幣。

正確使用可見性和修飾符有利於合約管理。而未正確使用的設置可能會讓惡意攻擊者調用管理配置函數來操縱項目，過度的修飾符設置也可能會給合約帶來中心化的問題，並引起社區的不安。

6. 部署到主網前必須獲得外部審計

代碼審計就像是接受一個以安全為重心的同行評審。審計員會逐行查看整個代碼庫，並使用形式化驗證技術來檢查智能合約是否存在任何漏洞。

如果不想讓自己的項目赤裸裸的暴露於漏洞的威脅之下，切忌在沒有審計的情況下部署代碼，或者在審計後改變代碼並重新部署。

這裏有一些幫助確保審計全面的建議：

a. 記錄一切，以便審計員更容易跟蹤所發生的事情b. 保持與審計團隊的溝通渠道暢通，以防他們有任何疑問可以得到及時解決c. 在你的代碼中添加注釋，確保其可以更快被理解

然而，安全是你自己需要切身關注的重中之重，一股腦的將身家全部寄予審計機構對你的安全保障是不該存在的心態。

如果你的協議遭到攻擊，最大的受害者是你自己以及你的團隊。

盡管安全審計非常有用，提供了額外的一輪審查，並可以幫助你查找未曾發現的漏洞，但它也不能確保100%的安全。

Tincho在推特上开啓了一個關於如何最高效率地進行安全審計的話題[6]，感興趣的小夥伴可以去看看。當然，如果你有任何審計需求，或是相關的疑問，隨時可在公衆號底部留言進行咨詢。

7. 進行測試並使用靜態分析工具

你需要對應用程序進行適當的測試。

如果你正苦惱於無處下手，Chainlink starter kit repos提供了一些測試套件樣本[7]供你參考。

像Aave和Synthetix這樣的協議也有很好的測試套件，建議也可以通過查看他們的代碼以了解一些測試的最佳實踐（也包括更普遍的編碼）。

靜態分析工具也會幫助你更早地發現代碼的錯漏之處。它們可以自動運行監測你的合約並尋找潛在的漏洞。

目前最流行的靜態分析工具之一是Slither[8]。CertiK目前還在根據其在審計、驗證和監控智能合約方面的豐富經驗，建立下一代靜態分析、語法分析、漏洞分析和形式驗證工具。

8.將安全視為重中之重

毫無疑問，在生產部署之前，您應該盡最大努力創建一個安全可靠的智能合約，但區塊鏈和DeFi協議快速發展的現實以及新型攻擊方式的不斷出現意味着這遠遠不足以保障安全。

开發者們應當積極獲取並跟蹤最新的監測和警報數據，並盡可能嘗試在智能合約本身中引入面向未來的功能以訪問快速增長的動態安全洞察數據，這一行為除了安全外更有其他益處。

CertiK Skynet天網動態掃描系統作為一個24*7全天候運行的安全情報引擎，可為智能合約的鏈上部署提供多維度和實時的透明安全監控。

它包括社會情緒、治理、市場波動、安全評估等安全基元，為區塊鏈用戶、社區和代幣投資者提供全面的安全見解。

而CertiK安全排行榜提供公开透明的、易於理解的安全見解和最新的項目狀態，所有人都可以通過這個平臺查詢所有需要的安全數據信息，並向平臺提供他們所認可的在安全領域表現優異的DeFi項目，這將激勵形成社區問責制。

9. 制定一個“翻身”計劃

對於一個協議來說，如果在受到攻擊後有一個准備許久的“翻身”計劃無疑是很好的一步落子。

• 購买相關保險產品

• 設置一個緊急 "暫停 "功能

• 有一個升級計劃

隨着加密技術的不斷發展，保險平臺及計劃作為一種從損失中被解救出來的保障越來越受到廣大項目和用戶的歡迎，保證了去中心化的同時更增加了一定程度的安全性。比如CertiK开發的去中心化鏈上資金保險平臺CertiKShield，可保證項目及其投資者的資產安全，避免其受到安全漏洞或黑客攻擊導致的資產丟失、被盜或無法訪問等情況的影響。

設置緊急 "暫停 "功能是一個有利有弊的策略。

如果發現漏洞，此功能將停止與智能合約的所有交互。如果你設置了這個功能，你需要確保你的用戶知道誰能夠操作它。

如果只有一個用戶，你就不是在運行一個去中心化的協議，那么用戶就可以通過代碼發現這些。因此要注意該功能實現方式，因為你實際上可能最終在一個去中心化的平臺上得到了一個中心化的協議。

進行升級也有同樣的問題。轉移到一個沒有bug的智能合約可能很好，但升級仍要十分慎重，以免中心化問題的出現。

因此有相當一部分安全機構幾乎極力反對可升級的智能合約模式。

更多關於智能合約升級的內容你可以在YouTube上觀看帕特裏克-柯林斯關於這個話題的視頻[9]或是查看《智能合約升級現狀》的演講[10]。

想要了解更多保險方面的建議？歡迎加入Chainlink Discord：

https://discord.gg/2YHSAey

10. 防止搶先交易Front-running

在區塊鏈中，所有的交易在mempool[11]中都是可見的，這意味着每個人都有機會看到你的交易，並有可能在你的交易進行之前進行交易，以便從你的交易中獲利。

例如，假設你使用DEX以當前市場價格將5個ETH兌換成DAI。一旦你把你的交易發送到mempool進行處理，一個先行者可以在你之前進行交易，購买大量的ETH，導致價格上漲。然後他們可以以更高的價格向你出售他們購买的ETH，並以差價獲利。

目前，搶先交易機器人[12]在區塊鏈世界中肆意妄為，以犧牲普通用戶的利益為代價獲利。

這個術語來自於傳統金融，交易員會使用同樣的操作來獲利，涉及到了股票、商品、衍生品等等金融資產和工具。

作為另一個例子，下方列出的函數就具備被搶先的風險。

根據修飾符'initializer'，該函數只能被調用一次。

如果攻擊者在mempool中監控調用`initialize（）`函數的交易，那么攻擊者就可以用一組定制的代幣、分發服務器（distributor）, 和工廠（factory）的值來`復制`該交易，並最終控制整個合約。由於函數 "initialize() "只能被調用一次，合約所有者無法對這種攻擊進行防御。

這通常也與礦工可提取值或MEV[13]有關。MEV是指礦工或機器人對交易進行重新排序，以便他們能以某種方式從排序中獲利。

就像搶先者支付更多的gas以使他們的交易領先於你的交易一樣，礦工可以直接重新排序交易，使他們的交易領先於你的交易。在整個區塊鏈生態系統中，MEV每天從普通用戶那裏竊取的資產高達數百萬美元。

幸運的是，一群世界級的智能合約和密碼學研究人員，包括Chainlink實驗室的首席科學家Ari Juels，正致力於用一種稱為“公平排序服務”的解決方案解決這一問題。

正在开發的解決方案——Chainlink公平排序服務（FSS）

Chainlink 2.0白皮書[14]概述了公平排序服務的主要特點，這是一個由Chainlink去中心化預言機網絡（DONs）提供動力的安全鏈外服務，將用於根據DApp概述的公平時間概念來排序交易。

FSS旨在極大地緩解搶先交易以及MEV的負面影響，並為整個區塊鏈生態系統的用戶減少費用消耗。

關於這方面的更多內容可以通過一篇介紹性的博文[15]或是Chainlink 2.0白皮書的第五節中進行了解。

除了FSS之外，緩解搶先交易問題的最好方法之一是盡可能降低交易排序的重要性，從而抑制協議中交易的重新排序及MEV。

寫在最後

加密世界是一個公正透明且需要我們每一個人協作互助的地方，這一點在开發者們身上體現尤甚。

在保護自己的這一點上，回顧已發生的攻擊事件有助於了解惡意攻擊者是如何實施攻擊的。除此之外，你還可以通過7*24全天候安全洞察系統（如CertiK Skynet天網）實時接收最新的鏈上安全漏洞相關信息及其更新狀況。 

如果你想深入了解安全又怕過程太枯燥，建議一定要看看Ethernaut遊戲[16]。你可以通過它了解DeFi中的安全問題，它包含了大量DeFi的安全實例，以及Solidity的許多內涵和外延。

還有Damn Vulnerable DeFi[17]也可以娛樂的方式學習相關安全知識。

如果想要了解更多閃電貸攻擊的信息，你可以登錄Prevent Flash Loan Attacks website[18]進行查看。

對加密世界的每個人來說，從錯誤中學習並吸取教訓是最基本的，這可以確保我們的智能合約被安全地構建並盡可能廣泛地採用。

如果這篇文章裏的解決方案中還有更多你想要了解的信息，請參閱Chainlink文檔[19]和CertiK文檔[20]。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。