幹貨：鑽石代理合約最佳安全實踐

代理合約是智能合約开發者的重要工具。如今，合約系統裏已有多種代理模式和對應的使用規則。我們之前已經概述了可升級的代理合約安全最佳實踐。

本文我們將介紹了另一種在开發者社區頗受青睞的代理模式，即鑽石代理模式。

鑽石代理合約，也被稱為“鑽石”， 是以太坊智能合約的一種設計模式，由以太坊改進提案（EIP） 2535 引入。

鑽石模式通過將合約的功能分割成較小的合約（也被形象地稱為“切面”），允許合約擁有無限的功能。鑽石充當代理，將函數調用路由到適當的切面。

鑽石模式的設計可以解決以太坊網絡的最大合約大小限制問題。通過將一個大型合約分解成較小的切面，鑽石模式允許开發人員建立更復雜和功能豐富的智能合約而不受大小限制影響。

與傳統的可升級合約相比，鑽石代理提供了巨大的靈活性。它們允許合約部分升級，增加、替換或刪除選定的部分函數，而不觸及其他部分。

本文提供了 EIP-2535 的概述，包括與廣泛使用的透明代理模式和 UUPS 代理模式的比較，以及它對开發者社區的 安全考慮。

在 EIP-2535 的背景下，"鑽石 "是一個代理合約，其功能實現由不同的邏輯合約提供，稱為“切面”。

想像一下，真正的鑽石有不同的側面，叫做切面（facet），那么相應的以太坊鑽石合約也有不同的切面。每一個鑽石借用功能的合約都是不同的側面或切面（facet）。

鑽石標准使用類比的方式擴展了“鑽石切割”的功能 ，用於增加，替換，或刪除切面和功能。

此外，鑽石標准提供了稱為“鑽石放大鏡(Diamond  Loupe)”的功能，返回關於切面的信息和鑽石存在的功能。

與傳統的代理模式相比，“鑽石”等同於代理合約，而不同的“切面”對應於實現合約。一個鑽石代理的不同切面可以共享內部函數、庫和狀態變量。鑽石的關鍵組成部分如下：

作為代理的中央合約，將函數調用路由到適當的切面。它包含一個函數選擇器到“切面”地址的映射。

實現特定功能的單個合約。每個切面都包含一組可以被鑽石調用的函數。

是在 EIP-2535 中定義的一組標准函數，提供關於鑽石中使用的切面和函數選擇器的信息。鑽石放大鏡允許开發者和用戶檢查和了解鑽石的結構。

用於添加、替換或刪除鑽石中的切面及其相應的功能選擇器的函數。只有授權的地址（例如，鑽石的所有者或多籤名的合約）才能進行鑽石切割。

與傳統代理類似，當鑽石代理上有一個函數調用時，代理的 fallback 函數（回退函數）就會被觸發。與鑽石代理的主要區別是，在回退函數中，有一個 selectorToFacet 映射，存儲並確定哪個邏輯合約地址有被調用的函數的實現。然後，它使用 delegatecall 來執行該函數，就像傳統的代理一樣。

所有的代理都使用 fallback()函數，將函數調用委托給外部地址。下面是鑽石代理的實現和傳統代理的實現。

值得注意的是它們的匯編代碼塊非常相似，因此唯一的區別是鑽石代理委托調用中的切面地址和傳統代理委托調用中的 impl 地址。

而其主要區別在於：在鑽石代理中，切面的地址是由調用者的 msg.sig（函數選擇器）到切面的地址的 hashmap 決定的，而在傳統代理中，impl 地址不依賴於調用者的輸入。

鑽石代理 fallback 函數

傳統的代理 fallback 函數

SelectorToFacet 映射決定了哪個合約包含了每個函數選擇器的實現。項目工作人員經常需要添加、替換或刪除這種函數選擇器到實現合約的映射。EIP-2535 規定：為了達到此目的，必須有一個 diamondCut() 函數。下面是一個示例接口。

每個 FacetCut 結構都包含一個切面地址和四字節的功能選擇器數組，以在鑽石代理合約中進行更新。FaceCutAction 允許人們添加、替換和刪除功能選擇器。diamondCut()函數的實現應該包括足夠的訪問控制，防止存儲槽的碰撞，在失敗時進行恢復等。

為了查詢一個鑽石代理有哪些功能，使用哪些切面，我們使用了“鑽石放大鏡”。“鑽石放大鏡”是一個特殊的切面，它實現了 EIP-2535 中定義的以下接口：

facets()函數應該返回所有切面的地址和它們的四字節的函數選擇器。facetFunctionSelectors()函數應該返回一個特定切面所支持的所有函數選擇器。facetAddresses()函數應該返回一個鑽石所使用的所有切面地址。

facetAddress()函數應該返回支持給定選擇器的切面，如果沒有找到，則返回 address( 0)。請注意，不應該有一個以上的切面地址具有相同的功能選擇器。

鑑於鑽石代理將不同的函數調用委托給不同的實現合約，正確管理存儲槽以防止衝突是至關重要的。EIP-2535 提到了幾種存儲槽管理方法。

這個切面可以在結構中聲明狀態變量。這個切面可以使用任意數量的結構，每個結構有不同的存儲位置。每個結構在合約存儲中都有一個特定的位置。切面可以聲明他們自己的狀態變量，但不能與其他切面所聲明的狀態變量的存儲位置相衝突。EIP-2535 中提供了一個樣本庫和鑽石存儲合約，如下圖所示：

