Web3.0安全开发实践：代理合约最佳实践总结

代理模式使智能合约能够升级其逻辑，同时维持其链上地点和状态值。对代理合约的调用会通过delegateCall的方式执行来自逻辑合约的代码，以修改代理合约的状态。
本文将为大家概述代理合约的范例、相干的安全事件和发起，以及使用代理合约的最佳实践。
可升级的合约和代理模式简介

我们都知道区块链的「不可窜改」特质，也阐明了智能合约代码在摆设于区块链上后就无法被修改。
因此当开发者想为逻辑升级、修复错误或因安全更新试图更新合约代码时，他们必须摆设一个新的合约，并会生成一个新的合约地点。
想要解决这个问题，就可以用代理模式。
代理模式实现了合约的可升级性，而且不会改变合约的摆设地点，这也是目前最广泛的合约升级模式。
代理模式是一个可升级的合约系统，包罗代理合约和逻辑实现合约。
代理合约处置惩罚用户交互和数据及合约状态存储。用户对代理合约的调用会通过delegatecall()执行来自逻辑合约的代码，从而改变代理合约的状态。升级则是通过更新在代理合约预定存储槽里记录的逻辑合约地点来实现。
较为常规的三种代理模式分别是透明代理、UUPS代理和Beacon代理。

• 透明代理
  

在透明代理模式中，升级功能是在代理合约中实现的。 代理合约的管理员角色被赋予了利用代理合约的直接权限，以更新代理对应的逻辑实现地点。没有管理员权限的调用者则会把他们的调用委托给实现合约。
注意：代理合约管理员不能是逻辑实现合约的关键角色，乃至也不能是普通用户，因为代理管理员无法与实现合约进行交互。

• UUPS代理
  

在UUPS（Universal Upgradeable Proxy Standard）模式中，合约升级功能是在逻辑合约中实现的。由于升级机制存储在逻辑合约中，升级过后的版本可以删除升级相干的逻辑，以克制未来的升级。在这种模式下，所有对代理合约的调用都会被转发给逻辑实现合约。

• Beacon代理
  

Beacon代理模式允许多个代理合约通过引用Beacon合约来共享同一个逻辑实现。Beacon合约为调用的代理合约提供逻辑实现合约的地点，当升级到一个新的逻辑实现地点时，只必要更新Beacon合约里记录的地点即可。

代理误用和安全事件

开发职员可以利用代理模式合约来实现可升级的合约系统。然而，代理模式也有肯定的利用门槛，如果使用不当，可能会给项目带来堪称毁灭性的安全问题。以下部门展示了与代理误用相干的事件，以及代理带来的中心化风险。

• 代理管理的密钥走漏
  

代理管理员控制着透明代理模式的升级机制，如果管理员的私钥被走漏，攻击者可以升级逻辑合约并在代理状态上执行他们本身的恶意逻辑。
2021年3月5日，PAID Network遭受了由于私钥管理不善而引起的“铸币”攻击。PAID Network被攻击者利用，攻击者窃取了代理管理员的私钥并触发了升级机制以更改逻辑合约。升级后，攻击者可以销毁用户的PAID，并为本身铸造了一批PAID，随后再将其出售。代码本身并不存在安全漏洞，而是攻击者从管理员那边获取了升级合约的私钥。

• 未初始化的UUPS代理实现
  

对于UUPS代理模式，在代理合约的初始化过程中，初始参数由调用者传给代理合约，再由代理合约调用逻辑合约里的initialize()函数实现初始化。
initialize()函数通常被“initializer”修饰符掩护，以限制该函数只能被调用一次。在调用initialize()函数后，从代理合约的角度看，逻辑合约被初始化了。然而，从逻辑合约的角度来看，逻辑合约并没有被初始化，因为initialize()并没有在逻辑合约中被直接调用。鉴于逻辑合约本身未被初始化，任何人都可以调用initialize()函数来初始化它，将状态变量设置为一个恶意的值，并有可能接管逻辑合约。
逻辑合约被接管的影响取决于系统中的合约代码。在最坏的情况下，攻击者可以将UUPS代理模式中的逻辑合约升级为恶意合约，并执行“自毁”函数调用，这可能导致整个代理合约变得毫无用处，合约中的资产将永世丢失。
案例
① Parity Multisig Freeze：未初始化逻辑合约。攻击者触发了许多钱包的初始化，并通过调用 selfdestruct() 将以太币锁定在合约中。
② Harvest Finance、Teller、KeeperDAO和Rivermen都使用了未初始化的逻辑合约，这将允许攻击者恣意设置合约的初始化参数，并在delegatecall() 期间执行selfdestruct()将代理合约销毁。

