这篇文章需要大家对 Solidity 的基本知识， 有所了解。
让合约可升级提供了很大的灵活性，但也使代码更难推理。这主要是由于需要绕过 Solidity 的类型系统，这意味着编译器捕捉错误的能力受到严重限制。最近的Audius 攻击[3]就是一个很好的例子，说明在使用可升级合约时很容易犯错，并强调了真正理解抽象概念下发生的事情的重要性。
这篇文章是两部分系列中的第一部分。我们将看到可升级合约是如何实现的，特别是什么地方会出错。然后，第二部分将仔细研究 Audius 攻击，重现攻击者执行的每一个步骤。即使有了第一部分的知识，如果你不去寻找它，被攻击者利用的错误仍然很难发现。
在整个文章中，我们使用用 Solidity 编写的 Foundry 测试来说明用于使合约可升级的各种技术，并使实验和探索尽可能容易。所有的代码都可以在 此 repo[4] 中找到。有一点需要注意。这里介绍的代码都不应该在生产中使用，因为开发时没有考虑到这个目的。
序言
区块链的不可更改性与传统的软件开发过程有根本性的冲突，在传统的软件开发过程中，代码被不断地更新以修复错误和增加新功能。但是，即使一个特定的智能合约的代码仍然是不可改变的，仍然有一些技术可以达到与更新代码相同的效果。这主要是通过两个功能的组合实现的。Solidity 中的delegatecallEVM 指令和回退函数 fallback。
代码和存储
为了理解 "delegatecall"，描绘智能合约执行过程中 EVM 的状态是很有帮助的。
我们可以区分持久性和易失性的执行状态。持久性状态在不同的交易中都会被记住，而易失性状态在交易执行后会立即被遗忘。EVM 代码（智能合约代码）和存储都是持久性的，而堆栈、内存、程序计数器和剩余 Gas 都是易失性。在这里，我们主要对代码和存储部分感兴趣，因为它们对于理解可升级合约来说是最重要的。
虽然代码和存储都是持久的，但两者之间有一个根本的区别。存储是可变的，可以被修改，而代码一旦部署就不可改变。为此，代码与存储在内存的只读部分分开保存。(这与典型的冯-诺依曼架构[5]如 x86 不同，后者的代码和内存共享同一个地址空间）。这种分离使得 delegatecall 指令成为可能，它使用一个合约的代码和另一个合约的存储（见下一节）。
区分存储和内存是很重要的。存储器是持久的，它将 32 个字节的地址映射到 32 个字节的值，这些值被称为槽。另一方面，内存是不稳定的，它将 32 字节的地址映射为 1 字节 1 字节的值。换句话说，存储是按字处理（一个字是 32 字节），而内存是按字节处理的。
在 Solidity 中，任何在合约层声明的变量都被映射到一个或多个存储槽。例如，考虑下面的合约：
//堆代码 duidaima.com
contract Token {
address immutable owner;
uint256 public totalSupply;
mapping(address => uint256) public balanceOf;
constructor() {
owner = msg.sender;
}
function mint(address user, uint256 amount) external {
require(msg.sender == owner, "Only owner is allowed to mint");
balanceOf[user] += amount;
}
}
第一个变量被映射到槽 0，第二个被映射到槽 1 [注 1]。从原理上讲，我们可以如下图所示表示这个合约。
注 1：若占用少于 32 字节的变量可以存储在同一个槽中。例如，一个槽可以包含两个类型为uint128的变量。
(注意Token::owner是不可变的（immtable）[6]，因此不占用任何存储槽）。虽然像 address和 uint256这样的简单类型的值最多需要 32 个字节，因此可以放入一个存储槽，但对于映射和动态数组来说，情况并非如此。由于这个原因，即使balanceOf被映射到槽 1，实际上没有任何东西被存储在这个槽里。相反，如果我们想访问balanceOf[addr]，相应的槽被计算出来，如下所示：
keccak(
leftPadTo32Bytes(addr) ++ leftPadTo32Bytes(1)
)
我们把 key（这里是：addr）和映射的槽号（这里是：1），把它们都零扩展到 32 字节，把它们连接起来（用++表示），最后计算结果的 keccak 哈希值。下面的 Foundry 测试展示了如何用 Solidity 来表达:
Token t = new Token();
t.mint(Alice, 5 ether);
bytes32 aliceBalanceSlot = keccak256(
abi.encodePacked(uint256(uint160(Alice)), uint256(1))
);
uint256 aliceBalance = uint256(vm.load(address(t), aliceBalanceSlot));
// Check that we have correctly computed the slot at which Alice’s balance is stored
assertEq(aliceBalance, t.balanceOf(Alice));
在这个例子中，我们想检索t.balanceOf(Alice)的值，但我们没有直接这样做，而是手动计算 Alice 的余额所在的槽。为此，aliceBalanceSlot是按照上面的描述计算的。然后我们使用 Foundry 提供的作弊代码 vm.load()[7] 来加载合约 t中存储在计算槽上的值。最后，我们使用 assertEq() 来确保我们实际上已经加载了正确的值。参见Storage.t.sol[8]以了解完整的例子。
对于像 Token 这样的简单合约，我们可以很容易地手动计算出合约变量的槽。然而，对于使用继承的更复杂的合约，或者有多个变量被存储在同一个槽中的合约，这项任务就变得更加困难了。幸运的是，Foundry 提供了一个命令来可视化合约的存储布局。例如，要显示 Token 合约的存储布局，你可以使用以下命令。
$ forge inspect Token storage-layout –-pretty
这适用于任何属于当前 Foundry 项目的合约。如果你想分析已经部署的合约，可以看看 sol2uml[9] 工具。
delegatecall(委托调用)
如果代码是不可变的，那么怎么可能升级智能合约并改变其行为呢？这主要是由于delegatecall指令[注 2]，它使用一个合约的代码，并使用另一个合约的存储来执行它。这可以通过一个简单的例子来说明。
注 2: 如果我们一般性地谈论改变合约的行为，那么这已经可以用selfdestruct来实现了，因为它删除了所有代码。虽然这是一种非常有限的（而且不是非常有用的）改变合约行为的形式，但当与create2[10]结合时，就有了更多的可能性。然而，delegatecall仍然是实现可升级合约的主要方式。
contract Counter {
uint256 number;
function get() external view returns(uint256) {
return number;
}
function add(uint256 n) external {
require(n <= 5, "Max increment is 5");
number += n;
}
}
contract DelegateCounter {
uint256 number;
function get() external view returns(uint256) {
return number;
}
function delegateAdd(Counter c, uint256 n) external {
bytes memory callData = abi.encodeWithSignature("add(uint256)", n);
(bool ok,) = address(c).delegatecall(callData);
if(!ok) revert("Delegate call failed");
}
}
Counter 合约代表了一个每次最多只能增加五的计数器。为此，它定义了一个函数 add() 来执行这个动作，还定义了一个函数 get() 来获取当前的计数器值。除了函数delegateAdd()外，DelegateCounter合约与Counter基本相同。为了解释delegateAdd()是如何工作的，将这两个合约形象化是有帮助的。
直观地说，delegateAdd()使用delegatecall来执行来自合约Counter的函数add()，使用DelegateCounter的存储。为了使其发挥作用，两个合约应该有兼容的存储布局，也就是说，它们应该将相同的变量分配到相同的存储槽中。
delegatecall是 Solidity 中的一个低级原语，使用起来不如普通函数调用方便。一般来说，每当我们想在一个合约上调用一个函数时，我们需要同时指定我们想调用的函数和我们想传递的论据。这些信息需要以一种众所周知的格式进行编码，以便目标合约知道如何解释它。这种格式也被称为应用二进制接口（ABI），并在 合约ABI规范中描述。对于正常的函数调用，Solidity 为我们做了这个编码，但是当使用delegatecall时，我们需要自己做。这是在delegateAdd()的第一行完成的。
bytes memory callData = abi.encodeWithSignature("add(uint256)", n);
encodeWithSignature()的第一个参数表示我们要调用的函数的签名，其余参数表示我们要传递给该函数的值。在上面的例子中，我们对一个名为 add 的函数的调用进行了编码，该函数需要一个uint256类型的参数，其值应该是n。如果我们假设n是，例如，4，那么callData将看起来如下：
0x1003e2d20000000000000000000000000000000000000000000000000000000000000004
(你可以通过在delegateAdd()函数中添加console.logBytes(callData)来验证这一点。)
前四个字节代表 "函数选择器"，它是通过获取函数签名的 keccak 哈希值中最重要的前四个字节计算出来的。这个函数签名是 "add(uint256)"，我们可以使用 Foundry 自带的 cast 命令行工具来计算其 keccak 哈希值。
$ cast keccak "add(uint256)"
0x1003e2d21e48445eba32f76cea1db2f704e754da30edaf8608ddc0f67abca5d0
正如你所看到的，哈希值的四个字节与 "callData" 中最重要的四个字节相匹配。函数选择器后面是参数（"callData" 值部分），这只是表示为 "uint256 "的值 4，即 32 字节的无符号数。现在我们已经在callData中存储了编码的函数调用，我们可以把它传递给delegatecall。
(bool ok,) = address(c).delegatecall(callData);
这一行在当前合约的上下文中执行函数Counter.add()。特别是，任何由Counter.add()执行的存储访问都将使用调用合约的存储，在此案例中，它是DelegateCounter类型。因此，当Counter.add()函数写到槽 0 以更新存储变量number时，它更新的是DelegateCounter的存储，而不是Counter的。
delegatecall返回两个值。一个表示调用是否成功的布尔值，和一个包含任何返回数据的字节数组。由于Counter.add()不返回任何东西，delegateAdd()忽略返回数据，只检查调用是否成功。这一点特别重要，因为当使用delegatecall时，被调用的函数中的 reverts 不会自动传播， [注 3]。
注 3: 为了简单起见，我们用一个固定的消息来作为 revert 消息，而不是传播原始错误。
if(!ok) revert("Delegate call failed");
为了使这一切更具体，这里有一个例子：
Counter c = new Counter();
DelegateCounter d = new DelegateCounter();
// Sanity check: both counters should start at zero
assert(c.get() == 0);
assert(d.get() == 0);
d.delegateAdd(c, 4);
// Check that `d` has been updated and that `c` remains unchanged
assert(c.get() == 0);
assert(d.get() == 4);
我们首先创建了 Counter和 DelegateCounter合约的新实例，并使自己相信它们都是从 0 开始的。然后是有趣的部分，即调用d.delegateAdd(c, 4)。如上所述，delegateAdd()本质上是调用c.add(4)，其方式是所有存储访问都指向d而不是c。下面两个断言验证了这一点，它们检查了c仍然为零，而d已经被更新。
现在我们可以清楚地看到delegatecall是如何用来实现可升级的合约的，因为我们可以将任何合约传递给delegateAdd()，它实现了一个签名为add(uint256)的函数。因此，即使 DelegateCounter保持不变，我们也可以通过向 delegateAdd()传递一些其他合约来改变其行为。然而，为了完全实现可升级的合约，我们还需要关注一个特性，即回退函数。这将在回退函数一节中介绍。然而，在我们继续之前，看看如何处理delegatecall的第二个返回值，即包含从被调用函数返回的数据的字节数组，是很有用的。
处理返回值
正如我们已经注意到的，使用delegatecall比正常的函数调用要不方便，因为我们必须根据 ABI 对调用进行手动编码。从调用中返回的数据也是如此。我们只是得到一个原始的字节数组，我们需要根据被调用的函数的返回类型自己解码。为了说明如何做到这一点，我们现在为DelegateCounter实现一个delegateGet()函数。
contract DelegateCounter {
// ...
function delegateGet(Counter c) external returns(uint256) {
bytes memory callData = abi.encodeWithSignature("get()");
(bool ok, bytes memory retVal) = address(c).delegatecall(callData);
if(!ok) revert("Delegate call failed");
return abi.decode(retVal, (uint256));
}
}
这个实现与delegateAdd()非常相似。我们首先对我们想要执行的调用进行 ABI 编码，然后使用delegatecall来进行调用。然而，这一次我们也处理了由调用返回的数据，我们将其存储在retVal中。因为get()返回一个uint256，ABI 规定像uint256这样的固定宽度类型的值是通过简单的取其big-endian[11]表示并将结果填充到 32 字节来编码的，返回的数据可以通过简单的将 retVal 类型转换为uint256来解码。
return uint256(bytes32(retVal));
然而，对于复杂的类型，解码变得更加复杂。幸运的是，Solidity 提供了函数abi.decode()，可以为我们执行解码。使用这个函数，我们可以将返回语句重写如下：
return abi.decode(retVal, (uint256));
函数abi.decode()需要两个参数。一个包含一些 ABI 编码值的字节数组，以及一个包含编码值类型的元组。
泛化
为了为以后做准备，我们可以对delegateGet()做最后的修改，以便对处理返回数据的方式进行概括。注意，当我们用abi.decode(retVal, (uint256))对返回数据进行解码时，我们对返回类型进行了硬编码。如果我们想在任意函数中使用delegatecall，那么我们也需要能够处理任意的返回数据。这在纯 Solidity 中是不可能的，所以我们需要转向汇编。特别是，我们需要替换：
return abi.decode(retVal, (uint256));
替换为：
assembly {
let data := add(retVal, 32)
let size := mload(retVal)
return(data, size)
}
return(data,size)指令结束当前函数的执行，并返回由data和size给出的内存范围内的数据，其中 data 表示起始地址，size表示数据的字节大小（详见Yul 规范[12]）。在上面的例子中，data和size的计算方式可能不是很明显。要理解这一点，重要的是要知道数组是如何在内存中布局的。首先，请注意，当我们从汇编块中引用像retVal这样的内存变量时，我们实际上是指它的地址。因此，当我们在上面的汇编块中使用retVal时，我们指的是retVal所表示的字节数组在内存中的起始地址。其次，Solidity 在内存中排列数组的方式如下 [注 4]。首先是数组的长度, 存储为一个 32 字节的无符号数字, 然后是所有的数组元素. 因此，retVal的数组长度直接存储在retVal的地址（我们通过mload加载），为了得到数组元素的地址，我们需要给retVal增加一个 32 字节的偏移量。
注 4: 这与数组在存储中的布局不同，见存储中状态变量的布局[13]和内存中的布局[14]。
有了上述汇编，我们可以简单地转发任何来自delegatecall的返回数据，而不需要知道编码后的值的类型。这使得我们可以调用任意的函数而不需要事先知道它们的返回类型。
要想玩转这段代码，请看DelegateCall.t[15]。
回退函数
回退函数[16]是实现可升级合约时另一个有用的功能。它们允许开发者指定当一个不存在的函数被调用时应该发生什么。默认的行为是回退，但这可以被改变。
interface Ifc {
function hello() external;
function bye() external;
}
contract C {
event Log(string msg);
function hello() external {
emit Log("hello");
}
fallback() external {
emit Log("fallback");
}
}
上面我们定义了一个带有函数hello()和bye()的简单接口。此外，我们定义了一个合约C，它包含一个函数hello()和一个fallback函数。现在考虑下面的例子：
Ifc ifc = Ifc(address(new C()));
ifc.hello(); // Emits Log("hello")
ifc.bye(); // Emits Log("fallback")
我们创建了一个新的合约C的实例，并将其转换为 Ifc 类型，这使得我们可以同时调用hello()和bye()。当我们调用Bye()时，由于C没有定义，所以会执行回退函数。
一个有用的事实是，我们可以使用msg.data来访问触发回退函数的原始调用数据。例如，如果在C的回退函数中加入console.logBytes(msg.data)，那么在调用ifc.bye()时就会产生如下日志信息。
0xe71b8b93
正如你所期望的，这只是bye()的函数选择器（因为bye()没有参数，所以没有编码的参数）。这意味着通过检查msg.data我们可以确定用户最初打算调用哪个函数。
完整的例子见Fallback.t.sol[17]。
可升级的合约
使用delegatecall和回退函数，我们可以实现一个基于代理 的可升级合约的一般解决方案。其核心思想如下。对于每一个我们希望其代码可以升级的合约，我们实际上部署了两个合约。一个代理合约和一个逻辑合约。代理合约是存储所有数据的合约，而逻辑合约则包含对这些数据进行操作的功能。用户将只与代理合约进行交互。当用户在代理上调用一个函数时，代理会使用一个委托调用将调用转发给逻辑合约。因为代理使用委托调用，执行逻辑合约的函数会影响代理的存储。因此，当使用可升级合约时，代理持有状态，而逻辑合约持有代码。从用户的角度来看，代理的行为与逻辑合约的行为是一样的。升级合约只是意味着代理使用了一个新的逻辑合约。
初次尝试 (不成功)
通过上面的解释，人们也许会被诱惑去实现代理合约，如下所示：
contract FaultyProxy {
address public implementation;
// 堆代码 duidaima.com
function upgradeTo(address newImpl) external {
implementation = newImpl;
}
fallback() external payable {
(bool ok, bytes memory returnData) = implementation.delegatecall(msg.data);
if(!ok)
revert("Calling logic contract failed");
// Forward the return value
assembly {
let data := add(returnData, 32)
let size := mload(returnData)
return(data, size)
}
}
}
正如它的名字 FaultyProxy 所示，这个代理在一般情况下是不起作用的。然而，了解为什么它不能工作仍然是有意义的，特别是因为我们后面要看的 Audius 协议中的错误与上述代理中的错误非常相似。
代理有一个单一的存储变量，implementation，它存储了逻辑合约的地址。通过调用upgradeTo()可以改变逻辑合约，使逻辑（换句话说：代码）可以升级。(现在，任何人都可以调用upgradeTo()，这当然是不可取的。我们稍后会回到这个问题上）。拼图的最后一块是回退函数。它的目的是转发任何对使用delegatecall的逻辑合约的调用。(除了对upgradeTo()和implementation()的调用，这些调用是由代理本身处理的。) 但我们怎么知道用户想调用哪个函数呢？幸运的是，触发回退函数的原始 calldata 可以通过msg.data [注 5] 访问。由于 calldata 包含函数签名和参数值，我们可以简单地将msg.data传递给delegatecall。之后，我们检查调用是否成功。如果不成功，我们就还原，否则就转发返回数据。
注 5： 回退函数也可以使用不同的签名，其中 calldata 被直接作为参数传递。更多信息请参见 Solidity 文档 关于 fallback 函数[18] 的说明。
下面的例子显示了代理应该如何使用：
// (1) 创建逻辑合约
Counter logic = new Counter();
// (2) Create proxy and tell it which logic contract to use
FaultyProxy proxy = new FaultyProxy();
proxy.upgradeTo(address(logic));
// (3) To be able to call functions from the logic contract, we need to
// cast the proxy to the right type
Counter proxied = Counter(address(proxy));
// (4) Now we treat the proxy as if it were the logic contract
proxied.add(2);
// (5) Did it work? (Spoiler: no!)
console.log(“counter =”, proxied.get()); // Reverts!
前两步分别创建了逻辑和代理合约。第二步还调用了upgradeTo()，这样代理就知道要使用哪个逻辑合约。第三步需要告诉 Solidity 编译器，我们现在计划使用代理，就像它是逻辑合约一样。第四步是它变得有趣的地方。我们在代理上调用add()函数。由于代理没有定义任何该名称的函数，其回调函数被执行。在回调函数中，msg.data包含以下调用数据：
0x1003e2d20000000000000000000000000000000000000000000000000000000000000002
这代表了对一个签名为 "add(uint256)"、参数为 2 的函数的调用 。然后，回退函数用上述调用数据执行一个 "delegatecall"，使用代理的存储空间执行 "Counter "合约中的 "add() "函数。
最后，在第五步中，我们试图从代理中获取当前的计数器值。然而，执行proxied.get()实际上是回退了! 这个错误的原因可以通过可视化代理和逻辑合约来轻松解释。
当比较两个合约的存储布局时，我们可以注意到它们在 0 槽中存储了不同的变量。这产生了一个不幸的后果。当Counter.add()使用FaultyProxy的存储空间执行时，它修改了存储槽 0，以便更新number。然而，在合约FaultyProxy中，槽 0 包含implementation的值。因此，当我们在步骤(4)中调用proxied.add(2)时，我们实际上将存储在implementation中的地址增加了 2，使得地址无效。更确切地说，现在产生的地址指向一个账户，而这个账户很可能没有被部署过合约。当对一个空账户进行委托时，调用将成功，但没有数据被返回。然而，由于我们确实希望返回一个uint256类型的值，所以测试被还原了。参见FaultyProxy.t.sol[19]中的代码。
可工作的版本 (但有错误)
我们怎样才能解决代理和逻辑合约之间的存储槽碰撞问题呢？一个简单的方法是在Counter合约中的number前添加一个虚拟存储变量。然后，number将被存储在槽 1 中，它将不再与FaultyProxy的implementation发生冲突。然而，这并不是一个好的解决方案。它很脆弱，很容易被遗忘，而且如果逻辑合约继承了其他合约，可能很难执行。
那么，代理合约怎样才能在不产生槽冲突的情况下存储逻辑合约的地址呢？有多种方法，见“设计选择”一节。在这里，我们将遵循非结构化存储模式[20]，它被广泛使用（例如 OpenZeppelin，也见使用非结构化存储的可升级性[21]），它为这个问题提供了一个不需要对逻辑合约进行任何修改的解决方案。这个想法是让代理将逻辑合约地址存储在某个遥远的插槽中，这样一来，插槽碰撞的几率就可以忽略不计了。有了这个想法，我们可以实现一个新的代理：
// 堆代码 duidaima.com
// This proxy is working but still has flaws, so don’t use it for anything serious
contract Proxy {
bytes32 constant IMPLEMENTATION_SLOT =
bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1);
function upgradeTo(address newImpl) external {
bytes32 slot = IMPLEMENTATION_SLOT;
assembly {
sstore(slot, newImpl)
}
}
function implementation() public view returns(address impl) {
bytes32 slot = IMPLEMENTATION_SLOT;
assembly {
impl := sload(slot)
}
}
fallback() external payable {
(bool ok, bytes memory returnData) =
implementation().delegatecall(msg.data);
if(!ok)
revert("Calling logic contract failed");
// Forward the return value
assembly {
let data := add(returnData, 32)
let size := mload(returnData)
return(data, size)
}
}
}
Proxy和FaultyProxy之间的关键区别是，Proxy没有声明任何存储变量。相反，逻辑合约的地址被存储在槽IMPLEMENTATION_SLOT中，它被计算为 eip1967.proxy.implementation字符串的 keccak 散列值减去 1[注 6] 。顾名思义，这个槽位号在EIP-1967[22]中被标准化。有了一个定义明确的槽来存储逻辑合约，像 Etherscan 这样的服务可以自动检测合约是否具有代理功能，在此案例中，可以显示代理和逻辑合约的信息。例如，如果你在 Etherscan 上查看USDC[23]的代码，除了正常的 读/写合约标签外，还有 作为代理读/写的选项，它提供了一个指向当前逻辑合约的链接。
注 6: 为什么我们要从 keccak 的哈希值中减去一个？纯粹从功能的角度来看，这没有什么区别。使用不加-1 的 keccak 哈希值也一样可以工作。然而，正如在EIP-1967[24]中提到的，增加-1 的偏移量是为了使预像攻击更加困难（见: https://github.com/ethereum/EIPs/pull/1967#issuecomment-489276813）
为了升级合约，upgradeTo()函数需要修改IMPLEMENTATION_SLOT给出的槽位上的地址，这可以使用sstore指令。注意，我们需要将IMPLEMENTATION_SLOT复制到一个局部变量中，因为不可能直接从汇编中读取常数。函数implementation()以类似的方式实现，读取存储在槽IMPLEMENTATION_SLOT的地址。最后，回退函数保持不变，只是我们现在使用implementation()函数而不是存储变量来获取逻辑合约地址。
我们使用sstore/sload来访问逻辑合约，而不是使用合约变量，这使得这个代理非结构化，这也解释了非结构化存储模式的名字。我们可以再次直观地看到代理和逻辑合约。
(这里，IMPL_SLOT = IMPLEMENTATION_SLOT) 之前提到，当使用delegatecall时，必须确保调用者合约和被调用者合约都有兼容的存储布局，以防止被调用者弄乱调用者的存储。对于delegatecall[25]部分的Counter和DelegateCounter合约，这很容易验证，因为这两个合约定义的存储变量完全相同。另一方面，Proxy与Counter的存储布局不相同，但由于两个合约使用完全不同的存储槽，因此不会"踩到对方的脚趾"，这不是一个问题。(事实上，Proxy是完全独立于所使用的具体逻辑合约，因此这意味着人们只需要写一个可以被所有人使用的代理。)
当然，这只有在IMPLEMENTATION_SLOT表示的槽不会意外地与逻辑合约中的任何存储变量冲突时才安全。这实际上能保证吗？首先，请注意，IMPLEMENTATION_SLOT表示一个相当大的值。由于像 uint256这样有固定大小的存储变量被分配到从零开始的槽号，现实中我们可以假设它们的槽号比IMPLEMENTATION_SLOT小得多。而且在任何情况下，由于这些槽是在编译时分配的，编译器可以检测到与IMPLEMENTATION_SLOT的碰撞并报告错误。
但是，对于动态大小的类型，如映射和动态数组，情况有点不同，其元素的存储槽是使用 keccak hashes 计算的（见 Solidity 文档中的映射和动态数组[26]）。这样计算的槽实际上可能与IMPLEMENTATION_SLOT相冲突。然而，一般的共识是，这种情况发生的几率很小，所以这不被认为是一个问题。
最后，虽然上面的代理实现是可行的，但它仍然有基本的缺陷，因此不应该被用于任何严肃的生产环境，这些缺陷是
该代理容易受到函数选择器冲突的影响，这可能导致意外的行为（见”设计选择“ 一节）。
upgradeTo()是无权限的，这意味着任何人都可以升级合约。由于升级合约可以极大地改变其行为，这是一个明显的安全问题，任何代理实现都必须解决。我们将在后续的文章中讨论与此直接相关的 Audius 攻击。
初始化
在迄今为止的例子中，我们只使用了Counter合约作为逻辑合约，它非常简单，甚至没有一个用户定义的构造函数。这让我们成功地忽略了使用代理时产生的一个重要限制。不能使用构造函数。原因是构造函数实际上不是函数，因此不能被 delegatecall 调用。解决的办法是使用一个单独的初始化函数。让我们修改Counter，这样我们可以用计数器的初始值来初始化它。
contract Counter {
bool isInitialized;
uint256 number;
function initialize(uint256 start) external {
require(!isInitialized, “Already initialized”);
number = start;
isInitialized = true;
}
function get() external view returns(uint256) {
return number;
}
function add(uint256 n) external {
require(n <= 5, "Max increment is 5");
number += n;
}
}
我们做了两个改动。我们添加了isInitialized存储变量和initialize()函数。与构造函数相比，initialize()函数只是一个普通的函数，可以被调用任意次数。由于安全敏感的参数经常在初始化过程中被设置，所以防止重新初始化是很重要的，我们在这里借助isInitialized来做到这一点。虽然这在这个简单的例子中是可行的，但对于生产来说，建议使用像 OpenZeppelin 的Initializable[27]这样的东西，它可以正确处理继承，并支持在升级后重新初始化。
最后一个例子
我们已经谈了很多关于可升级的合约，但到目前为止，我们还没有升级任何东西。让我们创建一个 "CounterV2"，它与 "Counter" 类似，但将增量限制从 5 增加到 10。
contract CounterV2 {
// ...
function add(uint256 n) external {
require(n <= 10, "Max increment is 10"); // Increase max increment to 10
number += n;
}
}
下面的例子说明了部署和升级一个合约的整个过程：
// (1) Create logic contract
Counter logic = new Counter();
// (2) Create proxy and tell it which logic contract to use
Proxy proxy = new Proxy();
proxy.upgradeTo(address(logic));
// (3) To be able to call functions from the logic contract, we need to
// cast the proxy to the right type
Counter proxied = Counter(address(proxy));
proxied.initialize(23);
// (4) Now we treat the proxy as if it were the logic contract
proxied.add(2); // Works as expected
// proxied.add(7); Would fail (as expected)
// (5) Upgrade to a new logic contract
CounterV2 logicV2 = new CounterV2();
proxy.upgradeTo(address(logicV2));
// (6) Now adding a value larger than 5 actually works!
proxied.add(7); // Works as expected
注意，在我们的代理实现中，初始化是一个多步骤的过程。在步骤（2）中，我们创建一个新的代理并分配逻辑合约，在步骤（3）中我们调用初始化函数。相比之下，OpenZeppelin 的实现可以在一个步骤中完成所有这些工作（见ERC1967Proxy.constructor()[28]），这可以防止前面的攻击，而且更节省 Gas。每一步之后，代理的存储看起来如下（只显示已经被写入的槽）：
当代理在第 2 步创建时，它还没有存储任何来自逻辑合约的状态。这只发生在第 3 步之后，当逻辑合约被初始化，将槽 0（isInitialized）设置为true，槽 1（counter）设置为 23。
完整的例子见Proxy.t.sol[29]。
设计选择
在实现可升级合约的代理时，有两个基本问题需要回答。
1.如何防止代理和逻辑合约之间的存储槽碰撞？
2.如何处理代理和逻辑合约之间的函数选择器冲突？
在这篇文章中，我们只看了第一个问题，我们的答案是使用非结构化存储模式。然而，还有其他的方法，比如 Inherited 存储或 Eternal 存储（参见代理模式[30]，了解相关概况）。
关于第二个问题。正如我们所看到的，函数在内部是由函数选择器来识别的，这些选择器有四个字节长，来自函数签名的 keccak 散列。这使得不同签名的函数有可能映射到同一个函数选择器上，从而导致选择器冲突。
例如，签名proxyOwner()和clash550254402()的函数选择器是一样的，见这里[31]：
$ cast keccak "proxyOwner()"
0x025313a28d329398d78fa09178ac78e400c933630f1766058a2d7e26bb05d8ea
$ cast keccak "clash550254402()"
0x025313a2bba9fda619061d44004df81011846caa708c8d9abf09d256021e23ee
通常，这不是一个问题，因为如果函数选择器冲突发生在单个合约的两个函数之间，那么 Solidity 编译器会以错误中止。然而，如果这样的冲突发生在不同合约的两个函数之间，那么就不会报告错误，因为这通常并不重要。但是，使用代理时除外。代理的回退函数会将任何它自己没有定义的函数转发给逻辑合约。现在，如果代理和逻辑合约定义了一个具有相同选择器的函数，那么代理将永远不会把对该函数的调用转发给逻辑合约，而是自己处理调用。更多信息请参见以太坊代理中的恶意后门[32]。
对这个问题至少有两种流行的解决方案：透明代理模式和通用可升级代理标准(UUPS)。透明代理模式的工作原理是，根据信息发送者的情况，将所有功能调用转发到逻辑合约，或者完全不转发。如果消息发送者是一个指定的代理管理员，那么我们假设他们只想调用代理本身的功能，而不是逻辑合约。对他们来说，调用是不会被转发的。另一方面，对于任何其他用户，我们假设他们只想调用逻辑合约中的功能，因此他们的调用总是被转发。这就避免了任何源于函数选择器冲突的问题，因为发送者决定了应该使用哪个合约。更多信息，请参阅透明代理模式[33]。
UUPS 模式描述于EIP-1822[34]。在这里，函数选择器冲突的问题是通过在代理中不定义任何公共函数来避免的。相反，所有管理代理的功能(包括upgradeTo())都在逻辑合约中实现。更多信息请参见Transparent vs UUPS Proxies[35]。
你可能已经注意到了，我们的例子代理合约既没有实现透明代理模式也没有实现 UUPS。事实上，它根本没有防止函数选择器的冲突，而且完全受到上述问题的影响。请看一下OpenZeppelin Proxy Library[36]的生产就绪的代理实现。
最后，还有其他具有不同权衡的代理模式。例如，有一个Beacon Proxy[37]模式，它引入了另一个层次的间接性，但允许一次升级许多合约。还有Diamond Pattern[38]，它允许将逻辑分散在多个合约中，规避了任何代码大小的限制。
结论和展望
在这篇文章中，我们已经开发了一个基本的代理实现，并讨论了一路走来的各种陷阱。不过，我们的实现还是有两个主要的缺点：
1.它很容易受到函数选择器冲突的影响
2.upgradeTo()是无权限的。
在这个系列中，我们不会解决第一个缺点（关于潜在的解决方案，见设计选择一节）。然而，在下一篇文章中，我们将更仔细地研究第二个问题，因为这将直接导致 Audius 攻击中被利用的漏洞
原文链接：
https://runtimeverification.com/blog/using-foundry-to-explore-upgradeable-contracts-part-1
参考资料
[1]登链翻译计划: https://github.com/lbc-team/Pioneer
[2]Tiny 熊: https://learnblockchain.cn/people/15
[3]Audius攻击: https://blog.audius.co/article/audius-governance-takeover-post-mortem-7-23-22
[4]此 repo: https://github.com/runtimeverification/foundry-upgradeable-contracts-examples
[5]冯-诺依曼架构: https://en.wikipedia.org/wiki/Von_Neumann_architecture
[6]不可变的（immtable）: https://docs.soliditylang.org/en/latest/contracts.html#immutable
[7]vm.load(): https://book.getfoundry.sh/cheatcodes/load
[8]Storage.t.sol: https://github.com/runtimeverification/foundry-upgradeable-contracts-examples/blob/master/test/Storage.t.sol
[9]sol2uml: https://github.com/naddison36/sol2uml
[10]create2: https://medium.com/consensys-diligence/smart-contract-security-newsletter-16-create2-faq-b641405044bf
[11]big-endian: https://en.wikipedia.org/wiki/Endianness
[12]Yul规范: https://docs.soliditylang.org/en/latest/yul.html#specification-of-yul
[13]存储中状态变量的布局: https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html
[14]内存中的布局: https://docs.soliditylang.org/en/latest/internals/layout_in_memory.html
[15]DelegateCall.t: https://github.com/runtimeverification/foundry-upgradeable-contracts-examples/blob/master/test/DelegateCall.t.sol
[16]回退函数: https://docs.soliditylang.org/en/latest/contracts.html#fallback-function
[17]Fallback.t.sol: https://github.com/runtimeverification/foundry-upgradeable-contracts-examples/blob/master/test/Fallback.t.sol
[18]fallback 函数: https://learnblockchain.cn/docs/solidity/contracts.html#fallback
[19]FaultyProxy.t.sol: https://github.com/runtimeverification/foundry-upgradeable-contracts-examples/blob/master/test/FaultyProxy.t.sol
[20]非结构化存储模式: https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#unstructured-storage-proxies
[21]使用非结构化存储的可升级性: https://blog.openzeppelin.com/upgradeability-using-unstructured-storage/
[22]注6] 。顾名思义，这个槽位号在[EIP-1967: https://eips.ethereum.org/EIPS/eip-1967
[23]USDC: https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code
[24]EIP-1967: https://eips.ethereum.org/EIPS/eip-1967
[25]delegatecall: https://docs.google.com/document/d/1jcgOWSRhSe6sDG4CO5r4eNrDkCGinLcOeJ1xXtDCeiY/edit#heading=h.5lko0ulckh7r
[26]映射和动态数组: https://learnblockchain.cn/docs/solidity/internals/layout_in_storage.html#id2
[27]Initializable: https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#initializers
[28]ERC1967Proxy.constructor(): https://docs.openzeppelin.com/contracts/4.x/api/proxy#ERC1967Proxy-constructor-address-bytes-
[29]Proxy.t.sol: https://github.com/runtimeverification/foundry-upgradeable-contracts-examples/blob/master/test/Proxy.t.sol
[30]代理模式: https://blog.openzeppelin.com/proxy-patterns/
[31]这里: https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357
[32]以太坊代理中的恶意后门: https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357
[33]透明代理模式: https://blog.openzeppelin.com/the-transparent-proxy-pattern/
[34]EIP-1822: https://eips.ethereum.org/EIPS/eip-1822
[35]Transparent vs UUPS Proxies: https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups
[36]OpenZeppelin Proxy Library: https://docs.openzeppelin.com/contracts/4.x/api/proxy
[37]Beacon Proxy: https://docs.openzeppelin.com/contracts/4.x/api/proxy#beacon
[38]Diamond Pattern: https://eips.ethereum.org/EIPS/eip-2535
闽公网安备 35020302035485号
