Merkle树是区块链技术的基本组成部分。它是由不同数据块的散列组成的数学数据结构，用作块中所有交易的摘要。

它还允许对大量数据中的内容进行有效和安全的验证。此结构有助于验证数据的一致性和内容。比特币和以太坊都使用Merkle树结构。Merkle树也被称为哈希树。

从根本上说，Merkle树是数据结构树，其中每个叶节点都用数据块的哈希标记，非叶节点用加密标记 其子节点标签的哈希值。叶节点是树中的最低节点。

原理

区块链中每个区块都会有一个 Merkle 树，它从叶子节点（树的底部）开始，一个叶子节点就是一个交易哈希。叶子节点的数量必须是双数，但是并非每个块都包含了双数的交易。如果一个块里面的交易数为单数，那么就将最后一个叶子节点（也就是 Merkle 树的最后一个交易，不是区块的最后一笔交易）复制一份凑成双数。

从下往上，两两成对，连接两个节点哈希，将组合哈希作为新的哈希。新的哈希就成为新的树节点。重复该过程，直到仅有一个节点，也就是树根。根哈希然后就会当作是整个块交易的唯一标示，将它保存到区块头，然后用于工作量证明。

代码实现

package main

import (
    "bufio"
    "crypto/sha256"
    "fmt"
    "os"
    "strconv"
)

//默克尔树节点结构体
type Node struct {
    Index    int
    Value    string
    RootTree *MHTree
}

//默克尔树结构体
type MHTree struct {
    Length   int
    Nodes    []Node
    rootHash string
}

//获得默克尔树根节点哈希值
func (t *MHTree) GetRootHash() string {
    //不管是否存储，都重新计算哈希值
    t.rootHash =   t.Nodes[1].getNodeHash()                            
    return t.rootHash
}

//计算默克尔树中某个节点的哈希值
func (n *Node) getNodeHash() string {
    //叶子节点，则直接计算该节点Value的哈希值
    if n.Value != "" {
        return calDataHash(n.Value)
    }
    //非叶子节点，则递归计算哈希值,其为2个子节点哈希值的哈希值123123123123
    return calDataHash(n.RootTree.Nodes[n.Index*2].getNodeHash() + n.RootTree.Nodes[n.Index*2+1].getNodeHash()
        )                                                         

//计算数据的哈希值
func calDataHash(data string) string {
    hash := sha256.New()
    hash.Write([]byte(data))
    return string(hash.Sum(nil))
}

//从结构化文件创建默克尔树
func CreateMHTree(fileName string) MHTree {
    var tree MHTree
    //打开文件
    file, err := os.Open(fileName)
    if err != nil {
        panic(err)
    }
    defer file.Close()
    //获取读取器
    buf := bufio.NewReader(file)
    //读取首行，获得叶子节点数目（要求叶子节点数目为2的整数次幂
    dataCountStr, _, _ := buf.ReadLine()
    dataCount, _ := strconv.Atoi(string(dataCountStr))

    //判断幂次
    level := 0
    for i := 1; ; i++ {                                          
        if 2<<i == dataCount {
            level = i
            break
        }
    }
    //创建默克尔树

    //给非叶子节点赋值
    for i := 1; i <= 2<<level-1; i++ {                               
        tree.Nodes[i].Index = i
        tree.Nodes[i].RootTree = &tree
    }
    //读取文件数据，给叶子节点赋值
    for i := 2 << level; i < tree.Length; i++ {                  
        str, _, _ := buf.ReadLine()
        tree.Nodes[i].Index = i
        tree.Nodes[i].RootTree = &tree
        tree.Nodes[i].Value = string(str)
    }
    return tree
}

func main() {
    var fileName string

    fmt.Println("请输入原始数据文件名称")
    fmt.Scanln(&fileName)
    mhTree1 := CreateMHTree(fileName)
    fmt.Println("请输入比对数据文件名称")
    fmt.Scanln(&fileName)
    mhTree2 := CreateMHTree(fileName)

    hash1 := mhTree1.GetRootHash()
    hash2 := mhTree2.GetRootHash()

    if hash1 == hash2 {
        fmt.Println("用户没有改变数据")
    } else {
        fmt.Println("用户改变了数据")
    }

}

转载自：https://learnblockchain.cn/article/5364

0.简介

在这个系列的教程中，我们将学习如何调试和逆向 EVM 智能合约。

你可能已经知道，当一个智能合约在区块链中没有被验证时，你无法读取它的实体代码，只有字节代码被显示。

问题是很难从字节码中完全 "反编译（de-compile）"，以重建编译前的solidity代码。

但是不用担心，在这一系列的教程中，我将清楚地教你所有的技术，以逆向区块链中的任何智能合约。
与不知道的人相比，学习这项技术有几个好处：

你将能够阅读不透明的智能合约(即使源代码没有被验证)。
你会对EVM有深刻的理解，从而成为一个更好的开发者/智能合约审计。(从而赚更多的钱:))。
你会在你的智能合约中更有效地调试代码，避免在出现错误时浪费大量的时间。(特别是如果顶层错误是通用的，如："执行被回退（Execution reverted）")

本文是关于通过逆向和调试理解EVM系列的第1篇，本系列包含 7 篇文章：

• 第1篇：理解汇编
• 第2篇：部署智能合约
• 第3篇：存储布局是如何工作的？
• 第4篇：结束/中止执行的5个指令
• 第5篇：执行流 if/else/for/函数
• 第6篇：完整的智能合约布局
• 第7篇：外部调用和合约部署

1. 简介

下面是我们将进行逆向/调试的智能合约：

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

contract Test {  

   function test() external {      } 

   function test2() external {      }  

   function test3() external {      }  
}

看上去很简单，对吗？

是的，我们就从简单合约开始。

1. 在Remix IDE中编译（0.8.7版） https://remix.ethereum.org
   

2. 部署（选择JavaScript London虚拟机）
   

3. 调用 test() 函数并点击蓝色的调试按钮，以显示调试器。
   

4. 一旦完成，你应该在Remix中看到调试标签。
   

我们90%的工作将在这里进行。
在深入研究这个问题之前，这里有一些前备知识，你需要了解：

• 一些solidity开发经验
• 十六进制数字和基本的计算机科学知识
• Remix IDE的基础知识。
• 兴趣和可能（很多）的咖啡。

