feat(protocol): switch to default EIP1559 implementation post Ontake fork

[dantaik]

Since block time no longer has any impact on L2's 1559 basefee calculation, we can switch to use the default EIP1559 implementation and relaying on proofs to verify the L2 basefee is correct, without doing it in the L2's anchor function.

@davidtaikocha @smtmfft lets briefly go over it tomorrow.

@k-kaddal if we merge this PR, it means you don't need to learn our own EIP-1559 math at all.

[openzeppelin-code]

feat(protocol): switch to default EIP1559 implementation post Ontake fork

Generated at commit: 9544673b1aee013d4c7a39d35cb5a2adaa369830

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 8 42 54
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[Brechtpd]

Since block time no longer has any impact on L2's 1559 basefee calculation

Not sure I follow, what mechanism will be used to calculate the basefee now that makes it possible to use the default formula?

[dantaik]

Since block time no longer has any impact on L2's 1559 basefee calculation

Not sure I follow, what mechanism will be used to calculate the basefee now that makes it possible to use the default formula?

Previous implementation assume block space (gas) will be issued per second (based on the L2 block's timestamp), the new implementation issues gas per L2 block, without time as an input.

EDIT

Given Ethereum's current EIP-1559 mechanism, a malicious block proposer could theoretically attack the protocol by submitting numerous small blocks to lower the base fee. This strategy would come at a cost to the proposer, as they would be willing to spend more Ether on these smaller blocks.

The attacker could then suddenly cease proposing blocks. Other block proposers might be reluctant to propose blocks because the current base fee would be too low to make a maximum-sized block profitable.

However, this attack can be mitigated if:

• There are sufficient users and transactions to build larger blocks.
• Other rational block proposers are present in the network.

These rational proposers could outcompete the malicious actor by paying a higher base fee for much larger blocks, provided there are enough transactions to fill such blocks.

For a network like Taiko's mainnet in its early stages, a relatively lower base fee might not be fatal and could even be seen as a feature to encourage early user adoption.

So I think we should try this simple approach (the Ethereum's current EIP-1559 math is simpler and well tested) and be open to further improvements.

[Brechtpd]

Given Ethereum's current EIP-1559 mechanism, a malicious block proposer could theoretically attack the protocol by submitting numerous small blocks to lower the base fee. This strategy would come at a cost to the proposer, as they would be willing to spend more Ether on these smaller blocks.

This behavior is very dependent on the current protocol implementation though where there is a fixed cost per block. It is possible to have the block proposing/proving cost onchain be unrelated to number of blocks. In which case the basefee can be arbitrarily manipulated by proposers (if it's high the proposer simply proposes empty block first to force the basefee down, or the basefee never increases to begin with because bigger than average blocks are never proposed). And so optimizing the protocol could break the EIP 1559 mechanism if it depends on costs.

However, this attack can be mitigated if:

* There are sufficient users and transactions to build larger blocks.

* Other rational block proposers are present in the network.

These rational proposers could outcompete the malicious actor by paying a higher base fee for much larger blocks, provided there are enough transactions to fill such blocks.

This seems incompatible with preconfirmations, where only a single preconfer can propose blocks.

So I think we should try this simple approach (the Ethereum's current EIP-1559 math is simpler and well tested) and be open to further improvements.

It is simpler and well tested, but in a significantly different setting with fixed block times and "free" block proposing. Also the current normal basefee calculation is only done this way for legacy reasons, the blob basefee is calculated in almost the exact way we calculate it: https://github.com/taikoxyz/revm/blob/v35-taiko/crates/primitives/src/utilities.rs#L24. So once we stop calculating the basefee in the anchor tx, we could also just use this standard and well tested Ethereum code as well.

[dantaik]

@Brechtpd Thanks for the feedback. After some thought, I still think we should go ahead with this change. The way our protocol works now isn't really different from Ethereum's 1559 setup – they both use L2 block numbers for gas issuance input instead of block time. The only real difference is the math.

[Brechtpd]

@Brechtpd Thanks for the feedback. After some thought, I still think we should go ahead with this change. The way our protocol works now isn't really different from Ethereum's 1559 setup – they both use L2 block numbers for gas issuance input instead of block time. The only real difference is the math.

The big difference is that for L1 there is always a single block each 12 seconds, and for L2 this is not true right? The L1 formula implicitly takes time into account because it directly depends on those constraints! If an L1 proposer would be able to propose multiple blocks per L1 slot things would not work because for L1 proposing a block is free, and so like I explained above the proposer would always be able to reduce the basefee to 0 first before proposing any block containing transactions.

Without taking time into account, there is also no upper limit on the throughput on L2. It is possible to consume an infinite amount of gas on L2, the only limitation would be how inefficient it is to propose/prove a block (which can go down to 0, but even currently would be up to 15M/400k == 37 blocks of 60M gas? per L1 block == 2200M gas per L1 block).

This problem could be solved by summing up all the gas used of all the L2 blocks inside a single L1 block and then using that in the L1 EIP1559 formula. But that is just a more complicated way of what we are currently doing.

I don't know how the L1 formula could work without fixed block times, unless the arguments I gave can be solved some way, otherwise I don't see how we can go ahead with this change.

[dantaik]

@Brechtpd Thanks for the feedback. After some thought, I still think we should go ahead with this change. The way our protocol works now isn't really different from Ethereum's 1559 setup – they both use L2 block numbers for gas issuance input instead of block time. The only real difference is the math.

The big difference is that for L1 there is always a single block each 12 seconds, and for L2 this is not true right? The L1 formula implicitly takes time into account because it directly depends on those constraints! If an L1 proposer would be able to propose multiple blocks per L1 slot things would not work because for L1 proposing a block is free, and so like I explained above the proposer would always be able to reduce the basefee to 0 first before proposing any block containing transactions.

Without taking time into account, there is also no upper limit on the throughput on L2. It is possible to consume an infinite amount of gas on L2, the only limitation would be how inefficient it is to propose/prove a block (which can go down to 0, but even currently would be up to 15M/400k == 37 blocks of 60M gas? per L1 block == 2200M gas per L1 block).

This problem could be solved by summing up all the gas used of all the L2 blocks inside a single L1 block and then using that in the L1 EIP1559 formula. But that is just a more complicated way of what we are currently doing.

I don't know how the L1 formula could work without fixed block times, unless the arguments I gave can be solved some way, otherwise I don't see how we can go ahead with this change.

If you look at the current code in TaikoL2.sol (with modification to cope for preconfirmation):

getBasefee no longer takes block time as input. See below:

So the change I proposed in this PR just assumes the above, previous change is OK and only switch the math equation.

If you disagree with the previous change (removing block time as an input), then it shall be added back. BUT, then there is another issue of basefee manipulation - the block proposer can always choose the smallest L2 time possible, even for multiple blocks he propose in a row, to issue as little gas as possible to increase the basefees dramatically. If he managed to proposer multiple blocks in a row by using the same minimal time for all these blocks, then there is no gas issued in his second, third ... blocks so the basefees are highly manipulative. And when the next proposer proposed a block, then there could be a very large number of gas issued then the basefee will drop dramatically. This is possible after the change introduced by preconfirmations - proposers now choose L2 block time, without being enforced by the protocol using L1's current block time.

[Brechtpd]

So the change I proposed in this PR just assumes the above, previous change is OK and only switch the math equation.

Oh I see, looks like I missed that.

If you disagree with the previous change (removing block time as an input), then it shall be added back.

Hopefully my concerns are clear, if they are correct and can't be worked around I think it's potentially a big problem.

BUT, then there is another issue of basefee manipulation - the block proposer can always choose the smallest L2 time possible, even for multiple blocks he propose in a row, to issue as little gas as possible to increase the basefees dramatically. If he managed to proposer multiple blocks in a row by using the same minimal time for all these blocks, then there is no gas issued in his second, third ... blocks so the basefees are highly manipulative. And when the next proposer proposed a block, then there could be a very large number of gas issued then the basefee will drop dramatically. This is possible after the change introduced by preconfirmations - proposers now choose L2 block time, without being enforced by the protocol using L1's current block time.

Definitely some more manipulation possible now from the protocol's point of view. Normally it's not in the proposer's best interest to artificially increase the basefee just for its own block because the proposer does not get any of the basefee being burned and it also reduces what transactions can be included in his own blocks (tx.max_base_fee < basefee).

However, it's not because the protocol cannot directly enforce "good" L1 block times being used we cannot do it on a different level. For example, an idea I had is to actually still force the preconfer to use a recent timestamp/L1 block but to enforce this on the block builder level using TEEs where we are free from L1 block time limitations.

[dantaik]

Normally it's not in the proposer's best interest to artificially increase the basefee just for its own block because the proposer ...

This analysis likely holds true for rational proposers.

I've created a pull request (PR) to reintroduce time input for EIP-1559 calculations: . We can gain some insights into the impact of base fee manipulation by investigating into behavior patterns on the Taiko mainnet. These are hard to test/predict on testnets.

[dantaik]

Marked this PR as a draft in favor of the other one