Solidity开发模式 - 紧密变量打包
本文为Solidity开发模式系列的一部分。
目的
优化存储加载定长变量的gas消耗
动机
这个模式的主要目的就是节约gas。这种特殊模式很容易应用，它不会影响任何合约逻辑。所要做的就是按照正确顺序声明状态变量。我们利用EVM分配存储的方式，减少合约部署gas，以及方法调用成本。以太坊存储是一个键值存储，键值都为32字节。分配存储时，所有定长变量（除了映射和动态数组）都会按声明顺序从位置0开始依次写下。最常用数据类型（例如byte32, uint, int）只占用一个32字节插槽。此模式介绍如何尽可能使用较小的数据类型（例如byte16，uint32）来节省gas，因为EVM可以将它们打包在一个32字节的插槽里，从而减少存储。EVM也会将多个多个读写合并到一个操作中，从而节约gas。这个底层行为被称为"紧密打包"，不幸的是，目前，优化器还不会自动实现这种行为。
适用性
在以下条件时使用紧密变量打包模式
- 希望降低合约交互成本。
- 使用多个状态变量，并且可以使用较小的数据类型代替。
- 使用由多个变量构成的结构，并且可以使用较小的数据类型代替。
- 使用静态数组，并且可以使用较小的数据类型代替。
参与者和协作
一般来说，这个模式唯一的参与者是实现它的合约。与合约交互的其它所有实体都不会受到影响，因为只改变了数据的存储方式。
实现
正如"适用性"一节所述，此模式可用于状态变量，结构体内部和静态数组。它的实现非常直接，分为两步：
-
使用保证代码正确执行的最小数据类型。例如，德国的邮政编码最多有5为数字。因此，
uint16数据类型（uint16最多表示数字216-1=65535）不够，需要使用```uint24```类型的变量（```uint24```最多表示数字224-1=16777215），足够保存所有邮政编码。 -
将同一组的数据类型放到一个32字节的插槽中，并在代码中逐个声明它们。将数据类型分组很重要，因为EVM按照给定顺序逐个保存变量。这只适用于状态变量和结构体内部。数组只有一种数据类型，不需要顺序。
将尽量多的变量存储在一个插槽中，只要它们的存储总小于等于32字节大小。例如，一个bool变量占用一个字节，uint8也是一个字节，uint16是两个字节，uint32是四个字节，依次类推。字节数据类型的存储大小更容易，例如，byte4就是四个字节。所以32个uint8变量的存储空间和1个uint256变量相同。只有当变量依次声明才有效，因为如果必须在变量间保存一个大数据类型，则需要新插槽。
代码示例
下面例子展示了本模式在结构体中的应用
// This code has not been professionally audited, therefore I cannot make any promises about
// safety or correctness. Use at own risk.
contract StructPackingExample {
struct CheapStruct {
uint8 a;
uint8 b;
uint8 c;
uint8 d;
bytes1 e;
bytes1 f;
bytes1 g;
bytes1 h;
}
CheapStruct example;
function addCheapStruct() public {
CheapStruct memory someStruct = CheapStruct(1,2,3,4,"a","b","c","d");
example = someStruct;
}
}
第5行声明了一个使用本模式的结构体对象。这8个变量每个需要一个字节的存储空间，并且没有被更大的数据类型打断，因此它们会被打包进一个存储槽中，并使用32个字节中的8个。这意味着我们在这个存储槽中还可以添加更多的变量。第19行，首先初始化一个结构体对象，然后写入第20行的存储器中。
Gas分析
为了量化所需gas的潜在减少量，使用在线Solidity编译器Remix进行测试。上面示例代码与存储相同输入数据但不使用最小数据类型方案进行对比，并改变变量顺序以阻止EVM采用紧密打包的方式。因此，8个变量将使用8个存储槽。实验代码可以在GitHub上。结果如下表所示：
| Tightly Packed Struct | Struct without Tight Packing | |
|---|---|---|
| Contract Creation | 133172 | 116560 |
| Saving Struct to Storage | 57821 | 161636 |
当不适用最小数据类型时，合约创建的gas成本大约便宜12%。这可以解释，因为EVM通常一次操作32个字节。它需要额外的操作来将变量大小变为最小数据类型大小，这个例子中是从byte32变为byte1，这需要额外的gas。当合约保存结构体变量时，这个成本得到补偿。这个示例中，我们节省了7个存储槽，相当于节省了大约64%的gas。这些gas不仅只节省一次，每次保存一个新结构体都会节省一次。
结果
在盲目实施之前，必须评估采用本模式的结果。巨大的好处是在合约生命周期内可能节省大量的gas。但如果没有实现正确，也可能达到相反的，花费更多gas的结果。它只适用于静态大小的状态变量。方法参数和动态大小的数组并不能获益。相反，正如Gas分析部分合约创建成本显示，EVM操作最小数据类型成本更高。重新排列变量的顺序会导致另个问题，降低可读性。变量通常按照逻辑顺序声明，更改这个顺序会使审核代码更加困难，并使用户和开发人员感到困惑。
已知应用
这种模式的实现很难被发现，因为很难区分变量类型和顺序的选择是基于紧密打包还是其它原因。直到目前，还没有一个合约被发现是经过深思熟虑使用这个模式。一个值得注意的例子是Roshambo，一个石头剪刀布的游戏，移动和决胜局保存在一个结构体的uint8变量中，这允许紧密打包。但是看起来这个设计决策并没有考虑本模式，因为它还可以做进一步优化。
另个例子是Etherization合约，一个类似文明游戏的去中心化应用。在这个合约中，每个玩家保存在一个结构体中。它可以采用最小数据类型，甚至可能不用破坏游戏逻辑。如果这样做，保存一个新玩家的gas消耗会显著降低。
完整内容请查看Solidity开发模式系列
