

I will read the source code of `go-ethereum ` and record this journey. Due to most of what I know about Ethereum is from building Dapp with Solidity, I prefer to start with the `vm` package.



The entry file is `evm.go`. 

## Call , StaticCall and DelegateCall

There are 4 method for executing the contract which are called `Call`,`StaticCall`,`CallCode` and `DelegateCall`. The differences between them is the execution environment (msg.sender,storage and code) .

We can dive into the implement of them except `CallCode` which is deprecated. `StaticCall` is the only readonly method and it is also the method used for `view` and `pure` function in Solidity. The storage will not be changed during `StaticCall` executing.

 `DelegateCall` differs from `Call` in the sense that it executes the given address code with the caller as context. EVM will generate a temporary contract instance with a chosen address and a chosen code. The storage of this address is the context in which the code runs.

Look at the code:

```go
func (evm *EVM) Call(caller ContractRef, addr common.Address, input []byte, gas uint64, value *uint256.Int) (ret []byte, leftOverGas uint64, err error) {
	............
  ............
  		code := evm.StateDB.GetCode(addr)
			addrCopy := addr
  
			// If the account has no code, we can abort here
			// The depth-check is already done, and precompiles handled above
			contract := NewContract(caller, AccountRef(addrCopy), value, gas)
			contract.SetCallCode(&addrCopy, evm.StateDB.GetCodeHash(addrCopy), code)
			ret, err = evm.interpreter.Run(contract, input, false)
			gas = contract.Gas
	............
  ............
	return ret, gas, err
}

```

 

```go
func (evm *EVM) DelegateCall(caller ContractRef, addr common.Address, input []byte, gas uint64) (ret []byte, leftOverGas uint64, err error) {
	............
  ............
		addrCopy := addr
		// Initialise a new contract and make initialise the delegate values
		contract := NewContract(caller, AccountRef(caller.Address()), nil, gas).AsDelegate()
		contract.SetCallCode(&addrCopy, evm.StateDB.GetCodeHash(addrCopy), evm.StateDB.GetCode(addrCopy))
		ret, err = evm.interpreter.Run(contract, input, false)
		gas = contract.Gas
	............
  ............
}

```

We can find the difference easily that is the parameter of constructor `NewContract`. The first uses the target address and the second uses the caller's address.

And the `StaticCall` :

```go
func (evm *EVM) StaticCall(caller ContractRef, addr common.Address, input []byte, gas uint64) (ret []byte, leftOverGas uint64, err error) {
	............
  ............
		ret, err = evm.interpreter.Run(contract, input, true)// readOnly
  ............
  ............

}
```

## Create and Create2

`Create` and `Create2` are basically same except calculating contract's address.

In `Create`, the address of new contract depends on the caller and it's nonce. 

In `Create2`, it depends on the caller, salt and code.

```go
func (evm *EVM) Create(caller ContractRef, code []byte, gas uint64, value *uint256.Int) (ret []byte, contractAddr common.Address, leftOverGas uint64, err error) {
	contractAddr = crypto.CreateAddress(caller.Address(), evm.StateDB.GetNonce(caller.Address()))
	return evm.create(caller, &codeAndHash{code: code}, gas, value, contractAddr, CREATE)
}

// Create2 creates a new contract using code as deployment code.
//
// The different between Create2 with Create is Create2 uses keccak256(0xff ++ msg.sender ++ salt ++ keccak256(init_code))[12:]
// instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
func (evm *EVM) Create2(caller ContractRef, code []byte, gas uint64, endowment *uint256.Int, salt *uint256.Int) (ret []byte, contractAddr common.Address, leftOverGas uint64, err error) {
	codeAndHash := &codeAndHash{code: code}
	contractAddr = crypto.CreateAddress2(caller.Address(), salt.Bytes32(), codeAndHash.Hash().Bytes())
	return evm.create(caller, codeAndHash, gas, endowment, contractAddr, CREATE2)
}
```



Go-ethereum code walkthrough Day 1


## EIP-2771简述

不知道大家在使用 openzepplin 轻松构建自己的 Dapp 时，有没有看到这样的代码：

```javascript
 function _msgSender() internal view virtual returns (address) {
        return msg.sender;
 }
```



