以太坊源码分析 交易
本文分析以太坊交易的相关代码,以太坊交易的完整流程分为以下步骤:
- 发起交易:指定目标地址和交易金额,以及需要的 gas/gaslimit
- 交易签名:使用账户私钥对交易进行签名
- 提交交易:把交易加入到交易缓冲池 txpool(会先对交易签名进行验证)
- 广播交易:通知 EVM 执行,同时把交易信息广播给其他结点
太坊交易流程图:
1. 发起交易
用户通过 JSON RPC 发起 eth_sendTransaction 请求,最终会调用 PublicTransactionPoolAPI 的实现,代码位于internal/ethapi/api.go:
func (s *PublicTransactionPoolAPI) SendTransaction(ctx context.Context, args SendTxArgs) (common.Hash, error) { // Look up the wallet containing the requested signer account := accounts.Account{Address: args.From} wallet, err := s.b.AccountManager().Find(account) if err != nil { return common.Hash{}, err } if args.Nonce == nil { // Hold the addresse's mutex around signing to prevent concurrent assignment of // the same nonce to multiple accounts. s.nonceLock.LockAddr(args.From) defer s.nonceLock.UnlockAddr(args.From) } // Set some sanity defaults and terminate on failure if err := args.setDefaults(ctx, s.b); err != nil { return common.Hash{}, err } // Assemble the transaction and sign with the wallet tx := args.toTransaction() var chainID *big.Int if config := s.b.ChainConfig(); config.IsEIP155(s.b.CurrentBlock().Number()) { chainID = config.ChainId } signed, err := wallet.SignTx(account, tx, chainID) if err != nil { return common.Hash{}, err } return submitTransaction(ctx, s.b, signed) }
首先根据from地址查找到对应的wallet,检查一下参数值,然后做了以下3件事:
- 通过SendTxArgs.toTransaction()创建交易
- 通过Wallet.SignTx()对交易进行签名
- 通过submitTransaction()提交交易
这里先分析创建交易部分。先看一下SendTxArgs类型的定义(internal/ethapi/api.go):
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"` // We accept "data" and "input" for backwards-compatibility reasons. "input" is the // newer name and should be preferred by clients. Data *hexutil.Bytes `json:"data"` Input *hexutil.Bytes `json:"input"` }
可以看到是和JSON字段相应的,包括了地址、gas、金额这些交易信息,nonce是一个随账户交易次数自增的数字,一般会自动填充。交易还可以携带一些额外数据,存放在data或者input字段中,推荐用input,data是为了向后兼容。
接着看一下它的toTransaction()函数:
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) }
可以看到,如果目标地址为空的话,表示这是一个创建智能合约的交易,调用NewContractCreation()。否则说明这是一个普通交易,调用NewTransaction()。不管调用哪个,最终都会生成一个Transaction实例,我们看一下Transaction类型的定义,代码位于core/types/transaction.go:
type Transaction struct { data txdata // caches hash atomic.Value size atomic.Value from atomic.Value }
主要就是包含了一个txdata类型的字段,其他3个都是缓存。看一下txdata类型的定义:
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:"-"` }
可以看到,除了刚刚那些参数值,还有3个签名字段和1个hash字段。需要注意的是,from地址并不包含在该结构中。
2. 交易签名
创建完Transaction实例以后,会调用Wallet.SignTx()进行签名。具体流程参见下图:
可以看到,是先通过Keccak-256算法计算交易数据的hash值,然后结合账户的私钥,通过ECDSA(Elliptic Curve Digital Signature Algorithm),也就是椭圆曲线数字签名算法生成签名数据。
这里有个疑问,为什么txdata里只有接收方的地址(Recipient),没有发送方的地址呢?那我们如何知道这笔交易的发起人时谁呢?实际上发送方的地址是可以根据交易数据以及签名推算出来的,参见下图:
至于为什么不把发送方地址放到txdata中,是为了故意隐藏发送方信息,还是为了减小数据量,就不得而知了。
下面开始分析代码。上一篇文章分析过,Wallet是一个接口,具体实现在keyStoreWallet中,代码位于accounts/keystore/keystore_wallet.go中:
func (w *keystoreWallet) SignTx(account accounts.Account, tx *types.Transaction, chainID *big.Int) (*types.Transaction, error) { // Make sure the requested account is contained within if account.Address != w.account.Address { return nil, accounts.ErrUnknownAccount } if account.URL != (accounts.URL{}) && account.URL != w.account.URL { return nil, accounts.ErrUnknownAccount } // Account seems valid, request the keystore to sign return w.keystore.SignTx(account, tx, chainID) }
继续跟踪KeyStore的SignTx()函数,代码位于accounts/keystore/keystore.go中:
func (ks *KeyStore) SignTx(a accounts.Account, tx *types.Transaction, chainID *big.Int) (*types.Transaction, error) { // Look up the key to sign with and abort if it cannot be found ks.mu.RLock() defer ks.mu.RUnlock() unlockedKey, found := ks.unlocked[a.Address] if !found { return nil, ErrLocked } // Depending on the presence of the chain ID, sign with EIP155 or homestead if chainID != nil { return types.SignTx(tx, types.NewEIP155Signer(chainID), unlockedKey.PrivateKey) } return types.SignTx(tx, types.HomesteadSigner{}, unlockedKey.PrivateKey) }
这里会首先判断账户是否已经解锁,如果已经解锁的话就可以获取它的私钥。
然后创建签名器,如果要符合EIP155规范的话,需要把chainID传进去,也就是我们的“--networkid”命令行参数。
最后调用一个全局函数SignTx()完成签名,代码位于core/types/transaction_signing.go:
func SignTx(tx *Transaction, s Signer, prv *ecdsa.PrivateKey) (*Transaction, error) { h := s.Hash(tx) sig, err := crypto.Sign(h[:], prv) if err != nil { return nil, err } return tx.WithSignature(s, sig) }
主要分为3个步骤:
- 生成交易的hash值
- 根据hash值和私钥生成签名
- 把签名数据填充到Transaction实例中
2.1 生成交易的hash值
以EIP155Signer为例,代码如下:
func (s EIP155Signer) Hash(tx *Transaction) common.Hash { return rlpHash([]interface{}{ tx.data.AccountNonce, tx.data.Price, tx.data.GasLimit, tx.data.Recipient, tx.data.Amount, tx.data.Payload, s.chainId, uint(0), uint(0), }) } func rlpHash(x interface{}) (h common.Hash) { hw := sha3.NewKeccak256() rlp.Encode(hw, x) hw.Sum(h[:0]) return h }
可以看到,先进行RLP编码,然后再用SHA3-256生成hash值。RLP是一种数据序列化方法,后面有时间再写文章分析。
2.2 根据hash值和私钥生成签名
crypto.Sign()函数代码位于crypto/signature_cgo.go:
// Sign calculates an ECDSA signature. // The produced signature is in the [R || S || V] format where V is 0 or 1. func Sign(hash []byte, prv *ecdsa.PrivateKey) (sig []byte, err error) { if len(hash) != 32 { return nil, fmt.Errorf("hash is required to be exactly 32 bytes (%d)", len(hash)) } seckey := math.PaddedBigBytes(prv.D, prv.Params().BitSize/8) defer zeroBytes(seckey) return secp256k1.Sign(hash, seckey) }
这里是通过ECDSA算法生成签名数据,水平有限就不继续分析了。最终会返回的签名是一个字节数组,按R / S / V的顺序排列。
2.3 填充签名数据
最后一步就是把签名数据的这3个值填充到Transaction结构中了,看一下WithSignature()函数,代码位于core/types/transaction.go:
func (tx *Transaction) WithSignature(signer Signer, sig []byte) (*Transaction, error) { r, s, v, err := signer.SignatureValues(tx, sig) if err != nil { return nil, err } cpy := &Transaction{data: tx.data} cpy.data.R, cpy.data.S, cpy.data.V = r, s, v return cpy, nil }
生成的签名数据是字节数组类型,需要通过signer.SignatureValues()函数转换成3个big.Int类型的数据,然后填充到Transaction结构的R / S / V字段上。可以瞄一眼这个转换函数:
func (fs FrontierSigner) SignatureValues(tx *Transaction, sig []byte) (r, s, v *big.Int, err error) { if len(sig) != 65 { panic(fmt.Sprintf("wrong size for signature: got %d, want 65", len(sig))) } r = new(big.Int).SetBytes(sig[:32]) s = new(big.Int).SetBytes(sig[32:64]) v = new(big.Int).SetBytes([]byte{sig[64] + 27}) return r, s, v, nil }
第0~31字节是R,第32~63字节是S,第64位加上27就可以得到V。
3. 提交交易
签名完成以后,就需要调用submitTransaction()函数提交到交易缓冲池txpool中。
在分析代码之前,先看下TxPool中的几个重要字段:
pending map[common.Address]*txList // All currently processable transactions queue map[common.Address]*txList // Queued but non-processable transactions all map[common.Hash]*types.Transaction // All transactions to allow lookups priced *txPricedList // All transactions sorted by price
pending字段中包含了当前所有可被处理的交易列表,而queue字段中包含了所有不可被处理、也就是新加入进来的交易。它们是按账号地址来组织的,每个地址对应一个txList,具体内部结构参见下图:
可以看到txList内部包含一个txSortedMap结构,实现按nonce排序,其内部维护了两张表:
- 一张是包含了所有Transaction的map,key是Transaction的nonce值。之前提到过,这个nonce是随着账户的交易次数自增的一个数字,所以越新的交易,nonce值越高。
- 还有一张表是一个数组,包含了所有nonce值,其内部是进行过堆排序的(小顶堆),nonce值按照从大到小排列。每次调用heap.Pop()时会取出最小的nonce值,也就是最老的交易。
all字段中包含了所有的交易列表,以交易的hash作为key。
priced字段则是把all中的交易列表按照gas price从大到小排列,如果gas price一样,则按照交易的nonce值从小到大排列。最终的目标是每次取出gas price最大、nonce最小的交易。
我们提交交易的目标是:先把交易放入queue中记录在案,然后再从queue中选一部分放入pending中进行处理。如果发现txpool满了,则依据priced中的排序,剔除低油价的交易。
另外,如果是本地(local)提交的交易,默认情况下会尽可能地保证被放入txpool中,除非显式关闭该配置。
接着我们看一下txpool的默认配置:
var DefaultTxPoolConfig = TxPoolConfig{ Journal: "transactions.rlp", Rejournal: time.Hour, PriceLimit: 1, PriceBump: 10, AccountSlots: 16, GlobalSlots: 4096, AccountQueue: 64, GlobalQueue: 1024, Lifetime: 3 * time.Hour, }
- GlobalSlots:pending列表的最大长度,默认4096笔
- AccountSlots:pending中每个账户存储的交易数的阈值,超过这个数量可能会被认为是垃圾交易或者是攻击者,多余交易可能被丢弃
- GlobalQueue:queue列表的最大长度,默认1024笔
- AccountQueue:queue中每个账户允许存储的最大交易数,超过会被丢弃,默认64笔
- PriceLimit:允许进入txpool的最低gas price,默认1 Gwei
- PriceBump:如果出现两个nonce相同的交易,gas price的差值超过该阈值则用新交易替换老交易
好,现在我们回到internal/ethapi/api.go,分析submitTransaction()函数:
func submitTransaction(ctx context.Context, b Backend, tx *types.Transaction) (common.Hash, error) { if err := b.SendTx(ctx, tx); err != nil { return common.Hash{}, err } if tx.To() == nil { signer := types.MakeSigner(b.ChainConfig(), b.CurrentBlock().Number()) from, err := types.Sender(signer, tx) if err != nil { return common.Hash{}, err } addr := crypto.CreateAddress(from, tx.Nonce()) log.Info("Submitted contract creation", "fullhash", tx.Hash().Hex(), "contract", addr.Hex()) } else { log.Info("Submitted transaction", "fullhash", tx.Hash().Hex(), "recipient", tx.To()) } return tx.Hash(), nil }
这里有一个Backend参数,是在eth Service初始化时创建的,具体实现在EthApiBackend中,代码位于eth/api_backend.go。可以看到,这里先调用了SendTx()函数提交交易,然后如果发现目标地址为空,表明这是一个创建智能合约的交易,会创建合约地址。下面分别进行分析。
3.1 提交交易到txpool
func (b *EthApiBackend) SendTx(ctx context.Context, signedTx *types.Transaction) error { return b.eth.txPool.AddLocal(signedTx) }
继续跟踪TxPool的AddLocal()函数:
func (pool *TxPool) AddLocal(tx *types.Transaction) error { return pool.addTx(tx, !pool.config.NoLocals) } func (pool *TxPool) addTx(tx *types.Transaction, local bool) error { pool.mu.Lock() defer pool.mu.Unlock() // Try to inject the transaction and update any state replace, err := pool.add(tx, local) if err != nil { return err } // If we added a new transaction, run promotion checks and return if !replace { from, _ := types.Sender(pool.signer, tx) // already validated pool.promoteExecutables([]common.Address{from}) } return nil }
这里有两个主要函数:add()和promoteExecuteables()。
add()会判断是否应该把当前交易加入到queue列表中,promoteExecuteables()则会从queue中选取一些交易放入pending列表中等待执行。下面分别讨论这两个函数。
3.1.1 TxPool.add()
这个函数比较长,我们分成一段一段的来分析:
// If the transaction is already known, discard it hash := tx.Hash() if pool.all[hash] != nil { log.Trace("Discarding already known transaction", "hash", hash) return false, fmt.Errorf("known transaction: %x", hash) }
这一段是先计算交易的hash值,然后判断是不是已经在txpool 中,在的话就直接退出。
if err := pool.validateTx(tx, local); err != nil { log.Trace("Discarding invalid transaction", "hash", hash, "err", err) invalidTxCounter.Inc(1) return false, err }
这一段是验证交易的有效性,主要进行以下几个方面的检查:
- 数据量必须<32KB
- 交易金额必须非负(>=0)
- 交易的gas limit必须低于block的gas limit
- 签名数据必须有效,能够解析出发送者地址
- 交易的gas price必须高于pool设定的最低gas price(除非是本地交易)
- 交易的nonce值必须高于当前链上该账户的nonce值(低于则说明这笔交易已经被打包过了)
- 当前账户余额必须大于“交易金额 + gasprice * gaslimit”
- 交易的gas limit必须大于对应数据量所需的最低gas水平
// If the transaction pool is full, discard underpriced transactions if uint64(len(pool.all)) >= pool.config.GlobalSlots+pool.config.GlobalQueue { // If the new transaction is underpriced, don't accept it if !local && pool.priced.Underpriced(tx, pool.locals) { log.Trace("Discarding underpriced transaction", "hash", hash, "price", tx.GasPrice()) underpricedTxCounter.Inc(1) return false, ErrUnderpriced } // New transaction is better than our worse ones, make room for it drop := pool.priced.Discard(len(pool.all)-int(pool.config.GlobalSlots+pool.config.GlobalQueue-1), pool.locals) for _, tx := range drop { log.Trace("Discarding freshly underpriced transaction", "hash", tx.Hash(), "price", tx.GasPrice()) underpricedTxCounter.Inc(1) pool.removeTx(tx.Hash(), false) } }
这一段是在当前txpool已满的情况下,剔除掉低油价的交易。还记得之前有个priced字段存储了按gas price以及nonce排序的交易列表吗?这里会先把当前交易的gas price和当前池中的最低价进行比较:
- 如果低于最低价,直接丢弃该交易返回
- 如果高于最低价,则从txpool中剔除一些低价的交易
// If the transaction is replacing an already pending one, do directly from, _ := types.Sender(pool.signer, tx) // already validated if list := pool.pending[from]; list != nil && list.Overlaps(tx) { // Nonce already pending, check if required price bump is met inserted, old := list.Add(tx, pool.config.PriceBump) if !inserted { pendingDiscardCounter.Inc(1) return false, ErrReplaceUnderpriced } // New transaction is better, replace old one if old != nil { delete(pool.all, old.Hash()) pool.priced.Removed() pendingReplaceCounter.Inc(1) } pool.all[tx.Hash()] = tx pool.priced.Put(tx) pool.journalTx(from, tx) log.Trace("Pooled new executable transaction", "hash", hash, "from", from, "to", tx.To()) // We've directly injected a replacement transaction, notify subsystems go pool.txFeed.Send(TxPreEvent{tx}) return old != nil, nil }
这一段是为了处理两个交易nonce相同的问题。如果用户发起了一笔交易,在还没有被执行之前又用同样的nonce发起了另一笔交易,则只会保留gas price高的那一笔。这个list.Overlaps()函数就是用来判断pending列表中是否包含相同nonce的交易的。
// New transaction isn't replacing a pending one, push into queue replace, err := pool.enqueueTx(hash, tx) if err != nil { return false, err }
如果之前的那些检查都没有问题,就真正调用enqueueTx()函数把交易加入到queue列表中了。
// Mark local addresses and journal local transactions if local { pool.locals.add(from) } pool.journalTx(from, tx)
最后,如果发现这个账户是本地的,就把它加到一个白名单里,默认会保证本地交易优先被加到txpool中。
至此,TxPool.add()函数就分析完了。
3.1.2 TxPool.promoteExecuteables()
这个函数比上面那个还长。。。主要目的是把交易从queue列表“提拔”到pending列表,代码逻辑比较清楚,具体可以参见下面这张图:
根据不同的目的可以分为3块,分别以粉色、紫色、绿色标识。
粉色部分主要是为了把queue中的交易“提拔”到pending中。当然在这之前需要先要进行一番检查:
- 丢弃nonce < 账户当前nonce的交易,也就是已经被打包过的交易
- 丢弃转账金额 + gas消耗 > 账户余额的交易,也就是会out-of-gas的交易
- 丢弃gas limit > block gas limit的交易,这部分交易可能会导致区块生成失败
紫色部分主要是为了清理pending列表,使其满足GlobalSlots和AccountSlots的限制条件:
- 如果有些账户的交易数超过了AccountSlots,则先按交易数最少的账户进行均衡。举例来说,如果有10个账户交易数超过了AccountSlots(默认16),其中交易数最少的账户包含20笔交易,那么先把其他9个账户的交易数量削减到20。
- 如果经过上面的步骤,pending的长度还是超过了GlobalSlots,那就严格按照AccountSlots进行均衡,也就是把上面的10个账户的交易数进一步削减到16。
绿色部分主要是为了清理queue列表,使其满足GlobalQueue和AccountQueue的限制条件:
- 如果每个账户的交易数超过了AccountQueue,丢弃多余交易
- 如果queue的长度超过了GlobalQueue,则把账户按最后一次心跳时间排序,然后依次去除账户中的交易,直到满足限制条件位置。
这里提到一个最后一次心跳时间,其实就是账户最近一次交易的时间,用来作为账户活跃度的判断
具体代码非常长,就不贴了,可以按照上面的图自行对照。
3.2 创建智能合约地址
再贴一下之前创建智能合约地址的代码:
addr := crypto.CreateAddress(from, tx.Nonce())
参数是发送方地址和交易的nonce值,然后调用CreateAddress()方法,代码位于crypto/crypto.go:
func CreateAddress(b common.Address, nonce uint64) common.Address { data, _ := rlp.EncodeToBytes([]interface{}{b, nonce}) return common.BytesToAddress(Keccak256(data)[12:]) }
可以看到,就是先对刚刚两个参数进行RLP编码,然后计算hash值,取后20位作为合约地址。
至此,提交交易部分的代码就分析完了。
4. 广播交易
交易提交到txpool中后,还需要广播出去,一方面通知EVM执行该交易,另一方面要把交易信息广播给其他结点。具体调用在3.1.2节中提到的promoteTx()函数中,代码位于crypto/tx_pool.go:
func (pool *TxPool) promoteTx(addr common.Address, hash common.Hash, tx *types.Transaction) { …… // Set the potentially new pending nonce and notify any subsystems of the new tx pool.beats[addr] = time.Now() pool.pendingState.SetNonce(addr, tx.Nonce()+1) go pool.txFeed.Send(TxPreEvent{tx}) }
可以看到,先更新了最后一次心跳时间,然后更新账户的nonce值,最后一行就是发送一个TxPreEvent事件,外部可以通过SubscribeTxPreEvent()函数订阅该事件:
func (pool *TxPool) SubscribeTxPreEvent(ch chan<- TxPreEvent) event.Subscription { return pool.scope.Track(pool.txFeed.Subscribe(ch)) }
我们只要搜索一下这个函数,就可以知道哪些组件订阅了该事件了。
4.1 执行交易
第一个订阅的地方位于miner/worker.go:
func newWorker(config *params.ChainConfig, engine consensus.Engine, coinbase common.Address, eth Backend, mux *event.TypeMux) *worker { …… // Subscribe TxPreEvent for tx pool worker.txSub = eth.TxPool().SubscribeTxPreEvent(worker.txCh) …… go worker.update() …… }
开启了一个goroutine来接收TxPreEvent,看一下update()函数:
func (self *worker) update() { …… // Handle TxPreEvent case ev := <-self.txCh: // Apply transaction to the pending state if we're not mining if atomic.LoadInt32(&self.mining) == 0 { self.currentMu.Lock() acc, _ := types.Sender(self.current.signer, ev.Tx) txs := map[common.Address]types.Transactions{acc: {ev.Tx}} txset := types.NewTransactionsByPriceAndNonce(self.current.signer, txs) self.current.commitTransactions(self.mux, txset, self.chain, self.coinbase) self.updateSnapshot() self.currentMu.Unlock() } else { // If we're mining, but nothing is being processed, wake on new transactions if self.config.Clique != nil && self.config.Clique.Period == 0 { self.commitNewWork() } } …… }
可以看到,如果结点不挖矿的话,这里会立即调用commitTransactions()提交给EVM执行,获得本地回执。
如果结点挖矿的话,miner会调用commitNewWork(),内部也会调用commitTransactions()执行交易。
4.2 广播给其他结点
另一个订阅的地方位于eth/handler.go:
func (pm *ProtocolManager) Start(maxPeers int) { …… pm.txSub = pm.txpool.SubscribeTxPreEvent(pm.txCh) go pm.txBroadcastLoop() …… }
同样也是启动了一个goroutine来接收TxPreEvent事件,看一下txBroadcastLoop()函数:
func (pm *ProtocolManager) txBroadcastLoop() { for { select { case event := <-pm.txCh: pm.BroadcastTx(event.Tx.Hash(), event.Tx) // Err() channel will be closed when unsubscribing. case <-pm.txSub.Err(): return } } }
继续跟踪BroadcastTx()函数:
func (pm *ProtocolManager) BroadcastTx(hash common.Hash, tx *types.Transaction) { // Broadcast transaction to a batch of peers not knowing about it peers := pm.peers.PeersWithoutTx(hash) //FIXME include this again: peers = peers[:int(math.Sqrt(float64(len(peers))))] for _, peer := range peers { peer.SendTransactions(types.Transactions{tx}) } log.Trace("Broadcast transaction", "hash", hash, "recipients", len(peers)) }
可以看到,这里会通过P2P向所有没有该交易的结点发送该交易。
下一章:以太坊源码分析 共识引擎
以太坊共识引擎的组件之间的关系:Engine接口定义了共识引擎需要实现的所有函数,实际上按功能可以划分为2类:区块验证类:以Verify开头,当收到新区块时,需要先验证区块的有效性区块盖章类:包括Prepare/F ...