Limitation (or Feature) on Tendermint

qizhou · April 3, 2020, 3:49am

After carefully study Tendermint, I found a couple of limitations based on my understanding:

When creating a new block, TM DOES NOT check the validity of transactions (although the transaction is pre-checked by CheckTx ABCI). This means that even the txs are valid individually, but can be invalid after running them sequentially (e.g., two tx with the same nonce).

A further issue is how TM imposes resource limits on a block such as a block size limit, gas limit or other resource limits (CPU, BW, etc) without executing the txs.

Any improvement or thoughts? Happy to discuss this.

qizhou · April 3, 2020, 4:44am

BTW: CheckTx response has gasWanted and gasUsed fields, which may help address resource limit issue.

qizhou · April 7, 2020, 11:44pm

However, current mempool implementation of TM doesn’t consider actual gas used:

github.com

tendermint/tendermint/blob/f70785bc957204c78b6da58a1ad35196815a418a/mempool/clist_mempool.go#L498


		// Check total size requirement
		aminoOverhead := types.ComputeAminoOverhead(memTx.tx, 1)
		if maxBytes > -1 && totalBytes+int64(len(memTx.tx))+aminoOverhead > maxBytes {
			return txs
		}
		totalBytes += int64(len(memTx.tx)) + aminoOverhead
		// Check total gas requirement.
		// If maxGas is negative, skip this check.
		// Since newTotalGas < masGas, which
		// must be non-negative, it follows that this won't overflow.
		newTotalGas := totalGas + memTx.gasWanted
		if maxGas > -1 && newTotalGas > maxGas {
			return txs
		}
		totalGas = newTotalGas
		txs = append(txs, memTx.tx)
	}
	return txs
}


func (mem *CListMempool) ReapMaxTxs(max int) types.Txs {

This means that an attacker can send tx with large gasWanted, but with very small gasUsed, and then essentially ddos the network.