初看你可能会觉得莫名其妙，msg sender 还能是什么东西？ 这东西有什么重写的必要吗？这就小看了 ethdevs 的脑洞了，在很多情况下，如果一个 Dapp 选择使用重写过的 _msgSender 做身份验证，会有很多便利和玩法，比如 [EIP-2771](https://eips.ethereum.org/EIPS/eip-2771) 就提供了一个思路，简单说来，就是为了应付某些账户没有 gas 确需要发交易的情况而生的，基本原理如下：



1. 用户 `user` 会把需要执行的**已签名交易信息**发送给 `Gas Relayer` (链下)
2.  `Gas Relayer` 调用一个叫做 `Trusted Forwarder` 的合约，合约内验证签名真伪
3.  `Trusted Forwarder`合约调用目标合约





而 EIP-2771 就会在这个过程里重新规定 msg sender 的定义。

首先在 `Trusted Forwarder `处理调用信息时，会将 `user` 的地址添加到下一次调用的 `calldata` 的最后边，而目标合约使用了被 EIP-2771 重写的 `_msgSender` 方法，若发送方是`Trusted Forwarder `，则解析出最后 20 个 bytes 作为 msg sender, 代码分别如下：

```javascript
//Trusted Forwarder     
        (bool success, bytes memory result) = req.to.call{ gas: req.gas, value: req.value }(
            abi.encodePacked(req.data, req.from)
        );
```



```javascript
// target contract
function _msgSender() internal view returns (address payable signer) {
        signer = msg.sender;
        if (msg.data.length>=20 && isTrustedForwarder(signer)) {
            assembly {
                signer := shr(96,calldataload(sub(calldatasize(),20)))
            }
        }    
    }
```

 按理来说，这样解析出来的 msgSender 就是签名的 `user` ，并没有什么不妥，但是强行读取 calldata 的动作十分危险，在 2023 年 12 月 6 日，TIME 由此出现安全事故，损失高达 18万美元。

交易链接:

https://etherscan.io/tx/0xecdd111a60debfadc6533de30fb7f55dc5ceed01dfadd30e4a7ebdb416d2f6b6



## 漏洞分析

我们先看其调用栈：

![](tracker.png '交易流程')

可以梳理其攻击手法：

1.先是在 uniswap 上兑换了一笔 TIME token, 

2.之后将 uniswap 的 WETH/TIME 池子中的 TIME burn 掉，得到了一个很高的 TIME 价格，

3.最后将那笔 TIME token 卖出，获得大量 WETH 完成攻击。

其中最关键的一步，“将池子的 TIME burn 掉” 是怎么做到的呢？我们主要分析第2步。

首先，用户调用了`Trusted Forwarder` 合约的 `execute` 方法()，其参数为：

```json
{
  "msg.sender":"0x6980a47bee930a4584b09ee79ebe46484fbdbdd0",
  "func":"execute",
  "args":{
    "req"		[
    {
    "from":"0xa16a5f37774309710711a8b4e83b068306b21724",
    "to":"0x4b0e9a7da8bab813efae92a6651019b8bd6c0a29",
    "value":"0",
    "gas":"5000000",
    "nonce":"0", 	"data":"0xac9650d8000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000003842966c680000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc1e043d99394a10605b2fa08f123d60faf840000000000000000"
  }
  ],
"signature":"0x9194983a3dbfb5779c09c95f5d830d8435d9ce88b383752c3dfb8a1b84b8c9f511b7c750f1334e2f26ca9be32c2d070a4a023edf745b02468d6cba9a15a494c61b"
},
"return":{ 
  "out0":true,
  "out1":"0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000"
         }
}
```

方法代码如下：

```javascript
//Trusted Forwarder     
function execute(ForwardRequest calldata req, bytes calldata signature)
        public
        payable
        returns (bool, bytes memory)
    {
        require(verify(req, signature), "MinimalForwarder: signature does not match request");
        _nonces[req.from] = req.nonce + 1;

        // solhint-disable-next-line avoid-low-level-calls
        (bool success, bytes memory result) = req.to.call{ gas: req.gas, value: req.value }(
            abi.encodePacked(req.data, req.from)
        );

        if (!success) {
            // Next 5 lines from https://ethereum.stackexchange.com/a/83577
            if (result.length < 68) revert("Transaction reverted silently");
            assembly {
                result := add(result, 0x04)
            }
            revert(abi.decode(result, (string)));
        }
        // Check gas: https://ronan.eth.link/blog/ethereum-gas-dangers/
        assert(gasleft() > req.gas / 63);
        return (success, result);
    }
```

`req.to` 也就是目标函数是 TIME 合约

解析 `req.data`:

```
0xac9650d8
0000000000000000000000000000000000000000000000000000000000000020
0000000000000000000000000000000000000000000000000000000000000001
0000000000000000000000000000000000000000000000000000000000000020
0000000000000000000000000000000000000000000000000000000000000038
42966c68
0000000000000000000000000000000000000000c9112ec16d958e8da8180000
760dc1e043d99394a10605b2fa08f123d60faf840000000000000000
```

通过函数签名 `0xac9650d8` 可以锁定其目标是 TIME 合约的 `multicall` 方法。

```javascript
    function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
        results = new bytes[](data.length);
        for (uint256 i = 0; i < data.length; i++) {
            results[i] = _functionDelegateCall(address(this), data[i]);
        }
        return results;
    }
```

但是 `req.data` 并不是 `multicall` 接收到的 `calldata` ，因为我们会在其后边加上 `req.from` 以确认 msg sender，那么 `multicall` 收到的参数则是：

```
0xac9650d8
0000000000000000000000000000000000000000000000000000000000000020
0000000000000000000000000000000000000000000000000000000000000001
0000000000000000000000000000000000000000000000000000000000000020
0000000000000000000000000000000000000000000000000000000000000038
42966c68
0000000000000000000000000000000000000000c9112ec16d958e8da8180000
760dc1e043d99394a10605b2fa08f123d60faf840000000000000000a16a5f37774309710711a8b4e83b068306b21724
```

`multicall`的参数是 `bytes[] calldata data` ,那么其每行的意思如下

```
0xac9650d8 //multicall 的函数选择器
0000000000000000000000000000000000000000000000000000000000000020 //第一个参数也就是 data 初始位置偏移
0000000000000000000000000000000000000000000000000000000000000001 //data数组的长度
0000000000000000000000000000000000000000000000000000000000000020 //data[0]的初始位置偏移
0000000000000000000000000000000000000000000000000000000000000038 //data[0]的长度
42966c68
0000000000000000000000000000000000000000c9112ec16d958e8da8180000
760dc1e043d99394a10605b2fa08f123d60faf840000000000000000a16a5f37774309710711a8b4e83b068306b21724
```

想必大家可能隐约意识到其问题所在了，我们可以通过设定 `data[0]` 的长度让 `multicall` 忽视掉某些信息！实际上 `multicall` 收到的 `data[0]` 是 `0x42966c680000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc1e043d99394a10605b2fa08f123d60faf84` ，而 `data` 也只有一个元素而已！



下一步`multicall` 使用调用`0x42966c680000000000000000000000000000000000000000c9112ec16d958e8da8180000760dc1e043d99394a10605b2fa08f123d60faf84`其自身， 匹配到了`burn`函数：



```javascript
    function burn(uint256 amount) public virtual {
        _burn(_msgSender(), amount);
    }
```

那么我们再次分析这个输入 `calldata`:

```
0x42966c68 //burn 的函数选择器
0000000000000000000000000000000000000000c9112ec16d958e8da8180000 //burn 的第一个参数 amount
760dc1e043d99394a10605b2fa08f123d60faf84
```

以及其`_msgSender`:

```javascript
    function _msgSender()
        internal
        view
        virtual
        override(ContextUpgradeable, ERC2771ContextUpgradeable)
        returns (address sender)
    {
        return ERC2771ContextUpgradeable._msgSender();
    }
```

也就是这个 `ERC2771ContextUpgradeable` ，把 `calldata` 的最后20字节 `0x760dc1e043d99394a10605b2fa08f123d60faf84` 返回了回去，作为 burn token 的账户，而这个 `0x760dc1e043d99394a10605b2fa08f123d60faf84` 正是 uniswap WETH/TIME 的资金池。这时，该池子里的 TIME 价格变得非常高，攻击者使用刚刚买入的 TIME 换走池子里剩下的 WETH ,完成攻击。



## 结语

这个案例的问题在于 `multicall` 并没有识别 `Trusted Forwarder` ，导致损失了 `req.from` 的信息，但是归根结底，这是过于相信拼接 `calldata` 的表达能力了，solidity 只会根据 abi 解析数据，任何拼接的参数都有一定程度的风险，我们尽量不要在跨项目的交互中过于依赖这种方法，有一个 puzzle 同样运用了该方法，留给诸君练习使用:  [abi-smuggling](https://www.damnvulnerabledefi.xyz/challenges/abi-smuggling/ ) 。

使用 abi.encode 在多个项目中传递信息是很危险的行为

由EIP-2771引发的血案 - TIME token 安全案例详解





可升级合约的原理听起来很简单，我们在可升级合约中采取 Proxy 合约存储数据，implement 合约存储代码，就可以实现在保证存储区不变的情况下更新代码，但是如果想保证我们的存储区的安全，非得对合约存储区有一定认识才可以。

我们可以从这两个实现合约入手：



```
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
abstract contract V1{
    uint public a;
    uint public b;

    function setA(uint a_) public {
        a = a_;
    }
    
    function setB(uint b_) public {
        b = b_;
    }

    function result() public view returns(uint){
        return a+b;
    }
    
}
```



```
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
abstract contract V2{
    uint public b;
    uint public a;

    function setA(uint a_) public {
        a = a_;
    }
    
    function setB(uint b_) public {
        b = b_;
    }

    function result() public view returns(uint){
        return a*b;
    }
    
}
```

我们可以看出，除了将 `function result() public view returns(uint)` 的实现改变之外，变量 `a` 和变量 `b` 的位置也发生了变化，这会导致一个问题，代理合约中的插槽 0 在第一版中是变量 `a` ， 而在第二版中是变量 `b` ，很多情况下这会导致存储和逻辑的代码出现冲突，在一些开发框架下，出现存储区冲突的升级会报错，而大多数情况我们都要保证一条，那就是"新实现的变量一定要写在所有原有变量之后。" (`constant` 变量除外 , 它们直接硬编码进code , 不占用存储区)。



在有合约继承的情况下，编译器会将所有的父合约和当前合约写在同一张合约里，其存储区也当然是通用的，而存储区的排列是：父合约1，父合约2，... ，当前合约。以下面的合约为例：

```
pragma solidity ^0.8.0;
import './Extend2.sol';
import './Extend1.sol';

contract Test is  Extend1 ,Extend2 {
   address public a;
   uint256 public u;
   uint256 public balance;

}
abstract contract Extend1{
    address internal  _e1;
}
abstract contract Extend2{
    address internal _e2;
}

```

父合约的顺序由合约声明时的顺序决定，`contract Test is  Extend1 ,Extend2` 中 `Extend1` 就在 `Extend2`之前，那么在这个合约中，存储区先分配 `Extend1` 中的变量，然后是 `Extend2` ,然后是 `Test` 合约。那么插槽0 即表示 `_e1`,插槽1 表示 `_e2`,插槽2 为  `a`。



既然父合约的变量一定会排在实现合约之前，那么是不是表示一旦加入了新的父合约，实现合约的存储区就会发生冲突呢？我们似乎在开发中很少遇到这种冲突情况，因为`openzepplin`提供了大多数基础合约的可升级版本，他们在所有的可升级合约中都没有显式声明任何非`constant`变量，而是通过直接指定插槽的方式进行存储和查询。

```javascript
// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v5.0.0) (access/Ownable.sol)

pragma solidity ^0.8.20;

import {ContextUpgradeable} from "../utils/ContextUpgradeable.sol";
import {Initializable} from "../proxy/utils/Initializable.sol";

/**
 * @dev Contract module which provides a basic access control mechanism, where
 * there is an account (an owner) that can be granted exclusive access to
 * specific functions.
 *
 * The initial owner is set to the address provided by the deployer. This can
 * later be changed with {transferOwnership}.
 *
 * This module is used through inheritance. It will make available the modifier
 * `onlyOwner`, which can be applied to your functions to restrict their use to
 * the owner.
 */
abstract contract OwnableUpgradeable is Initializable, ContextUpgradeable {
    /// @custom:storage-location erc7201:openzeppelin.storage.Ownable
    struct OwnableStorage {
        address _owner;
    }

    // keccak256(abi.encode(uint256(keccak256("openzeppelin.storage.Ownable")) - 1)) & ~bytes32(uint256(0xff))
    bytes32 private constant OwnableStorageLocation = 0x9016d09d72d40fdae2fd8ceac6b6234c7706214fd39c1cd1e609a0528c199300;

    function _getOwnableStorage() private pure returns (OwnableStorage storage $) {
        assembly {
            $.slot := OwnableStorageLocation
        }
    }

    /**
     * @dev The caller account is not authorized to perform an operation.
     */
    error OwnableUnauthorizedAccount(address account);

    /**
     * @dev The owner is not a valid owner account. (eg. `address(0)`)
     */
    error OwnableInvalidOwner(address owner);

    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    /**
     * @dev Initializes the contract setting the address provided by the deployer as the initial owner.
     */
    function __Ownable_init(address initialOwner) internal onlyInitializing {
        __Ownable_init_unchained(initialOwner);
    }

    function __Ownable_init_unchained(address initialOwner) internal onlyInitializing {
        if (initialOwner == address(0)) {
            revert OwnableInvalidOwner(address(0));
        }
        _transferOwnership(initialOwner);
    }

    /**
     * @dev Throws if called by any account other than the owner.
     */
    modifier onlyOwner() {
        _checkOwner();
        _;
    }

    /**
     * @dev Returns the address of the current owner.
     */
    function owner() public view virtual returns (address) {
        OwnableStorage storage $ = _getOwnableStorage();
        return $._owner;
    }

    /**
     * @dev Throws if the sender is not the owner.
     */
    function _checkOwner() internal view virtual {
        if (owner() != _msgSender()) {
            revert OwnableUnauthorizedAccount(_msgSender());
        }
    }

    /**
     * @dev Leaves the contract without owner. It will not be possible to call
     * `onlyOwner` functions. Can only be called by the current owner.
     *
     * NOTE: Renouncing ownership will leave the contract without an owner,
     * thereby disabling any functionality that is only available to the owner.
     */
    function renounceOwnership() public virtual onlyOwner {
        _transferOwnership(address(0));
    }

    /**
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Can only be called by the current owner.
     */
    function transferOwnership(address newOwner) public virtual onlyOwner {
        if (newOwner == address(0)) {
            revert OwnableInvalidOwner(address(0));
        }
        _transferOwnership(newOwner);
    }

    /**
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Internal function without access restriction.
     */
    function _transferOwnership(address newOwner) internal virtual {
        OwnableStorage storage $ = _getOwnableStorage();
        address oldOwner = $._owner;
        $._owner = newOwner;
        emit OwnershipTransferred(oldOwner, newOwner);
    }
}
```



我们可以看到这个我们经常使用的可升级合约合约，把该合约用到的数值打包进一个结构体，之后指定了一个 slot 进行存储，而不是让编译器自行安排，这样当我们添加或者删除这段代码后，合约的存储区不会由于错位导致冲突。



对于这种指定存储区的写法我们可以直接参考 `StorageSlot.sol` :



```javascript
library StorageSlot {
    struct AddressSlot {
        address value;
    }

    struct BooleanSlot {
        bool value;
    }

    struct Bytes32Slot {
        bytes32 value;
    }

    struct Uint256Slot {
        uint256 value;
    }

    struct Int256Slot {
        int256 value;
    }

    struct StringSlot {
        string value;
    }

    struct BytesSlot {
        bytes value;
    }

    /**
     * @dev Returns an `AddressSlot` with member `value` located at `slot`.
     */
    function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `BooleanSlot` with member `value` located at `slot`.
     */
    function getBooleanSlot(bytes32 slot) internal pure returns (BooleanSlot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `Bytes32Slot` with member `value` located at `slot`.
     */
    function getBytes32Slot(bytes32 slot) internal pure returns (Bytes32Slot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `Uint256Slot` with member `value` located at `slot`.
     */
    function getUint256Slot(bytes32 slot) internal pure returns (Uint256Slot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `Int256Slot` with member `value` located at `slot`.
     */
    function getInt256Slot(bytes32 slot) internal pure returns (Int256Slot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `StringSlot` with member `value` located at `slot`.
     */
    function getStringSlot(bytes32 slot) internal pure returns (StringSlot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `StringSlot` representation of the string storage pointer `store`.
     */
    function getStringSlot(string storage store) internal pure returns (StringSlot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := store.slot
        }
    }

    /**
     * @dev Returns an `BytesSlot` with member `value` located at `slot`.
     */
    function getBytesSlot(bytes32 slot) internal pure returns (BytesSlot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := slot
        }
    }

    /**
     * @dev Returns an `BytesSlot` representation of the bytes storage pointer `store`.
     */
    function getBytesSlot(bytes storage store) internal pure returns (BytesSlot storage r) {
        /// @solidity memory-safe-assembly
        assembly {
            r.slot := store.slot
        }
    }
}
```

当我们需要声明一个变量时，可以直接使用一个 `constant` 变量来标记变量，而非直接生命变量：

```javascript
 bytes32 internal constant _U_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbb;
```



需要写入数据，则使用：

```javascript
    function setU(uint256 u_) public {
        StorageSlot.getUint256Slot(_U_SLOT).value = u_;
   }
```

需要读取数据，就可以使用：

```javascript
   function getUSlot() public view returns (uint256) {
    return StorageSlot.getUint256Slot(_U_SLOT).value;
   }
   
```

这样就可以保证我们的变量不再受声明顺序的影响了。

总结一下，当开发可升级合约时，我们需要注意每次更新时的存储位置不发生冲突，在这个基础上，如果需要继承他人的代码库，需要确保他人的代码库也是可升级的。

使用指定slot解决可升级合约中的存储区冲突问题

可升级合约中的存储区问题


## 开篇

由于在站内看到了2022年layerzero极简教程，但是由于layerzero版本更迭，其官方示例的封装性高又缺乏注解，故写了这篇2024版layerzero示例。

本示例包含fantom testnet 跨链传递信息或native token至mumbai network的合约与脚本，希望能帮到诸位。




## 初始化项目

我们可以使用hardhat很轻松地创建一个solidity合约项目：

```shell
mkdir layerzero-tutorial

cd layerzero-tutorial

npm init

npm install --save-dev hardhat

npx hardhat init
```

最后一项选择创建一个ts项目

```
👷 Welcome to Hardhat v2.20.1 👷‍

? What do you want to do? …

  Create a JavaScript project

  Create a TypeScript project

 ❯ Create a TypeScript project (with Viem)

  Create an empty hardhat.config.js

  Quit
```



## 编写合约

我们期待从A链发送信息或者代币至B链，需要在A/B两条链上分别部署合约，如果你的操作是对称的，即相同业务的双向通信，则可以使用同一张合约，本示例的合约也只有一张，分别部署至 fantom testnet 和 mumbai。

下面是合约代码：

```javascript
//SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;
pragma abicoder v2;

import "../interfaces/ILayerZeroEndpoint.sol";
import "../interfaces/ILayerZeroReceiver.sol";
import "hardhat/console.sol";

contract LayerZeroDemo1 is ILayerZeroReceiver {
    event ReceiveMsg(
        uint16 _srcChainId,
        address _from,
        uint16 _count,
        bytes _payload
    );
    ILayerZeroEndpoint public endpoint;
    uint16 public messageCount;
    bytes public message;

    constructor(address _endpoint) {
        endpoint = ILayerZeroEndpoint(_endpoint);
    }
    
    function sendMsg(
        uint16 _dstChainId,
        address _destination,
        bytes calldata payload,
        bytes calldata _adapterParams
    ) public payable {
        require(abi.encodePacked(_destination,address(this)).length == 40, "Invalid destination");
        endpoint.send{value: msg.value}(
            _dstChainId,
            abi.encodePacked(_destination,address(this)),
            payload,
            payable(msg.sender),
            address(this),
            _adapterParams
        );
    }

    function sendNativeToken(
        uint16  _dstChainId, 
        address  _toAddress, 
        uint  _amount
    ) public payable {
        uint dstGas = 350000;
        uint16 version = 2;
        bytes memory adapterParams = abi.encodePacked(version, dstGas, _amount, _toAddress);
        bytes memory payload = abi.encode(_amount, msg.sender, _toAddress);
        //_lzSend(_dstChainId[i], payload, refundAddress, _zroPaymentAddress, adapterParams, address(this).balance);
        endpoint.send{value: msg.value}(
            _dstChainId,
            abi.encodePacked(_toAddress,address(this)),
            payload,
            payable(msg.sender),
            address(this),
            adapterParams
        );

    }
    
    function lzReceive(
        uint16 _srcChainId,
        bytes memory _from,
        uint64,
        bytes memory _payload
    ) external override {
        require(msg.sender == address(endpoint));
        address from;
        assembly {
            from := mload(add(_from, 20))
        }
        if (
            keccak256(abi.encodePacked((_payload))) ==
            keccak256(abi.encodePacked((bytes10("ff"))))
        ) {
            endpoint.receivePayload(
                1,
                bytes(""),
                address(0x0),
                1,
                1,
                bytes("")
            );
        }
        message = _payload;
        messageCount += 1;
        emit ReceiveMsg(_srcChainId, from, messageCount, message);
    }
    
    // Endpoint.sol estimateFees() returns the fees for the message
    function estimateFees(
        uint16 _dstChainId,
        address _userApplication,
        bytes calldata _payload,
        bool _payInZRO,
        bytes calldata _adapterParams
    ) external view returns (uint256 nativeFee, uint256 zroFee) {
        return
            endpoint.estimateFees(
                _dstChainId,
                _userApplication,
                _payload,
                _payInZRO,
                _adapterParams
            );
    }

    receive() external payable {
    }
}
```



接下来我会讲解这份合约：

**首先是引用的几个接口：**

```javascript
import "../interfaces/ILayerZeroEndpoint.sol";
import "../interfaces/ILayerZeroReceiver.sol";
```

这两个接口由LayerZero项目方提供，实现 ILayerZeroEndpoint 的 endpoint 合约与我们自己的业务合约直接对接，是我们使用LayerZero进行跨链操作的入口合约，而ILayerZeroReceiver 规定了一些标准使得我们处于目标链的合约可以接收到来自 LayerZero 桥的信息。

**之后我们在构造函数中存储endpoint的地址**，每条链上的endpoint地址都有不同，可以查询LayerZero官方文档：
[文档](https://layerzero.gitbook.io/docs/technical-reference/testnet/testnet-addresses)

```java
    constructor(address _endpoint) {
        endpoint = ILayerZeroEndpoint(_endpoint);
    }
```

**我们再来写消息传递方法：**

```
    function sendMsg(
        uint16 _dstChainId,
        address _destination,
        bytes calldata payload,
        bytes calldata _adapterParams
    ) public payable {
        require(abi.encodePacked(_destination,address(this)).length == 40, "Invalid destination");
        endpoint.send{value: msg.value}(
            _dstChainId,
            abi.encodePacked(_destination,address(this)),
            payload,
            payable(msg.sender),
            address(this),
            _adapterParams
        );
    }
```

这里我们可以看到一些意义不明的参数，由于业务代码可以随意设置，我们直接解释endpoint的send方法，_dstChainId 是目标链的id，注意不是我们区块链意义的chainId，而是目标链上的endpoint的ID，例如mumbai 的chain id是80001，mumbai上endpoint的id是10109,如果我们是想跨到mumbai，那这第一个参数应该写 10109。第二个参数名为 path,它是由目标合约和本业务合约 encodePacket形成的，第三个参数payload 和 第四个参数payloadAddress,分别是需要传递的信息和收退款的地址，这里我们设置为发送者本人了。第五个参数是给layerzero交手续费的地址，这里我们设置成合约本身。而最后一个adapterParams代表了对这次交易的gas设置和native token 处理方式，我会在下一个章节详细说明。

类似的我们也可以写出带有nativetoken 传递的方法，需要说明的是，上边的sendMsg本质上也可以通过手动构造adapterParams来实现这个类型的交易，我选择只是想使用sendNativeToken做例子说明在大多数的业务场景里，adapterParams在合约encode里更加便利一些。

```
    function sendNativeToken(
        uint16  _dstChainId, 
        address  _toAddress, 
        uint  _amount
    ) public payable {
        uint dstGas = 350000;
        uint16 version = 2;
        bytes memory adapterParams = abi.encodePacked(version, dstGas, _amount, _toAddress);
        bytes memory payload = abi.encode(_amount, msg.sender, _toAddress);
        //_lzSend(_dstChainId[i], payload, refundAddress, _zroPaymentAddress, adapterParams, address(this).balance);
        endpoint.send{value: msg.value}(
            _dstChainId,
            abi.encodePacked(_toAddress,address(this)),
            payload,
            payable(msg.sender),
            address(this),
            adapterParams
        );

    }
```

其实和sendMsg差不多，只是我们在合约里给 adapterParams 赋了值。

adapterParams的格式被按照交易类型分为两种：

第一种是不给目标合约发送原生代币，它的adapterParams格式为：
    // txType 1
    // bytes  [2       32      ]
    // fields [txType  extraGas]
总共34 byte，依次是交易类型，目标链gaslimit
第二种是给目标合约发送原生代币，它的adapterParams格式为：
    // txType 2
    // bytes  [2       32        32            bytes[]         ]
    // fields [txType  extraGas  dstNativeAmt  dstNativeAddress]
    // User App Address is not used in this version

依次是  交易类型，目标链gaslimit，发送代币数目，目标地址

所以我们的adapterParams构建为：

```javascript
        uint dstGas = 350000;
        uint16 version = 2;
        bytes memory adapterParams = abi.encodePacked(version, dstGas, _amount, _toAddress);
```





## 编写部署脚本

我们的部署脚本其实是一模一样的，只是部署参数中的endpoint地址不同而已：

Fantom testnet:

```typescript
async function main() {
  const LayerZeroDemo1 = await ethers.getContractFactory("LayerZeroDemo1");
  const layerZeroDemo1 = await LayerZeroDemo1.deploy(
    "0x7dcAD72640F835B0FA36EFD3D6d3ec902C7E5acf"
  );
  await layerZeroDemo1.waitForDeployment();
  console.log("layerZeroDemo1 deployed to:", await layerZeroDemo1.getAddress(),"on Fantom Testnet.");
}
/*
```



Mumbai :

```typescript
async function main() {
  const LayerZeroDemo1 = await ethers.getContractFactory("LayerZeroDemo1");
  const layerZeroDemo1 = await LayerZeroDemo1.deploy(
    "0xf69186dfBa60DdB133E91E9A4B5673624293d8F8"
  );
  await layerZeroDemo1.waitForDeployment();
  console.log("layerZeroDemo1 deployed to:", await layerZeroDemo1.getAddress(), " on Mumbai Testnet.");
}
```



我们便可以得到fantomtestnet 和 mumbai 上的合约：

fantomtestnet:*0xd79b3438968FB409340c9fd405109258C458C5F7*

mumbai:*0x55DD4f23aFA85305f8C7DCa8a9F86D0d0a5aE8Cd*

## 编写测试脚本

现在我们开始调用fantomtestnet 的合约：

### sendMsg方法：

```typescript
async function main() {
  const layerZeroDemo1 = await ethers.getContractAt("LayerZeroDemo1", "0xd79b3438968FB409340c9fd405109258C458C5F7");
  const transaction = await layerZeroDemo1.sendMsg(
    10109,
    "0x55DD4f23aFA85305f8C7DCa8a9F86D0d0a5aE8Cd",
    ethers.encodeBytes32String("Hello LayerZero1"),
    "0x00010000000000000000000000000000000000000000000000000000000001111111",
    { value: ethers.parseEther("1") }
  );
    console.log(transaction.hash);
}
```

这里值得一说的实际上只有 adapterparams, "0001"为transaction type,"0000000000000000000000000000000000000000000000000000000001111111"为gasLimit。而我们传入的 value，1个ftm会在扣除掉gas fee后还给我们。



### sendNativeToken方法：

```typescript
async function sendNativeToken(){
    const layerZeroDemo1 = await ethers.getContractAt("LayerZeroDemo1", "0xd79b3438968FB409340c9fd405109258C458C5F7");
    const transaction = await layerZeroDemo1.sendNativeToken(
        10109, 
        "0x55DD4f23aFA85305f8C7DCa8a9F86D0d0a5aE8Cd",
        100,
        { value: ethers.parseEther("1")}
    )
    console.log(transaction.hash);
}

```



## 检查方法：



我们可以在layerzero scan查看交易的情况：
[浏览器](https://layerzeroscan.com/)

![](2gz1RRm265e48eb67cf16.webp '浏览器截图')

LayerZero 跨链通信转账 2024极简示例


Evm puzzles 是一套练习和入门 evm 执行原理和 opcode 的习题，里边涉及到简单的 opcode 操作，如操作堆栈，操作内存，操作 calldata ，部署合约等等，更重要的是它只有十道题，即使是新手也可以在几个小时内解决谜题！让我们开始吧！

规则：输入恰当的 calldata 和 value，使得题目的 opcode 正确执行，直到执行STOP。

puzzle 交互工具：https://github.com/fvictorio/evm-puzzles

## puzzle 1:

题目：

```assembly
pc      opcode  opcode name
00      34      CALLVALUE
01      56      JUMP
02      FD      REVERT
03      FD      REVERT
04      FD      REVERT
05      FD      REVERT
06      FD      REVERT
07      FD      REVERT
08      5B      JUMPDEST
09      00      STOP
```

此题简单明了，我们需要跳转至`pc = 0x08`才能避免中途 revert，所以`0x01`位置的`JUMP`应该跳转至 `0x08`。
根据evm文档，JUMP 操作 的模式为：

| stack | name      | gas  | initial stack | result stack | mem/storage |
| ----- | --------- | ---- | ------------- | ------------ | ----------- |
| 56    | JUMP      | 8    | dst           | /            | /           |
| 34    | CALLVALUE | 2    | /             | msg.value    | /           |

即：CALLVALUE 把 msg.value 放在调用栈上，JUMP 从调用栈的一个值，跳转至该值位置。
现在应该很清楚了 msg.value == 8 即可通关。

## puzzle 2:

题目：

```assembly
pc      opcode  opcode name
00      34      CALLVALUE
01      38      CODESIZE
02      03      SUB
03      56      JUMP
04      FD      REVERT
05      FD      REVERT
06      5B      JUMPDEST
07      00      STOP
08      FD      REVERT
09      FD      REVERT
```

此题跟 puzzle 1 差不多，只新增了两个 opcode，我们依然先看文档：



| stack | name     | gas  | initial stack | result stack   | mem/storage |
| ----- | -------- | ---- | ------------- | -------------- | ----------- |
| 38    | CODESIZE | 2    | /             | len(this.code) | /           |
| 03    | SUB      | 3    | a,b           | a - b          | /           |

我们先使用 CALLVALUE 将 msg.value 压入调用栈，再把代码长度压栈，我们可以看到我们的 code 总长度为10，也就是 `10 - msg.value == 0x06`，可得 msg.value == 4。题解结束。

## puzzle 3:

题目：

```assembly
pc      opcode  opcode name
00      36      CALLDATASIZE
01      56      JUMP
02      FD      REVERT
03      FD      REVERT
04      5B      JUMPDEST
05      00      STOP
```

新增了一个 opcode:

| stack | name         | gas  | initial stack | result stack  | mem/storage |
| ----- | ------------ | ---- | ------------- | ------------- | ----------- |
| 36    | CALLDATASIZE | 2    | /             | len(msg.data) | /           |

只要我们的 `len(msg.data) == 4` 即可完成题解，例如 `msg.data == 0x00000000`

## puzzle 4:

题目：

```assembly
pc      opcode  opcode name
00      34      CALLVALUE
01      38      CODESIZE
02      18      XOR
03      56      JUMP
04      FD      REVERT
05      FD      REVERT
06      FD      REVERT
07      FD      REVERT
08      FD      REVERT
09      FD      REVERT
0A      5B      JUMPDEST
0B      00      STOP
```

XOR 大家应该都很熟悉了, 就是 pop 两个操作栈里的值，然后把异或结果 pop 回去：

| stack | name | gas  | initial stack | result stack | mem/storage |
| ----- | ---- | ---- | ------------- | ------------ | ----------- |
| 18    | XOR  | 3    | a,b           | a ^ b        | /           |

我们需要保证 `msg.value xor codesize == 0x0A`。0x0A 的二进制表示为 0000 1010，而我们可以知道 codesize == 0c（10进制的12）,二进制表示为0000 1100，可以计算出 `msg.data == 6` 即二进制表示为 0000 0110。

## puzzle 5:

题目：

```assembly
pc      opcode      opcode name
00      34          CALLVALUE
01      80          DUP1
02      02          MUL
03      610100      PUSH2 0100
06      14          EQ
07      600C        PUSH1 0C
09      57          JUMPI
0A      FD          REVERT
0B      FD          REVERT
0C      5B          JUMPDEST
0D      00          STOP
0E      FD          REVERT
0F      FD          REVERT
```

认识一下新的 opcode:



| stack | name  | gas  | initial stack  | result stack | mem/storage |
| ----- | ----- | ---- | -------------- | ------------ | ----------- |
| 80    | DUP1  | 3    | a              | a,a          | /           |
| 02    | MUL   | 5    | a,b            | a * b        | /           |
| 60    | PUSH1 | 3    | .              | uint8        | /           |
| 61    | PUSH2 | 3    | .              | uint16       | /           |
| 14    | EQ    | 3    | a,b            | a == b       | /           |
| 57    | JUMPI | 10   | dst, condition | /            | /           |

DUP1：将栈顶元素再复制一份放在栈顶。
MUL：pop 栈顶两元素，push a*b 的结果到栈顶。
PUSH1/PUSH2：把一个元素放在栈顶，如610100 即使用 PUSH2(61) 将 8(0100) 放在栈顶。
EQ：pop 栈顶两元素，push a==b 的结果到栈顶。
JUMPI：取栈顶两元素，分别是 dst 和 condition，如果 condition == 1 则跳转到 `pc == dst`的位置，否则，执行下一条语句。

我们可以从结果往前推，目的是达到`0x0d`位置的 STOP，需要通过跳转达到`0x0c`，也就是来自 `pc == 0x09`位置的 JUMPI 。
`pc == 0x07` 处我们得知，此时的栈顶元素是 PUSH1 操作符操作的 `0x0c`，这正好与我们的目标地址相等。也就是说明 JU MPI 的 condition 为真。即`pc == 0x06`处的 EQ 返回为真。
再往上就简单多了 ，其实只需要满足 `msg.value*msg.value == 0x0100` 注意，这里的0100是16进制数字而非二进制数字，所以`msg.data*msg.data == 256` 即  `msg.data == 16` 完成题解。

## puzzle 6:

题目：

```assembly
pc      opcode  opcode name
00      6000      PUSH1 00
02      35        CALLDATALOAD
03      56        JUMP
04      FD        REVERT
05      FD        REVERT
06      FD        REVERT
07      FD        REVERT
08      FD        REVERT
09      FD        REVERT
0A      5B        JUMPDEST
0B      00        STOP
```

新增一个 opcode:

| stack | name         | gas  | initial stack | result stack         | mem/storage |
| ----- | ------------ | ---- | ------------- | -------------------- | ----------- |
| 35    | CALLDATALOAD | 3    | idx           | msg.data[idx:idx+32] | /           |

简单明了 pop 栈顶元素作为 idx ，把 msg.data 从 idx 开始的32位写入操作栈。
这样我们可以直接获得构造条件：`msg.data[0:32]== 0x000000000000000000000000000000000000000000000000000000000000000a` 即可

## puzzle 7:

题目：

```assembly
pc      opcode    opcode name
00      36        CALLDATASIZE
01      6000      PUSH1 00
03      80        DUP1
04      37        CALLDATACOPY
05      36        CALLDATASIZE
06      6000      PUSH1 00
08      6000      PUSH1 00
0A      F0        CREATE
0B      3B        EXTCODESIZE
0C      6001      PUSH1 01
0E      14        EQ
0F      6013      PUSH1 13
11      57        JUMPI
12      FD        REVERT
13      5B        JUMPDEST
14      00        STOP
```

从第7题开始难度会增加一些，我们先看一下新引入的opcode吧



| stack | name         | gas      | initial stack    | result stack   | mem/storage                                         |
| ----- | ------------ | -------- | ---------------- | -------------- | --------------------------------------------------- |
| 37    | CALLDATACOPY | 3+       | dstOst, ost, len | /              | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] |
| F0    | CREATE       | 32000+   | val, ost, len    | addr           | /                                                   |
| 3B    | EXTCODESIZE  | 100/2600 | addr             | len(addr.code) | /                                                   |

CALLDATACOPY 简单明了，就是 pop 出三个栈顶元素，记为dstOst, ost, len。把`msg.data[ost:ost+len-1]`	复制到内存：`msg.data[ost:ost+len-1]`

CREATE 相对复杂，它是一个部署合约的 opcode，pop 出三个栈顶元素，记为val, ost, len。
val 是创建合约时传入的 eth 数目。
mem[ost:ost+len-1] 是合约的 contract code。
addr 返回值是已创建合约的地址。

EXTCODESIZE 取出栈顶元素，然后返回该合约的 code 长度。

我们先看第一段，`0x00` - `0x05`

```assembly
pc      opcode    opcode name
00      36        CALLDATASIZE
01      6000      PUSH1 00
03      80        DUP1
04      37        CALLDATACOPY
05      36        CALLDATASIZE
```

这一段其实就是把 `msg.data` 整个复制到内存`mem`。

第二段，`0x06`-`0x0a`

```assembly
pc      opcode  opcode name
06      6000      PUSH1 00
08      6000      PUSH1 00
0A      F0        CREATE
```

把 `mem`上的代码部署到链。并把合约地址写回栈顶。

第三段，`0x0b`-`0x14`

```assembly
pc      opcode    opcode name
0B      3B        EXTCODESIZE
0C      6001      PUSH1 01
0E      14        EQ
0F      6013      PUSH1 13
11      57        JUMPI
12      FD        REVERT
13      5B        JUMPDEST
14      00        STOP
```

我们可以看到要正确跳转需要满足的条件是 `len(address.code) == 1`。

现在的问题是，新创建合约使用的code是我们的 msg.data，那是不是意味着部署后合约的 code 也是msg.data 呢？其实不然。创建合约的 code 被称为 creation code, 而最终留在区块链里的合约代码被称为 runtime code。这其实隐含着 conrtuctor的内容，contructor 只存在于 creation code 而非 runtime code ，这也是构造函数只被执行一次的原因。合约 creation code 会在一个交易里执行，并把 runtime code通过 `RETURN` 返回。

我们还需要额外引入一个 opcode:

| stack | name   | gas  | initial stack | result stack | mem/storage |
| ----- | ------ | ---- | ------------- | ------------ | ----------- |
| F3    | RETURN | *    | ost, len      | /            | /           |

ost 为 runtime code 在内存的起始位置，len 为截取长度，我们尝试构建一个 creation code:

```assembly
pc      opcode    opcode name
00      6001      PUSH1 01
02      6000      PUSH1 00
04      F3        RETURN
```

这样我们返回的 runtime code 的长度就只是从内存中取出的一位操作符了。

也就是 `msg.data == 0x60016000f3` 即可完成 puzzle ！

## puzzle 8:

题目：

```assembly
pc      opcode    opcode name
00      36        CALLDATASIZE
01      6000      PUSH1 00
03      80        DUP1
04      37        CALLDATACOPY
05      36        CALLDATASIZE
06      6000      PUSH1 00
08      6000      PUSH1 00
0A      F0        CREATE
0B      6000      PUSH1 00
0D      80        DUP1
0E      80        DUP1
0F      80        DUP1
10      80        DUP1
11      94        SWAP5
12      5A        GAS
13      F1        CALL
14      6000      PUSH1 00
16      14        EQ
17      601B      PUSH1 1B
19      57        JUMPI
1A      FD        REVERT
1B      5B        JUMPDEST
1C      00        STOP
```

难度比起 puzzle 7 更上一层楼，我们先看看涉及到了几个新的 opcode:



| stack | name  | gas                           | initial stack                                  | result stack | mem/storage                               |
| ----- | ----- | ----------------------------- | ---------------------------------------------- | ------------ | ----------------------------------------- |
| 94    | SWAP5 | 3                             | a, ..., b                                      | b, ..., a    | /                                         |
| 5A    | GAS   | 2                             | /                                              | gasRemaining | /                                         |
| F1    | CALL  | base_gas + gas_sent_with_call | gas, addr, val, argOst, argLen, retOst, retLen | success      | mem[retOst:retOst+retLen-1] := returndata |

SWAP 系列的 opcode 很好理解，SWAP1 是把栈顶的 a，b 变成 b，a，SWAP5 就是把 a,x,x,x,x,,b 变成 b,x,x,x,x,a。
GAS 是计算 gas 费并写入栈顶。
CALL 即为调用合约，其使用到的栈顶元素 分别为 gas, addr(合约地址), val(msg.data), argOst(在内存中截取的输入数据起点), argLen(输入数据长度), retOst(在内存中截取的返回数据起点), retLen(返回数据长度)。若交易成功 将 1 写入栈顶，若失败，将0写入栈顶。

我们先看第一段：

```assembly
pc      opcode    opcode name
00      36        CALLDATASIZE
01      6000      PUSH1 00
03      80        DUP1
04      37        CALLDATACOPY
05      36        CALLDATASIZE
06      6000      PUSH1 00
08      6000      PUSH1 00
0A      F0        CREATE
```

z这一段跟 puzzle 7 一样，把我们 msg.data 的数据当成合约部署在链上，再把新创建的合约地址写回栈顶。

第二段：

```assembly
pc      opcode    opcode name
0B      6000      PUSH1 00
0D      80        DUP1
0E      80        DUP1
0F      80        DUP1
10      80        DUP1
11      94        SWAP5
12      5A        GAS
13      F1        CALL
```

这一段运行下到最后，我们可以知道这是一个 call 命令，参数依次是 gas , addr , 0, 0, 0, 0, 0。也就是不传入数据，没有返回值，不传入value, 若运行成功则把 1 压栈，反之压栈 0。

第三段

```assembly
pc      opcode    opcode name
14      6000      PUSH1 00
16      14        EQ
17      601B      PUSH1 1B
19      57        JUMPI
1A      FD        REVERT
1B      5B        JUMPDEST
1C      00        STOP
```

这一段就是用来反推我们合约返回结果的部分了，我们需要从上一个部分得到一个 `0x00`，使得EQ返回值为 1，方能成功触发 JUMPI 跳到终点。也就说明我们需要本次合约交易失败。这其实很简单，我们构造一个合约使得 runtime code只有一个 revert 就可以了，类似 puzzle 7，再稍微加点东西：

```assembly
pc      opcode    opcode name
00      60FD      PUSH1 FD //FD 是revert操作符的编号
02      6000      PUSH1 00
04      53        MSTORE8
05      6001      PUSH1 01
07      6000      PUSH1 00
09      F3        RETURN
```

这样，我们把 `0xfd` 写入内存 `0x00`了。这也就是我们的 runtime code。

这样我们得出题解：`msg.data == 0x60fd60005360016000f3`

## puzzle 9:

题目：

```assembly
pc      opcode    opcode name
00      36        CALLDATASIZE
01      6003      PUSH1 03
03      10        LT
04      6009      PUSH1 09
06      57        JUMPI
07      FD        REVERT
08      FD        REVERT
09      5B        JUMPDEST
0A      34        CALLVALUE
0B      36        CALLDATASIZE
0C      02        MUL
0D      6008      PUSH1 08
0F      14        EQ
10      6014      PUSH1 14
12      57        JUMPI
13      FD        REVERT
14      5B        JUMPDEST
15      00        STOP
```

经历了 puzzle 7 && puzzle 8 的折磨，接下来的两道题实际上已经难不住我们了，先看新出现的 opcode 文档，非常简单：



| stack | name | gas  | initial stack | result stack | mem/storage |
| ----- | ---- | ---- | ------------- | ------------ | ----------- |
| 10    | LT   | 3    | a, b          | a < b        | /           |
| 02    | MUL  | 5    | a,b           | a * b        | /           |

第一段：

```assembly
pc      opcode    opcode name
00      36        CALLDATASIZE
01      6003      PUSH1 03
03      10        LT
04      6009      PUSH1 09
06      57        JUMPI
07      FD        REVERT
08      FD        REVERT
09      5B        JUMPDEST
```

我们可以得出一个限制：`0x03 < len(msg.data)`

第二段：

```assembly
pc      opcode    opcode name
0A      34        CALLVALUE
0B      36        CALLDATASIZE
0C      02        MUL
0D      6008      PUSH1 08
0F      14        EQ
10      6014      PUSH1 14
12      57        JUMPI
13      FD        REVERT
14      5B        JUMPDEST
15      00        STOP
```

很容易得出另一个限制 `len(msd.data) * msg.value == 8`, 又根据第一部分的限制，我们可以随意构造一个长度为4的m sg.data，然后令 msg.value == 2。

即可构造出一个符合题意的题解：
`msg.value == 2`
`msg.data == 0x12121212`

## puzzle 10:

题目：

```assembly
pc      opcode      opcode name
00      38          CODESIZE
01      34          CALLVALUE
02      90          SWAP1
03      11          GT
04      6008        PUSH1 08
06      57          JUMPI
07      FD          REVERT
08      5B          JUMPDEST
09      36          CALLDATASIZE
0A      610003      PUSH2 0003
0D      90          SWAP1
0E      06          MOD
0F      15          ISZERO
10      34          CALLVALUE
11      600A        PUSH1 0A
13      01          ADD
14      57          JUMPI
15      FD          REVERT
16      FD          REVERT
17      FD          REVERT
18      FD          REVERT
19      5B          JUMPDEST
1A      00          STOP
```

和第九题很类似，我们看一下新增的几个 opcode，也都很简单:

| stack | name     | gas  | initial stack | result stack   | mem/storage |
| ----- | -------- | ---- | ------------- | -------------- | ----------- |
| 38    | CODESIZE | 2    | /             | len(this.code) | /           |
| 11    | GT       | 3    | a,b           | a > b          | /           |
| 01    | ADD      | 3    | a,b           | a + b          | /           |
| 06    | MOD      | 5    | a,b           | a % b          | /           |
| 15    | ISZERO   | 3    | a             | a == 0         | /           |

值得注意的是，codesize是指我们正在运行的代码的长度，本题中我们可以看到是 21 (0x1b)。

第一段：

```assembly
pc      opcode      opcode name
00      38          CODESIZE
01      34          CALLVALUE
02      90          SWAP1
03      11          GT
04      6008        PUSH1 08
06      57          JUMPI
07      FD          REVERT
08      5B          JUMPDEST
```

我们得到第一条限制 ` 21 > msg.value`

第二段：

```assembly
pc      opcode      opcode name
09      36          CALLDATASIZE
0A      610003      PUSH2 0003
0D      90          SWAP1
0E      06          MOD
0F      15          ISZERO
10      34          CALLVALUE
11      600A        PUSH1 0A
13      01          ADD
14      57          JUMPI
15      FD          REVERT
16      FD          REVERT
17      FD          REVERT
18      FD          REVERT
19      5B          JUMPDEST
1A      00          STOP
```

我们从结果反推`0x14`处， JUMPI 的 dst 操作数 应为 `0x19`指向`0x19`处的JUMPDEST，condition 操作数应为 1。
这其实就是 `0x13`处 ADD 的结果为 `0x19`，`0x0f`处的 ISZERO 结果为 1。

即 `len(msg.data) % 3 == 0`，`msg.data + 10 == 25`（0x0A的十进制是10，0x19的十进制是25）。

我们可以构造一个题解：
`msg.value == 15`
`msg.data == 0x121212`



通过 EVM PUZZLES 学习 EVM opcodes



I'm starting learning solidity today and create a simple contract using hardhat and chainlink VRF. I will continue to upgrade it in the days to come as I learn more deeper.

Completed the following functions today:

1. Deploy contract to Goerli TestNet by hardhat framework.
2. Interact with the contract by hardhat framework.
3. Implement a simple gambling function using VRF in the contract.

 learning notes:

1.Basic Contract

Note:

1. The `address` and `address payable` types both store a 160-bit Ethereum address. The concept of payable and non-payable addresses only exists in the Solidity type system at compile-time. The difference between payable and non-payable addresses is gone in the compiled contract code. You can use `payable(address)` to convert `address` to `payable address`.
2. Use `new CpntractFactory(cantractAddress)` to create a new contract in this contract.
3. The `A.transfer(value)` function is used to transfer ether to address A from this contract. The keyword `payable` allowed transferring ether to someone or receiving ether.

```solidity
pragma solidity ^0.8.9;

import "./VRFv2Consumer.sol";


contract lottery {
    event Received(address caller,uint amount,string message);

    address payable public owner;

    VRFv2Consumer VRF;

    constructor(uint64 subscriptionId) payable {
        owner =payable(msg.sender);
        VRF =new VRFv2Consumer(subscriptionId);
    }

    function Owner()public view returns (address) {
        return owner;
    }

    function Balance()public view returns (uint256) {
        return address(this).balance;
    }

    function VRFAddress()public view returns (address) {
        return address(VRF);
    }

    function buy_lottery() payable external returns (uint256) {
        uint256 value = msg.value;
        uint random = 5 + VRF.requestRandomWords()%10;
        uint256 lottery_value =  (value * random) /10;
        
        payable(msg.sender).transfer(lottery_value);
        return lottery_value;
    }

    function withdraw_lottery() external {
        owner.transfer(address(this).balance);
    }

    receive() external payable{
        emit Received(msg.sender, msg.value,"receive was called");
    }

}
```



2.VRFConsumercontract

Note:

VRF is a random number supplier in chainlink. We can deploy a VRFConsumer contract and register it in your Subscription Manager(require LINK token). The owner of VRFConsumer can get random numbers so we should deploy it by basic contract instead of the EOF account.

```solidity
// SPDX-License-Identifier: MIT
// An example of a consumer contract that relies on a subscription for funding.
pragma solidity ^0.8.9;

import "@chainlink/contracts/src/v0.8/interfaces/VRFCoordinatorV2Interface.sol";
import "@chainlink/contracts/src/v0.8/VRFConsumerBaseV2.sol";
import "@chainlink/contracts/src/v0.8/ConfirmedOwner.sol";

contract VRFv2Consumer is VRFConsumerBaseV2, ConfirmedOwner {
    event RequestSent(uint256 requestId, uint32 numWords);
    event RequestFulfilled(uint256 requestId, uint256[] randomWords);

    struct RequestStatus {
        bool fulfilled; // whether the request has been successfully fulfilled
        bool exists; // whether a requestId exists
        uint256[] randomWords;
    }
    mapping(uint256 => RequestStatus)
        public s_requests; /* requestId --> requestStatus */
    VRFCoordinatorV2Interface COORDINATOR;

    // Your subscription ID.
    uint64 s_subscriptionId;

    // past requests Id.
    uint256[] public requestIds;
    uint256 public lastRequestId;

    bytes32 keyHash =
        0x79d3d8832d904592c0bf9818b621522c988bb8b0c05cdc3b15aea1b6e8db0c15;

    uint32 callbackGasLimit = 100000;

    // The default is 3, but you can set this higher.
    uint16 requestConfirmations = 3;

    // For this example, retrieve 2 random values in one request.
    // Cannot exceed VRFCoordinatorV2.MAX_NUM_WORDS.
    uint32 numWords = 2;

    /**
     * HARDCODED FOR GOERLI
     * COORDINATOR: 0x2Ca8E0C643bDe4C2E08ab1fA0da3401AdAD7734D
     */
    constructor(
        uint64 subscriptionId
    )
        VRFConsumerBaseV2(0x2Ca8E0C643bDe4C2E08ab1fA0da3401AdAD7734D)
        ConfirmedOwner(msg.sender)
    {
        COORDINATOR = VRFCoordinatorV2Interface(
            0x2Ca8E0C643bDe4C2E08ab1fA0da3401AdAD7734D
        );
        s_subscriptionId = subscriptionId;
    }

    // Assumes the subscription is funded sufficiently.
    function requestRandomWords()
        external
        onlyOwner
        returns (uint256 requestId)
    {
        // Will revert if subscription is not set and funded.
        requestId = COORDINATOR.requestRandomWords(
            keyHash,
            s_subscriptionId,
            requestConfirmations,
            callbackGasLimit,
            numWords
        );
        s_requests[requestId] = RequestStatus({
            randomWords: new uint256[](0),
            exists: true,
            fulfilled: false
        });
        requestIds.push(requestId);
        lastRequestId = requestId;
        emit RequestSent(requestId, numWords);
        return requestId;
    }

    function fulfillRandomWords(
        uint256 _requestId,
        uint256[] memory _randomWords
    ) internal override {
        require(s_requests[_requestId].exists, "request not found");
        s_requests[_requestId].fulfilled = true;
        s_requests[_requestId].randomWords = _randomWords;
        emit RequestFulfilled(_requestId, _randomWords);
    }

    function getRequestStatus(
        uint256 _requestId
    ) external view returns (bool fulfilled, uint256[] memory randomWords) {
        require(s_requests[_requestId].exists, "request not found");
        RequestStatus memory request = s_requests[_requestId];
        return (request.fulfilled, request.randomWords);
    }
}

```

3.Hardhat Framework

Add network settings in hardhat.config.js:

```javascript
require("@nomicfoundation/hardhat-toolbox");

const ALCHEMY_API_KEY = "...";
const GOERLI_PRIVATE_KEY =
  "...";

module.exports = {
  solidity: "0.8.9",
  networks: {
    goerli: {
      url: `https://eth-goerli.alchemyapi.io/v2/${ALCHEMY_API_KEY}`,
      accounts: [GOERLI_PRIVATE_KEY],
    },
  },
};

