前置知识：Go、Geth、EVM、Solidity、操作系统

首先我们来简单介绍一下标题中的名词：

• EVM：由GO语言实现的虚拟机，封装在Ethereum的客户端Geth中。

• Opcode：EVM中字节操作码，是编写Solidity的低级语言。

• MUL：操作码中的乘法操作。

• MULMOD：操作码中的乘法取模操作。

MUL

首先我们来看一下MUL的大致用法，MUL接收两个整数参数，然后再将它们做乘法操作：

mul(2,5) = 10；

输出的是一个取模2^256的整数。注意，取模后的位数被限制在了256位以内，也就是如果乘法出现了溢出的情况，高于256位会被截断丢弃，只保留低位的256位。

我们可以使用该示例代码测试一下：

在cal函数中，我们使用三个变量来接收MUL计算的结果：

result0 = 0x      ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff

result1 = 0x 0001 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff fffe

result2 = 0x      ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff fffe 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

但由于MUL的结果只保留低位256，所以：

result0 保持不变

result1 = 0x  ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff fffe

result2 = 0x  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

最后的结果：

result0 = 2^256 - 1
result1 = 2^256 - 2
result2 = 2^256 - (2^256 - 1) = 1

MULMOD

介绍完了MUL，我们来看下MULMOD，

该方法接收三个整数参数，前两个参数做乘法操作，得到结果模上第三个参数：

mulmod(5,2,3) = 1;

到目前为止，我们似乎就能发现，MUL与MULMOD的区别就在于MULMOD仅仅是将MUL操作与MOD操作封装在了一个操作码里面。假如使用MUL与MOD似乎也能达到MULMOD的效果，让我们来测试一下。

首先提供两个函数，分别使用MUL与MOD，MULMOD来进行计算。

我们分别测试了两组数据，两种函数得到计算结果都相同，并无差异。但是细心的你也许会发现，所有的计算结果均未溢出256位。

接下来，让我们测试一下256位溢出的情况。

最后得到的结果大相径庭，可能与很多人预想的不一样。大多数人可能以为EVM支持最高的计算结果位数是256位，但其实不是，最高是512位。

在Solidity的汇编操作码中，有两个操作码支持512位以内的运算，分别是ADDMOD和MULMOD，他们都接收两个最大256位的整数，得到一个512位的数，然后再模上第三个参数，最后得到的始终会是一个256位的数。

上面的例子中，造成结果不一样的原因是因为mulThenMod会先得到一个256位的数，如果溢出，会先截断高位，再用低位去模上第三个参数。

而mulMod却不会截断高位。

EVM是如何做到这样的差异？

想要进一步探究其原理，我们需要查看EVM的源码，也就是Geth。

你可以将代码克隆下来查看：

git clone https://github.com/ethereum/go-ethereum.git

cd go-ethereum

在core/vm/instructions.go这个源码文件中，有所有opcode的源码。

找到opMulmod，这便是我们在汇编中写的mulmod操作码的源码，

如果你不想深究EVM的源码，只想了解个大概的底层原理，我们可以直接跳转到z.MulMod()这个函数的源码：

同样，你无需了解全部代码，只需跳转第五行代码umul()函数。

在下面图片中，我省略了大量计算源码，用cal…代替，如果你对计算过程感兴趣，可以自行查看。

该函数最后返回一个[8]uint64的数组，该数组的8个uint64整数，组合起来刚好是一个512位的整数。该整数便是操作码mulmod的中间计算结果。

最后在z.MulMod()中会用调用udivrem()方法返回一个[4]uint64的数组，该数组在Go的uint256.go中被声明位Int类型，也就是我们在Solidity中使用的uint256。

到这里，你或许已经知道操作码MUL与MULMOD的区别了。

如何本文有任何错误，或者你有什么疑问需要咨询，欢迎联系我。

前置知识：Smart Contract、Solidity

引用该开源工具的一段文本描述：

Browsing contracts directly on etherscan sucks! Browsing multi-file contracts on etherscan sucks even more. Limited search, weird syntax highlighting, and many, many more. Finally, it's often impossible to just git clone repository and browse source code locally because it's hard to find the exact commit that matches onchain code.

在etherscan等浏览器上查看合约的代码是一件十分糟糕的事情，但开源工具**dethcode**带来来全新的体验。

传统查看合约代码的方式：

在这种情况下，查看合约中的代码简直就像地狱，但如果我们将该合约所在的url修改一下，美好的事情将会发生。

比如该合约地址：

