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

Lowky 发布于2019-06-27 18:51 / 2648人阅读

摘要：前言以太坊是一个运行智能合约的平台，被称作可编程的区块链，允许用户将编写的智能合约部署在区块链上运行。交易执行以太坊是一个基于交易的状态机，一笔交易可以使以太坊从一个状态切换到另一个状态，即交易的执行伴随着状态的改变。

前言

以太坊是一个运行智能合约的平台，被称作可编程的区块链，允许用户将编写的智能合约部署在区块链上运行。而运行合约的主体便是以太坊虚拟机(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指令解释方式和虚拟机内部栈和内存等内部实现，参考本系列文章

小结

在以太坊中，交易的执行是由EVM完成的，网络中的所有全节点都会去执行每一笔交易(这样所有人的状态才可以保持一致)

交易分为普通转账和执行(创建)智能合约，两者都由sender付费，后者相比前者，EVM要额外执行合约的字节码

云服务器服务器托管以太坊区块链交易查询以太坊的区块链技术以太坊以太坊区块

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/24382.html

以太坊源码分析：共识（2）引擎

摘要：前言是以太坊封定义的一个接口，它的功能可以分为类验证区块类，主要用在将区块加入到区块链前，对区块进行共识验证。辅助类生成以太坊共识相关的。被使用，是以太坊状态管理服务，当报告数据的时候，需要获取区块的信息。前言 engine是以太坊封定义的一个接口，它的功能可以分为3类：验证区块类，主要用在将区块加入到区块链前，对区块进行共识验证。产生区块类，主要用在挖矿时。辅助类。接下...

YuboonaZhang 2019-06-27 18:52 评论0 收藏0
区块链技术学习指引

摘要：引言给迷失在如何学习区块链技术的同学一个指引，区块链技术是随比特币诞生，因此要搞明白区块链技术，应该先了解下比特币。但区块链技术不单应用于比特币，还有非常多的现实应用场景，想做区块链应用开发，可进一步阅读以太坊系列。本文始发于深入浅出区块链社区, 原文：区块链技术学习指引原文已更新，请读者前往原文阅读本章的文章越来越多，本文是一个索引帖，方便找到自己感兴趣的文章，你也可以使用左侧...

Cristic 2019-06-27 18:14 评论0 收藏0
以太坊源码分析—账户的管理

摘要：前言以太坊是一个巨大的状态机，在网络中，每一个全节点都保存着以太坊状态机的全部历史，只要愿意，我们可以查询到任何时刻的状态黄皮书中，而账户状态便是其中的状态，这部分功能由主要由代码中的包提供基本概念账户地址在以太坊中，无论是外部账户还是合约前言以太坊是一个巨大的状态机，在网络中，每一个全节点都保存着以太坊状态机的全部历史，只要愿意，我们可以查询到任何时刻的状态(黄皮书中World ...

WilsonLiu95 2019-06-27 18:51 评论0 收藏0
以太坊源码分析--MPT树

摘要：是以太坊中存储区块数据的核心数据结构，它和融合一个树形结构，理解结构对之后学习以太坊区块以及智能合约状态存储结构的模块源码很有帮助。 MPT(Merkle Patricia Tries)是以太坊中存储区块数据的核心数据结构，它Merkle Tree和Patricia Tree融合一个树形结构，理解MPT结构对之后学习以太坊区块header以及智能合约状态存储结构的模块源码很有帮助。首...

roadtogeek 2019-06-27 18:35 评论0 收藏0
以太坊源码分析：共识（1）矿工

摘要：接下来我们将从以下角度介绍矿工角色。我们分别使用矿长副矿长矿工进行类比。副矿长，负责具体挖矿工作的安排，把挖矿任务安排给。矿工的主要函数介绍和的主要函数，他们是矿工的具体运作机制。负责处理外部事件。前言矿工在PoW中负责了产生区块的工作，把一大堆交易交给它，它生成一个证明自己做了很多工作的区块，然后将这个区块加入到本地区块链并且广播给其他节点。接下来我们将从以下角度介绍矿工： ...

tylin 2019-06-27 18:52 评论0 收藏0