解构 Solidity 合约 #3：函数包装器

Tiny熊

发布于 2023-01-09 17:51:30

6500

发布于 2023-01-09 17:51:30

文章被收录于专栏：深入浅出区块链技术

译文出自：登链翻译计划[1] 译者：翻译小组[2] 校对：Tiny 熊[3]

号外，今天我们的登链社区网站做了一点小更新，作者们可以关联自己的社交账号，关联后，在文章右侧的作者区域就可以看到点亮的小图标，让更多的小伙伴通过内容交朋友，也欢迎大家关注登链社区的账号。

这是解构系列另一篇。如果你没有读过前面的文章[4]，请先看一下。我们正在解构一个简单的Solidity 合约[5]的EVM 字节码[6]。

在上一篇文章[7]中，我们看到函数选择器在我们的BasicToken.sol[8]合约中是如何充当枢纽作用。它位于合约的入口处，并将执行重定向到调用者想要运行的合约中的匹配函数。

图 1. 来自函数选择器的重定向，查看解构图[9]。

如果被调用的是 totalSupply 函数，执行将被重定向到位置 91，balanceOf 函数被重定向到 130，以此类推。

现在让我们像以前一样在 Remix 中启动一个新的调试会话，并再次调用totalSupply函数。请确保始终展开指令面板，这是 Remix 调试器的核心所在。正如我们之前看到的，Remix 会把你放在指令 246 处，在那里函数的主体即将被执行。上一次，我们把交易滑块从这个位置拉回到指令 0，因为我们想研究合约的入口点，以及它是如何从那里到达函数的入口点的。这一次，我们也要回去，但要回到指令 91，而不是指令 0，因为有这个东西，Solidity 用来包裹一个函数的主体。别担心，我们会在下一篇文章中很快讲到函数的主体。我们就快到了，你的耐心会得到回报的。

所以，回到指令 91，这是函数选择器指向的地方，因为函数 ID 与totalSupply（0x18160ddd）匹配。在这一点上，堆栈应该只包含函数的 id。现在让我们从这里开始走一遍代码。

图 2. non-payable 检查

如果交易中涉及到价值（即以太币），指令 92 到 103 会被回退。同样，这也是 Solidity 编译器在一个函数不是 payable时注入的一个非常常见的检查结构。我们看到这个完全相同的东西被用在构造函数中，在本系列的字节码一文[10]，它也是一个不可支付的函数。这个 非payable结构将检查CALLVALUE是否为零，如果是，将跳转到指令 103（0x67），跳过指令 102 的REVERT操作码。

如果你在 Remix 上调用totalSupply而没有附加任何价值（ETH），将到达指令 103。指令 104 清理了堆栈中剩余的一个零，然后 112（十六进制0x0070）和 245（十六进制0x00f5）被推到堆栈中。执行立即跳转到后一个位置：245 号指令。注意，跳转发生在指令 111，而之前推送的是 112，所以想象一下代码跳去某个地方做什么，然后跳回来，也就是说，它将记住我们离开的地方（112），跳转，然后返回。

图 3. 函数包装器跳入函数体（黄色虚线）。

让我们看看，通过跳转到那个神秘的 245 位置，是否真的会发生返回呢？

图 4. totalSupply 函数体。

如果你单步调试 245 到 250，你会发现我们的分析确实是正确的。代码执行的这部分是实际的函数体，其内部工作原理现在对我们并不重要。对于本文的范围来说，重要的是代码是如何到达和离开这个 "主体" 的，也就是说，它是如何环绕它的。它跳进了的函数体，又跳出了的函数体。因此，我们看到 250 处的 "JUMP "将我们带回了 112 处，正如我们巧妙地预测的那样。

如果这是帝国时代，我们现在应该听到青铜时代的狂欢。没错，我们正在疯狂地使用JUMP和JUMPI在字节码中导航！这就是我们的目标。

但是！这次在堆栈中出现了新东西：数字 10000（十六进制 0x2710）。

我们刚刚执行的函数体很好心地为我们把它放在那里。记住，我们正在调用totalSupply函数。以某种方式，你需要把这个值从堆栈中拿到RETURN操作码中，这样它就可以被返回给用户。这正是代码在指令 113 到 129 之间所做的，在最后有一个实际的RETURN操作码。

图 5. 一个 uint256 内存返回器结构

它首先会读取当前的空闲内存指针（指令 113 到 116），然后将函数主体放在堆栈中的值复制到该空闲空间（指令 117 到 119），最后在内存中存储数字 10000（十六进制0x2710）。看到了吗，我们已经很擅长这个了! 如果你不相信我，就在 Remix 中浏览一下操作代码。听起来很复杂，其实不然。