```

Deploy script:

```solidity
async function main() {
  const Lottery = await ethers.getContractFactory("lottery");
  const lottery = await Lottery.deploy(4038, {
    value: 100000,
  });
  console.log("Lottery deployed to:", lottery.address);
  console.log("VRF deployed to:", await lottery.VRFAddress());
}

```

Interact with deployed contract:

```javascript
async function main() {
  const LotteryAddress = "0x63219Df994Bb37307dEdbE6Cdf9a8A71b45Dcf4b";
  const lottery = await ethers.getContractAt("lottery", LotteryAddress);
  const reback_value = await lottery.buy_lottery({ value: 10 });
  console.log(reback_value);
}

```

We can also set sender.value and gas limit in deploy or other functions.

A learning note of deploying/testing contract by using hardhat and using vrf service.

solidity journey day1

最近在折腾node后端，遇到了一个redis连接失败的问题，记录一下：

场景复现：
本地连接redis代码：

```javascript
const client = redis.createClient("6379", "127.0.0.1");

client.on("connect", function () {
  console.log("Redis Connected!");
});

client.connect();
```

服务器连接redis代码：
```javascript
const client = redis.createClient("6379", "172.17.0.1");//redis docker 的 host 和 port

client.on("connect", function () {
  console.log("Redis Connected!");
});