"https://etherscan.io/token/0x60e4d786628fea6478f785a6d7e704777c86a7c6#code"

将.io修改成.deth.net

"https://etherscan.deth.net/token/0x60e4d786628fea6478f785a6d7e704777c86a7c6#code"

我们就会得到一个vscode风格的代码编辑器页面：

该功能支持以下多个链：

• etherscan.io

• ropsten.etherscan.io

• rinkeby.etherscan.io

• goerli.etherscan.io

• kovan.etherscan.io

• bscscan.com

• testnet.bscscan.com

• hecoinfo.com

• testnet.hecoinfo.com

• ftmscan.com

• testnet.ftmscan.com

• optimistic.etherscan.io

• kovan-optimistic.etherscan.io

• polygonscan.com

• testnet.polygonscan.com

• arbiscan.io

• testnet.arbiscan.io

• snowtrace.io

• testnet.snowtrace.io

同时你可以在你的浏览器收藏夹里添加一段这样的js代码：

javascript: location.href = location.href.replace(/\.\w+(\/)/, ".deth.net/")

之后每当你在区块链浏览器页面想要跳转到deth页面时，点击该收藏便会自动跳转。

快去给该项目star一下吧！

如何本文有任何错误，或者你有什么疑问需要咨询，欢迎联系我。

前置知识：Solidity、Solc、Remix、Ethers.js、Javascript/Typescript

前置条件：Solidity >=0.8.10

当我们希望了解EVM智能合约存储分布时，有三种方法可以获得智能合约状态变量的存储信息。

1.Remix

Remix功能强大，操作简便，我们可以使用Debug功能查看。

首先编写一个测试合约：

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    uint8 a ;

    constructor() {
        a = 1;
    }
}

之后我们点击部署按钮，控制台会输出成功部署合约的信息。

这时我们点击控制台右下角的调试按钮，Remix左侧会弹出合约调试器的界面。

看到这个页面之后，请用鼠标点击被圈出的按钮，该按钮会直接获得合约最后的运行状态。便于查看合约最后的存储情况。

点击之后让我们下翻调试器页面，会有一个Storage [Completely Loaded]的框体。

有了他我们便可以快速查询合约中状态变量的存储分布情况。

图中的key为变量a的槽位，value为a的值。

2.Solc

另外我们可以通过Solidity编译器查看状态变量的分布。

首先需要安装Solc（solcjs无法使用该功能，请安装solc）

安装完成后，进入合约文件所在目录，输入shell命令

solc --storage-layout storage.sol

加上的--storage-layout可以输出合约内变量分布的json信息。

solc --storage-layout contracts/storage.sol

======= contracts/storage.sol:Storage =======
Contract Storage Layout:
{"storage":[{"astId":3,"contract":"contracts/storage.sol:Storage","label":"a","offset":0,"slot":"0","type":"t_uint8"}],"types":{"t_uint8":{"encoding":"inplace","label":"uint8","numberOfBytes":"1"}}}

其中的slot便是变量的槽位。

3.Ethers.js

使用node.js的ethers.js库也可以查看状态变量的分布，但相对来说比较繁琐。

首先使用npm/yarn安装ethers.js库

yarn add ethers

编写脚本文件inspect_storage.js

const { ethers } = require('ethers');
const provider = new ethers.providers.JsonRpcProvider("https://mainnet.infura.io/v3/xxxxxxxxxxxx")

const main = async () => {
    const slot0 = await provider.getStorageAt("0xdAC17F958D2ee523a2206206994597C13D831ec7", 0)
    console.log(`slot0 value: ${slot0}`);
}
main()

运行脚本inspect_storage.js输出：

slot0 value: 0x000000000000000000000000c6cde7c39eb2f0f0095f41570af89efc2c1ea828

provider有个getStorageAt方法，第一个参数为已经部署的合约的地址，第二个参数为槽位数。代码中我们查看了该地址的第0x0个槽位，你可以根据自己的需求查看任意地址的任意槽位的值。

以上便是查看智能合约中状态变量的分布的三种方法。

如何本文有任何错误，或者你有什么疑问需要咨询，欢迎联系我。

前置知识：EVM、Smart Contract、Solidity

前置条件：Solidity 0.8.10

什么是存储布局（Storage layout）？

了解EVM的你应该知道Storage是存储智能合约变量的一段连续空间，合约中状态变量全部存储在这个地方，状态变量有不同的类型，不同的类型存储在Storage中，有着不同规则与分布，便是存储布局（Storage Layout）。

了解智能合约存储布局会对开发有什么帮助吗？

