feat(protocol): reenable time as basefee calculation input

[dantaik]

BEGIN_COMMIT_OVERRIDE
feat(protocol): revert removing time as input for L2 base fee calculation
feat(protocol): adjust gas excess once the gas target has changed
END_COMMIT_OVERRIDE

---

Here's an improved version of the PR description:

Background

Protocol changes for preconfirmation allow block proposers to select L2 block timestamps within a certain range. If base fee calculation uses a block's time (time since its parent block) as an input, it becomes susceptible to manipulation by the proposer. While the full impact of such manipulation is yet to be determined, it's prudent to address this issue.

We are considering two primary options:

Option 1: Remove block time from base fee calculation

This approach is currently implemented in the main branch prior to this PR. However, as noted by Brecht, this may introduce other issues. If removing the time input is acceptable, it would be logical to adopt the Ethereum client's default implementation for the EIP-1559 calculations. This is the goal of PR #17857.

Option 2: Retain block time as an input and accept potential base fee manipulation

This PR reintroduces block time as an input but does not implement measures to prevent manipulation.

An implementation detail

When two consecutive blocks have identical block times, no additional gas is issued for the second block, resulting in a slightly higher base fee for the second block compared to the first. This means that splitting a single block into two smaller ones (containing the same transactions) has different base fee implications. We could modify the code to ensure that the base fee remains consistent across multiple consecutive blocks with identical timestamps. However, I'm not convinced that this adjustment is necessary or beneficial.

---

I am currently undecided between these two options. Hope to learn more from the rest of the team...

[openzeppelin-code]

feat(protocol): reenable time as basefee calculation input

Generated at commit: 76444bf8a5a6906ecff3ecd9e740b0a262ebde24

🚨 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

[dantaik]

@Brechtpd @adaki2004 this PR is ready for another look.

[adaki2004]

I like this one.
Realistically in production it is more hard to manipulate this nr.2 one (even with preconfs) - tho possible to but the gain is less significant as you said. Perfect solution (sum up all the gas) would require extra work which does not worth the effort, given that the basefee shall be a small enough.

(In case of huge influx of traffic and demand, if a single preconfer is present, he/she can game this tho, but still not up to a level which is gameable now (main branch) imo.)