深入solidity内部 -以太坊EVN插槽存储关系

以太坊虚拟机Ethereum Virtual Machine(EVM) 拥有三种存储区域。

  • 存储storage ( 贮存了合约声明中所有的变量)

贮存了合约声明中所有的变量。 虚拟机会为每份合约分别划出一片独立的 存储storage 区域,并在函数相互调用时持久存在,所以其使用开销非常大。

每个账户有一块持久化内存区称为 存储 。 存储是将256位字映射到256位字的键值存储区。 在合约中枚举存储是不可能的,且读存储的相对开销很高,修改存储的开销甚至更高。合约只能读写存储区内属于自己的部分。

  • 内存memory ( 用于暂存数据)

用于暂存数据。其中存储的内容会在函数被调用(包括外部函数)时擦除,所以其使用开销相对较小。

合约会试图为每一次消息调用获取一块被重新擦拭干净的内存实例。 内存是线性的,可按字节级寻址,但读的长度被限制为256位,而写的长度可以是8位或256位。当访问(无论是读还是写)之前从未访问过的内存字(word)时(无论是偏移到该字内的任何位置),内存将按字进行扩展(每个字是256位)。扩容也将消耗一定的gas。 随着内存使用量的增长,其费用也会增高(以平方级别)

  • (用于存放小型的局部变量)

用于存放小型的局部变量。使用几乎是免费的,但容量有限。

对绝大部分数据类型来说,由于每次被使用时都会被复制,所以你无法指定将其存储在哪里。

在数据类型中,对所谓存储地点比较重视的是结构和数组。 如果你在函数调用中传递了这类变量,假设它们的数据可以被贮存在 存储storage 或 内存memory 中,那么它们将不会被复制。也就是说,当你在被调用函数中修改了它们的内容,这些修改对调用者也是可见的

EVM 不是基于寄存器的,而是基于栈的,因此所有的计算都在一个被称为 栈(stack) 的区域执行。 栈最大有1024个元素,每个元素长度是一个字(256位)。对栈的访问只限于其顶端,限制方式为:允许拷贝最顶端的16个元素中的一个到栈顶,或者是交换栈顶元素和下面16个元素中的一个。所有其他操作都只能取最顶的两个(或一个,或更多,取决于具体的操作)元素,运算后,把结果压入栈顶。当然可以把栈上的元素放到存储或内存中。但是无法只访问栈上指定深度的那个元素,除非先从栈顶移除其他元素

