Increase txMaxSize to 512kb from 128kb to help support on chain data availability in rollups.

[joeandrews]

Rationale

Why should this feature exist?

L2 zkrollups that support on chain data availability need to send a large amount of call data to the Ethereum blockchain to ensure the liveness of their networks. Limiting this to 128kb (far below the block gas limit) introduces a cap on the max TPS a zkrollup can do with on chain data availability.

What are the use-cases?

Increasing the cap to 512kb would allow a zkRollup like Aztec to bundle ~500txs in a single block instead of 112.

Implementation

Do you have ideas regarding the implementation of this feature?

I would like to ask the community to opine on the effects of increasing this cap, and if this may cause problems for geth client, other clients or the network in general?

Are you willing to implement this feature?

Aztec would be willing to contribute development resources to implement this feature.

[joeandrews]

The source code in question is here: https://github.com/ethereum/go-ethereum/blob/master/core/tx_pool.go#L53

[joeandrews]

Previous discussion for EIP 2028 can be found here. https://ethereum-magicians.org/t/eip-2028-transaction-data-gas-cost-reduction/3280.

If there are no objections, I will make a PR to make the change in tx_pool.go.

[MariusVanDerWijden]

I think we have some objections to this kinda change. I'll bring it up in our next meeting

[holiman]

Considering that we do get a number of issue reports about memory going out of bounds, where the root cause often seems to be the memory usage in the txpool, it might definitely be problematic to further raise the limit.

[joeandrews]

What would happen if transactions >128kb started being mined by other clients or existed in the mempool?

[holiman]

If they were just included in blocks, it wouldn't be a big deal, from the perspective of the txpool. They wouldn't blow up txpool nor would they add network overhead when passed between peers.

Theoretically, it shouldn't be an issue with the txpool either way though, because we have this notion of how many slots a tx takes up, so it might be fine.

(whether they would be problematic from block propagation perspective, if blocks suddenly were full of 512kb transactions, that's another question which I don't have any answer for).

[karalabe]

Is there any project already using such proofs live on mainnet? My guess would be that we'd need to wait until there's actual use that we can see the effect of, and then gradually go from 128 to whereever in smaller increments. Yes, this would take time, but it's easier to react to a small clog than to have to update the entire network because it just went belly up and we need to undo a release.

[joeandrews]

Hi @karalabe Yep, Aztec is already constrained by the 128kb limit. We are currently maxed out at 112 transactions per rollup. I can send across a local transaction payload if that would be helpful with much higher call data? Below is our main-net transaction.

Due to the way the rollup works, our circuits need to increase in powers of 2. This next circuit size would be ~224 transactions which is ~200kb of call data. Would an initial increase to 256kb be feasible?

Main-net tx with ~100kb of call data.

https://etherscan.io/tx/0xa21724a4b64f50e84cbebfcafbcd662538eff3e4c453e0c925eae306b9a06ef3

[karalabe]

Well, as long as there's one large tx every day that doesn't really help us figure out how the network behaves unfortunately. Raising the limits but the network not using it is dangerous because you don't see how it may be abused by an attacker (not using it all the time I mean). That's the rationale why we're a bit hesitant.

[joeandrews]

I am curious how EIP4488 would affect this decision. Rollup transactions will want to be close to the proposed block limit, but far higher than the 128kb in GETH. Would you be open to a PR to persist the tx_pool out of memory?

ethereum/EIPs#4488

[MariusVanDerWijden]

I think this issue can be closed now with 4844 coming up. With 4844 we will disallow blob transactions to be broadcasted and only fetch them if announced. This will mitigate some of the dos issues we have with big transactions