App 存儲是鑽石存儲的一個更專精的版本。這種模式被用來更方便、更容易地共享切面的狀態變量。一個 App 存儲結構被定義為包含一個應用程序所需的任意數量和類型的狀態變量。一個切面總是將 AppStorage 結構聲明為第一個也是唯一一個狀態變量，位於存儲槽的第 0 位。然後不同的切面可以從該結構中訪問變量。

此外也有其他的存儲槽管理策略，包括鑽石存儲和 AppStorage 的混合。比如有些結構在不同的切面之間共享，有些則是特定切面所特有的。在所有情況下，防止意外的存儲槽碰撞是非常重要的。

與透明代理和 UUPS 代理的比較

目前Web3开發者社區使用的兩種主要代理模式是透明代理模式和 UUPS 代理模式。在這一節中，我們簡要比較了鑽石代理模式與透明代理和 UUPS 代理模式。

1.EPI-2535:https://eips.ethereum.org/EIPS/eip-2535 #Facets,% 20 State% 20 Variables% 20 and% 20 Diamond% 20 Storage

2.EPI-1967:https://eips.ethereum.org/EIPS/eip-1967

3.Diamond proxy reference implementation: https://github.com/mudgen/Diamond

4.OpenZeppelin implementation: https://github.com/OpenZeppelin/openzeppelin-contracts/tree/v4.7.0/contracts/proxy

代理和可升級的解決方案是較復雜的系統，OpenZeppelin 為 UUPS、透明及 Beacon 可升級代理提供代碼庫及全面的文檔。然而對於鑽石代理模式，雖然 OpenZeppelin 肯定了它的好處，但他們仍然決定不把 EIP-2535 鑽石的實現納入他們的庫中。

因此，使用現有的第三方庫或自行實現該解決方案的开發者在實施時必須格外謹慎。在此我們編寫了一份安全最佳實踐清單，供开發者社區參考。

通過將合約邏輯分解成更小、更容易管理的模塊，开發人員可以更容易地測試和審計他們的代碼。

此外，這種方法允許开發人員專注於構建和維護合約的特定方面，而不是管理一個復雜的、單一的代碼庫。最終的結果是一個更加靈活和模塊化的代碼庫，可以很容易地在不影響合約其他部分的情況下被更新和修改。

資料來源：Aavegotchi Github

當鑽石代理合約被部署時，它必須將 DiamondCutFacet 合約的地址添加到鑽石代理合約中，並實現 diamondCut() 函數。diamondCut()函數用於添加、刪除或替換切面和函數，沒有 DiamondCutFacet 和 diamondCut()，鑽石代理無法正常工作。

資料來源：Mugen’s Diamond-3-Hardhat

在智能合約中向存儲結構添加新的狀態變量時，必須將其添加到結構的末端。在結構的开頭或中間添加新的狀態變量會導致新的狀態變量覆蓋現有的狀態變量數據，而新的狀態變量之後的任何狀態變量都可能會引用錯誤的存儲位置。

AppStorage 模式要求為鑽石代理聲明一個且僅有一個結構，並且該結構為所有切面所共享。如果需要多個結構，應該使用 DiamondStorage 模式。

不要將結構直接放在另一個結構中，除非確定不打算向內部結構添加更多狀態變量。如果不覆蓋結構之後所聲明的變量存儲槽，就無法在升級中向內部結構添加新的狀態變量。

解決方法是將新的狀態變量添加到存儲映射結構中，而不是直接將“結構”放置在“結構”中。映射中的變量存儲槽計算方式不同，在存儲中不連續。

數組的大小將受到結構大小的影響。當一個新的狀態變量被添加到一個結構中時，它會改變該結構的大小和布局。

如果該結構被用作數組中的一個元素，這可能會導致問題。如果結構的大小和布局發生變化，那么數組的大小和布局也會發生變化，這可能會導致索引或其他依賴結構大小和布局一致的操作出現問題。

與其他代理模式類似，每個變量都應該有一個唯一的存儲槽。否則，同一位置的兩個不同結構會相互覆蓋。

initialize()函數通常用於設置重要的變量，如特權角色的地址。如果在合約部署時沒有初始化，惡意行為者可以調用並控制合約。

建議在初始化/設置函數上加入適當的訪問控制，或者確保該函數在合約部署時被調用，不能被再次調用。

如果合約中的任何一個切面能夠調用 selfdestruct()函數，它就有可能破壞整個合約，導致資金或數據損失。這在鑽石代理模式中極其危險，因為多個切面可以訪問代理合約的存儲和數據。

目前，我們看到越來越多的項目在他們的智能合約中採用鑽石代理模式。與傳統代理相比，它具有靈活性和其他優勢。

然而，額外的靈活性也可能意味着給攻擊者提供了更廣泛的攻擊面。我們希望這篇文章對开發者社區了解鑽石代理模式的機制及其安全考慮有所幫助。

同時，項目團隊應該進行嚴格的測試和第三方審計，以減少與實施鑽石代理合約有關的漏洞風險。

CertiK 會持續發布此類技術文章，以幫助更多开發者進行安全开發。關注我們，獲取更多同類信息及資訊！

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