• 状态变量不同的排列组合顺序会影响Gas消耗的多少，理解存储分布有助于对Gas优化。

• 开发具有代理模式、钻石模式等功能的合约时需要拥有存储布局的知识。

• 更好的处理和管理合约中的数据，避免数据存储冲突。

• 加强对合约的安全审计，帮助你寻找或避免合约中的安全漏洞。

存储（Storage）的结构

EVM会为每一个合约分配一个独立的Storage，Storage是一段key-value存储结构，起始地址为0x0，长度为2^256。可以将其理解成为一个key是从0递增到2^256-的map,但实际中并不一定连续。

其中key是状态变量的地址，value是状态变量的值，变量在value上进行读写操作。单个key-value称为槽位（Slot），槽位的总数为2^256。

key和value都是256位，也就是说每个Slot最多存储32字节的数据。

状态变量的存储

查看合约中的状态变量存储位置有两种方式。

1.使用remix的debug功能，在Storage栏中可以查看槽位信息。

2.在ethers.js中，Provider提供了getStorageAt方法可以查询已经部署的合约的槽位信息。

3.通过solc编译添加 --storage-layout 参数可以输出存储信息。

1.布尔类型的存储

声明一个简单的合约：

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    bool b;

    constructor() {
        b = true;
    }
}

这里我们通过remix查看合约中的存储布局，可以发现bool b在Storage中的槽位为：

• key:0x0000000000000000000000000000000000000000000000000000000000000000

• value:0x0000000000000000000000000000000000000000000000000000000000000001

  图中key为变量b的槽位地址，value为变量b的值。

  通过constructor的初始化，bool b 存储在槽位0x0上，并且值为1（true），如果是false则为0，这里的value只占用1字节，剩余的31字节用0补齐。

2.整型的存储

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    uint8 a;
    uint256 b;
    uint16 c;
    // uint32 .....

    constructor() {
        a = 1;
        b = 12;
        c = 123;
    }
}

不难发现，槽位0x0的value为0x1，槽位0x1的value为0xc，槽位0x2的value为0x7b,对应constructor中初始化的数值。所以a的槽位是0x0，b的槽位是0x1，c的槽位是0x2。即便是只占用一个字节的变量a，也会单独占用一个32字节的槽位。

3.定长字节数组类型的存储

在solidity中，byte1、byte2、…、byte31这些类型被称为定长字节数组，因为他们一旦声明，长度是固定不变的。另外，address本质上是个byte20的定长字节数组，使用 address 类型可以方便地操作地址，address 类型支持许多与地址相关的内置函数，而无需手动处理字节数组。

contract Storage {
    bytes13 a;
    address b;
    bytes30 c;
    constructor() {
        a = "0xbach";
        b = address(0xeBF8F38Fc49928A315d9B10889EccE53d58062A9);
        c = "0xrachmaninoff";
    }
}

地址与整形类似，每个变量占用一个槽位，从高位开始存储数据，低位不足的地方用0补齐。

4.变长字节数组类型的存储

由于bytes与string的编码与存储方式相同，这里只用string举例说明。

存储字符串具有以下规则：

• 如果字符串长度小于等于31个字节，则存储在一个槽位之中，高位存储数据，低位存储字符串长度。

• 如果字符串长度大于等于32个字符，单个槽位32字节无法满足（32字节字符串数据+1字节字符串长度），则将字符串长度length * 2 + 1存入槽位中，数据按顺序存入槽位key = keccak256(abi.encode(slot))与之后的槽位。

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    string a;
    string b;
    string c;
    bytes32 e;

    constructor() {
        a = '1';
        b = '31byteslong00000000000000000000';
        c = '32byteslong000000000000000000000';
        e = keccak256(abi.encode(2));
    }
}

变量a占用槽位0x0，value的高位存储UFT-8的字节码，低位存储了字节长度length * 2 = 2，UTF-8中字符1的字节码为0x31，对应图中槽位0x0的value的值。

变量b占用槽位0x1，由于刚好等于31个字节，所以只占了一个槽位。"333162797465736c6f6e673030303030303030303030303030303030303030 "为数据"31byteslong00000000000000000000"的UTF-8编码。末尾"0x3e"为长度62。

变量c占用了两个槽位，分别是：

• 0x2

• 0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace

槽位0x2记录了字符串长度length * 2 + 1 = 0x41（64）

槽位0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace记录了字符串数据UTF-8的字节码。

变量e使用槽位0x3，展示了编译器是如何计算槽位的。

