CrtiK:钻石代理合约最佳安全实践
作者:CertiK
代理合约是智能合约开发者的重要工具。如今,合约系统里已有多种代理模式和对应的使用规则。我们之前已经概述了可升级的代理合约安全最佳实践。
钻石代理合约,也被称为“钻石”,是以太坊智能合约的一种设计模式,由以太坊改进提案(EIP)2535引入。
钻石模式的设计可以解决以太坊网络的最大合约大小限制问题。通过将一个大型合约分解成较小的切面,钻石模式允许开发人员建立更复杂和功能丰富的智能合约而不受大小限制影响。
本文提供了EIP-2535的概述,包括与广泛使用的透明代理模式和UUPS代理模式的比较,以及它对开发者社区的安全考虑。
在EIP-2535的背景下,"钻石 "是一个代理合约,其功能实现由不同的逻辑合约提供,称为“切面”。
钻石标准使用类比的方式扩展了“钻石切割”的功能 ,用于增加,替换,或删除切面和功能。
与传统的代理模式相比,“钻石”等同于代理合约,而不同的“切面”对应于实现合约。一个钻石代理的不同切面可以共享内部函数、库和状态变量。钻石的关键组成部分如下:
作为代理的中央合约,将函数调用路由到适当的切面。它包含一个函数选择器到“切面”地址的映射。
实现特定功能的单个合约。每个切面都包含一组可以被钻石调用的函数。
是在EIP-2535中定义的一组标准函数,提供关于钻石中使用的切面和函数选择器的信息。钻石放大镜允许开发者和用户检查和了解钻石的结构。
用于添加、替换或删除钻石中的切面及其相应的功能选择器的函数。只有授权的地址(例如,钻石的所有者或多签名的合约)才能进行钻石切割。
所有的代理都使用fallback()函数,将函数调用委托给外部地址。下面是钻石代理的实现和传统代理的实现。
而其主要区别在于:在钻石代理中,切面的地址是由调用者的msg.sig(函数选择器)到切面的地址的hashmap决定的,而在传统代理中,impl地址不依赖于调用者的输入。
钻石代理fallback 函数
传统的代理fallback 函数
SelectorToFacet映射决定了哪个合约包含了每个函数选择器的实现。项目工作人员经常需要添加、替换或删除这种函数选择器到实现合约的映射。EIP-2535规定:为了达到此目的,必须有一个 diamondCut() 函数。下面是一个示例接口。
每个FacetCut结构都包含一个切面地址和四字节的功能选择器数组,以在钻石代理合约中进行更新。FaceCutAction允许人们添加、替换和删除功能选择器。diamondCut()函数的实现应该包括足够的访问控制,防止存储槽的碰撞,在失败时进行恢复等。
为了查询一个钻石代理有哪些功能,使用哪些切面,我们使用了“钻石放大镜”。“钻石放大镜”是一个特殊的切面,它实现了EIP-2535中定义的以下接口:
facets()函数应该返回所有切面的地址和它们的四字节的函数选择器。facetFunctionSelectors()函数应该返回一个特定切面所支持的所有函数选择器。facetAddresses()函数应该返回一个钻石所使用的所有切面地址。
鉴于钻石代理将不同的函数调用委托给不同的实现合约,正确管理存储槽以防止冲突是至关重要的。EIP-2535提到了几种存储槽管理方法。
这个切面可以在结构中声明状态变量。这个切面可以使用任意数量的结构,每个结构有不同的存储位置。每个结构在合约存储中都有一个特定的位置。切面可以声明他们自己的状态变量,但不能与其他切面所声明的状态变量的存储位置相冲突。EIP-2535中提供了一个样本库和钻石存储合约,如下图所示:
App存储是钻石存储的一个更专精的版本。这种模式被用来更方便、更容易地共享切面的状态变量。一个App存储结构被定义为包含一个应用程序所需的任意数量和类型的状态变量。一个切面总是将AppStorage结构声明为第一个也是唯一一个状态变量,位于存储槽的第0位。然后不同的切面可以从该结构中访问变量。
此外也有其他的存储槽管理策略,包括钻石存储和AppStorage的混合。比如有些结构在不同的切面之间共享,有些则是特定切面所特有的。在所有情况下,防止意外的存储槽碰撞是非常重要的。
目前Web3开发者社区使用的两种主要代理模式是透明代理模式和UUPS代理模式。在这一节中,我们简要比较了钻石代理模式与透明代理和UUPS代理模式。
1.EPI-2535:https://eips.ethereum.org/EIPS/eip-2535#Facets, State Variables and Diamond Storage
3.Diamond proxy reference implementation:https://github.com/mudgen/Diamond
代理和可升级的解决方案是较复杂的系统,OpenZeppelin为UUPS、透明及Beacon可升级代理提供代码库及全面的文档。然而对于钻石代理模式,虽然OpenZeppelin肯定了它的好处,但他们仍然决定不把EIP-2535钻石的实现纳入他们的库中。
通过将合约逻辑分解成更小、更容易管理的模块,开发人员可以更容易地测试和审计他们的代码。
资料来源:Aavegotchi Github
当钻石代理合约被部署时,它必须将DiamondCutFacet合约的地址添加到钻石代理合约中,并实现diamondCut() 函数。diamondCut()函数用于添加、删除或替换切面和函数,没有DiamondCutFacet和diamondCut(),钻石代理无法正常工作。
资料来源:Mugen’s Diamond-3-Hardhat
在智能合约中向存储结构添加新的状态变量时,必须将其添加到结构的末端。在结构的开头或中间添加新的状态变量会导致新的状态变量覆盖现有的状态变量数据,而新的状态变量之后的任何状态变量都可能会引用错误的存储位置。
AppStorage模式要求为钻石代理声明一个且仅有一个结构,并且该结构为所有切面所共享。如果需要多个结构,应该使用DiamondStorage模式。
不要将结构直接放在另一个结构中,除非确定不打算向内部结构添加更多状态变量。如果不覆盖结构之后所声明的变量存储槽,就无法在升级中向内部结构添加新的状态变量。
解决方法是将新的状态变量添加到存储映射结构中,而不是直接将“结构”放置在“结构”中。映射中的变量存储槽计算方式不同,在存储中不连续。
数组的大小将受到结构大小的影响。当一个新的状态变量被添加到一个结构中时,它会改变该结构的大小和布局。
与其他代理模式类似,每个变量都应该有一个唯一的存储槽。否则,同一位置的两个不同结构会相互覆盖。
initialize()函数通常用于设置重要的变量,如特权角色的地址。如果在合约部署时没有初始化,恶意行为者可以调用并控制合约。
如果合约中的任何一个切面能够调用selfdestruct()函数,它就有可能破坏整个合约,导致资金或数据损失。这在钻石代理模式中极其危险,因为多个切面可以访问代理合约的存储和数据。
目前,我们看到越来越多的项目在他们的智能合约中采用钻石代理模式。与传统代理相比,它具有灵活性和其他优势。
同时,项目团队应该进行严格的测试和第三方审计,以减少与实施钻石代理合约有关的漏洞风险。