client.connect();
```

本地连接成功，服务器连接redis docker失败，
报错：

```
Error: connect ECONNREFUSED 127.0.0.1:6379
```

之后无论怎么修改配置端口号和host都会报错说连不上`127.0.0.1:6379`。
后排查原因发现`redis.createClient("6379", "172.17.0.1");`代码错误，导致redis绕过配置连接默认host和端口号，本地的redis恰好在默认`127.0.0.1:6379`下运行。
修改方法：
将 `redis.createClient("6379", "172.17.0.1");` 
修改为：

```javascript
const client = redis.createClient({
  url: "redis://172.17.0.1:60379",
});
```

即可。



redis配置失效导致 Error:connect ECONNREFUSED 127.0.0.1:6379

Node.js连接Redis遇到的一个问题


## 原理讲解：

由于区块链在存储/检索大量数据上成本过高，在一些情况下会采用用链下存储，链上验证的方法。例如如果要管理一个数万地址的白名单，使用merkle树不失为一种好方案。

![img](https://upload.wikimedia.org/wikipedia/commons/thumb/9/95/Hash_Tree.svg/310px-Hash_Tree.svg.png)
merkle树本质是一个满二叉树，它的叶子结点保存着原数据的hash值，非叶子结点存储的数据是左儿子节点和右儿子节点数据的拼接后求hash(排序后)。
如上图所示，$Hash0 = hash(Hash0\_0 + Hash0\_1)，Top Hash = hash( Hash0 + Hash1 )$。

详细介绍可见：https://mirror.xyz/qiwihui.eth/HRifb9gziR1UvVmRcMjDfDvQ9mq7o7FA6BNuCJMFT00

## 用法：

如果我们需要存储1W个地址作为白名单用户，那么全部存储和操作都在区块链上的成本明显有点太高了，我们可以利用merkle树的特性解决。步骤如下：
1.在链下使用1W个地址生成merkle树并存储。
2.并将根结点$TopHash$存入合约。
3.如果需要查询 L4 地址是否在白名单内，需要提供A地址本身和验证路径上的节点信息。例如需要验证L4在该树中，则需要提供 $Hash 1\_0$ 与 $Hash 0$.
4.在合约内验证 $hash( Hash 0 + hash(Hash 1\_ 0 + hash( L4 ))) == TopHash$ ，即可判断 L4 是否在merkle树内了。

## 实现：

### 链下部分：

链下部分负责生成 merkle 树，存储 merkle 树，获取`proof`验证路径数据。

我们可以直接使用现成的 `keccak256` 与 `merkletreejs` 库来管理merkle树，无论是存储，构建，生成验证路径，获取树根都有直接可用的方法供我们使用：
需要注意的只是要将数据结构匹配成aptos可以接受的形式

```typescript
import keccak256 from "keccak256";
import MerkleTree from "merkletreejs";
export const NODE_URL = "https://fullnode.devnet.aptoslabs.com/v1";
export const FAUCET_URL = "https://faucet.devnet.aptoslabs.com";
export const privateKey = '0x.............';


let whitelistAddresses = [
    "0x36346bbcda6f9f74cf36cff31e00ac83c9d8a512a6564c9f93b00d249e3b2b45",
    "0x09d4ee382de0fa20f889ac6158273f29c81a1fec7385e8e26801db2e9e0c2f32",
    "0x09d4ee382de0fa20f889ac6158273f29c81a1fec7385e8e26801db2e9e0c2f32",
  ];

  let leafNodes = whitelistAddresses.map((address) => keccak256(address));
  let tree = new MerkleTree(leafNodes, keccak256, { sortPairs: true });

  export let root = tree.getRoot();

  function convert_to_bytes(v:string[]):Uint8Array{
    let len = v.length;
    let result = new Uint8Array(32*len);
    for(let i = 0;i<len;i++){
        result.set(Buffer.from(v[i].slice(2),'hex'),i*32);
    }
    return result;
  }

  export function get_proof(account:string):Uint8Array{
    let proof = tree.getHexProof((keccak256(account)));
    return convert_to_bytes(proof)
  }
```

### 链上部分：

负责存储树根和验证计算，代码是参考 `openzeppelin` 写的 ：

Aptos 上使用 vector\<u8\>存储树根以及接收代验证数据和验证路径的原数据，

下图函数是使用 待验证的叶子结点`leaf`和验证路径数据`proof`计算`tophash`：

```rust
    fun processProof(proof:vector<u8>,leaf:vector<u8>):vector<u8>{
        assert!(vector::length(&proof)%32==0,error::invalid_argument(LENGTH_INVALID));
        let deep = vector::length(&proof)/32;
        assert!(vector::length(&leaf)==32,error::invalid_argument(LENGTH_INVALID));
        let node = leaf;
        let index = 0;
        while(index < deep){
            node = hashPair(node,extract_vector(proof,index*32,index*32+32));
            index = index +1;
        };
        node
    }
```

由于aptos不能像 evm 一样可以直接传 `byte32` 和 `byte32[]`, 我们需要对验证路径信息即 `proof` 做简单的序列化。`leaf`和拆解出来的每一个vector\<u8\>挨个拼接并取hash ，以下为拼接函数:
```rust
fun hashPair(a:vector<u8>,b:vector<u8>):vector<u8>{
        if(compare_vector(&a,&b)==SMALLER){
            vector::append(&mut a,b);
            aptos_hash::keccak256(a)
        }else{
            vector::append(&mut b,a);
            aptos_hash::keccak256(b)
        }
    }
