feat(protocol): Gas limit behavior changes

[Brechtpd]

Follow up on #14087

• Updates the how to prove blocks document
• Removes the input.gasLimit > config.blockMaxGasLimit check in the smart contract

Also changes meta.gasLimit to simply always equal config.blockMaxGasLimit, this change could be reverted if that requires too many changes in other places as well, the circuits can simply ignore. input.gasLimit is not used anymore and could also be removed.

There seem to be two tests failing, but unrelated to my changes I think.

[dantaik]

Also changes meta.gasLimit to simply always equal config.blockMaxGasLimit, this change could be reverted if that requires too many changes in other places as well, the circuits can simply ignore. input.gasLimit is not used anymore and could also be removed.

Brecht, will this force all L2 blocks to be large and small blocks won't be proposed, as on L2, the 1559 gas price is calculated using the block's gas limit:

If this is true, then the confirmation latency will be larger if there are not enough transactions.

[Brechtpd]

The block gas limit is only used as the delta for the new base fee (the extra amount of gas that is bought), so how much this impacts the basefee depends on how fast the EIP-1559 base fee changes. We don't want the basefee to change that fast, so just using the worst case scenario for the new block should have practically no impact on the calculated basefee.The other costs like the L1 tx cost )and maybe the prover cost as well) will have a much bigger impact on making proposers think twice submitting smaller blocks.

If the basefee has a non-zero value then that also means there is congestion, so in that case the proposer will want, and should be able to, create full blocks as well. If there aren't enough transactions to fill up blocks the basefee will be 0.

[dantaik]

@adaki2004 @davidtaikocha @cyberhorsey please take a look at this PR.

[dantaik]

We don't want the basefee to change that fast, so just using the worst case scenario for the new block should have practically no impact on the calculated basefee.

Brecht, after a second thought, I feel like there may still be an issue. With the current change, we forces L2 proposer to purchase blockMaxGasLimit gas through EIP1559. But ideally, the block proposer may want to dry-run the transactions and only purchase enough gas, for example, 10% more than try-run result. Then on L2, the base fee will be smaller compared to purchasing blockMaxGasLimit gas, which will allow the proposer to earn more transaction fees.

As of EIP-1559, the overall fee a transaction creator pays is calculated as: ( (base fee + priority fee) x units of gas used).

[Brechtpd]

Making the basefee dependent on what is done in the current block makes block building very tricky, because that would mean that depending on what transactions are included in a block, will also impact what transactions can actually be included and how those transactions are executed. This is also different than how blocks are built for Ethereum.

It's also only additional gas purchased used for the basefee calculation for the current block, so the difference will be really tiny no matter what value is used and have no impact on the basefee of future blocks. The assumption is also that all blocks will be be full when there's congestion (basefee > 0), because if there is no congestion and there aren't enough transactions the basefee == 0 and so purchasing the full block gas limit will have no noticeable impact on the calculated basefee.

It's possible to just purchase 0 gas for the current block instead. I just think it will be more accurate (and a bit safer) to just purchase the max amount because it will be a much better estimate because full blocks are expected. But in the end I think purchasing 0 gas or the block gas limit is only a theoretical difference here.

[dantaik]

Making the basefee dependent on what is done in the current block makes block building very tricky, because that would mean that depending on what transactions are included in a block, will also impact what transactions can actually be included and how those transactions are executed. This is also different than how blocks are built for Ethereum.

It's also only additional gas purchased used for the basefee calculation for the current block, so the difference will be really tiny no matter what value is used and have no impact on the basefee of future blocks. The assumption is also that all blocks will be be full when there's congestion (basefee > 0), because if there is no congestion and there aren't enough transactions the basefee == 0 and so purchasing the full block gas limit will have no noticeable impact on the calculated basefee.

It's possible to just purchase 0 gas for the current block instead. I just think it will be more accurate (and a bit safer) to just purchase the max amount because it will be a much better estimate because full blocks are expected. But in the end I think purchasing 0 gas or the block gas limit is only a theoretical difference here.

Created a PR https://github.com/taikoxyz/taiko-mono/pull/14388/files to make sure L2 1559 basefee calculation is independent of gas limit, bur depend on gas used.