1. 引言

首先需了解以下基本概念：

1）区块链
2）世界状态
3）账号
4）交易
5）消息
6）去中心化账本
7）原子性和顺序性

1.1 何为以太坊区块链？

以太坊可看成是基于交易的状态机，交易代表了2个状态间的valid arc：
在这里插入图片描述
将多笔交易整理打包为区块，区块为package of data：

从状态的角度来看，可将以太坊看成是状态链（chain of states）：

从实现的角度来看，还可将以太坊看成是“BLOCKCHAIN”（chain of blocks）：

从账本的角度来看，还可将以太坊看成是“stack of transactions”：
在这里插入图片描述

1.2 何为世界状态？

世界状态（World state）为address与account state之间的mapping：
在这里插入图片描述
可从多个角度来看待world state：

mapping角度
table表格角度
object对象角度

在这里插入图片描述

1.3 何为账号？

账号（Account）为world state的object对象表示：
在这里插入图片描述

账号状态中可包含EVM code和Account storage：
在这里插入图片描述
以太坊中主要有2种账号状态：

Externally owned account（EOA）：由某个私钥控制。不允许包含EVM code。
Contract account（CA，合约账号）：包含了EVM code。由EVM code控制。

在这里插入图片描述

账号地址以160-bit code来表示：

1.4 何为交易？

交易为经密码学签名的单个指令：
在这里插入图片描述
交易由external actor来提交：

有两种实用的交易类型：

contract creation交易
message call交易

在这里插入图片描述

交易中包含的字段有：

nonce
gasPrice
gasLimit
to：若为contract creation交易，该值为0；否则为160 bit address。
value：为tranasferred wei（ether）
v, r, s：交易签名
init or data：contract creation 或 message call

1.4.1 contract creation交易

contract creation交易示意为：
在这里插入图片描述

1.4.2 message call交易

message call交易示意为：
在这里插入图片描述

1.5 何为message？

message的来源主要有：

由交易触发的关联消息
由EVM code触发的消息

在这里插入图片描述
消息之间的发送和接收方可分为以下四种场景：

1）由EOA通过交易发送消息给EOA
2）由EOA通过交易发送消息给CA
3）由CA通过EVM code发送消息给EOA
4）由CA通过EVM code发送消息给CA

在这里插入图片描述

1.6 何为去中心化账本？

区块链不仅为a globally shared, transactional database：
在这里插入图片描述
区块链还是a globally shared, 去中心化, transactional database：
由去中心化节点构成以太坊P2P网络：

external actors通过以太坊节点来访问以太坊世界：

不过，实际以太坊客户端是通过Web3 API来访问以太坊网络：
在这里插入图片描述

1.7 何为原子性和顺序性？

交易的原子性是指：

交易为原子式操作，无法分解或中断。
交易要么完全执行成功，要么完全失败。（All（complete done）or Nothing（zero effect））

在这里插入图片描述

交易的顺序性是指：

交易是无法重叠的
交易必须按顺序执行

在这里插入图片描述
不过，交易的顺序不是按交易发起时间来确定的，交易的顺序是无法保证的，由矿工来决定区块内的交易顺序：

同时，区块间的顺序则由共识算法（如PoW）来决定：

2. 虚拟机

以太坊虚拟机为stack-based, big-endian VM with a word size of 256-bits，并用于运行智能合约。智能合约与普通账号类似，只是当收到某交易时，智能合约会运行EVM bytecode，处理相应的计算以及后续交易。
EVM中的opcode有：
在这里插入图片描述
Contract execution starts at the beginning of the bytecode.
Each opcode is encoded as one byte, except for the PUSH opcodes, which take a immediate value.
All opcodes pop their operands from the top of the stack and push their result.

交易的payload可为0或一定字节数的data，用于定义与合约交互的类型即其它额外信息：

1）合约创建交易：
交易的data payload为所创建合约自身的bytecode，会运行合约的构造函数、设置合约初始状态、并返回最终的合约bytecode。即，一旦合约部署完毕，构造函数将不展示在合约中。
2）合约交互交易：
通常合约会暴露一个public API——为支持用户与合约交互的一组方法。
为与合约交互，用户将提交交易，交易内可包含任意wei数量（包括0），以及某格式与ABI匹配的data payload，定义了交互类型以及其他额外参数。
合约通常由4种方式来处理data：
- 1）Call Data：通常为：4字节的method identifier + 序列化的参数。相关指令有：CALLDATALOAD/CALLDATASIZE/CALLDATACOPY。
- 2）Stack：EVM会维护a stack of uint256s来保存本地变量、函数调用参数以及返回地址。区分返回地址与其它变量是复杂的。相关指令有：PUSH1/DUP1/SWAP1/POP等。
- 3）Memory：为uint8数组，用于保存合约执行过程中的临时数据。memory中的数据无法跨交易保存。相关指令有：MLOAD/MOSTROE/MSTORE8。
- 4）Storage：为持久关联map，以uint256为key，uint256为value。所有的合约元素以及mappings都存储在storage中。Storage中的元素可通过web3.eth.getStorageAt(address, key)接口来访问获得。相关指令有：SLOAD/SSTORE。