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

前言

以太坊是一个运行智能合约的平台，被称做可编程的区块链，容许用户将编写的智能合约部署在区块链上运行。而运行合约的主体即是以太坊虚拟机(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要额外执行合约的字节码