2. 什么是字节码/汇编？

每个智能合约都是由字节码构成的，例如，这是我们在文章开头创建的智能合约的字节码（十六进制）：

0x6080604052348015600f57600080fd5b5060043610603c5760003560e01c80630a8e8e0114604157806366e41cb7146049578063f8a8fd6d146051575b600080fd5b60476059565b005b604f605b565b005b6057605d565b005b565b565b56fea2646970667358221220d28f98515dc0855e1c6f5aa3747ff775f1b8ab6545f14c70641ff9af67c2465164736f6c63430008070033

这个字节码的每一个字节都对应着汇编语言中的一条指令。你可能已经知道，EVM并不直接理解solidity语言，它只理解汇编中的指令，这是一种低级语言。

在编译的时候，编译的作用只是把 solidity 代码翻译成汇编代码。
汇编是一种非常原始的 "语言"，只有指令和参数， 例如：

000 PUSH 80
041 PUSH1 00
056 DUP1

智能合约中第00字节（第一个指令）的指令是PUSH 80（在字节码操作码中翻译为6080）。
第41字节的指令是PUSH1 00（并且有1个参数是00）（在字节码操作码中是6000）。
第56字节的指令是DUP1 没有参数（字节码操作码为80）。

在后面，我们将逐步解释这些指令的内部作用。
在EVM中，大约有100条有效指令，有些是很容易猜到其含义，比如：

• ADD/SUB/OR/XOR
• 但其他的则需要更多的解释。

提示。每次有不明白的指令，你可以去https://www.ethervm.io/，这个网站总结了所有以太坊指令，显示了参数和返回值。

3. Solidity中的存储

你可能已经知道，在solidity中有3种类型的存储。
solidity中有3种类型的存储。

• 存储（storage），直接存储在区块链中，使用32字节数字 "槽（slot）"来标识，。一个槽的大小是32个字节（或64个十六进制数字）。
• "内存（memory）"，在智能合约执行结束时被清除，由一个名为 "十六进制数字 "的地址来标识。
• 还有栈，它是一个LIFO（后进先出）类型的队列，当每个项由一个数字标识(以0开始)。

4. LIFO栈是如何工作的？

默认情况下，在智能合约开始的时候，堆栈是空的，它包含的内容是不存在的!
现在有2种方法可以操作堆栈，可以通过使用指令PUSH或POP。

4.1 PUSH

它将数据推在第0位，并将每个数据往前推1个位置。例如，如果我们使用PUSH指令在堆栈中写入0xff。

Stack before (3 elems): |Place 0: 0x50|Place 1: 0x17|Place 2: 0x05|
----------------------------
Stack after PUSH ff: |Place 0: 0xff|Place 1: 0x50|Place 2: 0x17|Place 3: 0x05|

0xff被写在0位，0x50从0位到1位，0x17从1位到2位，0x05从2位到3位，现在栈包含4个元素而不是3个。

让我们看看另一个例子:

Stack before (0 elems, empty): ||
----------------------------
Stack after PUSH 33: |Place 0: 0x33|

堆栈现在包含1个元素。最后一个例子:

Stack before (0 elems, empty): |Place 0: 0x33|
----------------------------
Stack after PUSH 00: |Place 0: 0x00|Place 1: 0x33|

堆栈现在包含2个元素，就像这样简单。

4.2 POP

POP指令，做逆向操作：弹出第0槽中的数据，并将每个数据向后推1槽。

Stack before (3 elems): |Place 0: 0x50|Place 1: 0x17|Place 2: 0x05|
----------------------------
Stack after POP (2 elems): |Place 0: 0x17|Place 1: 0x05|

第0位的数据被删除了，0x17的位置从1位变成了0位，同样，0x05的位置从2位变成了1位。栈现在包含2个元素

下面是另一个例子：

Stack before (1 elems): |Place 0: 0x33|
----------------------------
Stack before POP (0 elems, empty): ||

如果你理解了这一点，也就这么简单。你理解了LIFO类型的存储，你就可以更进一步了:)

在EVM（以及其他汇编）中，堆栈通常用于存储函数和指令的参数 + 返回值。

在这个系列的文章中，我们将使用以下表示:

• Stack(0) = 堆栈中的第一个值（在位置0）。
• Stack(1) = 堆栈中的第二个值（在位置1处）。
• Stack(n) =堆栈中的第n+1个值（在位置n处）。

每次我解释一条指令时，堆栈的内容以这种格式： |0x15|0x25|0x00| , 这里：

• 0x15是Stack(0)，是堆栈中的第一个值，位置为0
• 0x25是Stack(1)，是Stack的第二个值
• 0x00是Stack(2)。
• 以此类推，如果堆栈里有更多的值的话

5. 汇编的第一行

一旦你理解了这些概念，现在就可以开始了， 点击下面的按钮，重新启动智能合约的执行：（默认情况下，remix在函数test()的开始处启动调试会话，因为在执行函数之前有一些代码，我们需要改变这一点）

如果一切顺利，第一批指令应该弹出，可以通过点击这些箭头在指令之间逐一导航。

第一条指令是：

000 PUSH 80 | 0x80 |
002 PUSH 40 | 0x40 | 0x80 |
004 MSTORE  ||

EVM在堆栈中PUSH 80和PUSH 40，结果它看起来像：
| 0x40 | 0x80 |。
在第4字节：MSTORE需要2个参数（offset，value）： Stack(0) 和 Stack(1)
MSTORE将Stack(1)的值存储在内存中的Stack(0)位置中。

因此，EVM将0x80存储在内存的0x40地址，在调试标签的内存部分，你应该看到：

由于内存中的每一个插槽都是32个字节的长度（使用小端序的十六进制0x20），因此插槽40的内存位于0x40和0x40+0x20=0x60之间（我们将其记为内存[0x40:0x60]。

这就是为什么0x80在最后（0x5f位置）。

“????? "是内存中的字节的ASCII表示。