• 存储冲突
  

在一个可升级的合约系统中，代理合约不会声明状态变量，而是使用伪随机存储槽来存储重要数据。
代理合约将逻辑合约状态变量的值保存在它们被声明的相对位置。如果代理合约声明了它本身的状态变量，这时代理和逻辑合约都试图使用同一个存储槽，就会发生存储冲突。
OpenZeppelin库提供的代理合约不会在合约中声明状态变量，而是基于EIP 1967标准，将必要存储的数值（如管理地点）保存到特定的存储槽中，以防止冲突。
案例
北京时间2022年7月23日，去中心化音乐平台Audius遭到黑客攻击，该事件是由于在代理合约中引入新的逻辑，从而产生存储冲突所导致的。
代理合约声明了一个proxyAdmin地点状态变量，在执行逻辑合约代码时，其值会被错误地读取。
项目方私自定义的proxyAdmin的值被错误的当成了initialized和initializing的值，使得initializer修饰符返回了错误的结果，进而允许攻击者再次调用initialize()函数并将管理合约的权限授予本身。攻击者随后更改了投票参数并通过了他们的恶意提案，以窃取Audius资产。

• 在逻辑合约里调用delegatecall()或不信任的合约
  

假设delegatecall()存在于一个逻辑合约中，而合约没有精确验证调用目的。在这种情况下，攻击者可以利用该函数来执行对其控制的恶意合约的调用，以破坏逻辑实现或执行自定义逻辑。
同样地，逻辑合约中如有一个不受限制的address.call()函数，一旦攻击者恶意提供地点和数据字段，就可以利用其充今世理合约。
案例
Pickle Finance、Furucombo以及dYdX攻击事件。
在这几起事件中，存在漏洞的合约获得了用户token的批准，而且合约内存在一个由用户提供调用合约地点和数据的call()/delegatecall()，攻击者将能够调用具有transferFrom()功能的合约，以提取用户余额。在dYdX事件中，dYdX执行了他们本身的白帽攻击以掩护资金。
最佳实践

• 一般情况
  

①仅在必要的时间才使用代理模式
不是每个合约都必要升级。如上文所示，使用代理模式涉及许多风险。“可升级”的属性也会引起信任问题，因为代理管理员可以在没有得到社区同意的情况下升级合约。我们发起仅在必要时才将代理模式整合到项目中。
② 不要修改代理库
代理合约库很复杂，尤其是处置惩罚存储管理和升级机制的部门。修改中的任何错误都会影响代理和逻辑合约的工作。我们在审计过程中发现的大量与代理有关的高严肃性bug都是由不精确的代理库修改造成的。Audius事件就是一个典型的例子，展示了代理合约修改不当所带来的结果。

• 代理合约利用管理要点
  

① 初始化逻辑合约
攻击者可以接管一个未初始化的逻辑合约，并有可能借此破坏代理合约系统。因此请在摆设后初始化逻辑合约，大概在逻辑合约的构造函数中使用_disableInitializers()来主动禁用初始化。
② 确保代理管理账户的安全
一个可升级的合约系统通常必要一个“代理管理员”的特权角色来管理合约的升级。如果管理密钥走漏，攻击者可以自由地将合约升级为恶意合约，就可以窃取用户的资产。我们发起审慎管理代理管理账户的私钥，以避免任何被黑客攻击的潜在风险。可以使用多签名钱包来防止单点的密钥管理失败。
③为透明代理管理使用单独的账户
代理管理和逻辑管理应该是独立的地点，以防止丢失与逻辑实现的交互。如果代理管理和逻辑管理引用同一个地点，就不会转发任何调用来执行特权功能，从而克制管理功能的更改。

