The blockchain is dealing with transactions. Today we will introduce an important part of the transaction processing process: txpool. This article mainly introduces from the functional point of view. Through this article, you will understand:
- The position and function of txpool in the transaction.
- The function of txpool, the core components are queued and pending.
- How txpool realizes its function.
- Important focus of txpool source code.
An important internal function of Ethereum is txpool, which can be seen from the literal meaning, the transaction pool is the pool for storing transactions. Its position in Ethereum is as shown in the figure below. As long as there is a new transaction, whether it is created by the node or broadcast by other peer nodes, it will be added to the transaction pool first. When packing the block, it will be from this pool. After extraction, after the block is generated, the consensus block and the transaction are uploaded to the chain.
txpool has 4 functions:
- As a buffer for storing transactions, when a large number of transactions arrive, store them first
- Serving for packaging blocks, suitable transactions will be packaged into blocks
- cleanup transaction
- Filter/penalize accounts (attackers) who send a large number of transactions when the number of transactions is more than the buffer size
Let's take a slightly more detailed module interaction diagram to see how txpool implements the above four functions.
The design of the cache function
Transactions in txpool are divided into two types: queued and pending, where queued stores future transactions that cannot be executed currently . Ethereum uses the nonce value to determine the transaction order of an account. The nonce values of multiple transaction values must be continuous. If they are not continuous with the past transactions, they cannot be executed. We might as well use the nonce value to mark the transaction number. Transactions with a nonce of 10 , called Transaction No. 10. For example, the nonce of the current account is 10, and there is transaction No. 100 of this account in txpool, but there are no transactions No. 11 to No. 99 in txpool. The lack of these transactions makes transaction No. 100 impossible to execute, so No. 100 Transactions are future transactions, non-executable transactions, stored in the queue.
pending stores executable transactions . For example, if we complete the transactions No. 11~99 above, then transactions No. 11~100 can be entered into pending, because these transactions are continuous and can be packaged into blocks.
When a node receives a transaction (initiated by a local node or broadcasted by a peer), it will be stored in queued first. In some cases, txpool will transfer the executable transaction in queued to pending.
Serving for block packaging
This is the core function of txpool . When workers pack blocks, they will get all pending transactions , but these transactions are still stored in txpool, and workers just read them out. As for when txpool deletes transactions, they will be cleaned up from txpool later. point of view alone.
cleanup transaction
The txpool cleanup transaction has the following conditions. If any of the following conditions are met, it is an invalid transaction and will be removed from pending or queued :
- The nonce value of the transaction is already lower than the nonce value of the account at the current height, which means that the transaction has expired, and this is the case when the transaction has been uploaded to the chain
- The GasLimit of the transaction is greater than the GasLimit of the block, and the block cannot accommodate the transaction
- The balance of the account is no longer sufficient to support the fee consumed by this transaction
- The number of transactions exceeds the buffer size of queued and pending, and needs to be cleaned up
There are three main scenarios for transaction cleanup :
-
txpool subscribes to the ChainHeadEvent event, which means that there is a new block on the main chain. txpool will check the transactions of each account according to the latest block. Some invalid ones will be deleted, and some will be moved from pending to due to block rollback. queued, and then move the executable transactions in queued to pending to prepare for the next round of block packaging group numbers.
-
Moving the queued transaction to pending is called "promoting". During this process, the transaction will also be checked. When the transaction does not meet the above conditions, it will be directly deleted from the queued.
-
Delete transactions that stay in the queue for more than 3 hours. The timeout period of 3 hours can be adjusted through the startup parameters of geth. txpool records the time when a certain account transaction enters pending. If this time exceeds 3 hours, it means that the transaction of this account cannot be packaged by the main chain for a long time. Since it cannot be accepted by the main chain, it will be deleted and cannot be executed in the queue. transaction.
Punish malicious accounts
This is also a very important attribute of txpool, which can prevent malicious accounts from initiating a large number of spam transactions. Prevent malicious users from causing:
- Occupies txpool space
- Waste a lot of memory and CPU of the node
- Reduced packaging performance
Only when the total number of transactions exceeds the buffer size, txpool will consider a malicious account to initiate a large number of transactions . The pending and queued buffer sizes are different, but the processing strategies are similar:
- The buffer capacity of pending is 4096. When the number of pending transactions is more than this time, it will run a check to see if the number of transactions for each account is more than 16. Collect these accounts and clean them up in turn. What does that mean? That is, only delete (move to queued) one transaction per account of these accounts in each round, and then check whether the number has dropped. If not satisfied, proceed to the next round until it is satisfied.
- The buffer capacity of queued is 1024. After that, the cleaning strategy is similar to that of pending, but it is really deleted here.
This part of the function is not abstracted into a separate function, but in promoteExecutables(), which is executed after each queued transaction is transferred to pending.
The privilege of local transactions , although txpool has many restrictions on transactions, if the transaction is initiated by the account of the node, the above quantity restrictions are invalid for him. Therefore, if you use the node account to send transactions continuously, you will not be considered as an attacker. You can use the txpool.status command to view the number of transactions, which must be greater than 4096. I have reached 60000+.
Focus on source code
The main design of txpool is finished above. If you want to read the code of txpool, I suggest you focus on these functions and variables, and you can fully grasp the implementation of txpool by following the diagram.
- TxPoolConfig: configuration parameters of txpool
- chainHeadCh: txpool has subscribed to new block events
- pending: pending transactions, each account has a transaction list
- queue: queued transactions, each account has a transaction list
- loop: event processing function of txpool
- addTx: add the source of 1 transaction, you can find similar functions
- promoteExecutables: queued transactions are moved to pending
- reset: reset the transactions in txpool according to the latest height of the current block
- Read it carefully, you will find that txpool involves multiple locks (TxPool.mu, TxPool.all, TxPool.priced.all), so when there are many transactions in txpool, its performance is very low, which will also affect to block packaging.