内存中的 "0x40 "槽在EVM中被命名为空闲内存指针，当需要内存时，它被用来分配内存的新槽。(我将在后面解释为什么它是有用的）。

重要的是：注意在一条指令之后，堆栈中所有需要的参数都会从堆栈中清除，并被返回值所取代。

由于MSTORE在堆栈中占用了2个参数，在MSTORE指令完成后，这2个参数会从堆栈中删除。

所以堆栈现在什么都不包含。

6. MSG.VALUE

005 CALLVALUE |msg.value|
006 DUP1      |msg.value|msg.value|
007 ISZERO    |0x01|msg.value|
008 PUSH1 0f  |0x0f|0x01|msg.value|
010 JUMPI     |msg.value|
011 PUSH1 00  |0x00|msg.value| (if jumpi don't jump to 0f)
013 DUP1      |0x00|0x00|msg.value|
014 REVERT 

CALLVALUE指令把msg.value（发送给智能合约的以太币）放在堆栈中。
由于我们没有向智能合约发送任何以太币，堆栈中的值是：| 0x00 |

DUP1指令将Stack(0)推入堆栈，我们可以说它 "复制"了堆栈开头的第一个指令：
|0x00 |0x00 |

注意还有DUP2, DUP3...DUPn(直到DUP16)，它们将第n个值(Stack n-1)推到堆栈中。

而EVM在第7字节调用ISZERO，ISZERO使用Stack中的1个参数（它是Stack(0)）。

顾名思义，ISZERO验证Stack(0)是否等于0，如果是，EVM在第一个槽中推送 "1 "的值，即True。
| 0x01 | 0x00 |

EVM还删除了第一个0x00，因为它是ISZERO的参数。

之后在第8个指令，EVM将0x0f推到堆栈中 ： | 0x0f | 0x01 | 0x00 |。

接下来我们有一个条件跳转(JUMPI)，如果Stack(1)是1，EVM直接进入字节数Stack(0)所在的位置(因为Stack(0)=0f，十进制15），因此Stack(1)=1，EVM直接跳转到第15个指令

如果不是，EVM继续执行它的路径，执行PUSH**、DUP1和最后在第14字节的REVERT指令一样，以一个错误停止执行。

但是在这里，一切都很好！因为Stack(1)=1，所以在执行过程中会出现错误。由于Stack(1)=1，所以EVM跳到了0x0f（相当于15的十进制）。

我们将尝试理解在第5个指令和第14个指令之间发生了什么。

请注意，我们声明函数test()是非 payable 的，而且合约中没有receive()或fallback()函数可以接收以太币。

因此，这个合约不能接收到任何以太币（除了一个特定的情况，但在这里并不重要），所以如果我们发送以太币，它就会回退！。汇编中的代码相当于:

005 CALLVALUE load msg.value
006 DUP1      duplicate msg.value
007 ISZERO    verify if msg.value is equal to 0
008 PUSH1 0f  push 0f in the Stack (the byte location after the REVERT byte location)
010 JUMPI     jump to this location if msg.value is not equal to 0
011 PUSH1 00  push 00 in the Stack
013 DUP1      duplicate 00 in the Stack
014 REVERT    revert the execution

用 Solidity 表示，等价于:

if (msg.value > 0) { 
   revert(); 
} else {
   // Jump to byte 15
}

所以这第二部分的代码只是验证是否有任何以太币发送到合约中，否则它就会被回退。

在第15个指令时，堆栈为 | 0x00 | (因为JUMP在堆栈中使用了2个参数，EVM将它们删除)

7. CALLDATASIZE

015 JUMPDEST     | 0x00 |
016 POP          ||
017 PUSH1 04     | 0x04 |
019 CALLDATASIZE | msg.data.size | 0x04 |
020 LT           | msg.data.size > 0x04 |
021 PUSH1 3c    | 0x3c | msg.data.size > 0x04 |
023 JUMPI        || (JUMPI takes 2 arguments)060 JUMPDEST     ||
061 PUSH1 00     |0x00|
063 DUP1         |0x00|0x00|
064 REVERT       ||

JUMPDEST没有任何作用。它只是表示一条JUMP或JUMPI指令指向这里，如果EVM跳到一个没有标记为 "JUMPDEST"的地址(比如16号是POP)，它就会自动回退。

接下来，EVM将堆栈的最后一个元素POP出来，然后PUSH 04，因此在第17个指令之后，堆栈内只有一个元素： | 0x04 |

EVM调用CALLDATASIZE，等于msg.data.size（以太坊交易中数据字段的大小），现在堆栈是：| 0x04 | 0x04 |

(当一个函数被调用时没有参数msg.data.size = 4，这4个字节被称为函数 "签名")

例如这里msg.data等于"0x12345678"，msg.data.size=4（8个十六进制数字）。

后来在第20个指令，EVM调用LT（小于），它比较堆栈上的两个值（如果Stack(0) < Stack(1)，那么我们写1，否则写0）。

在我们的例子中，它是假的! 4不小于4（运算符LT是严格的）。

所以EVM不会跳到3c（因为Stack(0) = 3c和Stack(1) = 0），EVM继续执行流程，就像什么都没发生一样。

但是如果CALLDATASIZE小于4（如0、1、2或3），那么Stack(1)=1，然后EVM跳到0x28（十进制的40），EVM 回退 !

下面是发生的情况：

015 JUMPDEST     
016 POP           pop
017 PUSH1 04      store 0x04 in the stack
019 CALLDATASIZE  get msg.data.size in the stack
020 LT            verify if msg.data.size < 0x04
021 PUSH1 3c      push 0x3c (60 in dec)
023 JUMPI         jump to 60 if msg.data.size < 0x04060 JUMPDEST     
061 PUSH1 00     
063 DUP1         
064 REVERT        revert the execution

这意味着msg.data不能小于4，你会在下一节明白为什么!

if (msg.data.size < 4) { revert(); }

8. 函数选择器

一旦所有事先验证完成。

我们需要调用函数test()并执行它的代码。但在我们的合约中有几个函数（test() test2() 和 test3()），如何找出EVM需要执行的函数呢？

这就是函数选择器的作用。

下面是接下来的反汇编步骤

024 PUSH1 00 |0x00| (the stack was previously empty in byte 23)
026 CALLDATALOAD |0xf8a8fd6d0000000.60zeros.000000000|
027 PUSH1 e0 |0xe0|0xf8a8fd6d0000000.60zeros.000000000|
029 SHR |0xf8a8fd6d|
030 DUP1 |0xf8a8fd6d|0xf8a8fd6d|
031 PUSH4 0a8e8e01 |0x0a8e8e01|0xf8a8fd6d|0xf8a8fd6d|
036 EQ |0x0|0xf8a8fd6d|0xf8a8fd6d| 
037 PUSH1 41 |0x41|0x1|0xf8a8fd6d|
039 JUMPI |0xf8a8fd6d|
040 DUP1 |0xf8a8fd6d|0xf8a8fd6d|
041 PUSH4 66e41cb7 |0x66e41cb7|0xf8a8fd6d|0xf8a8fd6d|
046 EQ |0x0|0xf8a8fd6d|
047 PUSH1 49 |0x49|0x1|0xf8a8fd6d|
049 JUMPI |0xf8a8fd6d|
050 DUP1 |0xf8a8fd6d|0xf8a8fd6d|
051 PUSH4 f8a8fd6d |0xf8a8fd6d|0xf8a8fd6d|0xf8a8fd6d|
056 EQ |0x1|0xf8a8fd6d|
057 PUSH1 51 |0x51|0x1|0xf8a8fd6d|
059 JUMPI |0xf8a8fd6d|

你可能已经知道什么是以太坊的函数签名：它是函数名称的哈希值的前4个字节，对于test()来说，它是 ：

bytes4(keccak256(”test()”)) = 0xf8a8fd6d

CALLDATALOAD 接受1个参数Stack(0)作为偏移量，并将msg.data之后的在参数位置（这里是Stack(0)）的下一个32字节存储在堆栈中Stack(0)

在此案例中，它存储msg.data的前32字节（因为Stack(0) = 0）。

但只有4个字节（如前所述），因此堆栈将是这样的：
| 0xf8a8fd6d00000000000000000000000000000000000000000000000000000 |

下一个操作码是PUSH e0和SHR位于第27指令（使用2个参数），它通过Stack(0)（这里是c0）向右（>>）执行二进制移位，堆栈（在SHR之前）的值为：

|0xc0|0xf8a8fd6d00000000000000000000000000000000000000000000000000000 |

下面是用SHR进行的详细计算（如果你愿意可以跳过）：

A place in stack is of length 32 bytes = 256 bits

In binary Stack(1) = 11111000101010001111110101101101 and 192 zeros after that

c0 = 192 in decimal, so we will shift 192 time to the right

0 times   : 11111000101010001111110101101101..... + 192 zeros
1 times   : 011111000101010001111110101101101.... + 191 zeros
2 times   : 0011111000101010001111110101101101... + 190 zeros
192 times : 192 zeros + 0011111000101010001111110101101101...

= 0x00000000000000000000000000000000000000000000000000000f8a8fd6d
= 0x00..60zeros00f8a8fd6d

在DUP操作码之后，堆栈看起来像| 0xf8a8fd6d | 0xf8a8fd6d |。

值得注意的是，这就是我们的test()签名，这很正常！函数的签名总是出现在交易数据的前4个字节中。

在以太坊交易中，我们不会直接发送要执行的函数的名称，而只是发送4个字节的签名。

在第31个操作码中，EVM PUSH一个4字节的值到堆栈：0a8e8e01

| 0xa8e8e01 | 0xf8a8fd6d | 0xf8a8fd6d |

并调用EQ，比较（Stack(0)和Stack(1)）。

这两个值显然是不相等的：因此我们用0代替它们
| 0x0 | 0xf8a8fd6d |

这样我们就不会JUMP到41（65的十六进制）（后面有指令PUSH1 41和一个JUMPI）。

EVM对0x66e41cb7（操作码41到50）也做了同样的事情，这也不等于0xf8a8fd6d。

最后，EVM用0xf8a8fd6d来执行，由于现在等于0xf8a8fd6d! 所以我们跳到51（十六进制是81），这是test()函数的开始：

081 JUMPDEST |0xf8a8fd6d|
082 PUSH1 57 |0x57|0xf8a8fd6d|
084 PUSH1 5d |0x5d|0x57|0xf8a8fd6d|
086 JUMP |0x57|0xf8a8fd6d|
087 JUMPDEST |0xf8a8fd6d|
088 STOP ||
093 JUMPDEST |0x57|0xf8a8fd6d|
094 JUMP |0xf8a8fd6d|

你可以很容易地分析我们的test()函数中最后执行的8条指令。

它只执行了一系列的JUMP指令，在函数的最后，操作码STOP，它停止了合约的执行而没有产生错误。
所有这些代码的行为就像编程中的一个开关。

0xf8a8fd6d是 "test()"函数的签名
0x0a8e8e01和0x66e41cb7是test2和test3函数的签名。

如果交易数据中的签名与这些签名之一相符，那么通过跳转到函数的代码位置（代码中的41，49和51）来执行函数的代码。

否则。如果交易数据中的签名与代码中的任何函数签名不匹配，EVM将调用回退函数，但在我们的智能合约中没有这样的函数（至少现在没有）！因此：EVM将重新调用回退函数。结果是：EVM回退，故事到此结束。

这是59（函数选择器开关）之后的代码：

060 JUMPDEST
061 PUSH1 00
063 DUP1
064 REVERT

因此，我们可以重构智能合约的完整代码：

mstore(0x40,0x80)                              
if (msg.value > 0) { revert(); }                              
if (msg.data.size < 4) { revert(); }
byte4 selector = msg.data[0x00:0x04]                                
switch (selector) {                               
   case 0x0a8e8e01:   // JUMP to 41 (65 in dec)   stop()
   case 0x66e41cb7:   // JUMP to 49 (73 in dec)   stop()
   case 0xf8a8fd6d:   // JUMP to 51 (85 in dec)   stop()
   default: revert();
stop()

我们完成了!

9. 总结

我们成功地学会了。

• 一些基本的EVM 汇编。
• EVM如何执行智能合约。
• 哪些代码在执行函数之前被执行。
• LIFO堆栈如何工作。
• remix调试器的基本使用。
• 函数选择器。
• 还有很多...

这个系列的第一篇关于通过调试理解EVM的内容就到此为止。我希望你在这里学到很多东西。

下一部分见!

这是我们关于通过调试理解EVM系列的第1部分，在这里你可以找到之前和接下来的部分。

转载自：https://learnblockchain.cn/article/4913

Solidity智能合约有关安全和代码质量标准的建议，在 BoringCrypto, Mudit Gupta, Runtime Verification, 和 ConsenSys Diligence 的工作基础上整理。

常规审查方法

• 阅读项目的文档、规范和白皮书，了解智能合约的作用。
• 在查看代码之前，先构建一个期望中的合约架构模型。
• 快速浏览一遍合约，感受项目架构，可以利用Surya这类工具。
• 将项目架构与期望中的合约架构模型进行比较，仔细检查不符合预期的部分。
• 创建威胁模型并列出理论上的高级攻击向量。
• 查看与价值交换相关的地方，尤其是transfer，transferFrom，send，call，delegatecall，和 selfdestruct。优先检查它们，确保安全。
• 查看与外部合约交互的地方，并确保所有关于它们的假设都是有效的，例如价格只会上涨等等。
• 对合约进行一般性的逐行审查。
• 从威胁模型中每个参与者的角度进行另一次审查。
• 快速浏览项目的测试 + 代码覆盖率，并深入了解缺乏覆盖率的地方。
• 运行 Slither/Solhint 等工具并审查其输出。
• 查看相关项目及其审计，以检查是否存在任何类似问题或疏忽。

变量（Variable）

• V1 - 变量可以是 internal 吗？
• V2 - 变量可以是 constant 吗？
• V3 - 变量可以是 immutable 吗？
• V4 - 是否设置了可见性？ (SWC-108)
• V5 - 变量的用途和其他重要信息是否使用 natspec 标准记录？
• V6 -可以与相邻的存储变量一起打包吗？
• V7 - 是否可以和其他变量打包在一个struct中？
• V8 - 使用完整的 256 位类型，除非与其他变量一起打包。
• V9 - 如果它是一个public array，是否提供了一个单独的函数来返回完整的数组？
• V10 - 使用更加灵活的internal，而不是private，除非有意阻止子合约访问变量。

结构体（Struct）

• S1 - 是否有必要用struct ？ 可以仅用原始存储变量打包吗？
• S2 - 字段是否打包在了一起 (如果可以) ？
• S3 - struct的用途和所有字段是否使用 natspec 标准进行文档记录 ？

函数（Function）

• F1 - 函数可以是 external 吗？
• F2 - 函数是否应该是 internal ？
• F3 - 函数是否应该是 payable ？
• F4 - 是否可以与另一个类似的函数合并？
• F5 - 验证所有参数都在安全范围内，即使该函数只能由受信任的用户调用。
• F6 - 是否遵循 check-before-effect 模式？ (SWC-107)
• F7 - 检查抢跑的可能性，例如授权方法（approve）。 (SWC-114)
• F8 - 是否会遭受恶意的 gas 不足攻击 ？ (SWC-126)
• F9 - 是否应用了正确的修改器，例如 onlyOwner/requiresAuth ？
• F10 - 返回值是否总是有赋值？
• F11 - 在一个函数能够正确运行之前，写下并测试关于状态的不变性检查（invariants）。
• F12 - 写下并测试关于函数运行后的返回值或任何状态变化的不变性检查。
• F13 - 命名函数时要注意，因为人们会根据名称来假设行为。
• F14 - 如果一个函数是故意unsafe（为了省gas等），使用一个不便的名字来引起人们对其风险的注意。
• F15 - 所有参数、返回值、副作用和其他信息是否用natspec文档记录？
• F16 - 如果函数允许对系统中的另一个用户进行操作，不要假设msg.sender是被操作的用户。
• F17 - 如果函数要求合约处于未初始化的状态，请检查一个明确的initialized变量。不要使用owner == address(0)或其他类似的检查作为替代。
• F18 - 只使用private来有意防止子合约调用该函数，为了灵活性，最好使用internal。
• F19 - 在合法（和安全）的情况，可能子合约希望覆盖该函数的行为，则使用virtual。

修改器（Modifier）

• M1 - 是否没有进行存储更新（重入锁除外）？
• M2 - 是否避免了外部调用？
• M3 - 修改器的用途和其他重要信息是否使用 natspec 标准文档记录？

代码

• C1 - 使用SafeMath或solidity 0.8 检查的数学？(SWC-101)
• C2 - 是否有任何存储槽被多次读取？
• C3 - 是否使用了任何可能导致DoS的无界循环/数组？ (SWC-128)
• C4 - 只对长间隔使用block.timestamp。(SWC-116)
• C5 - 不要使用block.number来表示经过的时间。(SWC-116)
• C7 - 尽可能避免委托调用，特别是对外部（即使是可信的）合约。(SWC-112)
• C8 - 在迭代数组时，不要更新其长度。
• C9- 不要使用blockhash()等来实现随机性。(SWC-120)
• C10 - 签名是否用nonce和block.chainid防止重放 (SWC-121)
• C11 - 确保所有签名使用EIP-712。(SWC-117 SWC-122)
• C12 - 如果需要对大于 2个动态类型进行 hash 时，一般情况下，最好使用abi.encode()而不是abi.encodePacked()的输出进行 hash。(SWC-133)
• C13 - 谨慎使用汇编，不要使用任何任意数据。(SWC-127)
• C14 - 不要假设一个特定的ETH余额. (SWC-132)
• C15 - 避免gas不足攻击。(SWC-126)
• C16 - 私有数据并不是私有的。(SWC-136)
• C17 - 在内存中更新结构体/数组不会在存储中修改它。
• C18 - 永远不要覆盖（shadow）状态变量。(SWC-119)
• C19 - 不要修改函数参数的值。
• C20 - 即时计算一个值是否比存储它更便宜？
• C21 - 所有的状态变量是否从正确的合约中读取（主合约与克隆合约）？
• C22 - 是否正确使用比较运算符（>, <, >=, <=），特别是防止缺位错误（off-by-one error）？
• C23 - 是否正确使用逻辑运算符(==, !=, &&, ||, !), 特别是防止缺位错误（off-by-one error）?
• C24 - 总是先乘后除，除非乘法可能溢出。
• C25 - 魔术数字是否由一个具有直观名称的常数代替？
• C26 - 如果ETH的接收者有一个fallback 函数，会不会造成DoS 攻击？ (SWC-113)
• C27 - 使用openzepplin SafeERC20或安全检查返回值 。
• C28 - 不要在循环中使用msg.value。
• C29 - 如果可能出现递归委托调用，不要使用msg.value（比如合约继承了Multicall/Batchable）。
• C30 - 不要假设msg.sender总是一个相关的用户。
• C31 - 不要使用assert()，除非用于模糊处理或形式验证。(SWC-110)
• C32 - 不要使用tx.origin进行授权。(SWC-115)
• C33 - 不要使用address.transfer()或address.send()。使用.call.value(...)("")代替。(SWC-134)
• C34 - 当使用低级调用时，确保调用前合约存在。
• C35 - 当调用一个有许多参数的函数时，使用命名参数的语法。
• C36 - 不要使用汇编来create2。更倾向于使用新式加salt合约创建语法。
• C37 - 不要使用汇编来访问chainid或合约代码/大小/哈希。更倾向于新式Solidity语法。
• C38 - 当设置一个变量为零值时（0，false，""等），使用delete关键字。
• C39 - 尽可能多地注释 "为什么" 要这样做。
• C40 - 如果使用晦涩的语法或编写非常规的代码，则注释在做 "什么"。
• C41 - 在复杂和定点数学运算的旁边注释解释+输入/输出的例子。
• C42 - 在做了优化的地方做注释，并估计它们能节省多少gas。
• C43 - 在特意避免某些优化的地方进行注释，并估计如果实施这些优化会/不会节省多少gas。
• C44 - 在溢出/下溢是不可能的，或者溢出/下溢在人类的时间尺度上是不现实的（计数器等），使用unchecked块。在使用unchecked的地方进行注释，同时估计它能节省多少gas（如果相关）。
• C45 - 不要依赖Solidity的算术运算符优先级规则。括号不仅用来覆盖默认运算符优先级，而且可以用于强调它。
• C46 - 传递给逻辑/比较运算符（&&/||/>=/=/等）的表达式不应该有副作用。
• C47 - 凡是进行可能导致精度损失的算术运算，都要确保它对系统中的正确角色有利，并用注释记录下来。
• C48 - 用注释来记录为什么必须使用重入锁的原因， 不管是行内或@dev 来记录 。
• C49 - 如果模糊函数仅支持特定范围的参数，使用取模操作限制参数输入范围（如x = x % 10000 + 1来限制在从1到10,000）。
• C50 - 尽可能使用三元表达式来简化分支逻辑。
• C51 - 当在一个以上的地址上操作时，问自己如果它们是相同的会怎样。

外部调用

• X1 -是否真的需要外部合约调用？
• X2 - 如果运行出现报错，是否会导致 DoS？比如 balanceOf() 回退。 (SWC-113)
• X3 - 如果调用重新进入当前函数是否有害？
• X4 - 如果调用重新进入另一个函数是否有害？
• X5 - 是否检查结果并处理了错误? (SWC-104)
• X6 - 如果用完所有提供的 gas 会发生什么?
• X7 - 如果它返回大量数据，会导致调用合约中的 out-of-gas 出错吗？
• X8 - 如果你调用特定函数时返回了 success，也不意味着该函数存在 (phantom functions) 。

静态调用（Static Call）

• S1 -是否真的需要外部合约调用？
• S2 - 在接口中是否应该标记为 view 吗？
• S3 - 如果运行出现报错，是否会导致 DoS？比如 balanceOf() 回退。 (SWC-113)
• S4 - 如果调用进入无限循环，是否会导致 DoS？

事件（Event）

• E1 - 是否应该对任何字段进行索引indexed ？
• E2 - 相关动作的创建者是否包括在索引字段中 ？
• E3 - 不要将包括string 和 bytes 的动态变量设为事件的 inedex。
• E4 - 触发事件的时机和事件变量是否使用 natspec 标准记录文档?
• E5 - 触发事件的函数中所有被操作用户/ID是否设为indexed字段？
• E6 - 避免函数调用和事件参数中使用表达式求值，他们的求值顺序是不可预测的。

合约

• T1 - 使用 SPDX 许可证标识符.
• T2 - 是否所有会修改 storage 变量的函数都触发了事件？
• T3 - 检查所有的继承是否正确，保证他们简洁且线性。 (SWC-125)
• T4 - 如果合约要接收 ETH， 使用 receive() external payable 函数。
• T5 - 写下并测试关于关联存储变量的不变性。
• T6 - 合约的目的和与其他合约的交互是否使用 natspec 标准记录文档？
• T7 - 如果另一个合约必须继承一个合约以解锁其全部功能，则否则应标记为 abstract。
• T8 - 如果构造函数中设置了非不可变量（non-immutable）的值，或在其他函数中被改变，都应该触发事件。
• T9 - 避免过度继承，因为它使得事情复杂化并可能鼓励过度抽象。
• T10 - 始终使用命名的导入语法来明确声明哪些合约是从另一个文件中导入的。
• T11 - 按文件夹/包将引入进行分组，每组之间空一行，外部依赖组放在开头，然后是模拟/测试合约（如有），最后是本地导入。
• T12 - 使用 natspec 标准中的 @notice 记录合约的目的和功能，@dev 记录合约如何与项目内部/外部的其他合约交互。

项目

• P1 - 使用正确的许可证书 （例如如果你依赖GPL协议包，你也要用GPL）。
• P2 - 单元测试所有内容。
• P3 - 尽可能多的模糊测试。
• P4 - 尽可能的使用符号执行。
• P5 - 运行 Slither/Solhint 并审查所有发现。

DeFi

• D1 - 检查你对其他合约作用和返回值的假设。
• D2 - 不要混淆内部计算值与账户实际余额。
• D3 - 不要将 AMM 的现货价格用作价格预言机。
• D4 - 如果没达到链下或预言机的价格目标，不要在 AMM 上进行交易。
• D5 - 使用完备的检查来防止预言机/价格操纵。
• D6 - 要注意 rebasing 代币。如果它们不受支持，要在文档中明确说明。
• D7 - 要注意 ERC-777 代币，即使是你信任的代币也可以被重入。
• D8 - 要注意转账收税的代币，如果它们不受支持，要在文档中明确说明。
• D9 - 要注意使用太大或太小 decimial 的代币，要在文档中明确支持decimial 的最大值和最小值。
• D10 - 要注意依赖原始代币余额来确定收益的合约，直接向合约发送资产，可能会打乱依靠地址的原始以太或代币余额的价格计算功能。
• D11 - 如果你的合约是代币授权的目标地址，请不要根据用户输入随意调用。

原文： https://github.com/transmissions11/solcurity
转载自：https://learnblockchain.cn/article/5329

原文：https://roadmap.sh/blockchain

什么是zkEVM？

Polygon zkEVM是第一个开源的zk-Rollup，以太坊提供安全性保证、 完整的EVM操作码等价，确保无摩擦的用户体验。
github: https://polygon.technology/solutions/polygon-zkevm

-- 它是一个与Polygon Matic POS不同的网络吗？
是的，它是一个完全不同的网络，有自己的代币和钱包配置。

-- 这是否意味着它使用自己的代币？
是的，它使用自己的原生代币，而不是Matic或Mumbai Testnet代币。

-- EVM 等价（EVM-equivalence） 是什么意思？
等价指的是Type2 ZK-EVM，Vitalik 博客：不同类型的 ZK-EVMs 对其有更好的定义。

Type2 ZK-EVMs努力做到完全等同于EVM，但不完全等同于以太坊。也就是说，它们 "从内部 "看起来和以太坊完全一样，但它们在外部有一些差异，特别是在数据结构上，如块结构和状态树。
https://vitalik.eth.limo/general/2022/08/04/zkevm.html

-- 对于开发者来说
这意味着你可以部署你现有的solidity代码，而不需要通过任何额外的步骤来编译你的代码，让它在这个网络上工作。与其他ZK-EVM解决方案相比，Type 2提供了一种更简单的方式与该ZK-EVM解决方案结合。

目标是与现有的应用程序完全兼容，但对以太坊做一些小的修改，使开发更容易，并使证明生成更快。

了解了这些， 让我们开始吧

钱包配置

需要注意的是，这些信息有很多已经存在于官方的Polygon Wiki For zkEVM，当zkEVM主网可用时，这些设置可能会改变。
zkEVM的钱包配置在Chainlist.org上吗？很遗憾还没有，因为网络配置和端口号可能会改变。

我们对zkEVM Testnet的配置设置如下：

• 网络名称： Polygon zkEVM Testnet
• rpc网址： https://rpc.public.zkevm-test.net
• 链的ID: 1402
• 货币符号: ETH
• 区块链浏览器网址: https://explorer.public.zkevm-test.net

你可以通过进入网络，手动添加一个网络，将其添加到当前的MetaMask钱包：
MetaMask手动添加一个网络

使用Polygon zkEVM Testnet配置MetaMask

让我们看看在zkEVM浏览器上的钱包信息：

https://explorer.public.zkevm-test.net/address/0xB3f03B93F0bd65B960EE950d9aFC6867D461C33f

从水龙头获取测试代币

与其他Testnet网络相比，zkEVM获得测试代币的方式有点不同。你需要先获得Goerli Testnet代币，然后将它们桥接到zkEVM。
我们将使用QuickNode Goerli Faucet，但你也可以使用从以下任何一个链接获取：

• QuickNode Goerli Testnet Faucet
• AlchemyGoerli Testnet Faucet

一旦我们有了Goerli Testnet代币，我们需要通过使用https://public.zkevm-test.net/， 将它们桥接到zkEVM Testnet上。

连接你喜欢的钱包，确保网络设置为以太坊 Goerli，输入需要桥接的金额，然后点击继续。

确认桥接交易:

通过切换到zkEVM，然后确认交易，最终完成交易。

如果交易成功，你应该有一个确认屏幕，并在区块浏览器上看到结果。

将ERC20合约部署到zkEVM Testnet上

接下来，我们要用Hardhat来设置和部署ERC20合约到zkEVM。

安装依赖

请确保在你的电脑上事先安装好以下依赖：

• nvm或node v18.12.1
• pnpm v7.15.0

设置Hardhat

我们要做的第一件事是创建一个新的项目文件夹，启动pnpm，安装Hardhat，并对其进行配置：

mkdir zkevm-erc20;
cd zkevm-erc20;
git init;
pnpx hardhat;

# Expected Prompts
# 888    888                      888 888               888
# 888    888                      888 888               888
# 888    888                      888 888               888
# 8888888888  8888b.  888d888 .d88888 88888b.   8888b.  888888
# 888    888     "88b 888P"  d88" 888 888 "88b     "88b 888
# 888    888 .d888888 888    888  888 888  888 .d888888 888
# 888    888 888  888 888    Y88b 888 888  888 888  888 Y88b.
# 888    888 "Y888888 888     "Y88888 888  888 "Y888888  "Y888
#
#  Welcome to Hardhat v2.12.3 
#
# ? What do you want to do? …
#   Create a JavaScript project
# ❯ Create a TypeScript project
#   Create an empty hardhat.config.js
#   Quit

# ? Hardhat project root: › /path/to/zkevm-erc20

# ? Do you want to add a .gitignore? (Y/n) › y

# ? Do you want to install this sample project's dependencies with npm (@nomicfoundation/hardhat-toolbox)? (Y/n) › y

pnpm install;

让我们通过运行一个节点，部署默认的合约，然后测试该合约，来仔细检查我们的Hardhat设置是否按预期工作。

在终端1

# FROM: ./zkevm-erc20

./node_modules/.bin/hardhat node;

# Expected Output:
# Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/
# 
# Accounts
# ========
# 
# WARNING: These accounts, and their private keys, are publicly known.
# Any funds sent to them on Mainnet or any other live network WILL BE LOST.
# ...

在终端2

将 "Lock.sol" 合约部署到我们正在运行的本地节点：

# FROM: ./zkevm-erc20

./node_modules/.bin/hardhat run scripts/deploy.ts

# Expected Output:
# Compiled 1 Solidity file successfully
# Lock with 1 ETH and unlock timestamp 1701595951 deployed to 0x5FbDB2315678afecb367f032d93F642f64180aa3

运行由原始脚手架项目生成的测试：

# FROM: ./zkevm-erc20

./node_modules/.bin/hardhat test;

# Expected Output:
#   Lock
#     Deployment
#       ✔ Should set the right unlockTime (894ms)
#       ✔ Should set the right owner
#       ✔ Should receive and store the funds to lock
#       ✔ Should fail if the unlockTime is not in the future
#     Withdrawals
#       Validations
#         ✔ Should revert with the right error if called too soon
#         ✔ Should revert with the right error if called from another account
#         ✔ Shouldn't fail if the unlockTime has arrived and the owner calls it
#       Events
#         ✔ Should emit an event on withdrawals
#       Transfers
#         ✔ Should transfer the funds to the owner
#
#  9 passing (1s)

创建一个ERC20合约

我们将以OpenZeppelin的ERC20 Solidity合约为基础，它将创建初始10,000个代币的代币，并允许所有者铸造更多的代币。

添加依赖

# FROM: ./zkevm-erc20

pnpm add -D @openzeppelin/contracts;

配置ERC20

使用OpenZepplin Wizard来配置ERC20代币：

编写新的合约

重命名现有的Lock.sol为zkerc20.sol，并用我们从OpenZeppeling向导中生成的代码替换它：

# FROM: ./zkevm-erc20

mv ./contracts/Lock.sol ./contracts/zkERC20.sol;

文件： ./contracts/zkERC20.sol：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract ZkERC20 is ERC20, Ownable {
    constructor() ERC20("zkERC20", "ZK20") {
        _mint(msg.sender, 10000 * 10 ** decimals());
    }

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }
}

测试ERC20合约

首先我们要为我们的ERC20合约做一个单一的测试，然后验证它是否正常工作。

部署脚本

首先，我们需要修改我们的部署脚本，以考虑到新的合约名称。

文件： ./scripts/deploy.ts。

// Imports
// ========================================================
import { ethers } from "hardhat";

// Main Deployment Script
// ========================================================
async function main() {
  // Make sure in the contract factory that it mateches the contract name in the solidity file
  // Ex: contract ZkERC20
  const zkERC20Contract = await ethers.getContractFactory("ZkERC20");
  const contract = await zkERC20Contract.deploy();

  await contract.deployed();

  console.log(`ZkERC20 deployed to ${contract.address}`);
};

// Init
// ========================================================
// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

创建测试

接下来要把Lock.ts测试文件重命名为zkERC20.test.ts，并添加一个测试，确认铸造erc20代币的总余额：

# FROM: ./zkevm-erc20

mv ./test/Lock.ts ./test/zkERC20.test.ts;

文件： ./test/zkERC20.test.ts：

// Imports
// ========================================================
import { loadFixture } from "@nomicfoundation/hardhat-network-helpers";
import { expect } from "chai";
import { ethers } from "hardhat";

// Tests
// ========================================================
describe("zkERC20", function () {
  // We define a fixture to reuse the same setup in every test.
  // We use loadFixture to run this setup once, snapshot that state,
  // and reset Hardhat Network to that snapshot in every test.
  async function deployZkERC20() {
    // Contracts are deployed using the first signer/account by default
    const [owner, otherAccount] = await ethers.getSigners();
    // Make sure in the contract factory that it mateches the contract name in the solidity file
    // Ex: contract ZkERC20
    const zkERC20Contract = await ethers.getContractFactory("ZkERC20");
    const zkERC20 = await zkERC20Contract.deploy();

    return { zkERC20, owner, otherAccount };
  };

  /**
   * 
   */
  describe("Deployment", function () {
    /**
     * 
     */
    it("Should deploy with initial 10,000 supply", async function () {
      // Setup
      const { zkERC20 } = await loadFixture(deployZkERC20);

      // Init + Test
      expect(await zkERC20.totalSupply()).to.equal(ethers.utils.parseEther(`10000`).toString());
    });
  });

  /**
   * 
   */
   describe("Minting", function () {
    /**
     * 
     */
    it("Should mint and increase the supply by 137", async function () {
      // Setup
      const { zkERC20, owner } = await loadFixture(deployZkERC20);

      // Init
      await zkERC20.connect(owner).mint(owner.address, ethers.utils.parseUnits('137', 18));

      // Init + Test
      expect(await zkERC20.totalSupply()).to.equal(ethers.utils.parseEther(`10137`).toString());
    });
  });
});

让我们运行Hardhat节点并测试这个合约。

在终端1

运行一个本地节点：

# FROM: ./zkevm-erc20

./node_modules/.bin/hardhat node;

# Expected Output:
# Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/
# 
# Accounts
# ========
# 
# WARNING: These accounts, and their private keys, are publicly known.
# Any funds sent to them on Mainnet or any other live network WILL BE LOST.
# ...

在终端2

运行测试：

# FROM: ./zkevm-erc20

./node_modules/.bin/hardhat test;

# Expected Output:
#   zkERC20
#     Deployment
#       ✔ Should deploy with initial 10,000 supply (803ms)
#     Minting
#       ✔ Should mint and increase the supply by 137
#
#  2 passing (819ms)

部署ERC20合约

需要注意的是，目前Hardhat中不支持zkEVM的部署。为了部署你的合约，你需要使用以太坊 Remix的Injected Provider配置。

确保在remix中创建一个zkERC20.sol文件，其中包含上面的合约代码：

切换到编译部分，点击“编译按钮”，得到绿色的复选标记，表示一切编译正确。

切换到左侧导航栏的部署部分，将环境设置为 "Injected Provider - Metamask"。并确保你的钱包被设置为zkEVM网络。

准备好后，点击部署按钮，在你的钱包中确认交易。

在MetaMask中查看代币

打开MetaMask钱包，点击交易，在区块浏览器上查看该交易。在区块浏览器中点击合约地址，打开合约。在区块浏览器中加载合约后，复制合约地址。

打开你的MetaMask，点击Asset（资产），并点击Import tokens（导入代币）：

粘贴合约地址，并根据需要填写其他字段。它们可能会自动弹出，然后点击添加自定义代币：

现在你应该能够按照提示操作，然后在你的钱包里看到新的ZK20代币，并有正确的初始金额。

你已经完全部署了一个ERC20合约到Polygon Hermes zkEVM 测试网上。

完整的代码

zkEVM ERC20 代币的完整代码。请记住，目前还不支持Hardhat部署。
GitHub - codingwithmanny/zkevm-erc20

如果其他 zkEVM 教程，我们会及时更新，欢迎在 Twitter 关注 @登链社区 。

转载自：https://learnblockchain.cn/article/5349