• 代理合约存储相干
  

①在代理合约中声明状态变量时要小心审慎
正如Audius黑客事件中所解释的那样，代理合约在声明本身的状态变量时必须审慎。在代理合约中以正常方式声明的状态变量会在读写数据时造成数据冲突。如果代理合约必要一个状态变量，请将该值保存在一个类似EIP1967的存储槽中，以防止在执行逻辑合约代码时发生冲突。
② 维护逻辑合约的变量声明顺序和范例
每个版本的逻辑合约都必须保持状态变量类似的顺序和范例，而且必要在现有变量的末尾添加新的状态变量。否则，委托调用会导致代理合约读取或覆盖不精确的存储值，而且旧的数据可能与新声明的变量相干联，这会给应用程序带来严肃的问题。

③ 在基础合约中包罗存储间隙
逻辑合约必要在合约代码中包罗存储间隙，以便在摆设新的逻辑实现时猜测到新的状态变量。在添加新的状态变量后，必要得当地更新间隙的巨细。

④ 不在构造函数或声明过程中设置状态变量的值
在声明期间或构造函数中分配状态变量只会影响逻辑合约中的值，不会影响代理合约。非不可变的参数应该使用initialize()函数来分配。

• 合约继承（Contract Inheritance）
  

① 可升级合约只能继承自其他可升级合约
与不可升级的合约相比，可升级的合约具有不同的结构。例如，构造函数与改变代理状态不兼容，它使用initialize()函数来设置状态变量。任何继承另一个合约的合约都必要使用其继承合约的initialize()函数来分配各自的变量。当使用OpenZeppelin库或编写本身的代码时，确保可升级的合约只能继承其他的可升级合约。
② 不要在逻辑合约中实例化新合约
通过Solidity创建实例化的合约将不可升级。合约应单独摆设，并将其地点作为参数通报给可升级的逻辑合约，以实现可升级状态。

③ Parent合约初始化风险
当初始化Parent合约时，_{ContractName}_init函数将初始化其Parent合约。调用多个 _{ContractName}_init可能导致Parent合约的第二次初始化。注意__{ContractName}_init_unchained()将只初始化{ContractName}的参数，而不会调用其Parent合约的初始化器。
然而，这并不是一个值得保举的做法，因为所有的Parent合约都必要被初始化，不初始化所需的合约会导致以后的执行问题。

• 逻辑合约的实现
  

① 避免使用selfdestruct()或对不信任的合约执行delegatecall()/call()。
如果合约中存在selfdestruct()或delegatecall()，攻击者就有可能利用这些函数来破坏逻辑实现或执行自定义逻辑。开发者应验证用户的输入，不允许合约执行对不信任合约的delegatecall/calls。别的，不发起在逻辑合约中使用delegatecall()，因为在多个合约的代理链中管理存储结构会很贫苦。
写在最后

代理合约通过使协议在摆设后能够更新其代码逻辑，来绕过区块链的不可窜改特质。然而，开发代理合约仍旧必要十分审慎，不精确的实现可能会导致项目安全与逻辑问题。
总的来说，最佳实践是使用权势巨子提供的且颠末广泛测试的解决方案，因为透明、UUPS和Beacon代理模式每个都有针对各自用例的颠末验证的升级机制。除此之外，升级代理的特权角色也应该被安全地管理，以防止攻击者改变代理逻辑。
逻辑实现合约也应注意不要使用delegatecall()，如许可以防止攻击者执行某些恶意代码，如selfdestruct()。虽然遵循最佳实践可以确保代理合约摆设的稳固，同时保持可升级的灵活性，但所有代码都轻易出现可能危及项目的新安全或逻辑问题，https://t.me/gtokentool 。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。