全面理解智能合约升级_DRE:DDR币

译文出自:登链翻译计划

译者:Tiny熊

从技术角度对不同的以太坊智能合约升级模式和策略进行了调查,并提供了一套有关升级管理和治理的良好实践和建议。

什么是智能合约升级?

对于以太坊开发人员来说,智能合约升级并不是一个新概念。最早的升级模式之一可以追溯到2016年5月的NickJohnson的gist,是在4年前的时间,几乎覆盖了整个以太坊的历程。

从那时起,智能合约升级工作进行了很多的探索、出现了各种不用的实现方式。升级既可以用作在出现漏洞时进行修复,也可以用作逐步添加新功能来迭代系统开发。

但是,由于智能合约升级带来的技术复杂性以及它们可能对真正的权力下放构成威胁,因此围绕智能合约升级也存在很多争议。在这篇文章中,我们将讨论这两个问题。我们将介绍不同的升级实现,并回顾一些成功的示例,并讨论每个示例的优缺点。然后,我们将回顾一些用于治理和管理的良好实践,以减轻向系统添加升级选项的中心化风险。

让我们首先定义智能合约升级的含义:

什么是智能合约升级?智能合约升级是一种在保留存储和余额的同时,而又可以任意更改在地址中执行代码的操作。

但是在我们深入进行升级之前,我们将介绍一些无需实施全面升级即可更改系统的策略,这些策略可以作为升级的简单补充。

请坐稳了,这将是一个很长的文章。

升级替代方案

有许多策略可用于修改系统而无需完全升级。一个简单的解决方案是通过迁移来更改系统:部署一组新合约,将必要状态从旧合约复制到新合约(有时可以无信任地完成),根据社区共识,让社区开始与新合约进行交互。

本节中列出的升级策略可用于以可预测的方式修改系统,这与升级不同。修改系统这是根据已有的规则来进行管理,在更改时系统的行为更加可预测。让我们研究其中一些策略。

参数的配置

简单地调整合约中的一组参数,可修改范围非常有限,以至于我怀疑是否将其包含在此列表中。一个很好的例子是MakerDAO的稳定费率,这是在合约中可设置的数值,它会改变系统的行为。该值经常更改,并且由于其含义很清楚,因此可以放心地执行操作。

但是,重要的是要了解系统对这些参数中设置的极值的反应。任意高昂的费用或零费用都可能导致系统停止运行,甚至使攻击者能够窃取所有资金。在合约中硬编码合理范围的参数值通常是一个好主意,并以此作为保障措施。

合约注册表

由多个合约组成的系统可能依赖合约注册中心。每当合约A需要与B进行交互时,它首先会查询注册表以获得B的地址。通过对注册表的修改,管理员可以将B替换为替代实现B',从而改变其行为。AAVE的早期版本使用了这种模式。

但是,此机制在切换到B'时不会保留B的状态,如果需要手动迁移,则可能会出现问题。此模式的某些版本通过将逻辑和存储合约解耦来缓解这种情况:状态保持在不变的存储合约中,并且只能根据需要更改的业务逻辑合约。我们将在本文后面部分深入探讨逻辑和存储合约分离。

这种模式的另一个缺点是,它也为外部客户端带来了额外的复杂性,这些外部客户端在与系统交互之前也需要调用注册表。可以通过添加具有不可变接口的外部包装接口来减轻这种情况,该包装接口负责管理注册表查找。

策略模式

策略模式是更改合约中部分特定功能函数的代码的简便方法。替代在调用合约中实现函数来执行特定功能,而是通过调用单独的合约来处理该任务,通过切换该合约的实现,可以有效地在不同的“策略”之间进行切换。

Compound就是一个很好的例子,它具有不同的RateModel实现计算利率及其CToken合约可以在它们之间切换。由于已知更改仅限于系统的特定部分,这可以轻松地推出修复程序或在费率计算上改进gas消耗。当然,一个恶意利率模型实现可以设置为始终还原和停止系统,或为特定帐户提供任意高的利率。尽管如此,限制系统更改的范围仍使对这些更改的推理更加容易。

可插拔模块

策略模式的一个更复杂的变体是可插拔模块,其中每个模块都可以向合约添加新函数。在此模型中,主合约提供了一组核心不变的函数,并允许注册新模块。这些模块为核心合约增加了可调用的新函数。这种模式在钱包中最为常见,例如GnosisSafe或InstaDapp。用户可以选择将新模块添加到自己的电子钱包中,然后每次调用钱包合约时都要求从特定模块执行特定函数。

请记住,此模式要求核心合约没有漏洞。无法通过在此方案中添加新模块来修补管理模块本身上的任何漏洞。此外,根据实现方式的不同,新模块可能有权通过使用委托调用方式(DELEGATECALL,下面会进一步解释)代表核心合约运行任何代码,因此也应仔细检查它们。

升级模式

在前面不太简短的介绍之后,是时候进入实际的合约升级模式了。这些模式中的大多数都依赖于EVM原语(DELEGATECALL操作码),因此让我们从其工作原理的简要概述开始。

委托调用

