"consensus_params": {
    "block_size_params": {
      "max_txs_bytes": "22020096",
      "max_gas": "-1"
    },
    "tx_size_params": {
      "max_bytes": "10240",
      "max_gas": "-1"
    },
    "block_gossip_params": {
      "block_part_size_bytes": "65536"
    },
    "evidence_params": {
      "max_age": "100000"
    }
  }

Right now, in consensus params we have TxSize.MaxBytes, which is supposed to limit the size of a single transaction. It's enforced in the mempool (>= 0.24.0), but not in the consensus when we validate a block ("A proposer running different mempool code could include txs larger than TxSize.MaxBytes".)

There are two ways we can go:

1. Enforce TxSize.MaxBytes in the consensus.
2. Get rid of TxSize.MaxBytes and use BlockSize.MaxBytes & TxSize.MaxGas to limit transactions.

1) Enforce TxSize.MaxBytes in the consensus.

This gives you more control as you can have different values for tx / block maximums (e.g., TxSize.MaxBytes: 1KB and BlockSize.MaxBytes: 10MB).

NOTE: we can allow -1 for unlimited transactions (~ up to BlockSize.MaxBytes).

Questions:

• Is it worth it? What if we remove it? Will it make Tendermint-based networks more fragile to DDOS where an attacker floods the network with large transactions (tx size ~ maximum block size)?

2) Get rid of TxSize.MaxBytes and use BlockSize.MaxBytes & TxSize.MaxGas to limit transactions.

This reduces the surface area (number of config parameters). Other blockchains seems to be doing fine with tx gas (TxSize.MaxBytes) and block max size (BlockSize.MaxBytes).

===========

Original discussion: #2184 (comment)