以太坊交易流程及交易池TXpool分析

本文带大家了解一下以太坊和交易池TXpool的交易流程。

以太坊交易流程

用户通过Json RPC向以太坊网络发送的交易请求，最终会被go-ethereum/internal/ethapi/api.go的SendTransaction函数接收到。 从接收到用户传入的参数到将交易放入交易池等待广播的过程如下图所示：

整个过程从SendTransaction接收到SendTxArgs开始，SendTxArgs的结构如下；

type SendTxArgs struct {
   From     common.Address  `json:"from"`
   To       *common.Address `json:"to"`
   Gas      *hexutil.Uint64 `json:"gas"`
   GasPrice *hexutil.Big    `json:"gasPrice"`
   Value    *hexutil.Big    `json:"value"`
   Nonce    *hexutil.Uint64 `json:"nonce"`
   Data  *hexutil.Bytes     `json:"data"`
   Input *hexutil.Bytes     `json:"input"`
}

SendTransaction首先需要根据From字段找到当前账户，为签名交易做准备。

然后开始对交易进行预处理，为SendTxArgs的一些空字段设置默认值，比如赋值Nonce，根据To字段是否为空判断交易是部署合约还是发送交易。

经过预处理后，交易需要进行RLP编码，然后根据之前得到的账户私钥进行签名。

最后将交易提交给TXpool。

事务序列化

事务的序列化是通过 toTransaction 函数完成的。

序列化时，根据To字段是否为nil判断是将交易序列化为交易还是创建合约。

调用SendTranstion接口的Data和Input字段最终会赋值给Input，然后序列化成Payload放入交易池（TXpool）。 现在保留数据字主要是为了向后兼容。 目前，建议使用输入字段。

Input是部署合约时合约的代码，发送交易时Input是交易内容

func (args *SendTxArgs) toTransaction() *types.Transaction {
   var input []byte
   if args.Data != nil {
      input = *args.Data
   } else if args.Input != nil {

      input = *args.Input
   }
   if args.To == nil {
      return types.NewContractCreation(uint64(*args.Nonce), (*big.Int)(args.Value), uint64(*args.Gas), (*big.Int)(args.GasPrice), input)
   }
   return types.NewTransaction(uint64(*args.Nonce), *args.To, (*big.Int)(args.Value), uint64(*args.Gas), (*big.Int)(args.GasPrice), input)
}

最终序列化的交易包含以下字段。 应该注意的是，From 字段不包括在内。 将交易与发送方解耦后，可以支持域名和地址，提供更多的可能性。

type txdata struct {
   AccountNonce uint64          `json:"nonce"    gencodec:"required"`
   Price        *big.Int        `json:"gasPrice" gencodec:"required"`
   GasLimit     uint64          `json:"gas"      gencodec:"required"`
   Recipient    *common.Address `json:"to"       rlp:"nil"` // nil means contract creation
   Amount       *big.Int        `json:"value"    gencodec:"required"`

   Payload      []byte          `json:"input"    gencodec:"required"`
   // Signature values
   V *big.Int `json:"v" gencodec:"required"`
   R *big.Int `json:"r" gencodec:"required"`
   S *big.Int `json:"s" gencodec:"required"`
   // This is only used when marshaling to JSON.
   Hash *common.Hash `json:"hash" rlp:"-"`
}

r、s、v是交易签名后的值，它们可以用来生成签名者的公钥； R、S是ECDSA椭圆加密算法的输出值，V是用来还原结果的ID

由用户私钥签名的序列化交易稍后会被放入交易池中。

交易池

无论是本节点（本地）创建的交易，还是其他节点（远程）广播的交易，都会缓存在TXpool中。 当需要出块时，会从TXpool中选择合适的交易打包成块，最终通过共识确认。

TXpool的核心功能

TXpool的核心结构如下；

TXpool的核心结构是两个Map：queued和pending，分别用来存储未验证交易和已验证交易。

添加交易

向TXpool添加交易的过程比较简单，整体流程如下；

清理交易池

TXpool存在于内存中，不能无限大。 当超过一定阈值时，需要清理交易池中的交易。

pending默认缓存容量为4096，queued默认缓存容量为1024

清算交易分为清算排队和清算待定，清算顺序为排队->待定->排队

当满足以下条件时，队列将被清除

清理排队会影响pending的大小，所以排队清理优先级高

清空挂起时，先按降序记录超过每个账户可执行交易数（AccountSlots）的交易数，然后按降序删除。 举例说明消除规则；

如果AccountSlots为4，则有4个多余账户，编号分别为10、9、7、5。第一次淘汰[10]，淘汰结束[10]，第二次淘汰[10, 9]淘汰结束[9， 9] 第三次淘汰 [9, 9, 7] 淘汰结束 [7, 7, 7] 第四次淘汰 [7, 7, 7, 5] 淘汰结束 [5, 5, 5, 5] 此时，如果还是超限，继续淘汰第五次淘汰 [5, 5, 5, 5] 淘汰结束 [4, 4, 4, 4]

然后清理ququed，规则也很简单，先进入排队，最后删除，直到清理到最大队列长度（GlobalQueue）。

重构交易池（reset）

至此，还有一个问题没有解决。 以太坊是一个分布式系统。 当本地节点选出最优交易准备向全网广播时，此时矿工打包了一个区块，本地节点的区块头是旧的，本地筛选的交易可能有被打包。 如果一个新的区块已经被打包生成，那么广播这个交易就没有意义了。 甚至我们努力准备的待处理缓冲区中的交易也是无效的。

为了避免出现上述情况，我们需要监听链上是否有新的区块，这就是ChainHeadEvent事件。

当监听到ChainHeadEvent事件时，我们应该如何调整queued和pending呢？

首先，需要将分叉链回滚到相同的区块号（blockNumebr）。 可能是本地节点领先，也可能是网络上其他节点领先，但不管怎样，都会回滚到同一个区块号。

本地节点回滚时，撤销的交易保存在discarded slice中，网络上其他节点撤销的交易保存在included slice中。

当区块号一致时，还需要进一步比对区块的Hash，进一步确认区块中的交易是否一致。 如果不一致，则会回滚到区块Hash中，未完成的交易仍会存放在discarded and include中。 切片。

当充分确认本地链和网络链没有分叉后，需要对比discarded和included中的交易，因为网络上的区块生成优先级高于本地，所以需要剔除包含在丢弃和生成重新注入切片中的事务。 移除后，需要根据网络上新生成的区块信息，设置TXpool上的世界状态等信息。 设置完成后以太坊可以交易吗，将reinject重新注入到TXpool中以太坊可以交易吗，加入后进行验证和清洗流程。

思考

本文作者清源，区块链共建者。 欢迎关注清源博客，不定期分享一些区块链底层技术的技术文章。

注：编者对原文略有改动。

深入浅出区块链-打造优质区块链技术博客，学习区块链就来这里，关注知乎和微博。

区块链技术问答 - 专家坐下来回答所有问题。