blockchainblocksraw-transactiontransactions
When are transactions dropped from the blockchain?
Suppose I broadcast a transaction to the blockchain, then it is a pending transaction waiting to be mined.
But when are pending transactions dropped from the blockchain, e.g., if the gas price is too low? Can someone think of other reasons for miners not willing to include the transaction?
If transactions are not discarded at some point, then an enormous amount of pending transactions could result.
Second question first: pendingTransactions are transactions held in memory, while getBlock('pending').transactions are the transactions included in the block being mined.
A full node checks blocks and transactions validity before relaying them. However it doesn't have to be a miner. No mining, therefore no transactions in getBlock('pending').transactions.
As for the first question, etherscan is a node with a handy web interface. Transactions that are broadcast to it can be displayed as pending even though it's not mining. You don't mention how long you left the transaction pending, but eventually it should reach etherscan. I look quickly but couldn't find transactions broadcasting statistics. It may be linked to that.
Another limitation is the pending transaction pool of your peers. Remember the infamous ICOs clogging up the network. If your peers have a full queue they may just drop your transaction.
the result is ok. At first, i send 110 txs, the result of txpool.status
{
pending: 110,
queued: 0
}
and then start mined,all of transactions were mined. As follows
so the tx_pool doesn't drop any transactions. In go-ethereum source files,tx_pool.go file deal with transaction logic , some transactions will be removed if tx_pool is full that pool size over 4096+1024,the source as follows:
// 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 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())
}
}
so there is no overflow.
Best Answer
It's important to note that in the context of this question, transactions aren't ever dropped from the blockchain. The blockchain represents transactions that were validated by nodes (locally) and registered as blocks on the blockchain (remotely). Each full node in the Ethereum network possesses its own copy of the blockchain in local memory, which means that when a transaction makes it to one of these nodes for validation, this process is done offline. A transaction can remain pending in a node or never make it to the blockchain for a number of reasons, which can be grouped into four categories.
The first of which, maybe most obviously, is machine failure; the node simply could be corrupted in some form. There are, however, enough nodes validating transactions that the failure of a few is not enough to stop the chain, but widespread machine failure could prevent pending transactions from registering.
The second reason is that the transaction itself is invalid and cannot be validated, or cannot yet be validated. If a transaction is invalid because it's inherently invalid then it will never make it to the chain. But a transaction which "should" be valid may find itself in the mempool of a full node because of a nonce gap, for example. Perhaps multiple transactions were made in rapid succession and the network didn't neatly serialize them or the client generating the transaction is poorly coded and assigned an invalid nonce, resulting in a transaction that made it to a node with a nonce that was higher (or even lower) than the node was expecting. In this case, this transaction will reside in the mempool until another transaction from the same address with the missing nonce makes it to the chain, and then the node will attempt to validate this "out-of-order" transaction. However, if the transaction with the missing nonce never makes it to the chain then this "out-of-order" transaction will reside in the mempool indefinitely until it's purged by the node for no other reason than lack of local memory (disk space). If the node had an infinite amount of memory then it would likely hang onto this transaction forever, but that is certainly not the case.
The third reason is competition. If the network is hot enough, where there are more transactions willing to pay more gas than yours, enough to keep your transaction in a mempool long enough to get it purged (again, for no other reason than lack of disk space on the node itself), then your transaction may never become a block on the chain.
And the fourth reason is the exception to the rule. A core tenet of Ethereum is to "break stuff" and it's certainly possible that future changes to the protocol could jeopardize pending transactions. Ethereum developers are warned at the door to be ready for anything and events in the past, namely the infamous hard fork, reinforce the wisdom of this advice.
But the practical answer to the question is whenever the node runs out of its mempool's allocated disk space. The operative question then becomes: why is the transaction idling in a mempool?