以太坊源码分析—交易的执行

#前言
以太坊是一个运行智能合约的平台，被称作可编程的区块链，允许用户将编写的智能合约部署在区块链上运行。而运行合约的主体便是以太坊虚拟机(EVM)

#####区块 交易 合约
区块链由区块(Block)组成，而区块中打包一定数量的交易(Transaction)，交易可能是一个单纯的转账操作，也可能是调用一个智能合约，无论是哪一种，EVM在运行(excute)交易时都会创建合约(Contract)
#####外部账户 合约账户
以太坊中的账户有两类

• 外部账户 由账户持有人的私钥控制的真实存在的账户
• 合约账户 由合约代码控制，保存着合约代码
  一笔交易包含发送方(sender) 接收方(recipient) 和数额(value) 三要素。发送方将一定数额的ETH转移到接收方的账户，这里的转账交易中，接收方是外部账户。而在调用智能合约的交易时，接收方是合约账户。
  #####gas
  如同现实中的税费一样，交易也需要将支付少量的费用，称为gas，费用支付给矿工，这可以激励矿工打包交易到区块，也使得区块链避免恶意运算攻击。gas由交易的发送者使用ETH购买，在执行交易的每一步都会消耗gas，如果gas用完了，交易状态会被回退，但消耗的gas不会返还。

#交易执行
以太坊是一个基于交易的状态机，一笔交易可以使以太坊从一个状态(state)切换到另一个状态，即交易的执行伴随着状态的改变。
交易执行的入口在 core/state_processor.go 的 **Process()**方法，下面是该方法的轮廓

func (p *StateProcessor) Process(block *types.Block, statedb *state.StateDB, cfg vm.Config) (types.Receipts，[]*types.Log，uint64，error) {
    ......
    var (
        usedGas = new(uint) 
        header = block.Header()
        gp = new(GasPool).AddGas(block.GasLimit())
    )
    for i, tx := range block.Transactions() {
        receipt, _, _ := ApplyTransaction(p.config, p.bc, nil, gp, statedb, header, tx, usedGas, cfg)
        receipts = append(receipts, receipt)
        allLogs = append(allLogs, receipt.Logs...)        
    }
    p.engine.Finalize(p.bc. header, statedb, block.Transactions(), block.Uncles(), receipts)
    ......
}

Process()方法对block中的每个交易tx调用ApplyTransaction()来执行交易，入参state存储了各个账户的信息，如账户余额、合约代码(仅对合约账户而言)，我们姑且将其理解为一个内存中的数据库。其中每个账户以state object表示

**ApplyTransaction()**方法完成以下功能

• 调用AsMessage()用tx生成core.Message 其实现就是将tx中的一些字段存入Message以及从tx的数字签名中反解出tx的sender，重点关注其中的data 字段：对普通转账交易，该字段为空，对创建一个新的合约，该字段为新的合约的代码，对执行一个已经在区块链上存在的合约，该参数为合约代码的输入参数
• 调用NewEVMContext()创建一个EVM运行上下文vm.Context。注意其中的Coinbase字段填入的矿工的地址，Transfer是具体的转账方法，其实就是操作sender和recipient的账户余额
• 调用**NewEVM()**创建一个虚拟机运行环境EVM，它主要作用是汇集之前的信息以及创建一个代码解释器(Interpreter)，这个解释器之后会用来解释并执行合约代码
• 接下来就是调用ApplyMessage()将以上的信息作用在当前以太坊状态上，使得状态机发生状态变换

**ApplyMessage()的顶层比较简单，它创建一个StateTransition结构并调用其TransitionDb()**方法，StateTransition表示一次以太访的状态转移 其定义如下：

type StateTransition struct {
    gp  *GasPool
    msg Message
    gas  uint64
    gasPrice  *big,Int
    initialGas   uint64
    value   *big.Int
    data    []byte
    state   vm.StateDB
    evm    *vm.EVM
}

其中的字段都是之前**ApplyTransaction()**方法中创建的结构得到。一次状态转移包括以下流程

• nonce检查：交易的nonce值用于标识这是sender发起的交易的序号，该值总是等于上一笔交易的nonce值递增1，当我们检查发现当前Apply的这笔交易与该sender期待的nonce不一致时，就会拒绝此次状态转换
• gas预购： sender 预购此次转换需要的gas，简单说来就是扣除sender账户的ETH(反映在stateDB)，扣除的数量却决于交易设定的gasPrice和gasLimit的乘积，单位是gwei。
• 合约账户创建： 如果交易的recipient为空的话，标识这笔交易需要创建一个合约，那么就创建一个合约账户(state object)
• 价值转移：每笔交易都伴随着价值转移，即ETH从sender账户发送到receipt账户，如果创建了合约，还要执行合约代码

**TransitionDB()**完成这样的状态转换，其实现流程如下：

最终由交易的receipt是否为空决定是使用evm.Create()还是evm.Call()，无论是哪种，最终都是创建一个Contract结构，然后调用run()方法运行之。注意，即使是外部账户之间普通的转账也会调用Call() 和 run()，只是由于receipt上没有代码，运行会很快结束而已。**run()最终调用Interpreter的Run()**方法。

前面提到过，在调用**NewEVM()**时创建了一个解释器(Interpreter)

func NewInterpreter(evm *EVM，cfg Config)  *Interpreter {
     switch {
         case evm.ChainConfig().IsConstantinople(evm.BlockNumber):
             cfg.JumpTable = constantinopleInstructionSet
         case evm.ChainConfig().IsByzantium(evm.BlockNumber):
             cfg.JumpTable = byzantiumInstructionSet
         case evm.ChainConfig().IsHomestead(evm.BlockNumber):
             cfg.JumpTable = homesteadInstructionSet
         default:
             cfg.JumpTable = fromtierInstructionSet  
     }
     return &Interpreter{
         evm:      evm,
         cfg:      cfg,
         ......
     }
}

根据当前Block的高度，计算出它处于以太坊演进的阶段，得到该阶段支持的指令集(InstructionSet)，新的阶段在兼容老的阶段的所有指令前提下，再增加了独特的新指令。最终存储在Interpreter的cfg字段

合约代码本质上上是由Solidity语言编译后形成的EVM字节码,字节码中的操作也正是指令集中定义的指令

再回到**Run()**方法，其大概流程如下

EVM逐字节的解析合约代码并调用excute()方法运行，直到运行完成或者gas提前耗尽。

关于具体的EVM指令解释方式和虚拟机内部栈和内存等内部实现，参考本系列文章

#小结

1. 在以太坊中，交易的执行是由EVM完成的，网络中的所有全节点都会去执行每一笔交易(这样所有人的状态才可以保持一致)
2. 交易分为普通转账和执行(创建)智能合约，两者都由sender付费，后者相比前者，EVM要额外执行合约的字节码