不同数据类型的变量会有各自默认的存储地点:

  • 状态变量总是会存在

    存储storage

  • 函数参数默认存放在

    内存memory

  • 结构、数组或映射类型的局部变量,默认会放在

    存储storage

  • 除结构、数组及映射类型之外的局部变量,会储存在栈中

    因为结构和数组属于引用类型,  映射mapping和动态数组不可预知大小,不能在状态变量之间存储他们

    引用类型

    引用类型可以通过多个不同的名称修改它的值,而值类型的变量,每次都有独立的副本。因此,必须比值类型更谨慎地处理引用类型。 目前,引用类型包括结构,数组和映射,如果使用引用类型,则必须明确指明数据存储哪种类型的位置(空间)里:

    • 内存memory 即数据在内存中,因此数据仅在其生命周期内(函数调用期间)有效。不能用于外部调用。
    • 存储storage 状态变量保存的位置,只要合约存在就一直存储.
    • 调用数据calldata 用来保存函数参数的特殊数据位置,是一个只读位置。

    状态变量在储存(storage)中的布局

    合约的状态变量以一种紧凑方式存储到区块存储中, 除了动态大小的数组和 映射mapping (见下文),数据的存储方式是从位置 0 开始连续放置在 存储storage 中。 对于每个变量,根据其类型确定字节大小。

    存储大小少于 32 字节的多个变量会被打包到一个 存储插槽storage slot 中,规则如下:

    • 存储插槽storage slot 的第一项会以低位对齐的方式储存。
    • 值类型仅使用存储它们所需的字节。
    • 如果  中的剩余空间不足以储存一个值类型,那么它会被存入下一个存储插槽storage slot
    • 结构体(struct)和数组数据总是会开启一个新插槽(但结构体或数组中的各元素,则按规则紧密打包)。
    • 结构体和数组之后的数据也或开启一个新插槽。

    对于使用继承的合约,状态变量的排序由C3线性化合约顺序( 顺序从最基类合约开始)确定。如果上述规则成立,那么来自不同的合约的状态变量会共享一个 存储插槽storage slot 。

    结构体和数组中的成员变量会存储在一起,就像它们单独声明时一样

     在使用小于 32 字节的元素(变量)时,合约的 gas 使用量可能会高于使用 32 字节的元素。这是因为 以太坊虚拟机Ethereum Virtual Machine(EVM) 每次操作 32 个字节, 所以如果元素比 32 字节小,以太坊虚拟机Ethereum Virtual Machine(EVM) 必须执行额外的操作以便将其大小缩减到到所需的大小。

    当我们在处理状态变量时,利用编译器会将多个元素缩减的存储大小打包到一个 存储插槽storage slot 中,也许是有益,因为可以合并多次读写为单个操作。

    如果你不是在同一时间读或写一个槽中的所有值,这可能会适得其反。 当一个值被写入一个多值存储槽时,必须先读取该存储槽,然后将其与新值合并,避免破坏同一槽中的其他数据,再写入。

    当处理函数参数或 内存memory 中的值时,因为编译器不会打包这些值,所以没有什么额外的益处。

    最后,为了允许 以太坊虚拟机Ethereum Virtual Machine(EVM) 对此进行优化,请确保 存储storage 中的变量和 struct 成员的书写顺序允许它们被紧密地打包。

    例如,应该按照 uint128,uint128,uint256 的顺序来声明状态变量,而不是使用 uint128,uint256,uint128 , 因为前者只占用两个 存储插槽storage slot,而后者将占用三个。

    映射和动态数组

    由于 映射mapping 和动态数组不可预知大小,不能在状态变量之间存储他们。相反,他们自身根据 以上规则 仅占用 32 个字节,然后他们包含的元素的存储的其实位置,则是通过 Keccak-256 哈希计算来确定。

    假设 映射mapping 或动态数组根据上述存储规则最终可确定某个位置 p 。 对于动态数组,此插槽中会存储数组中元素的数量(字节数组和字符串除外,见下文)。 对于 映射mapping ,该插槽未被使用(为空),但它仍是需要的,以确保两个彼此挨着 映射mapping ,他们的内容在不同的位置上。

    数组的元素会从 keccak256(p) 开始; 它的布局方式与静态大小的数组相同。一个元素接着一个元素,如果元素的长度不超过16字节,就有可能共享存储槽。

    动态数组的数组会递归地应用这一规则,例如,如何确定 x[i][j] 元素的位置,其中 x 的类型是 uint24[][],计算方法如下(假设 x`本身存储在槽`p): 槽位于 keccak256(keccak256(p)+i)+floor(j/floor(256/24)) 且可以从槽数据 v``得到元素内容,使用``(v>>((j%floor(256/24))*24))&type(uint24).max.

    映射mapping 中的键 k 所对应的槽会位于 keccak256(h(k). p) ,其中 . 是连接符, h 是一个函数,根据键的类型:

    • 值类型, h 与在内存中存储值的方式相同的方式将值填充为32字节。
    • 对于字符串和字节数组, h(k) 只是未填充的数据。

    如果映射值是一个非值类型,计算槽位置标志着数据的开始位置。例如,如果值是结构类型,你必须添加一个与结构成员相对应的偏移量才能到达该成员。

    例如,考虑下面的合约:

    *// SPDX-License-Identifier: GPL-3.0***pragma solidity** >=**0.4.0** <**0.9.0**;
    
    **contract** **C** {
        struct S { uint16 a; uint16 b; uint256 c; }
        uint x;
        mapping(uint => mapping(uint => S)) data;
    }
    

    让我们计算一下 data[4][9].c 的存储位置。映射本身的位置是 1``( 前面有32字节变量 ``x )。 因此 data[4] 存储在 keccak256(uint256(4) . uint256(1))。 data[4] 的类型又是一个映射, data[4][9] 的数据开始于槽位 keccak256(uint256(9). keccak256(uint256(4). uint256(1))

    在结构 S 的成员 c 中的槽位偏移是 1,因为 a 和 b``被装在一个槽位中。 最后 ``data[4][9].c 的插槽位置是 keccak256(uint256(9) . keccak256(uint256(4) . uint256(1)) + 1. 该值的类型是 uint256,所以它使用一个槽

    变量在内存布局

    Solidity保留了四个32字节的插槽,字节范围(包括端点)特定用途如下:

    • 0x00 - 0x3f (64 字节): 用于哈希方法的暂存空间(临时空间)
    • 0x40 - 0x5f (32 字节): 当前分配的内存大小(也作为空闲内存指针)
    • 0x60 - 0x7f (32 字节): 零位插槽

    暂存空间可以在语句之间使用 (例如在内联汇编中)。 零位插槽用作动态内存数组的初始值,并且永远不应写入(空闲内存指针最初指向 0x80).

    Solidity 总是将新对象放在空闲内存指针上,并且内存永远不会被释放(将来可能会改变)。

    Solidity 中的内存数组中的元素始终占据32字节的倍数(对于 bytes1[] 总是这样,但不适用与 bytes 和 string )。

    多维内存数组是指向内存数组的指针,动态数组的长度存储在数组的第一个插槽中,然后是数组元素。

    警告:

    ? Solidity中有一些需要临时存储区的操作需要大于64个字节, 因此无法放入暂存空间。 它们将被放置在空闲内存指向的位置,但是由于使用寿命短,指针不会更新。 内存可以归零,也可以不归零。 因此,不应指望空闲内存指针指向归零内存区域。

    尽管使用 msize 到达绝对归零的内存区域似乎是一个好主意,但使用此类非临时指针而不更新空闲内存指针可能会产生意外结果

    与存储中布局的不同

    如上所述,在内存中的布局与在 存储中有一些不同。下面是一些例子:

    • 数组的不同

    下面的数组在存储中占用32字节(1个槽),但在内存中占用128字节(4个元素,每个32字节)。

    uint8[4] a;
    
    • 结构体的不同

    下面的结构体在存储中占用 96 (1个槽,每个32字节) ,但在内存中占用 128 个字节(4 个元素每个 32 字节)。

    struct S {
        uint a;
        uint b;
        uint8 c;
        uint8 d;
    }
    

    Call Data布局

    假定函数调用的输入数据采用 ABI规范。 其中,ABI规范要求将参数填充为32的倍数 个字节。 内部函数调用使用不同的约定。

    假定函数调用的输入参数数据采用 ABI规范 定义的格式。 其中,ABI规范要求将参数填充为32字节的倍数。 内部函数调用则使用不同的约定。

    合约构造函数的参数直接附加在合约代码的末尾,也采用ABI编码。 构造函数将通过硬编码偏移量而不是通过使用 codesize 操作码来访问它们,因为在将数据追加到代码时,它就会会改变

    数据位置与赋值行为

    数据位置不仅仅表示数据如何保存,它同样影响着赋值行为:

    • 在  和  之间两两赋值(或者从  赋值 ),都会创建一份独立的拷贝。

      存储storage

      内存memory

      调用数据calldata

    • 从  到  的赋值只创建引用, 这意味着更改内存变量,其他引用相同数据的所有其他内存变量的值也会跟着改变。

      内存memory

      内存memory

    • 从  到本地存储变量的赋值也只分配一个引用。

      存储storage

    • 其他的向  的赋值,总是进行拷贝。 这种情况的示例如对状态变量或  的结构体类型的局部变量成员的赋值,即使局部变量本身是一个引用,也会进行一份拷贝

      存储storage

    // SPDX-License-Identifier: GPL-3.0
    pragma solidity >=0.5.0 <0.9.0;
    
    contract Tiny {
        uint[] x; // x 的数据存储位置是 storage, 位置可以忽略
    
        // memoryArray 的数据存储位置是 memory
        function f(uint[] memory memoryArray) public {
            x = memoryArray; // 将整个数组拷贝到 storage 中,可行
            uint[] storage y = x;  // 分配一个指针(其中 y 的数据存储位置是 storage),可行
            y[7]; // 返回第 8 个元素,可行
            y.pop(); // 通过 y 修改 x,可行
            delete x; // 清除数组,同时修改 y,可行
    
            // 下面的就不可行了;需要在 storage 中创建新的未命名的临时数组,
            // 但 storage 是“静态”分配的:
            // y = memoryArray;
            // 下面这一行也不可行,因为这会“重置”指针,
            // 但并没有可以让它指向的合适的存储位置。
            // delete y;
    
            g(x); // 调用 g 函数,同时移交对 x 的引用
            h(x); // 调用 h 函数,同时在 memory 中创建一个独立的临时拷贝
        }
    
        function g(uint[] storage ) internal pure {}
        function h(uint[] memory) public pure {}
    }