智能合约opcode结构分析与ida静态调试
opcode简介
在学习和分析opcode的过程中，需要参照EVM OPCODEhttps://ethervm.io/#opcodes 。表格已经描述的比较清晰了：第一列是通过0x00～0xFF表示的opcode；第二列是对应的指令；第三列当前指令相关的输入参数（栈中）；第四列是执行当前指令的出参（栈中）；最后一列是表达式。
opcode分类
在以太坊官方黄皮书中，对OPCODE进行了相应的分类:
0s: Stop and Arithmetic Operations (从0x00-0x0f的指令类型是STOP指令加上算术指令)
10s: Comparison & Bitwise Logic Operations (0x10-0x1f的指令是比较指令和比特位逻辑指令)
20s: SHA3 (目前0x20-0x2f只有一个SHA3指令)
30s: Environmental Information (0x30-0x3f是获取环境信息的指令)*
40s: Block Information (0x40-0x4f是获取区块信息的指令)*
50s: Stack, Memory, Storage and Flow Operations (0x40-0x4f是获取栈、内存、储存信息的指令和流指令(跳转指令))*
60s & 70s: Push Operations (0x60-0x7f是32个PUSH指令，PUSH1-PUSH32)
80s: Duplication Operations (0x80-0x8f属于DUP1-DUP16指令)
90s: Exchange Operations (0x90-0x9f属于SWAP1-SWAP16指令)
a0s: Logging Operations (0xa0-0xa4属于LOG0-LOG4指令)
f0s: System operations (0xf0-0xff属于系统操作指令)
实际上结合参照表格，opcode还是比较容易理解的，就是需要多点时间和耐心去一一分析。这里挑其中几个获取环境信息的指令进行说明：
CALLVALUE向栈中压入msg.value，即在调用智能合约的函数时传入的value值；
CALLDATALOAD读取msg.data值从i开始往后32字节的值，并将该值压入栈中，覆盖i；
CALLDATASIZE读取msg.data的长度，并压入栈中；
CALLDATACOPY读取msg中的制定位子的数据存储到相应位子的内存中；
CODESIZE统计当前合约的代码字节码长度，压入栈中；
CODECOPY指定当前合约的代码片段存储内容中。
可以通过remix的debug功能验证以上的指令。
在上面我们提到了栈和内存，他们都是存储数据，有什么区别呢？
存储方式
在智能合约中有三种存储方式，分别是stack(栈)、memory(内存)、storage。
stack
在接触EVM的时候，一定看到过介绍说EVM是基于栈的，基于栈的虚拟机数据的存取为先进后出（也即后进先出），在debug的时候跟踪stack的内容就可以看出来。stack可以免费使用，没有 gas 消耗，用来保存函数的局部变量，数量被限制在了 16 个。
用于操作栈的指令有：
push：用从栈顶弹出一个元素
popX：把紧跟在后面的 1-32 字节元素推入栈顶，Push 指令一共 32 条，从 Push1）到 Push32，因为栈的一个字是 256bit，一个字节 8bit，所以 Push 指令最多可以把其后 32 字节的元素放入栈中而不溢出。
dupX：用来复制从栈顶开始的第 1-16 个元素，复制后把元素在推入栈顶，Dup 指令一共 16 条，从 Dup1到 Dup16。
swapX：把栈顶元素和从栈顶开始数的第 1-16 个元素进行交换，Swap 指令一共 16 条，从 Swap1一直到 Swap16。
memory
memory 是一个易失性的可以读写修改的空间，主要是在运行期间存储数据，将参数传递给内部函数。内存可以在字节级别寻址，一次可以读取 32 字节。
用于操作 memory 的指令有三个：
mload 加载一个字从 stack 到内存；
sstore 存储一个值到指定的内存地址，格式 mstore（p，v），存储 v 到地址 p；
mstore8 存储一个 byte 到指定地址 ；当我们操作内存的时候，总是需要加载 0x40，因为这个地址保存了空闲内存的指针，避免了覆盖已有的数据。
stroage
Storage 是一个可以读写修改的持久存储的空间，也是每个合约持久化存储数据的地方，存储消耗的gas费用最高。Storage 是一个巨大的 map，一共 2^256 个插槽，一个插糟有 32byte。注意，存储在storage中的值是可以通过外部接口直接读取的：
eth.getStorageAt(合约地址, slot)
# 该函数还有第三个参数，默认为"latest"，还可以设置为"earliest"或者"pending"，具体作用本文不做分析
EVM 提供的用于操作 storage 的指令有两个：
sload 用于加载一个字到 stack 中；
sstore 用于存储一个字到 storage 中；
opcode结构分析
Deconstructing a Solidity Contract —Part I: Introduction – OpenZeppelin blogDeconstructing a Solidity Contract — Part II: Creation vs. Runtime – OpenZeppelin blogDeconstructing a Solidity Contract — Part III: The Function Selector – OpenZeppelin blogDeconstructing a Solidity Contract — Part IV: Function Wrappers – OpenZeppelin blogDeconstructing a Solidity Contract — Part V: Function Bodies – OpenZeppelin blogDeconstructing a Solidity Contract — Part VI: The Metadata Hash – OpenZeppelin blog
该部分主要参考以上六篇blog，这六篇文章十分详细有条理的分析了一个合约编译后的opcode的结构，主要思路围绕这幅图：
将从一下几个方面对一个合约的opcode结构进行介绍：
总体介绍 —>Creation & Runtime —> 函数selector —> 函数 wrapper —> 函数体分析 —>元数据哈希