Cap the size of the transaction to reduce strain on network

[cmwaters]

Summary

Similar to how Celestia has constraints on block and square size to ensure that the network does not fall over under excess demand, we should also consider adding constraints to the max tx size and max number of transactions.

Currently we do have an antehandler that sets the max tx size to the size of the current max block (note that nodes can locally set a smaller max tx size for their mempool). However, as the block jumps to 8MB, having to gossip an 8MB transaction without any chunking could be detrimental to the network. As a precaution we should set a max size that is no longer equal to the block size. This also makes it easier for submitters to know how large they should batch their transactions.

[cmwaters]

Does this require a CIP (It is technically a consensus breaking rule)?

What would we want to set this size to? 1MB? 2MB?

[evan-forbes]

yeah, this would require at least 1 CIP, but as touched on above, the reasoning for the two is quite distinct so we might want to do 2 separate things.

The cap on tx size is difficult, as users have indicated that larger blobs can help things like "super blobs". The protocol also might not need such a limit until blocks are increased to meaningfully larger than > 4MB. Configurations and expectations could also just need to be changed for larger txs. Larger txs take longer to gossip, therefore users should not expect them to be included within the typical 2 block period. For the same reason, proposers using any flavor of compact blocks change their calculations for inclusion of large txs. If that's the case, then maybe we don't need a limit.

The cap on the number of txs seems much less difficult to find an effective number and to see the urgency. At least for the medium term. This might be needed sooner rather than later as well, considering 5000 txs can already fit in a 2MB block.

[cmwaters]

The cap on the number of txs seems much less difficult to find an effective number and to see the urgency. At least for the medium term. This might be needed sooner rather than later as well, considering 5000 txs can already fit in a 2MB block.

But if the problem here is with execution costs, then don't we want to go about this by setting a max gas?

[cmwaters]

The protocol also might not need such a limit until blocks are increased to meaningfully larger than > 4MB

That could be the case, but that's on the horizon. Ideally we add the cap before we increase such that it has less impact on current users

[evan-forbes]

setting a max gas?

by this, are you referring to setting the max gas value to something other than -1? adjusting resource pricing is a great alternative to simply hardcoding the max number of txs! That seems like a bit more complex of a problem if we continue to price blobs in the same unit as doing things with state.

[cmwaters]

by this, are you referring to setting the max gas value to something other than -1?

Yup, I think this would be better if we can calculate a reasonable upper bound

[evan-forbes]

after a sync discussion, we can first have a soft cap via overriding the mempool config in a patch release, and then a consensus critical hardcoded parameter pending a CIP.

[rootulp]

we can first have a soft cap via overriding the mempool config in a patch release

A soft cap on the number of transactions in the mempool or the size of an individual transaction?

[rootulp]

Clarified during a call: the soft cap is proposed for the size of an individual transaction:

[mempool]

max_tx_bytes = 7897088

and not for the number of transactions in the mempool.

[adlerjohn]

Strong approve of this proposal (both the max transaction size and the max number of transactions or just in general max resource consumption of the Celestia state machine).

I'd suggest a maximum number of bytes for a single transaction to be limited to the current ~2 MB, and increasing it only after carefully studying the effects of larger transaction sizes, since the current benchmarking etc. is more focused on larger block sizes. The max transaction size can be increased later as needed, but setting it to ~2 MB to start at least users can continue submitting any blob they could submit today.

[musalbas]

I'm not sure a tx size limit needs to be consensus critical, perhaps it can just be a mempool param.

Like if a validator makes a block with a 32mb tx they received out of band, I don't think that causes any issues

[cmwaters]

EDIT: I have split this out into two different issues. You can find the discussion on limiting the amount of computation here: https://github.com/celestiaorg/celestia-app/issues/3820