在常规的CALL-消息调用中,合约A向B发送payload数据。合约B响应此payload数据执行其代码,可能会从其自己的存储中读取或写入数据,然后将响应返回给A。当B执行其代码时,它可以访问有关调用本身的信息,例如msg

}

由于代理在实现中使用了委托调用,因此就好像它自己在运行实现的代码一样。实现代码可以修改自己的存储和余额,并保留了调用的原始msg

functionupgrade(addressnewImplementation)external{require(msg

}

此版本通常还包含函数用来将代理的所有权转账到其他地址。Compound将这种模式与额外的twist一起使用:新的实现合约需要能_接受_转账,以防止意外升级到无效合约。

这种模式的好处是,与升级相关的所有逻辑都包含在代理中,并且实现合约不需要任何特殊逻辑即可充当委派目标(除实现合约限制和初始化程序中列出的一些例外)。但是,这种实现模式容易受到函数选择器冲突导致的漏洞的攻击。

选择器冲突和透明代理

以太坊中的所有函数调用都由有效载荷payload前4个字节来标识,称为“函数选择器”。选择器是根据函数名称及其签名的哈希值计算得出的。然而,4字节不具有很多熵,这意味着两个函数之间可能会发生冲突:具有不同名称的两个不同函数最终可能具有相同的选择器。如果你偶然发现这种情况,Solidity编译器将足够聪明,可以让你知道,并且拒绝编译具有两个不同函数名称,但具有相同4字节标识符的合约。

//这个合约无法通过编译,两个函数具有相同的函数选择器contractFoo{functioncollate_propagate_storage(bytes16)external{}functionburn(uint256)external{}}

但是,对于实现合约而言,完全有可能具有与代理的升级函数具有相同的4字节标识符的函数。这可能会导致尝试调用实现合约时,管理员无意中将代理升级到随机地址。这个帖子由PatricioPalladino解释了该漏洞,然后MartinAbbatemarco说明如何将其用于做恶.

这个问题可以通过开发用于可升级智能合约的适当工具解决,也可以通过代理本身解决。特别是,如果将代理设置为仅管理员能调用升级管理函数,而所有其他用户只能调用实现合约的函数,则不可能发生冲突。

//Samplecode,donotuseinproduction!contractTransparentAdminUpgradeableProxy{addressimplementation;addressadmin;fallback()externalpayable{require(msg

functionupgrade(addressnewImplementation)external{if(msg

}

该模式被称为“透明代理合约”(请勿与EIP1538混淆),在这篇文章中有很好的解释。这是OpenZeppelin升级(以前称为ZeppelinOS)现在使用的模式。它通常与ProxyAdmin合约结合使用,以允许管理员EOA与管理代理合约进行互动(管理员只能管理代理合约交互)。

让通过一个例子看看是怎么工作的。假定代理具有owner()函数和upgradeTo()函数,该函数将调用委派给具有owner()和transfer()函数的ERC20合约。下表涵盖了所有导致的情况:

msg

}abstractcontractUUPSProxiable{addressimplementation;addressadmin;functionupgrade(addressnewImplementation)external{require(msg

}

这种方法有几个好处。首先,通过在实现合约上定义所有函数,它可以依靠Solidity编译器检查任何函数选择器冲突。此外,代理的大小要小得多,从而使部署更便宜。在每次调用中,从存储中需要读取的内容更少,降低了开销。

这种模式有一个主要缺点:如果将代理升级到没有可升级函数的实现上,那就永久锁定在该实现上,无法再更改它。一些开发人员更喜欢保持可升级逻辑不变,以防止出现这些问题,而这样做的最佳方式是放在代理合约本身。

代理存储冲突和非结构化存储

在所有代理模式变体中,代理合约都需要至少一个状态变量来保存实现合约地址。默认情况下,Solidity存储变量在智能合约存储中的顺序是:声明的第一个变量移至插槽0,第二个变量移至插槽1,依此类推(映射和动态大小数组是此规则的例外)。这意味着,在以下代理合约中,实现合约地址将保存到存储插槽零。

//Samplecode,donotuseinproduction!contractProxy{addressimplementation;}

现在,如果我们将该代理与以下看似无害的实现合约结合使用,会发生什么?

//Samplecode,donotuseinproduction!contractBox{addresspublicvalue;functionsetValue(addressnewValue)public{value=newValue;}}

遵循Solidity存储布局规则,通过代理对Box

}

尽管有效,但它有一个缺点,即要求所有委托目标合约都添加此额外的虚拟变量。这限制了可重用性,因为普通合约不能用作实现合约。这也容易出错,因为很容易忘记在合约中添加该额外变量。

我是广告

本文来源于非小号媒体平台:

登链社区

现已在非小号资讯平台发布105篇作品,

非小号开放平台欢迎币圈作者入驻

入驻指南:

/apply_guide/

本文网址:

/news/9562977.html

免责声明:

1.资讯内容不构成投资建议,投资者应独立决策并自行承担风险

2.本文版权归属原作所有,仅代表作者本人观点,不代表非小号的观点或立场

上一篇:

币安为何推出第三条链?这对BNB意味着什么?

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:0ms0-4:176ms