再举一个例子：

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    string a;

    constructor() {
        a = '65byteslong00000000000000000000065byteslong0000000000000000000000';
    }
}

槽位0x0记录了字符串长度length * 2 + 1 = 0x83（131）

数据存储在0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563与0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e565之间的3个槽位，共65个字节。

5.动态数组类型的存储

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    uint256[] a;

    constructor() {
        a.push(1);
        a.push(12);
        a.push(123);
    }
}

array与string的存储方式类似：

在槽位0x0上存储数组的length = 3；

在槽位keccak256(abi.encode(a.slot))=0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563处开始存储数据，每一个元素开辟一个新的连续槽位。

6.映射类型的存储

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    mapping (uint256 => uint256) a;
    bytes32 a1; 
    bytes32 a2; 

    constructor() {
        a[1] = 1;
        a[2] = 22;
        a1 = keccak256(abi.encode(1,0));
        a2 = keccak256(abi.encode(2,0));
    }
}

图中并未显示出槽位0点信息，我们使用solc来获取相关信息

"storage":[
    {"astId":5,"contract":"contracts/storage.sol:Storage","label":"a","offset":0,"slot":"0","type":"t_mapping(t_uint256,t_uint256)"},
    {"astId":7,"contract":"contracts/storage.sol:Storage","label":"a1","offset":0,"slot":"1","type":"t_bytes32"},
    {"astId":9,"contract":"contracts/storage.sol:Storage","label":"a2","offset":0,"slot":"2","type":"t_bytes32"}
]

通过solc编译后生成的layout json，我们可以发现map a是占用了槽位0x0的。

map类型的数据存储有自己独有的机制：

数据槽位s = keccak256(v . p)，其中v是存储的变量，p是map所在的槽位。

以constructor中的a[1] = 1;为例：

v是key 0x1，p是map a的槽位0x0

代码为：keccak256(abi.encode(1,0))，计算出的槽位是0xada5013122d395ba3c54772283fb069b10426056ef8ca54750cb9bb552a59e7d，槽位对应value为0x1。

7.结构体类型的存储

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    struct S {
        uint256 id;
        string name;
    }
    S s;

    constructor() {
        s = S({id : 1, name : "name"});
    }
}

根据图中的信息不难推测出，结构体并没有特别的规则。

了解了以上的状态变量存储规则，似乎并没有可以调优Gas的地方，接下来将介绍编译器的一个变量打包机制。

状态变量的紧密打包

在浏览之前的代码中你也许会想到，uint8明明只需要一个字节就可以存储，但却占用了整个槽位的32个字节。

Solc确实提供了这个问题的解决方案，就是将变量紧密的打包在一起。

我们用这个例子介绍一下：

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    uint8 a ;
    uint256 b;
    uint8 c;
    string divider;
    uint8 d ;
    uint8 e;
    uint256 f;

    constructor() {
        a = 1;
        b = 2;
        c = 3;
        divider = "divider";
        d = 4;
        e = 5;
        f = 6;
    }
}

在例子中，变量d e被打包进了同一个槽位0x4。

如果你按照变量a b c 的编写方式编写合约，那么每一个变量会占用一个槽位，你需要支出最少3个槽位的Gas fee。

但如果你按照变量d e f的排列方式编写，变量d e会被编译器打包在一个槽位中，这样你只需要支付2个槽位的Gas fee，尽管未来在修改这些被紧密打包的槽位时消耗的Gas会比普通槽位多，但如果修改频率较低时，你或许应该选用紧密打包的方式。

能够触发紧密打包的状态变量

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    struct S {
        uint8 a ;
        bool b;
        address c;
        bytes1 d;
    }   
    uint8 a ;
    bool b;
    address c;
    bytes1 d;
 
    S s;

    constructor() {
        a = 1;
        b = true;
        c = address(0x2681Ca153D2d1F4Df4b335339043B161B5B1f193);
        d = 'x';
        s = S({a: 1, b: true, c: address(0x2681Ca153D2d1F4Df4b335339043B161B5B1f193), d: 'x'});
    }
}

从合约和remix的输出可以推测出，能够触发紧密打包的状态变量类型有整型（uint256除外）、布尔型、定长字节数组/地址类型、结构体型。

结构体外的变量无法与结构体内的变量被动打包在一起

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.10;

contract Storage {
    struct S {
        uint8 a ;
    }
    uint8 a ;
 
    S s;
    
    constructor() {
        a = 1;
        s = S({a: 1});
    }
}

如何本文有任何错误，或者你有什么疑问需要咨询，欢迎联系我。