```

这里读者可以看到有一个拼接顺序的判断，因为我们并不知道当前位置的节点是左节点还是右节点，更不知道它的父节点、爷爷节点、太爷爷节点是左节点还是右节点，所以我们无法判断拼接的顺序。
这样就需要我们在链下和链上规定同一种排序方法，使得任意给两个兄弟节点，我们都可以知道他们的左右。
在这里我们使用比大小的方式，实际上如何排序都可以，只要链上链下的规则统一就不会出问题。

最后 判断 `processProof`计算得出的数据与合约中存储的树根是否相等，确定该 `leaf` 是否存在于该树中。

```rust
 public entry fun verify(proof:vector<u8>,leaf:vector<u8>)acquires Root {
        assert!(exists<Root>(Admin),error::not_found(ROOT_UNEXISTED));
        let root = borrow_global<Root>(Admin);
        assert!(com
```

再贴一下设置树根的方法：
```rust
struct Root has key {
   hash : vector<u8>
}

public entry fun set_root(signer:&signer,new_root:vector<u8>)acquires Root{
        assert!(address_of(signer)==Admin,error::permission_denied(NO_AUTHORIZATION));
        if(!exists<Root>(Admin)){
            move_to(
                signer,
                Root{
                    hash:new_root
                }
            );
        }else{
            let root = borrow_global_mut<Root>(Admin);
            root.hash = new_root;
        }
    }
```

### 交互部分：

只需要完成执行 `set_root` 和 `verify` 两个交易的方法，使用aptos官方sdk，做好序列化就好：

设置树根：

```typescript
async function set_root(hash:string) {
    console.log(`set merkle root: ${hash}`);
    const entryFunctionPayload = new TransactionPayloadEntryFunction(
        EntryFunction.natural(          
          "0xe463a68bb1dd0d9b9864ed030a8cd357f2a38b6b3fea92c0af07694db203a6e0::merkle",         
          "set_root",
          [],
          [BCS.bcsSerializeBytes(Buffer.from(hash.slice(2),'hex')),],
        ),
      );
      const [{ sequence_number: sequenceNumber }, chainId] = await Promise.all([
        client.getAccount(admin.address()),
        client.getChainId(),
      ]);
      const rawTxn = new RawTransaction(
        AccountAddress.fromHex(admin.address()),
        BigInt(sequenceNumber),
        entryFunctionPayload,
        BigInt(2000),
        BigInt(100),
        BigInt(Math.floor(Date.now() / 1000) + 10),
        new ChainId(chainId),
      );
      const bcsTxn = AptosClient.generateBCSTransaction(admin, rawTxn);
      const transactionRes = await client.submitSignedBCSTransaction(bcsTxn);
      await client.waitForTransaction(transactionRes.hash);
    console.log(transactionRes.hash);
}
```

验证：
```typescript
async function verify(proof:Uint8Array,hash:Buffer) {
    console.log(`set merkle root: ${hash}`);
    const entryFunctionPayload = new TransactionPayloadEntryFunction(
        EntryFunction.natural(          
          "0xe463a68bb1dd0d9b9864ed030a8cd357f2a38b6b3fea92c0af07694db203a6e0::merkle",          
          "verify",          
          [],
          [BCS.bcsSerializeBytes(proof),BCS.bcsSerializeBytes(hash)],
        ),
      );
      console.log(BCS.bcsSerializeBytes(proof));
      console.log(BCS.bcsSerializeBytes(hash));
    
      const [{ sequence_number: sequenceNumber }, chainId] = await Promise.all([
        client.getAccount(admin.address()),
        client.getChainId(),
      ]);
      const rawTxn = new RawTransaction(
        AccountAddress.fromHex(admin.address()),
        BigInt(sequenceNumber),
        entryFunctionPayload,
        BigInt(2000),
        BigInt(100),
        BigInt(Math.floor(Date.now() / 1000) + 10),
        new ChainId(chainId),
      );
      const bcsTxn = AptosClient.generateBCSTransaction(admin, rawTxn);  
      const transactionRes = await client.submitSignedBCSTransaction(bcsTxn);
      await client.waitForTransaction(transactionRes.hash);
    console.log(transactionRes.hash);
}

let account = '0x09d4ee382de0fa20f889ac6158273f29c81a1fec7385e8e26801db2e9e0c2f32'
//console.log('0x254a8d20f95c8a0ac2cb39041ba3375f6742dea2accf4361028e43ea669b8a91');
verify(get_proof(account),keccak256(account));
```

源码仓库地址：https://github.com/passer-byzhang/aptos-merkle
作者地址：alvan.coffee














merkle树验证在aptos上的实现，练练手

Aptos中实现merkle树验证


![The Move Prover: A Practical Guide](https://osec.io/blog/assets/posts/move-prover/move-prover-title.png)

*形式化验证* - 一种验证程序正确性的强力工具。但它是如何工作的呢？这篇博客会介绍一些Move Prover的使用技巧，充分利用其潜力，并探讨如何在一个实际例子中使用形式化验证去保证合约安全。

从上层看，形式化验证可以为程序提供规范，程序的符号输入会根据规范进行校验，并要求证明所有可能的输入都符合该规范。

## Move Prover

Move Prover是一个对Move语言智能合约形式化验证的自动化工具。

Move在设计上就是便于自动化验证的，更有趣的是Move Prover也是操作MoveVM的字节码本身，这就避免了潜在的编译器错误影响证明程序的正确性。

Move Prover由多个组件构成，如下图所示：

![Move Prover arch](https://i.imgur.com/ti4vkTu.png)

首先，Move Prover 接收一个Move源文件作为输入，该文件中需要设置程序输入规范。之后 Move Parser 会在源码中把规范提取出来。Move 编译器将源文件编译为字节码，和规范系统(specification)共同转化为验证者对象模型(Prover Object Model)。

这个模型会被翻译成一种名为[Boogie](https://www.microsoft.com/en-us/research/project/boogie-an-intermediate-verification-language/)的中间语言。这段 Boogie 代码会被传入 Boogie 验证系统，该系统对输入进行“验证条件生成”([verification condition generation](https://en.wikipedia.org/wiki/Verification_condition_generator))。该验证条件(VC)会被传入一个名为 Z3 的自动理论验证器([automated theorem prove](https://en.wikipedia.org/wiki/Automated_theorem_proving))中。

VC 被传进 Z3 程序后，该验证器会检查 SMT公式 是否是不可满足的。如果是这样，这意味着规范是成立的。否则，将生成一个满足条件的模型，并将其转换回Boogie格式，以便发布诊断报告。然后将诊断报告还原为与标准编译器错误类似的源码级错误。

*译者注：SMT是形式语言与自动机的相关知识，有兴趣的读者可以搜索 SAT 与 SMT 进一步了解，大致意思就是SMT/SAT是一个公式，可满足性是指是否存在一组输入使其为真。*

## Move Specification Language 

MSL是Move语言的子集，它引入了对静态描述有关程序正确性的行为的支持，而不影响生产。

为了更好地理解使用MSL的方法，我们将使用[Pontem’s U256 library](https://github.com/pontem-network/u256)作为教学案例，这是一个实现U256的Move开源库。

U256是由一个包含4个u64的结构体实现的。

```rust
struct U256 has copy, drop, store {
    v0: u64,
    v1: u64,
    v2: u64,
    v3: u64,
}
```

现在我们聚焦到函数`add(a: U256, b: U256): U256`上。为了保证这样一个函数的正确性，验证一些群论的公理可能会有用处，比如交换律和结合律。

规范(specifications)被声明在“规范代码块”(specification block，下均称spec代码块)中，它可能在Move Module的函数中，也可能作为一个单独的规范module文件。

例如，如果你的文件是`sources/u256.move`,那你可以把规范放在`sources/u256.spec.move`里。

```
spec add { ... }
```

放置在spec代码块中的规范被视为*表达式*。

## 表达式

我们先看一些通用表达式吧。

`aborts_if`定义了函数应该何时终止(abort)。这在智能合约开发中非常有用，在合约里一个abort就可以导致整个交易回滚。

举个例子：当且仅当U256加法溢出的时候`add`函数abort。让我们把这句话变成表达式：

```rust
const P64: u128 = 0x10000000000000000;

spec fun value_of_U256(a: U256): num {
    a.v0 + 
    a.v1 * P64 + 
    a.v2 * P64 * P64 + 
    a.v3 * P64 * P64 * P64
}

spec add {
    aborts_if value_of_U256(a) + value_of_U256(b) >= P64 * P64 * P64 * P64;
}
```

我们在上边的代码片段中可以看到在spec代码块中可以调用函数。但是被调用者必须是一个MSL函数或者一个纯Move函数。纯Move函数就是不修改全局变量或者其使用的语句和特性均被MSL支持。

 `aborts_if` 的一个常见写法是 `aborts_if false`，它可以让一个函数验证永不abort。

```move
spec critical_function {
    aborts_if false;
}
```

另一个我们经常使用的表达式是 `ensures`，顾名思义，就是保证在函数运行的结尾确认一个状态。

在`add`函数的例子里我们希望确认返回值是两个参数之和。⚠️注意，因为MSL使用无界数，我们可以清楚这个表达式是不会溢出的。

```
spec add {
    aborts_if value_of_U256(a) + value_of_U256(b) >= P64 * P64 * P64 * P64;
    ensures value_of_U256(result) == value_of_U256(a) + value_of_U256(b);
}
```

因为Move规范函数是用MSL写的，所以在这里不存在溢出风险。

让我们试着用上面的规范来验证这个库：

```
$ move prove
```

报出以下错误信息：

```
[...]

error: abort not covered by any of the `aborts_if` clauses
╭     spec add { 
|         aborts_if value_of_U256(a) + value_of_U256(b) >= P64 * P64 * P64 * P64;
|         ensures value_of_U256(result) == value_of_U256(a) + value_of_U256(b);
|     }
╰─────^

[...]

 at ./sources/u256.move:316: add
 enter loop, variable(s) carry, i, ret havocked and reassigned
     carry = 54
     i = 3792
     ret = u256.U256{v0 = 26418, v1 = 27938, v2 = 6900, v3 = 1999}
 at ./sources/u256.move:346: add
     ABORTED
     
FAILURE proving 1 modules from package `u256` in 9.143s
{
    "Error": "Move Prover failed: exiting with verification errors"
}

```

验证器说这个abort没有被abort_if覆盖到所以验证失败了，但是我们明明已经做到了全覆盖不是吗？

让我们继续看错误信息，会遇到一个意义不明的信息：`ret havocked and reassigned`.

这是什么意思？

深入理解Move Prover源码后，我们找到了一个[可能性怀疑](https://github.com/move-language/move/blob/e0dafc5cf3efe4c4e61411f10cdf0f379a36673c/language/move-prover/bytecode/src/loop_analysis.rs#L94)。验证器试图用归纳法证明所有的循环！

严格来说，它会把循环分解为两个关键步骤，遵循经典的归纳法证明

1.基本情况：对循环开始时的循环不变量进行断言
2.归纳：假设不变量，执行循环体，并断言不变量成立

*译者注：此处和下面的 不变量，均为 invariant 和 invariants 的翻译，与 const常量 不同，不变量 并不是一个值，而代表一个状态，例如在某个循环中，a 永远小于 b，那么 a < b 是一个 循环不变量，其他 不变量 也类似。*

循环证明程序还会把循环内的所有变量破坏和随机赋值。回到日志消息，这意味着变量` carry`， ` ret`和 `i `已经被破坏，或被分配了随机值。这也解释了为什么`add`的输入输出不灵了。

更具体地说，循环分析转换为以下步骤：

1. 断言循环不变量
2. 破坏所有修改过的变量
3. 假设循环不变量
4. 假设循环保护(while条件里的代码)
5. 执行循环体
6. 断言循环不变量

这里有两种处理循环的解决方案

第一个是指定循环不变量。

为了指定循环不变量我们需要用到一些特殊的语法，在[之前的一篇文章里](https://osec.io/blog/tutorials/2022-09-06-move-introduction/)简单介绍过。

```rust
  while ({
      spec {
          invariant len(amounts_times_coins) == i;
          invariant i <= n_coins;
          invariant forall j in 0..i: amounts_times_coins[j] == input[j] * n_coins;
      };
      (i < n_coins)
  }) {
      vector::push_back(
          &mut amounts_times_coins,
          (*vector::borrow(&input, (i as u64)) as u128) * (n_coins as u128)
      );
      i = i + 1;
  };
```

在这个例子里，括号中指明了`while` 循环中的循环不变量，请注意，由于循环不变量实在循环保护之后执行的，所以我们需要一个额外的步骤`i <= n_coins`。

```move
  while ({
      spec {
          invariant len(amounts_times_coins) == i;
          invariant i <= n_coins;
          invariant forall j in 0..i: amounts_times_coins[j] == input[j] * n_coins;
      };
      (i < n_coins)
  }) {
```

循环不变量通常情况下很难写，尤其是重要循环体

第二个处理循环的解决方案是展开循环。这种技术在某些特定情况下是有效的，就如我们所看到那样，`add`函数内的循环恰好循环4次。

```rust
/// Total words in `U256` (64 * 4 = 256).
const WORDS: u64 = 4;

[...]

let i = 0;
while (i < WORDS) {
    let a1 = get(&a, i);
    let b1 = get(&b, i);

[...]
```

展开这个函数再跑一次，Move Prover会打印出成功信息：

```
SUCCESS proving 1 modules from package `u256` in 9.685s
{
    "Result": "Success"
}
```

为了确保**交换律**(`a+(b+c) = (a+b)+c`) 成立，改变加数的分组不改变加法结果。为了验证该项，我们首先写一个模拟该属性的函数：

```
fun add_assoc_property(a: U256, b: U256, c: U256): bool {
    let result_1 = add(b, c); 
    let result_11 = add(a, result_1); 
    let result_2 = add(a, b); 
    let result_22 = add(c, result_2); 

    let cmp = compare(&result_11, &result_22); 
    if ( cmp == EQUAL ) true else false
}
```

然后再创建一个spec代码块来规范溢出话函数结果：

```
spec add_assoc_property {
    aborts_if (value_of_U256(a) + value_of_U256(b)) + value_of_U256(c) >= P64 * P64 * P64 * P64;
    ensures result == true;
}
```

运行Move Prover的新规范吗我们可以确认这里没有验证错误：

```
SUCCESS proving 1 modules from package `u256` in 9.685s
{
    "Result": "Success"
}
```

如果余姚进一步了解Move Prover语法，建议阅读Move仓库中的[spec-lang.md](https://github.com/move-language/move/blob/main/language/move-prover/doc/user/spec-lang.md) 完整文档。

## 用例

 形式化验证可以证明智能合约满足所有可能情况下的给定需求，甚至不需要运行该合约。困难的是制定规范。在这里，我们希望探索一些验证思想的实际例子。

### 错误条件


以`std::fixed_point32`为例，显式定义函数何时可能中止通常是有用的。例如具有定点数的算术运算只有在溢出时才会出错。

```move
      spec schema MultiplyAbortsIf {
          val: num;
          multiplier: FixedPoint32;
          aborts_if spec_multiply_u64(val, multiplier) > MAX_U64 with EMULTIPLICATION;
      }
      spec fun spec_multiply_u64(val: num, multiplier: FixedPoint32): num {
          (val * multiplier.value) >> 32
      }
```

### 访问控制策略

与错误条件类似，在规范中强制显式访问控制策略通常很有用。

例如，在`std::offer` 中，我们可以看到，当且仅当不存在offer时或者接收者不被允许时，函数应该abort。

```move
    spec redeem {
      /// Aborts if there is no offer under `offer_address` or if the account
      /// cannot redeem the offer.
      /// Ensures that the offered struct under `offer_address` is removed.
      aborts_if !exists<Offer<Offered>>(offer_address);
      aborts_if !is_allowed_recipient<Offered>(offer_address, signer::address_of(account));
      ensures !exists<Offer<Offered>>(offer_address);
      ensures result == old(global<Offer<Offered>>(offer_address).offered);
    }
```

这些访问控制规范使得以后不会意外删除关键访问控制策略。

### 复杂的数学公式

无论是十进制实现还是更复杂的数据结构，验证"期望的输出"恒等于"输出"通常是有用的。

证明基本数据结构完全按照预期工作将使您对代码库的其余部分更有信心。

例如，在我们与[Laminar Markets](https://laminar.markets/)的合作中，我们提供了针对更简单的优先级队列数据结构验证其内部扩展树实现的建议。

### 数据不变量

形式化验证提供了验证某些“变量”或“资源”没有超出预期边界的最佳环境。让我们从下面考虑结构。我们可以使用`struct invariant`确保` index `永远不大于4。

```rust
struct Type {
    index: u64
}

spec Type {
    invariant index < 4;
}
```

 我们最近对[LayerZero](https://layerzero.network/)和[Aries Markets](http://ariesmarkets.xyz/)的审计中验证更复杂的属性，细节留给读者练习。

### 经济不变量

设计恰当的经济不变量需要更高的创造力，但可以非常有效地保护您的协议。

举个例子，您不能通过增加和减少股权从池子里提走代币，在实践中，您可以将其作为工具帮助函数实现。

```move
  // #[test] // TODO: cannot specify the test-only functions
  fun no_free_money_theorem(coin1_in: u64, coin2_in: u64): (u64, u64) acquires Pool {
      let share = add_liquidity(coin1_in, coin2_in);
      remove_liquidity(share)
  }
  spec no_free_money_theorem {
      pragma verify=false;
      ensures result_1 <= coin1_in;
      ensures result_2 <= coin2_in;
  }
```

这里有一些中心思想：

1. 通过 AMM 进行 swap 操作永远不会在池的一边没减少的情况下令另一边增加。换句话说，no free money。
2. 在一系列的存贷取款指令之后，贷款协议应该始终是完全抵押的。
3. 在下单后取消订单后，订单簿不应该赔钱。

## 结语

 在这篇文章中，我们探讨了如何正确地利用Move验证器来验证代码库中的关键不变量。

 在我们接下来的文章中，我们将探索如何通过学习问正确的问题，将Move验证器变成压制安全漏洞的利器，所以请继续关注!

我们热衷于形式化验证，并将Move安全的可能性推向极致。如果您有任何想法或者想深入了解审计，请随时联系我[@notdeghost](https://twitter.com/notdeghost/)。

## 原文链接

https://osec.io/blog/tutorials/2022-09-16-move-prover/

翻译自一个关于Move Prover的入门教程

Move Prover 入门


## 背景

最近项目中需要做一个抽奖的功能，在这个功能里，随机数种子必须是公开的，方便用户查询的，计算过程方便公示的。本来的想法是使用声明抽奖后的第x个区块的区块哈希，这样用户也很容易验证，代码写起来也很简单。但是不幸的是aptos链并没有通过高度获取哈希这种东西，这很令我头秃。组长提议从链下引入，但是公平公正和中心化的稳定性又成了问题，最后我选用了这种方法：

## 原理

该方法分为三步：

1.创建随机数

在创建某个抽奖项目时，项目方可以自主选用一些密钥  $x_1,x_2,x_3...x_n$

同时定义并公开一个陷门函数$f$

在执行交易时，把$f(x_1,x_2,x_3...x_n)$ 传入合约存储，并触发事件以供用户查验

2.构造随机数(可省略)

每一个用户参与抽奖时，可以添加一个随机数，最后生成一个随机数组$a_0,a_1...a_m$

3.揭示中奖密码

管理员传入密钥 $y_1,y_2,y_3...y_n$，合约验证$f(x_1,x_2,x_3...x_n)==f(y_1,y_2,y_3...y_n)$ 

若不成功，则说明管理员徇私，不予通过。

若成功，则中奖号码为$(\sum_{i=0}^ma_i + \sum_{i=1}^n y_i)\%m$

## 后记

本来想做一个mpc的过程，但是aptos的生态实在太缺了，不太好做，就决定用这个单陷门函数控制的方法了。


一种带揭示功能的生成luckycode的方法

在抽奖系统中生成lucky code


## 前言

Aptos 的 AIT3 注册快结束了，Alvan搞完节点也终于空出时间来整理一个关于Aptos和Move的分享，这篇文章会讲一下Aptos和Move的优势和特性，以及觉得它们中很有意思的地方。

## Aptos的前世今生

2019年有一个Libra项目后来改名diem，运营不善后diem项目组秽土转生出了分裂成了两个项目，aptos和sui，他们从diem继承的共同遗产就是move语言。

这两个是一个专注于高性能高安全,不兼容evm的layer1，pos机制。一个承袭了老项目多一点，一个自由发挥多一点。
aptos目前还处于测试阶段，根据项目方透露今年万圣节之前可以主网上线。

目前已经有四十多个项目已经宣布加入aptos生态，钱包和nft市场以及开发者工具之类项目量大管饱，但是目前真正完成并上线测试网并且开源的很少。一方面是由于现在版本迭代太快，不太稳定，另一方面就是很多solidity的团队需要时间去学习使用Move投入生产。

## Aptos有哪些特性呢

Aptos其实写的很明白，它和其他传统区块链的最大区别就是高效(存疑)和安全。

第一点是使用了流水线模式，增强了并行程度，根据开发团队声称tps可以到十万，但是测试网明显没有压榨出最大的效率，究竟能达到什么程度持保留意见，毕竟以太坊升级之后的理想状态也是超过十万的。

第二点，我觉得这是它与以太坊差异最大的的设计，就像下图所示，

![aptos分享稿.004](aptosShares.004.png)

以太坊的storage，是合约账户拥有的一块存储区，里边每个合约存储着不同人的账户信息，
aptos里的信息被称为resource资源，存在每一个外部账户的存储区里。
这有什么区别呢，要实现一个A token的记账，以太坊的做法是在A token合约里存一个map，key是账户地址，value是账户余额，要空投币就是在合约内部去找key改value。而aptos的做法是在A token合约里声明一个叫coin的resoure，然后把resource发送给用户，这样A token就到了用户的存储区。如果对应现实世界的话，一种是记账模式，一种是现金模式。这个之后我们再讲。



## Move语言又是何方神圣

讲完aptos链本身，现在我们开始看看时薪1200刀的Move语言，它并不是一个新玩意了,Libra(Diem)时期就已经投产的语言，也被Sui和aptos继承了，现在最全的Move文档依然在Diem的网站下边挂着。

它脱胎于rust,很多设计和概念都有相似。Move声称对solidity的优势是安全高效，实际上rust对Cpp和GC语言的优势也分别是安全和高效,也就会围绕着这两点介绍move的特性。可能会涉及到一些概念没接触过也不要紧，我会简单说明一下，并不会耽误理解。

首先我们从安全说起，在我们编程的时候肯定会遇到一个重要的问题，如果它不是你编程时遇到的问题，那一定也是面试的时候一定会遇到问题，就是申请和回收内存。

C++在处理变量或者指针时，需要全程手动，所以C++程序员的心智负担很重，他也不知道哪里出现一个悬垂指针哪里有一个内存泄漏，软件的可靠性就会极度依赖开发者的水平。

Java和Go使用了GC机制，在运行的时候有一个GC程序监控记录引用情况，在变量失效时清除，这让程序员的日子好过不少，但是意味着一定会造成额外的性能开销。

那么有没有既不增加开销还能自动管理内存的方案呢？答案是肯定的，Rust或者说Move的 生命周期+所有权 是一个用语法规范内存操作的方案，可以把内存安全检测放在编译期解决。

简单来说像这段rust代码一样

```rust
fn timelife_and_ownership()->String{
    let x :String = "hello aptos".to_string();//x的生命周期开始，开辟内存
    {
        let y :String = "hello move".to_string();//y的生命周期开始，开辟内存
    }//y的生命周期结束，回收内存
    //println!("{}",y); error:cannot find value `y` in this scope
    x
}//x的生命周期结束，回收内存
```

每一个变量有一个作用域，也就是一个大括号代码块。
当程序运行出代码块时，就把这块里声明的内存清理掉了。这样在编译期就能解决指针乱飞的问题，也不会造成额外开销，同时是把它变得高效的根本原因。

所有权又是什么呢？
在rust里，每一个变量都有一个所有者，其他变量想要使用它需要复制或者借用/引用。而move把这个思路用在了处理资源上，资源其实就是我们存储区上的数据，比如我们刚才说的A token。

每一个资源有四个可选ability：Copy，Drop，Store，Key。Copy表示可以被复制，Drop的意思是可以销毁该资源，store表示可以存进全局也就是区块链，key表示该资源可以被检索。

他们之间也有一定耦合，比如一个拥有key的结构体，它里边的资源肯定是store的，这是不言自明的。使用的时候就是在声明变量的后边加上"has copy"，‘has key’。

```rust
struct MessageHolder has key {
        message: string::String,
        message_change_events: event::EventHandle<MessageChangeEvent>,
    }

    struct MessageChangeEvent has drop, store {
        from_message: string::String,
        to_message: string::String,
    }
```

我们完全可以按照写程序的思维去理解它的顶层设计。上文提到了所有权和借用，当一个借用是不可变借用的时候它当然是安全的，如果是可变借用，那必须只有一个，不然这段代码就很难安全(最重要的是不知道什么时候释放)，尤其是在异步程序里。

在move里可变引用和不可变引用分别是borrow_global 和 borrow_global_mut

aptos官方的coin设计里是这样的

![aptos分享稿.011](aptos分享稿.011.png)



某人持有的资金是存在自己存储区下的一个resource，我们暂且把它称为Coin，实现持有就是把amount放进一个没有copy和drop的资源Coin里，转账的时候是切割/合并Coin资源来实现。这样资源相当于被实体化了，在同一时间里想要有可变的Coin资源只能被一个所有者修改，避免了很多安全问题。跟以太坊的账户转账相比一个是账本模式一种现金模式。感觉有点UTXO的味道。

标准库代码：

这是标准coin的transfer函数，可以看到分为两步，发送方withdraw，接收方deposit。

```rust
/// Transfers `amount` of coins `CoinType` from `from` to `to`.
    public entry fun transfer<CoinType>(
        from: &signer,
        to: address,
        amount: u64,
    ) acquires CoinStore {
        let coin = withdraw<CoinType>(from, amount);
        deposit(to, coin);
    }
```

withdraw与extract函数，请看注释

```rust
/// Withdraw specifed `amount` of coin `CoinType` from the signing account.
    public fun withdraw<CoinType>(
        account: &signer,
        amount: u64,
    ): Coin<CoinType> acquires CoinStore {
        let account_addr = signer::address_of(account);
        assert!(
            is_account_registered<CoinType>(account_addr),
            error::not_found(ECOIN_STORE_NOT_PUBLISHED),
        );
        //先用变量coin_store拿到account_addr中coin资源的所有权
        let coin_store = borrow_global_mut<CoinStore<CoinType>>(account_addr);

        event::emit_event<WithdrawEvent>(
            &mut coin_store.withdraw_events,
            WithdrawEvent { amount },
        );
				//分割coin，并返回一个coin
        extract(&mut coin_store.coin, amount)
    }
    public fun extract<CoinType>(coin: &mut Coin<CoinType>, amount: u64): Coin<CoinType> {
        assert!(coin.value >= amount, error::invalid_argument(EINSUFFICIENT_BALANCE));
        //修改传入coin的值
        coin.value = coin.value - amount;
        //创建一个新coin并返回
        Coin { value: amount }
    }
```

接收方的deposit就是上述操作的逆操作而已。我们可以在上述代码中看到所有权的流动。

我们再往下想从这个方面来讲，aptos里就没有了token和CryptoCurrency的高低贵贱之分，在以往以太坊里边eth是一等公民，erc20是二等公民，在aptos里所有的coin理论上都是同等地位，因为他们都是resource，也不用在写合约的时候把e th和erc20每一个都写一个分支逻辑了。

从存储区的角度来说，一切信息存在用户处，合约反而成了一个纯粹的lib，这也使得合约的逻辑和存储天然分离，更有助于智能合约的去中心化。

## 结语

Aptos的业务模型和Move合约的设计远远比高性能更让人拍案叫绝，在学习的时候忍不住把它们和rust联系起来(因为真的很像)，一点粗浅理解，还望诸君包涵！







aptos和move的一些安全特性，跟rust很像

金融特化，现金交易，浅析新公链Aptos与Move语言




这两天搭aptos测试网节点，本来以为像喝汤一样简单，对着手册突突突突弄下去就行了。没在新服务器上干过活，啥都要从头装，遇到了几个坑，记录一下

## 1.clang版本太低，centos是默认安装3.4版本，rust要求至少3.9

解决方法：

安装`llvm-toolset-7`

```bash
$ sudo yum install centos-release-scl
$ sudo yum install llvm-toolset-7
```

开启 `llvm-toolset-7`:

```bash
$ scl enable llvm-toolset-7 bash
```

检查一下

```bash
$ clang --version
```

## 2.gcc版本不匹配，有些程序需要C++17的特性，centos用yum默认下载的版本也不对

解决方法：

安装 `devtoolset-8`:

```bash
$ sudo yum install centos-release-scl
$ sudo yum install devtoolset-8
```

开启 `devtoolset-8`:

```bash
$ scl enable devtoolset-8 bash
```


centos搭建rust环境的几个坑



从前有一个大网红Diana坐拥百万粉丝，她有一天突发奇想，想给每一个粉丝发放一个粉丝牌NFT，那么她应该怎么做呢？第一步，她需要部署一张NFT合约；第二步，铸造100万枚粉丝牌NFT；第三步，将粉丝牌NFT发送给粉丝。先不说天价gas费和Diana小姐会不会写合约，这一套下来等到粉丝全部收到粉丝牌保守估计得有四五天了，Diana很是头疼，怎么办呢。

直到直播间的穷哥们小A发现了Aptos，这条链有着很强的性能和很低的使用门槛，链上内置了原生的NFT合约，这就省去了第一步的麻烦，又由于其超高性能，第二第三步居然可以在几个小时内解决！小A立刻来了精神，要是把这件事拿下，Diana小姐岂不是会尊敬我崇拜我爱上我对我欲罢不能？

这就开干：

由于下面会复用aptos官方example中的部分代码，可以先阅读该篇文章：http://alvan.coffee/2022/07/30/aptos-tutorial

Aptos官网有铸造nft的example，python版本和typescript版本，rust版本还没有添加，那我们就用rust写了补全一下吧。

第一步，构造一个Client用于和Aptos节点和水龙头交互：

```rust
pub struct NftClient {
    url: String,
    pub rest_client: RestClient,
}

impl NftClient {
    /// Represents an account as well as the private, public key-pair for the Aptos blockchain.
    pub fn new(url: &str) -> Self {
        Self {
            url: url.to_string(),
            rest_client: RestClient::new(url.to_string()),
        }
    }
   pub fn submit_transaction_helper(&self, account: &mut Account, payload: Value) {
        self.rest_client
            .execution_transaction_with_payload(account, payload);
    }
}
```

这里复用了上一篇文章的RestClient，官方样例很贴心地把构造，提交，验证交易相关的操作都写好了，我们只需要添加业务层面的逻辑，也就是写写REST请求体就可以了。

第二步，铸造NFT

Nft在所谓0x1合约也就是`aptos-framework`中，提供了数种创建collection和token的方法。

在aptos里我们可以创建有限或无限的Nft系列(collection)，根据业务需要，有些系列的NFT要强调稀缺性，有些系列则需要持续铸造，我们可以用选择不同的方法。这里我们使用`create_unlimited_collection_script`和`create_unlimited_token_script`，在`aptos-move/framework/aptos-framework/sources/token.move`中我们可以看到更详细的说明。

在创建好collection后我们就可以去铸造该collection下的token了，可以批量生产，supply参数就是产量。

我们只需要很简单的根据需求构造出对应name，description和url的collection/token，然后把它们塞进payload里，用自己的账户把交易发出去就ok了。

```rust
pub fn create_collection(
        &self,
        account: &mut Account,
        name: &str,
        uri: &str,
        description: &str,
    ) {
        let payload = serde_json::json!({
            "type": "script_function_payload",
            "function": "0x1::token::create_unlimited_collection_script",
            "type_arguments": [],
            "arguments": [
                hex::encode(name.as_bytes()),
                hex::encode(description.as_bytes()),
                hex::encode(uri.as_bytes()),
            ]
        });
        self.submit_transaction_helper(account, payload)
    }
    pub fn create_token(
        &self,
        account: &mut Account,
        collection_name: &str,
        name: &str,
        description: &str,
        supply: i32,
        uri: &str,
    ) {
        let payload = serde_json::json!({
            "type": "script_function_payload",
            "function": "0x1::token::create_unlimited_token_script",
            "type_arguments": [],
            "arguments": [
                hex::encode(collection_name.as_bytes()),
                hex::encode(name.as_bytes()),
                hex::encode(description.as_bytes()),
                true,
                supply.to_string().as_str(),
                hex::encode(uri.as_bytes()),
                "0",
            ]
        });
        self.submit_transaction_helper(account, payload)
    }
```

第三步，交易NFT

由于aptos独特的所有权机制，转移nft其实并不是合约记一下账这么简单，需要分为两步走，发送方发送`(offer_token`)之后，接收方还要声明接收一下(`claim_token`)，这两个方法都在`0x1::token_transfers`合约里，文件在`aptos-move/framework/aptos-framework/sources/token_transfers.move`

值得注意的是，想要转移nft，需要知道创建者地址，collection名和name名。

```rust
pub fn offer_token(
        &self,
        account: &mut Account,
        receiver: &str,
        creator: &str,
        collection_name: &str,
        token_name: &str,
        amount: i32,
    ) {
        let payload = serde_json::json!({
            "type": "script_function_payload",
            "function": "0x1::token_transfers::offer_script",
            "type_arguments": [],
            "arguments": [
                receiver,
                creator,
                hex::encode(collection_name.as_bytes()),
                hex::encode(token_name.as_bytes()),
                amount.to_string().as_str()
            ]
        });
        self.submit_transaction_helper(account, payload)
    }
    pub fn claim_token(
        &self,
        account: &mut Account,
        sender: &str,
        creator: &str,
        collection_name: &str,
        token_name: &str,
    ) {
        let payload = serde_json::json!({
            "type": "script_function_payload",
            "function": "0x1::token_transfers::claim_script",
            "type_arguments": [],
            "arguments": [
                sender,
                creator,
                hex::encode(collection_name.as_bytes()),
                hex::encode(token_name.as_bytes())
            ]
        });
        self.submit_transaction_helper(account, payload)
    }
```

第四步，查询NFT

现在交易写完了，我们查询一下NFT的持有量和数据，这就复用到了上一篇文章里的`account_resource`，无论什么资源，原生代币还是项目代币，抑或是NFT，他们都是我们账户的资源(resource)，所以使用这个就可以查到我们持有的nft了。

```rust
    pub fn get_collection(&self, creator: &str, collection_name: &str) -> Value {
        let collection = &self
            .rest_client
            .account_resource(creator, "0x1::token::Collections")
            .unwrap()["data"]["collections"]["handle"];
        match collection {
            Value::String(s) => self.get_table_item(
                s.as_str(),
                "0x1::string::String",
                "0x1::token::Collection",
                Value::String(collection_name.to_string()),
            ),
            _ => panic!("get_collection:error"),
        }
    }
    pub fn get_token_balance(
        &self,
        owner: &str,
        creator: &str,
        collection_name: &str,
        token_name: &str,
    ) -> Value {
        let token_store = &self
            .rest_client
            .account_resource(owner, "0x1::token::TokenStore")
            .unwrap()["data"]["tokens"]["handle"];
        let token_id = serde_json::json!({
            "creator": creator,
            "collection": collection_name,
            "name": token_name,
        });
        match token_store {
            Value::String(s) => {
                self.get_table_item(s, "0x1::token::TokenId", "0x1::token::Token", token_id)
                    ["value"]
                    .clone()
            }
            _ => panic!("get_token_balance:error"),
        }
    }
    pub fn get_token_data(&self, creator: &str, collection_name: &str, token_name: &str) -> Value {
        let token_data = &self
            .rest_client
            .account_resource(creator, "0x1::token::Collections")
            .unwrap()["data"]["token_data"]["handle"];
        let token_id = serde_json::json!({
            "creator": creator,
            "collection": collection_name,
            "name": token_name,
        });
        match token_data {
            Value::String(s) => self
                .get_table_item(s, "0x1::token::TokenId", "0x1::token::TokenData", token_id)
                .clone(),
            _ => panic!("get_token_data:error"),
        }
    }
```

写完之后，小A把代码放在这里：https://github.com/passer-byzhang/aptos-core/tree/main/developer-docs-site/static/examples/rust/first_nft

随着测试代码绿油油的passed，小A开心地私信了Diana小姐，但是不知道为什么弹出了：由于对方隐私设置，无法发送私信。呵呵，一定是平台针对我，等进入了Web3时代，就不会有这样的事了吧，小A这样想着，合上电脑去睡觉了。

无需合约，在Aptos上发布NFT

Aptos链入门，发交易和构造合约

aptos初体验

Aave v3的tech paper，主要讲了在此次迭代中四个方面的老缺陷与新提升，包括资本效率，安全，权限管理和用户体验

AAVE v3 技术说明



## 背景

作者在搬groth16上链的项目里需要用到一些椭圆曲线上的秘密随机点(自然也可以把它当作root生成随机数)，需要用到MPC计算生成。记录一下算法和思路，加密部分使用bls12-381加密库。

## 概述

因为在Groth16中需要使用到一系列的随机点进行掩藏数据，产生这些随机数的参数绝不能泄漏，比如bls12-381上的一个$\alpha$点来源$g_1\times a$，由于陷门函数的特性，我们无法通过$\alpha$来推导出$a$，但是一旦$a$遭到泄漏，就可以直接计算出$\alpha$。

那么我们就需要一种在运算过程中不可能泄露$a$的方法去生成$\alpha$，这就可以转换成一个多方协同计算的问题：

假设有n个参与生成计算的节点参与，它们会依次提供$a_1，a_2，a_3...a_n$这n个随机数计算出$\alpha_1，\alpha_2...\alpha_n$，如果先计算$a$再进行隐藏：$\alpha=(\prod_{i=1}^n a_i)\times g_1$，那么$a$和传输过程中的$a_i$都有可能泄露。

要将中间变量加密变成$E(\prod_{i=1}^n a_i)$和$E(a_i)$，才能在运行过程中不泄漏任何一个人提供的信息$a_i$，就可以保证每一个参与提供随机数的节点都不可能的知道最终的$a$，所有人拿到的只有加密后中间值。

## 基本思路

可以预见的一点就是在依次计算的过程中，我们需要防止有人作恶，篡改之前的结果。如果第3个节点收到了加密数据$E(a_1\times a_2)$，但是它传给下一个人的却是$E(a_3\times a_3 \times a_3)$——擅自修改了内容，我们需要如何验证呢？

如果我们没有使用加密数据$E(a_1\times a_2)$和$E(a_3\times a_3 \times a_3)$，而是直接存储了$a_1\times a_2$，接受第三个节点的$a_3\times a_3 \times a_3$和他自己的$a_3$，那么我们只需要验证上一次的结果$a_1\times a_2$与新节点提供的随机数$a_3$乘积是否等于它传给下一个人的$a_3\times a_3 \times a_3$，就可以了。

但是**所有人拿到的只有加密后中间值**，我们只要保证中间值的运算结果符合数字运算的规律，也就是“同态”即可。

**如果加密函数E(x)满足以下特性,则认为有同态性**
$加法同态:E(a+b)=E(a)+E(b)  \\ 乘法同态:E(ka)=kE(a) \\双线性映射:假设有两个群G_1,G_2,G_1*G_1=G_2,g是G_1的生成元,e(g,g)是G_2的生成元,则
e(g^a,g^b)=e(g,g)^{ab}=e(g^b,g^a)$

我们的bls12-381中也符条件，既
加法同态：$(a_1+a_2)\times g_1 = a_1\times g_1 + a_2\times g_1$
乘法同态：$k \times (a_1\times g_1) = (k\times a_1)\times g_1$

双线性映射：$pairing(a_1\times g_1 , a_2\times g_2) = pairing((a_1\times a_2)\times g_1，g_2)$

## 实现方法

我使用双线性映射来进行验证，第i个节点传输的数据为：

```rust
#[derive(Clone, Copy)]
pub struct ParameterPair<E: Engine> {
    pub g1_result: Option<E::G1Affine>,//传给下一个节点的数据,g1上的点,既(a1*a2*..ai * g1)
    pub g2_result: Option<E::G2Affine>,//传给下一个节点的数据,g2上的点,既(a1*a2*..ai * g2)
    pub g1_mine: Option<E::G1Affine>,//该节点新加入的数据,g1上的点,既(ai * g1)
    pub g2_mine: Option<E::G2Affine>,//该节点新加入的数据,g1上的点,既(ai * g2)
}
```

验证端保存着之前$i-1$个节点传输数据的列表：

```rust
Vec<ParameterPair<E>>;
```

需要通过这个列表 的最新数据和节点自己的随机数更新信息：

```rust
pub fn mpc_common_paramters_custom<E>(
    paramter_last: &ParameterPair<E>,
    num: E::Fr,
) -> Result<ParameterPair<E>, SynthesisError>
where
    E: Engine,
    E::G1: WnafGroup,
    E::G2: WnafGroup,
{
    let g1 = E::G1::generator();
    let g2 = E::G2::generator();//g1,g2是两个群上的元，类似于自然数中的1。
    let g1_before = paramter_last.g1_result.unwrap();//之前列表的最新值：a1*a2*...a(n-1) * g1
    let g1_after = (g1_before * num).to_affine();//预期中更新之后的值：a1*a2*...a(n-1)*a(n) * g1
    let g2_before = paramter_last.g2_result.unwrap();
    let g2_after = (g2_before * num).to_affine();
    let g1_mine = (g1 * num).to_affine();//a(n)*g1
    let g2_mine = (g2 * num).to_affine();//a(n)*g2
    let result = ParameterPair {
        g1_result: Some(g1_after),
        g2_result: Some(g2_after),
        g1_mine: Some(g1_mine),
        g2_mine: Some(g2_mine),
    };
    return Ok(result);
}
```

在新增数据之前，可以通过该列表和新节点传入数据验证：

```rust
pub fn verify_mpc_g1<E>(new_paramter: &ParameterPair<E>, paramters: &Vec<ParameterPair<E>>) -> bool
where
    E: Engine,
    E::G1: WnafGroup,
    E::G2: WnafGroup,
{
  	/**
  	*g1,g2是两个群上的元，类似于自然数中的1。
  	*/
    let g1 = E::G1::generator();
    let g2 = E::G2::generator();
  	/**
  	*这一步验证传来的结构体里g1,g2上的点是一一对应而非假造的，验证方法为：
		* pairing(g1_mine, g2)== E::pairing(g1, g2_mine);
		* pairing(g1_result, g2)== E::pairing(g1, g2_result);
  	*/
    let mut result = E::pairing(&new_paramter.g1_mine.unwrap(), &g2.to_affine())
        == E::pairing(&g1.to_affine(), &new_paramter.g2_mine.unwrap());
  	result = E::pairing(&new_paramter.g1_result.unwrap(), &g2.to_affine())
        == E::pairing(&g1.to_affine(), &new_paramter.g2_result.unwrap());
    let index = paramters.len();
		/**
		* 这一步用来验证第i个节点是否篡改了原来的数据：拿出一个进故宫验证的节点i-1的数据list[i-1]
		* 那么应该有：pairing(list[i-1].g1_result,new_paramter.g2_mine)==pairing(new_paramter.g1_result,g2)
		*/
    if (index >= 1) {
        let paramter_last = new_paramter.g1_result.unwrap();
        let paramter_part2 = new_paramter.g2_mine.unwrap();
        let paramter_part1 = paramters[index - 1].g1_result.unwrap();
        result = result
            && E::pairing(&paramter_last, &g2.to_affine())
                == E::pairing(&paramter_part1, &paramter_part2);
    }
    result
}
```

如果验证通过，再将该节点的信息加入进列表，进行下一轮计算。

最后拿到的g1_result和g2_result就是$(\prod_{i=1}^n a_i)\times g_1$和$(\prod_{i=1}^n a_i)\times g_2$了，这同时我们确实没有泄露任何一个$a$，也避免了作恶。

## 一些总结和延伸

大家应该可以看出这个实例也可以用同态加法或乘法来做，比如每个人传$a_i\times g_1$，然后维护一个$(a_1+a_2+...+a_i)\times g_1$来使用和验证即可。或者说任何一个同态加密方法都可以依照此法进行多方计算。

同态加密也可以用于验证信息，比如同一组信息分成几个碎片，通过这吸热碎片验证这个集体对某物的所有权，我们可以通过同态加密计算，每一个人的私钥碎片是$k_1,k_2...k_n$，私钥为$K=(\prod_{i=1}^n k_i)$如何在不互通私钥信息的情况下一起生成一个私钥呢？可以把每一个私钥同态隐藏起来$E(k_i)$，计算$E(\prod_{i=1}^n k_i) = \prod_{i=1}^n E(k_i)$来进行验证。

感谢您的观看，作者也是刚刚接触，如有错漏请诸君斧正。

[作者博客: alvan.coffee](alvan.coffee)

一个多方协同计算生成椭圆曲线上的秘密点的思路与实现，可以应用于随机数，身份验证等等

基于bls12-381生成秘密随机点


原文链接：https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-a5f
译者：[Alvan's Blog](alvan.coffee)

# 深入理解EVM - Part 5 - 调用/委托调用



今天我们详细解读一下 CALL 和 DELEGATECALL 两个操作，如果没看过[第二篇](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-d6b?utm_source=%2Fprofile%2F80455042-noxx&utm_medium=reader2&s=r)，[第三篇](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-3ea?utm_source=%2Fprofile%2F80455042-noxx&utm_medium=reader2&s=r) 和[第四篇](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-5a5?utm_source=%2Fprofile%2F80455042-noxx&utm_medium=reader2&s=r)的话，建议作为前置知识读一下。

我们将从solidity，EVM 和 Geth 三个层面解读这两个opcode，让你对它们有一个全面的认识。然而在深入理解他们之前，我们先确认一下合约执行上下文的概念：

### 执行上下文

*当EVM运行合约时，会创造一个[上下文](https://www.evm.codes/about)，它包含以下几个部分：*

- Code
  - 存储在链上的合约的不可变代码。
- Call Stack
  - 前文讲过的合约的调用栈，EVM运行合约时会初始化一个空的。
- Memory
  - 合约的内存，EVM运行合约时会初始化一个空的。
- Storage
  - 存储区在执行过程中持久化，链上存储，根据合约地址和插槽寻址。
- The Call Data
  - 交易的传入数据
- The Return Data
  - 合约调用的返回数据

在阅读下面内容时，时刻记着这几个点。我们先从[Smart Contract Programmer](https://www.youtube.com/watch?v=uawCDnxFJ-0)的DELEGATECALL使用用例开始讲：

### Solidity 样例

下图是同一个合约中的两个调用，一个使用了DELEGATECALL，另一个使用了CALL。现在我们看一下他们之间的区别。

[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fbd68e45d-6238-483a-bf8f-393db30ac39c_2650x1572.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fbd68e45d-6238-483a-bf8f-393db30ac39c_2650x1572.png)

下边是这次交互的一些信息(如果你在remix里自己执行的话，会是不一样的数据)：

我们有两个合约，即 Contract A 和 Contract B 还有一个 EOA：

- EOA 地址 = 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
- Contract A 地址 = 0x7b96aF9Bd211cBf6BA5b0dd53aa61Dc5806b6AcE
- Contract B 地址 = 0x3328358128832A260C76A4141e19E2A943CD4B6D

现在把 Contract B 的地址和一个uint值 12以及 1000000000000000000 Wei 传入，调用 Contract A 里的两个方法， setVarsDelegateCall 和 setVarsCall。

***Delegate Call***

1. 一个 EOA 地址把 Contract B 的地址和一个uint值 12以及 1000000000000000000 Wei 传入，调用Contract A的setVarsDelegateCall，这次是委托调用Contract B执行setVars(uint256)，参数是12。
2. 委托调用运行 Contract B 的 setVars(uint256) 但是更新的是 Contract A 的存储区，它运行时的存储区，msg.sender 和msg.value 也都和父调用一样。
3. Contract A的存储区写入数据：num=12，sender = EOA Address以及value = 1000000000000000000。尽管Contract A 调用的setVars(uint256)不带value，

执行完这个方法之后我们检查Contract A 和Contract B的num， sender 和 value状态。我们可以看到Contract B没有被初始化，都设置在Contract A里了。

***Call***

1. 一个 EOA 地址把 Contract B 的地址和一个uint值 12以及 1000000000000000000 Wei 传入，调用 Contract A 的setVarsCall，这次是调用Contract B执行setVars(uint256)，参数是12。
2. 调用运行 Contract B 的setVars(uint256) ，不改变(本合约的)存储区，msg.sender,和msg.value
3. Contract B的存储区写入数据：num=12，sender = Contract A Address 以及value = 0。(1000000000000000000 Wei被传进了父调用setVarsCall。)

执行完这个方法之后我们检查Contract A 和Contract B的num， sender 和 value状态。我们可以看到Contract A没有被初始化，都设置在Contract B里了。

“委托调用”就是允许你从别的合约里复制一个方法粘贴到你的合约里，运行起来就行在你的合约里执行的一样，使用本合约的存储区，msg.sender 和 msg.value。而“调用”是进入到另一个合约去执行方法，相当于发了一笔交易，有其自己的value值和sender(也就是调用call的合约)。

### Delegate Call & Storage Layout委托调用与内存布局

在上述例子里，你肯呢个注意到Contract B 第5行的注释*“NOTE: storage layout must be the same as contract A”*。

合约里的每一个函数都会经过编译成为一个静态的字节码。当我们理解solidity变量的时候，是看见num，sender和value去理解的。但是字节码不知道这些，它只认存储插槽，而声明变量的时候就把插槽定下来了。

Contract B 的 setVars(uint256) 函数里，“num = _num”就是说要把 _num 存进插槽0。当我们看一个DELEGATECALL的时候不要去想num → num，sender → sender的映射，因为在字节码的层面不是这样的，我们需要认识到这是slot 0 → slot 0, slot 1 → slot 1的映射。

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fcf64c77b-f60f-4720-96bb-575dabef8917_1006x306.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fcf64c77b-f60f-4720-96bb-575dabef8917_1006x306.png)

试想如果我们改变了声明变量的顺序会怎样。那么他们的插槽位置会改变，同时setVars(uint256) 的字节码也跟着变了。如果我们把 Contract B 的6行和8行互换位置，先声明 value 后声明 num 。那就意味着11行的“num = _num”意味着把 _num存进插槽2里，13行的“value = msg.value”意味着把msg.value 存进插槽0。这就用意味着两合约中，我们变量之间的映射和插槽之间的映射不匹配了

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0f24b3ce-a2ed-4bbe-b87d-6d36b9148640_1006x306.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0f24b3ce-a2ed-4bbe-b87d-6d36b9148640_1006x306.png)

在这种情况下，当我们运行 DELEGATECALL 时，num变量会被存在插槽2，而这里在 Contract A 中映射到 value 变量。反过来也是一样的，两个变量就会存储进预想之外的地方。这就是DELEGATECALL比较危险的原因之一。我们意外地 value 值把 num 覆盖了，用 num 值把 value 覆盖了。但是黑客可不会意外，他们会有目的地攻击。

试想我们知道一个开放 delegatecall 的合约，我们知道那个合约存储 owner的插槽。现在我们可以做一个相同布局的合约，然后写一个更新owner的方法，这就意味着我们可以通过委托调用这个更新方法来改变该合约的owner。

如果你对这个黑客攻击感兴趣的话可以在这里深入了解一下：

- [Ethernaut Level 6 - Delegation](https://ethernaut.openzeppelin.com/level/0x9451961b7Aea1Df57bc20CC68D72f662241b5493)
- [Ethernaut Level 16 - Preservation](https://ethernaut.openzeppelin.com/level/0x97E982a15FbB1C28F6B8ee971BEc15C78b3d263F)

下面看一看opcode层面

## Opcodes

我们现在知道DELEGATECALL怎么工作了，那么深入一下，看看DELEGATECALL和CALL的操作码。

对于DELEGATECALL我们有以下输入变量

- `gas`: 执行的gas费
- `address`: 执行上下文的account
- `argsOffset`: 输入数据(calldata)的偏移量
- `argsSize`: calldata的大小
- `retOffset`: 输出数据(returndata)的偏移量
- `retSize`: returndata的大小

CALL比起上边的只多一个value，其它的都一样

- `value`: 发送给account的以太币(CALL only)

委托调用不需要value输入，它从父调用继承。我们的执行上下文有和父调用一样的存储区，msg.sender 和 msg.value。

他们都是有一个返回值布尔值"success"，为0则为执行失败，反之则为1。

> *如果调用位置没有合约或者没有代码，Delegatecall会返回true。这会出现bug，因为它没执行，我们是希望返回False的*

### DELEGATECALL Opcode Inspection With Remix利用Remix检验DELEGATECALL

下边是Remix中调用DELEGATECALL操作码的截图。对应Solidity代码的24-26行。

我们可以看到栈和内存的条目以及它们是怎么传进DELEGATECALL的。

[![img](https://substackcdn.com/image/fetch/w_5760,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F39945796-94b6-4d6b-8bf6-52b29ac22559_3404x1334.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F39945796-94b6-4d6b-8bf6-52b29ac22559_3404x1334.png)

我们按照这条路线理解：opcode → stack → memory → calldata

1. Solidity代码的24行，使用了delegatecall 调用 Contract B 的 setVars(unit256)，调用了DELEGATECALL操作码。
2. DELEGATECALL从栈上拿6个输入：
   1. Gas = 0x45eb
   2. Address = 0x3328358128832A260C76A4141e19E2A943CD4B6D (Address for Contract B)
   3. ArgsOffset = 0xc4
   4. ArgsSize = 0x24
   5. RetOffset = 0xc4
   6. RetSize = 0x00
3. 注意到 argsOffset 和 argsSize 两个代表了传入 Contract B 的 calldata。这两个变量让我们从内存位置0xc4开始，复制后边的 0x24 (十进制36)作为calldata。
4. 我们因此拿到了0x6466414b000000000000000000000000000000000000000000000000000000000000000c，6466414b是setVars(uint256) 的函数签名，而000000000000000000000000000000000000000000000000000000000000000c是我们传入的数据 12。
5. 这对应了Solidity代码的25行，abi.encodeWithSignature("setVars(uint256)", _num)。

因为setVars(uint256)不返回任何值，所以retSize置0。

如果有返回值的话，就是存在retOffset以后的retOffset以内。这应该让你对这个操作码的底层逻辑了解的深一点，也会和Solidity联系起来了。

现在我们看一下Geth里的实现。

### Geth实现

我们看一下Geth里写DELEGATECALL的部分。目标是展现DELEGATECALL和CALL在存储的层面的区别，以及是怎么联系上SLOAD的。

下边的图有点唬人，但是我们拆解开来一步一步做，在结束的时候你就会对DELEGATECALL和CALL有深刻的认识。

[![img](https://substackcdn.com/image/fetch/w_5760,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F60abd9bd-475f-4694-8bce-aa4c4b43fadd_4102x3874.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F60abd9bd-475f-4694-8bce-aa4c4b43fadd_4102x3874.png)

We have the DELEGATECALL & CALL opcodes labeled on the left-hand side and the SLOAD opcode labeled bottom right. Let’s see how they’re connected.

1. 这图里有两个 [1] 号截图，分别对应DELEGATECALL和CALL操作码的代码，在[instructions.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/instructions.go)里。我们可以看到从栈里弹出的那几个变量，之后可以看到调用 interpreter.evm.DeleagteCall和 interpreter.evm.Call 这两个函数，传进去了栈里的变量，目标地址和现在的合约上下文
2. 图里也有两个 [2] 号截图，分别对应 evm.DelegateCall 和 evm.Call 的代码的代码，在 [evm.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/evm.go)里边。中间省略了一些校验和其它函数，我们主要关注执行调用NewContract方法新建上下文的代码，其它的可以忽略掉。
3. 图里有两个 [3] 号截图。里边主要是evm.DelegateCall和evm.Call 调用NewContract。它们非常相似，以下两点除外：
   1. DelegateCall的value参数设为nil，它从之前的上下文继承，所以不写进这个参数里。
   2. NewContract的第二个参数也不一样。evm.DelegateCall 里caller.Address( ) 用的是Contract A的地址。evm.Call 里addrCopy是复制的toAddr，也就是Contract B的地址，这一点区别非常大。他俩都是AccountRef类型，这个很重要，后边会提到。
4. DelegateCall’s的NewContract会返回一个Contract结构体。它又调用了AsDelegate()方法(在[contract.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/contract.go)里)(见图[4])，把msg.sender 和 msg.value设置成了父调用的样子，也就是EOA地址和1000000000000000000 Wei。这在Call的实现里是没有的。
5. evm.DelegateCall 和 evm.Call 都执行NewContract方法(在[contract.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/contract.go)里)，NewContract方法的第二个入参是“object ContractRef”，对应着第三点里提到的AccountRef。
6. “object ContractRef”和一些其他值被用来初始化合约，对应Contract结构体里的“self”
7. Contract结构体( 在[contract.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/contract.go)里)有一个“self”字段，你可以看到也有其他的字段与我们之前提到的执行上下文有关。
8. 现在我们跳跃一下，去看看Geth里SLOAD(在[instructions.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/instructions.go)里)的实现，它在调用GetState时用的参数就是scope.Contract.Address( )。这里的“Contract”就是我们在第7条提到的结构体。
9. Contract结构体的Address( ) 返回的是self.Address。
10. Self是一个ContractRef类型，ContractRef必然有一个Address( ) 方法。
11. ContractRef是一个接口，规定如果一个类型要做ContractRef，那必须有一个返回值类型是common.Address的Address( ) 函数。common.Address是一个长度20的字节数组，也就是以太坊地址的长度。
12. 我们回到第3块看一下evm.DelegateCall和evm.Call 中AccountRef的区别。我们可以看到AccountRef就是一个有Address( ) 函数的地址，那它也符合ContractRef接口的规则。
13. AccountRef 的 Address( ) 函数是把 AccountRef 转化成common.Address，也就是 evm.DelegateCall 里的 Contract A 地址和 evm.Call 里的Contract B 地址。这意味着第8部分讲的 SLOAD 会在 DELEGATECALL 时使用 Contract A 的存储区，在 CALL 时使用 Contract B 的存储区。

通过学习Geth的实现你应该对DelegateCall的存储区， msg.sender和msg.value的来龙去脉有了深刻了解，对DELEGATECALL也有了一定的认识，很棒！下次再见！





从solidity使用，到opcode原理，再到Geth实现，三个层次解读委托调用的原理与实现

深入理解EVM - Part 5 - 调用/委托调用的原理与实现


原文链接：https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-5a5?s=r


这是“深入理解EVM”系列的第四期。在[第三期](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-3ea?s=)中我们了解了合约存储相关的知识，这期会说明以太链的“世界状态”是怎么容纳单个合约的存储区的。为此我们需要审视以太链的体系结构和数据结构，一探Geth客户端深处的秘密。

我们从以太区块的数据开始，反推回特定合约存储区。再用Geth如何实现SSTORE与SLOAD收尾。需要了解的知识有很多，我们会介绍Geth代码库，讲讲以太坊的世界状态，让你对EVM有一个更深的了解。

## 以太坊体系结构

我们从下图开始，不要有恐惧心理，在文章的结尾你会对它有一个全面的认识，这里画出了以太坊的体系结构和以太链的数据。

[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff6f48734-3cd7-42a0-a2dd-8f09fdd8a90e_1048x728.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff6f48734-3cd7-42a0-a2dd-8f09fdd8a90e_1048x728.png)以太坊体系结构 - 来源： [Zanzu](https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture)

相比看整个的图，我们不如一块一块看。现在我们看一下第N块的区块头和它包含的字段。

### 区块头

区块头包含以太区块的关键信息，下边的第N块区块头就划分出了这些信息。看看以太坊[第14698834块](https://etherscan.io/block/14698834) 是否有下图的字段吧。

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F1e081473-12c5-4b01-ab0b-5f1ec1db106d_482x231.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F1e081473-12c5-4b01-ab0b-5f1ec1db106d_482x231.png)

区块头包含以下字段：

- Prev Hash - 父区块的Keccak 哈希
- Nonce - 用于PoW计算，检验区块是否被成功挖出
- Timestamp - UNIX时间戳
- Uncles Hash - 叔叔节点的Keccak 哈希
- Beneficiary - 收款人地址，矿工费接收者
- LogsBloom - 布隆过滤器，提取自receipt，用于查找交易回执中的智能合约事件信息。
- Difficulty - 表示当前区块的挖出难度
- Extra Data - 最长32字节的自定义信息，由矿工自定义
- Block Num - 区块高度
- Gas Limit - 每个区块允许的最大gas量
- Gas Used - 该区块实际消耗的gas量
- Mix Hash - PoW验证时使用，代表区块不含nonce时的哈希值
- ***State Root - 执行完此区块中的所有交易后以太坊中，所有账户状态的默克尔树根哈希值***
- Transaction Root - 交易生成的梅克尔树的根节点哈希值。
- Receipt Root - 交易回执生成的梅克尔树的根节点哈希值。

让我们看看这些和Geth代码的对应关系，[block.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/types/block.go#L70)里定义的“Header”结构体就代表一个区块头。

[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F35765b7d-a78d-4350-86b7-02925e25b35a_3226x1178.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F35765b7d-a78d-4350-86b7-02925e25b35a_3226x1178.png)代码地址： [go-ethereum/core/types/block.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/types/block.go)

我们可以看到代码里声明的变量是和上边的概念图匹配的，我们的目标是从从区块头一路找到合约存储区。为此我们要关注被标红的“State Root”字段

### 状态根

“状态根(State Root)”是一个梅克尔根，它取决于其下所有的数据块，任何一块数据的变动都会改变它。这个状态树的数据结构是MPT，叶子结点存储这网络上每一个以太坊账户的数据。该数据为k-v结构，key是地址，value是账户信息。

*实际上key是地址的哈希值而value是账户信息的RLP编码，但是我们可以暂时忽略这件事*

以太坊体系结构图的这一部分正是代表了状态根的MRT。

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fd1cf36d8-9880-4aa1-9b7b-a4176273d210_178x258.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fd1cf36d8-9880-4aa1-9b7b-a4176273d210_178x258.png)

MPT是一种复杂的数据结构，我们这篇文章不做深究。如果你对MPT感兴趣的话建议看[这篇文章](https://medium.com/shyft-network-media/understanding-trie-databases-in-ethereum-9f03d2c3325d)。接下来我们重点看看以太坊的账户信息是如何映射到地址的。

### 以太坊账户

以太坊账户由以下四项构成：

- Nonce - 账户的交易数
- Balance - 账户余额
- Code Hash - 合约账户的所执行的代码，一旦被初始化就是只读的。
- Storage Root - 存储根，该值随着合约的存储区的增加、删除、改动而不断变更

(译者注：后两项是合约账户拥有的数据段，普通账户并没有)

我们在之前以太坊体系结构图的这一段可以看到：

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0f0b898c-8fb1-469a-9fb1-0346ccbae601_409x57.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0f0b898c-8fb1-469a-9fb1-0346ccbae601_409x57.png)

现在我们去看看Geth的代码，找到对应的 [state_account.go](https://github.com/ethereum/go-ethereum/blob/b1e72f7ea998ad662166bcf23705ca59cf81e925/core/types/state_account.go#L27) ，这个StateAccount结构体就是“以太坊账户”。

[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F630df44e-bdab-41b9-8894-f09be4a09ea7_2122x574.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F630df44e-bdab-41b9-8894-f09be4a09ea7_2122x574.png)代码地址： [go-ethereum/core/types/state_account.go](https://github.com/ethereum/go-ethereum/blob/b1e72f7ea998ad662166bcf23705ca59cf81e925/core/types/state_account.go)

可以看到代码里声明的变量与概念图对应上了。接下来我们需要探讨以太坊账户的存储根。

### 存储根

存储根(storage root)很像状态根，在它的下面是另一棵MPT。区别就是这次的key是存储插槽，而value是插槽里的数据。

*跟状态根一样，key其实是哈希值而value是RLP编码*

以太坊体系结构图的这一部分正是代表了存储根的MRT。

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F18d30b84-5853-4505-9466-a8c2804be40e_196x260.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F18d30b84-5853-4505-9466-a8c2804be40e_196x260.png)

存储根是一个梅克尔根，任何合约存储区的数据的改变都会改变存储根的值，从而影响区块头的值。现在我们知道怎么从区块找到合约存储区了。下一步我们继续研究Geth的代码，看看存储区是怎么初始化的，以及调用SSTORE和SLOAD是会发生什么。这会帮助你找到底层opcode和solidity代码之间的联系。

### StateDB → stateObject → StateAccount

我们需要一个全新的合约，全新的合约意味着StateAccount也是全新的。

开始之前我们看三个结构：

- StateAccount
  - StateAccount 是以太坊账户的一致化表达
- stateObject
  - stateObject 代表着尚未被修改的以太坊账户
- StateDB
  - StateDB 存储梅克尔树的所有数据，用于检索合约和以太坊账户的查询接口

我们看看这三个结构的内在关系：

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fc0e579c8-adb2-4679-9744-03c4bd3c1182_2002x1572.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fc0e579c8-adb2-4679-9744-03c4bd3c1182_2002x1572.png)StateDB → stateObject → StateAccount

1. [StateDB struct](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/statedb.go#L64), 我们可以看到它有一个stateObjects字段，是地址到stateObject的映射集(牢记状态根的MPT是地址到以太坊账户的映射，而stateObject是尚未修改的以太坊账户)。
2. [stateObject struct](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L66), 我们可以看到它包含一个StateAccount字段，这是一个代码实现里的中间态。
3. [StateAccount struct](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/types/state_account.go#L29), 现在我们终于看到这个代表以太坊账户的结构了，它的Root字段就是我们之前讨论的存储根。

现在一些令人疑惑的东西逐渐明晰了起来，我们看一看新的以太坊账户，或者说StateAccount是怎么初始化的。

### Initalising A New Ethereum Account (StateAccount)

我们需要操作[statedb.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/statedb.go)以及它的StateDB结构体去创建新的StateAccount。StateDB有一个名为createObject的函数，它会创建一个新的stateObject然后放进去一个空的StateAccount。

下图是代码细节：

[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F5b2cc945-1634-4315-9adc-f5a2a147406e_3296x1104.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F5b2cc945-1634-4315-9adc-f5a2a147406e_3296x1104.png)

1. StateDB有一个 [createObject 函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/statedb.go#L575) ，传入一个地址返回一个stateObject。(重申stateObject是一个未修改的以太坊账户)。
2. 这个createObject函数调用[newObject 函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L102) ，它传入stateDB，地址和一个空的StateAccount，返回一个stateObject。
3. 在newObject函数的返回语句中，我们可以看到有许多字段与stateObject, address, data, dirtyStorage等相关
4. tateObject的data映射到空的StateAccount，可以在103-111行看到从nil值转变为初始化空值的过程。
5. stateObject被成功创建并带着已经初始化完成的StateAccount(也就是data字段)返回了。

现在我们有了一个空stateAccount，下一步我们存些数据吧，用SSTORE。

## SSTORE

在深入了解SSTORE的Geth实现之前我们先回忆一下SSTORE是干什么的。

SSTORE会从栈上弹出两个值，一个32字节的key，一个32字节的value。key决定了value存在哪个插槽里。

下面就是Geth的SSTORE操作的源码，我们看看他做了什么：



[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F8b9e61f6-7a74-48db-9c07-b2a3717bd3b5_2882x1762.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F8b9e61f6-7a74-48db-9c07-b2a3717bd3b5_2882x1762.png)

1. 我们从 [instructions.go](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/instructions.go#L524)开始看，它定义了所有的opcode，在这个文件里我们可以看到opSstore函数。
2. 这个函数的入参包括合约上下文信息，例如栈，内存等，我们把两个值弹出栈，标记成loc(location)和val(value)。
3. 这两个值被弹出来后作为入参和合约地址一起传进[StateDB的SetState 函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/statedb.go#L414)，SetState会用合约地址检验合约里是否有stateObject如果没有就创建一个。之后调用stateObject的SetState，传进StateDB，key和value。
4. [stateObject的SetState 函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L245)对fakeStorage做了检查，看看value是否被改变过，之后运行journal的append函数。
5. 如果你阅读[journal struct](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/journal.go#L38)的注释会看到journal是用来跟踪状态的改变(就是保存中间变量)，这样它们就可以在执行异常或撤销请求的情况下恢复。
6. journal更新之后，调用[stateObject的SetState 函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L245)。更新stateObject.dirtyStorage。

现在我们已经更新了stateObject 的 dirtyStorage。而这究竟意味着什么呢？与我们学的东西有什么关系吗？

让我们看看定义dirtyStorage的代码

[![img](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fe62db976-b29d-4803-af46-22bc577d5755_2210x1794.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fe62db976-b29d-4803-af46-22bc577d5755_2210x1794.png)dirtyStorage → Storage → Hash → 32-byte

1. dirtyStorage是在[stateObject](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L66)里定义的，被描述为"在当前事务执行中被修改的存储项"。
2. dirtyStorage的类型[Storage type](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L41)是一种从common.Hash到common.Hash的映射。
3.  [Hash type](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/common/types.go#L49) 就是一个长度为HashLength的字节数组
4. [HashLength](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/common/types.go#L36)是常量，值是32。

32字节key到32字节value的映射对你来说应该很熟悉，这完全就是[第三篇](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-3ea?utm_source=%2Fprofile%2F80455042-noxx&utm_medium=reader2&s=r)我们提到过的合约存储区的概念。你现在可能注意到dirtyStorage字段上边的pendingStorage和originStorage了。他们是有相关性的，dirtyStorage在确定写入的过程中，会复制到pendingStorage，然后在MPT更新时复制到originStorage。MPT更新了之后，StateDB的commit过程中StateAccount的状态根也会更新。会将新的状态写进MPT的底层数据库。

下面轮到最后一个难点，SLOAD。

## SLOAD

我们快速回忆一下SLOAD是干什么的：它会把一个32字节的key从栈里弹出来，然后返回key对应的插槽里的值。下面看一下Geth实现SLOAD的代码：

[![img](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F991e7cec-54bd-41b2-afe4-247144fea091_3430x1316.png)](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F991e7cec-54bd-41b2-afe4-247144fea091_3430x1316.png)

1. 我们依然从[instructions.go file](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/vm/instructions.go#L516) 开始，找到opSload函数，我们从栈顶获取到了存储插槽。也就是临时变量loc。
2. 调用[StateDB的GetState函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/statedb.go#L308)传入合约地址和存储位置，GetState获得了合约地址对应的stateObject，如果它不为空，则调用[stateObject的GetState函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L172)。
3. [stateObject的GetState函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L172)对fakeStorage和dirtyStorage做检查。
4. 如果dirtyStorage存在，则返回key在dirtyStorage映射里的值(dirtyStorage代表着合约的最新状态，所以要最先返回它)。
5. 否则将调用[GetCommitedState 函数](https://github.com/ethereum/go-ethereum/blob/d4d288e3f1cebb183fce9137829a76ddf7c6d12a/core/state/state_object.go#L187)里查询数据，再次检验fakeStorage。在这个函数里完成下面两步。
6. 如果pendingStorage存在，则返回key在pendingStorage映射里的值。
7. 如果上边的都没有，就检索originStorage里的值并返回。

你会发现函数最先试图返回dirtyStorage，然后依次是pendingStorage和originStorage。这是合情合理的，在运行的过程中dirtyStorage是最新状态，紧接着是pendingStorage和originStorage。一个交易可能多次改变同一个插槽的数据所以我们必须保证拿到的是最新的值。

让我们设想在同一笔交易里，SLOAD之前在同一个插槽发生了SSTORE操作，在这种情况下dirtyStorage是被SSTORE更新过的，SLOAD返回的正应该是它。

现在您已经了解了Geth是如何实现SSTORE和SLOAD的。它们如何与状态和存储区交互，以及如何更新插槽与世界状态相关的知识。

这篇文章的强度很大但是你坚持下来了，我猜这篇文章会让你的问题比刚开始更多了，但这正是加密世界的乐趣不是吗？

只要功夫深，铁杵磨成针！

以Geth代码为基础，从区块结构讲到账户状态/合约存储，最后是SSTORE和SLOAD两个操作码的具体实现

深入理解EVM - Part 4 - Geth中存储区的实现

合约存储区相关知识，SSTORE和SLOAD

深入理解EVM - Part3 - 存储区

从opcode角度讲解EVM的内存机制，包括数据结构，空闲内存指针与变量赋值等

深入理解EVM - Part2 - 内存


原文链接：https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy?s=r
译者博客:  [Alvan的Blog](alvan.coffee)


aaaaaaaa
### Digging deep into the EVM mechanics during contract function calls



第一性原理我们经常听说，就是着重于理解事物的基本概念从而更好地理解构建与其之上的组件。

在智能合约的世界里，EVM和它的算法与数据结构就是第一性原理，
我们写的智能合约就是建立在其之上的组件。要想成为一个优秀的solidity开发，必须要对EVM有深刻了解。

这系列文章的第一要义就是深入理解EVM，构建成为“shadowy super coder”的基础知识。

## The Basics: Solidity → Bytecode → Opcode 

开始之前，本文嘉定读者是掌握了solidity的基本用法以及怎么部署到以太坊的，后边只会简单提到，如果你想复习一下这部分知识的话请看[这篇文章](https://medium.com/@eiki1212/explaining-ethereum-contract-abi-evm-bytecode-6afa6e917c3b)。

solidity在部署到以太坊网络之前是需要被编译成字节码的，这些字节码又和一系列opcode匹配，这些opcode可以被EVM解释。

这一个系列会着眼于编译后字节码的特定部分并阐释他们的工作机制。在每一篇文章的结尾，你都可以对这些函数更清晰的认知。一路下来，你会学到有关EVM的许多概念。 

今天我们就看一个基础的solidity合约，从它的字节码/opcode片段里解释一下EVM是怎么选择函数的。

solidity创造的运行时字节码对应着一整个合约，合约部署之后，其中可能存在多个可以被调用的函数。这里边一个基础问题是EVM怎么根据合约调用的函数知道执行哪些字节码。

### 1_Storage.sol Breakdown 

在demo里我们使用了一个Storage.sol的合约，这是remix生成的默认合约之一。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F3400bba6-f870-4b68-8ba8-118562b08aef_489x538.png)

在这个合约里有两个函数，store(uint256) 和 retrieve() ，当函数调用的时候EVM就必须进行区分，下边就是此合约编译出的字节码。

```
608060405234801561001057600080fd5b50600436106100365760003560e01c80632e64cec11461003b5780636057361d14610059575b600080fd5b610043610075565b60405161005091906100d9565b60405180910390f35b61007360048036

0381019061006e919061009d565b61007e565b005b60008054905090565b8060008190555050565b60008135905061009781610103565b92915050565b6000602082840312156100b3576100b26100fe565b5b60006100c184828501610088565b

91505092915050565b6100d3816100f4565b82525050565b60006020820190506100ee60008301846100ca565b92915050565b6000819050919050565b600080fd5b61010c816100f4565b811461011757600080fd5b5056fea264697066735822

1220404e37f487a89a932dca5e77faaf6ca2de3b991f93d230604b1b8daaef64766264736f6c63430008070033 
```

我们看一下下面的片段，这个片段就是函数选择器的逻辑，可以用ctrl + f 验证一下它是否在上述字节码中。

```
60003560e01c80632e64cec11461003b5780636057361d1461005957
```

这段字节码对应一系列的opcode与其输入值，你可以在[这里](https://www.ethervm.io/)查看EVM的opcode列表。opcode的长度为1个字节也就是最多支持256种opcode，现在EVM已使用140种。

下边展示了字节码所对应的opcode，它们会在EVM的调用战(call stack)中逐条执行。比如你可以从上边的链接里找到字节码 60 代表着opcode PUSH1等等。在这篇文章的结尾，你会对它们有一个全面的认知。

```
60 00                       =   PUSH1 0x00 
35                          =   CALLDATALOAD
60 e0                       =   PUSH1 0xe0
1c                          =   SHR
80                          =   DUP1  
63 2e64cec1                 =   PUSH4 0x2e64cec1
14                          =   EQ
61 003b                     =   PUSH2 0x003b
57                          =   JUMPI
80                          =   DUP1 
63 6057361d                 =   PUSH4 0x6057361d     
14                          =   EQ
61 0059                     =   PUSH2 0x0059
57                          =   JUMPI  
```

### Smart Contract Function Calls & Calldata

在深挖opcode之前需要快速过一遍我们究竟是怎么调用函数的。当我们调用一个合约函数时，需要包含有函数签名和所需参数的calldata。可以在solidity里完成:

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fa9957ce1-945b-4afa-a395-c9d2563d2094_1614x670.png)

这里我们调用了合约的store函数，参数为10。我们使用abi.encodeWithSignature()获得calldata，emit会记录用于测试的calldata。

```
0x6057361d000000000000000000000000000000000000000000000000000000000000000a
```

上边就是abi.encodeWithSignature("store(uint256)", 10) 返回的字节码

之前提到了函数签名，现在我们再明确一下：

> 函数签名就是函数规范化表示的Keccak Hash的前四个字节。

函数标准化表示其实就是函数名+参数类型，就像 “store(uint256)” 和 “retrieve()”。你可以在[这里](https://emn178.github.io/online-tools/keccak_256.html)验证一下store(uint256)的hash。

```
keccak256(“store(uint256)”) →  first 4 bytes = 6057361d

keccak256(“retrieve()”) → first 4 bytes = 2e64cec1
```

我们可以看到calldata有36个字节，前四字节对应着我们刚刚计算出来的 store(uint256) 函数签名，剩下的32个字节对应着传入的uint256参数，一个16进制的a，也就是10进制的10.

```
6057361d = function signature (4 bytes)

000000000000000000000000000000000000000000000000000000000000000a = uint256 input (32 bytes)
```

我们获得了函数选择器 6057361d，你可以ctrf + f去opcode那一段确认一下。

### Opcodes & The Call Stack

现在关于EVM的函数选择器的前置知识已经学完了，现在正式开始。首先要过一遍每一个opcode和它们对调用栈的操作。如果你不熟悉栈的话可以看一下这个[视频](https://www.youtube.com/watch?v=FNZ5o9S9prU)。

PUSH1代表着把下一个字节(0x00也就是十进制0)的数据压入调用栈中，下一个opcode我们可以知道这么做的理由。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F52e45eff-44b3-4028-a075-9f5591fd2e7e_900x151.png)

接下来用CALLDATALOAD弹出栈顶元素stack(0)作为该命令的输入值。

这个opcode要把calldata载入调用栈，而输入值(也就是上边弹出的值)是偏移量(offset)，我们设为i。栈元素是32字节，而calldata是36字节，要压入的数据就是msg.data[i:i+32] (译者注:msg.data就是完整的calldata)，这既保证了只有32字节压栈，又允许我们访问calldata的任何一部分。

在这种情况下，我们并没有偏移量，因为offset = 0x00，所以我们把calldata前32字节压栈。之前我们记录过整个的call data为“0x6057361d000000000000000000000000000000000000000000000000000000000000000a”。这意味着我们丢失了后边四个字节(“0000000a”)，如果我们想访问这个uint256变量则需要使用4字节的偏移量，忽视前四字节的函数签名，而得到完整的变量。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fe6f79343-c4c4-4ee6-a29f-f1923fea5b9e_901x150.png)

这次又有一个PUSH1，它想压一个0xe0，也就是十进制224。224是这么来的: 函数签名有4字节或者说32位，载入的calldata有32字节256位，256 - 32 = 224。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F161dea9b-d35b-4eb1-aac5-7adecb6cc17d_901x149.png)

下一步，SHR操作意味着右移一位，而栈顶弹出的224则是移位次数，栈的下一个元素0x6057361d0…0a便是执行移位操作的主题。现在我们可以在调用栈里看到4字节的函数选择器了。如果你不了解移位操作的话请看这个[视频](https://youtu.be/fDKUq38H2jk?t=176)。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F8db5bd19-2271-44b3-99ed-0eec2731be5c_893x144.png)

下一个是DUP1，一个复制栈顶元素的简单操作。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F40b72e9d-6e80-4232-9099-8718604542a8_896x146.png)

PUSH4压入了 retrieve()的4字节函数签名(2e64cec1)，你可能疑惑evm是怎么知道这个值的，请记住字节码由solidity编译而来，它有函数名和参数类型等所有信息。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F23dc9994-e360-4205-bf5d-af92aaba42e5_899x189.png)

EQ 操作会弹出两个元素去判断是否相等，在这里0x2e64cec1 != 0x6057361d ，如果他们相等则压1，不相等则压0。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F7cfc3f88-d5eb-4b03-b4c3-eb605bdeb283_895x144.png)

PUSH2压入两字节的 0x003b 也就是十进制59。

调用栈有一个称为程序计数器的东西，它会确认字节码下一个要执行的指令在哪里，现在我们设置59是因为这是 retrieve() 函数的起始位置是59。(看下边EVM Playground 部分可以清楚这里具体是怎么实现的)。你可以看到程序字节码定位方式类似solidity代码行数，如果这个函数在59行声明，你可以使用行数来告诉机器怎么找到这个函数。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F67596d4e-054d-4cd7-b516-64b4789ee01f_900x190.png)

JUMPI 表示 “jump if” ，它会弹出两个值作为参数，59表示跳转地址而第二个元素作为布尔值代表是否跳转。

如果真值为true，程序计数器将更新然后执行跳转到指定位置，而在我们这个例子里真值为false，程序计数器并没有改变，程序继续顺序执行。

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F1357763b-4150-4e14-8a8c-583ee74572aa_896x146.png)

再次DUP1

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F40b72e9d-6e80-4232-9099-8718604542a8_896x146.png)

PUSH4把store(uint256) (0x6057361d)压栈

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff937657d-dbb3-4133-95bb-1b3f5b8117cd_897x188.png)

EQ判断，此次为真

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F9c0617f7-2181-427e-9dca-917be7847f0a_898x145.png)

PUSH2把 store(uint256) 的定位0x0059也就是89压栈

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F44dea0e0-9e0c-4459-bd1e-4af814c89203_898x186.png)

JUMPI，这次执行跳转了，程序计数器更新为89然后到字节码的其他部分运行去了。在目的地会有一个JUMPDEST，如果目的地没有这个opcode，跳转将会失败。( 译者注: 我们可以在两个函数跳转的目的地可以找到JUMPDEST的字节码 5b )

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F9f3a7f3c-a5f6-4e29-888f-60708e8863dc_896x146.png)

我们可以到store(uint156)的字节码处依照此法继续执行了。虽然这个合约只有2个函数，但是原理和20+函数的合约是一样的。你现在知道EVM如何基于函数调用找到函数的字节码了，这其实就是对合约里所有函数的位址进行if-else判断实现的。

### EVM Playground

我强烈建议大家看看[这个](https://www.evm.codes/playground),这是一个EVM运行环境，你可以设置字节码然后在上边执行。在这里可以看到调用栈的变化，我也添加了JUMPDEST，所以你也可以看到JUMPI后发生了什么

![img](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F86591a6b-ee71-4590-8462-4ebb38f5cb80_1503x887.png)

这个EVM运行环境也可以帮你理解程序计数器，在这份代码里，可以看到每个命令的注释，其偏移量代表程序计数器标记的位置。

你也可以看到Run按钮左边的calldata输入，去试试把它改成retrieve()  0x2e64cec1看看有什么变化吧！只需要点击Run然后step into按钮(就是那个弯箭头)，一步一步运行opcode。



本系列下一节我们会研究一下内存 [EVM Deep Dives - Part 2](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-d6b?s=r)。

翻译深入理解EVM系列文章，第一篇是关于函数选择器与字节码/opcode

06 / 2024

05 / 2024

04 / 2024

03 / 2024

03 / 2023

12 / 2022

11 / 2022

10 / 2022

09 / 2022

08 / 2022

07 / 2022

06 / 2022