最后，代码将计算出需要返回的数据的大小。我们接下来看一下：

图 6. 内存指针的偏移？

它首先再次加载内存指针，并在指令 120 到 124 中使用减法与之前的内存指针进行比较，很可能是为了计算出需要返回的数据的大小。这个值似乎是在指令 125 中硬编码的，这似乎是多余的。这可能是优化器意识到返回数据的大小可以硬编码以节省一些 Gas 的结果，在应用优化后，一些残留的操作码被留下了。

这是一个奇怪的字节码的完美例子，它显然没有做任何相关的事情，或者看起来是多余的。忽略那些看起来没有任何作用的操作码是可以的，学会与它们共存（或者说 "通过它们"）并简单地继续前进。随着你阅读越来越多的字节码，你会开始识别这些通用的、显然是空洞的结构的目的。

现在，这些深奥的废话已经足够了，让我们回到地面上:

图 7. 向用户返回数值

指令 125 将数字 32 （十六进制0x20）推到堆栈，并将其加上偏移量，将这些值交换，以符合RETURN消耗其值的顺序，用户有totalSupply值返回。

好的。所以，我们看到了代码是如何从函数选择器出发，进入这个包装结构，进入函数体，又从函数体出来，然后处理函数体产生的返回值，并打包这些数据返回给用户。那么，我们是否应该看看其他的函数，看看我们是否也能在其中观察到类似的模式？

如果你想先休息一下，这将是最佳时机。我们接下来要做的是简单地重复我们刚刚在其他两个函数中分析的结构，顺便在这里和那里加点眼色和一点魔法。

喝杯咖啡吧!

那么，这就是一个函数：第两个函数，让我们接下来看看balanceOf函数。

我们强烈建议你快速浏览一下解构图[11]，以便直观地验证刚刚发生在totalSupply上的事情，并了解我们将在balanceOf上做什么。

函数选择器应该把我们带到指令 130，也就是balanceOf的包装器，然后从那里把我们带入函数的主体，再从函数体出来，为用户打包返回值。然而，如果你注意到图中的情况，代码确实像预期的那样跳入了函数的主体，但是它返回到了totalSupply的包装器，而不是它自己的包装器。为什么？

图 8. balanceOf 的蓝色包装器跳回 totalSupply 的黄色包装器。

一个诱人的原因是，由于totalSupply和balanceOf都返回一个uint256值，从堆栈中抓取一个uint256值并通过内存返回一个uint256的代码块是相同的，可以重复使用。Solidity 编译器可能注意到为这两个包装器生成的部分代码是相同的，并决定重新使用这些代码以节省 Gas。实际上，它就是这样做的，如果我们在编译合约时没有启用优化功能，我们就不会观察到这一点。让我们把这个被重用的结构称为 uint256内存返回器。一个很好的练习是在没有优化的情况下编译合约，并自己验证这一点。

Remix 时间，让我们开始一个新的调试会话，使用我们部署合约的账户地址作为参数，调用balanceOf函数。它应该返回数字 10000，因为代币的创建者最初持有所有的币。在Debug区域，退到指令 142，也就是函数选择器离开的地方。

图 9. balanceOf 函数包装器

在指令 144，112（十六进制0x0070）被推入堆栈 -- 毫不奇怪，这就是我们刚才看到的uint256 内存返回器所在的位置。代码即将跳转到balanceOf的主体，它正在记录主体执行后要跳回哪里。

然而，在指令 175 处跳入函数体的过程并没有立即发生。在它真正进行跳转之前，在指令 147 和 172 之间有一些事情正在发生：

图 10. 解包 Calldata

在指令 147 中，一个带有 40 个 f 的十六进制数字（20 个字节）被推到堆栈中，然后是推入 4。CALLDATALOAD被调用，以 4 为参数，其效果是在函数 id 之后从我们的 calldata 中读取第一个字（32 字节）的数据。如果这听起来很奇怪，那么我建议你看一下系列函数选择器部分[12]，在那里我们分析了 calldata 的工作原理。这个词是我们传入函数调用的参数，也就是我们在调用balanceOf时要检查其余额的地址。这个地址被大的0xffffffffffffffffffffffffff数字掩盖，用于类型检查/掩盖，然后在指令 175 中跳转到指令 251（十六进制0x00fb）的目标函数体，从 calldata 读取的地址，舒服地放在堆栈中，准备供主体使用。

因此，我们可以看到，函数包装器的工作不仅是重定向到函数体，并为用户包装从函数体返回来的任何东西，而且还要包装供函数主体使用参数。这样，函数包装器的本质就完全展现在我们面前了!