How does the tx pool handle txs from same address with consecutive nonce?

Question

I have two questions here.

First one is about the txs from same address with consecutive nonce. When we use promoteExecutables to move txs from future queue to pending list, it compares the balance of all the txs with consecutive nonce with the current state balance(with filter function), but when you process one tx and the following tx should be compared with the balance of pending state. For example, if the current balance is 100, account nonce is 5. I have two txs in future queue, first total cost is 80 with nonce 6,and the second is also 80 with nonce 7, then, it seems both txs can be promoted to the pending list because both is less than 100. How can we avoid such situation happening when package blocks? I can not find any function handle this kind of check in tx-pool.

Second one is about the contract validation. It seems tx pool do not run the contract and make sure it is process-able before adding it to pending list. What if one contract transaction is not process-able and some miner package it in block?

I found obscuren and karalabe once talked about it in this issue, however it became stale afterwards.

Answer 1

The pool only handle the virtual nonce management, other rule would not be checked by the pool. When worker package the txs into block ,they will commit all the pending transaction and those transactions with executable issues would not been added to the block. Check the code below:

func (self *worker) commitNewWork(){
........

pending, err := self.eth.TxPool().Pending()
    if err != nil {
        log.Error("Failed to fetch pending transactions", "err", err)
        return
    }
    txs := types.NewTransactionsByPriceAndNonce(self.current.signer, pending)
    env.commitTransactions(self.mux, txs, self.chain, self.coinbase)

    // Create the full block to seal with the consensus engine
    if fullBlock, err = self.engine.Finalize(self.chain, header, env.state, env.txs, uncles, env.receipts); err != nil {
        log.Error("Failed to finalize block for sealing", "err", err)
        return
    }
........
}