add --max-blobs cli flag and only check maxBlobsPerBlock >= maxBlobsPerTransaction if it's a public Ethereum network

[daniellehrner]

PR description

Adding the --max-blobs flag to restrict how many blobs a block builder will include independently of how many are avaialable in the tx poool.

Fix an issue with the blob schedule where Ethereum network blob restrictions where also imposed on Linea and other networks with a custom genesis file.

Fixed Issue(s)

fixes #7683

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[fab-10]

this works, but using enum ordinals seems fragile, why not leverage something derived from MilestoneDefinitions::createMainnetMilestoneDefinitions where we manually enforce the orders?

[fab-10]

why this special case for Osaka, what will happen for future hardforks?

[fab-10]

is it correct to say that if hardfork == MainnetHardforkId.OSAKA then opts.getBlobSchedule(hardfork) is not empty?
If so the code in or is not needed

[fab-10]

Suggested change

	"maxBlobsPerTransaction (%s) must not be greater than maxBlobsPerBlock (%s) for %s. "
	"maxBlobsPerTransaction (%d) must not be greater than maxBlobsPerBlock (%d) for %s. "

[fab-10]

is the option name fixed, or it can be extended to tell that the number if per transactions, to avoid ambiguity with per block, etc...

[fab-10]

while be nice to have a test about the failure, when max block per tx is greater than max blol per block

[fab-10]

it seems this value cannot be changed at runtime, so it should not be part of mutable values

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Gabriel-Trintinalia]

I really don’t think DEFAULT_MAX_BLOBS_PER_TRANSACTION should live in MiningConfiguration. It really belongs in OsakaTargetingGasLimitCalculator. While the same constant exists there today, it’s only used by tests in this PR. That means if a future fork changes the default, we’d have to change it through the mining configuration, which isn’t ideal. The default should exist in a single place: the TargetingGasLimitCalculator implementations.

A cleaner approach is to make maxBlobsPerTransaction in MiningConfiguration an OptionalInt that defaults to empty. If the user doesn’t explicitly set --max-blobs, we pass OptionalInt.empty() and let the TargetingGasLimitCalculator apply its own constant depending on the fork. This makes the code more resilient to future protocol changes.

Regarding the maxBlobsPerBlock >= maxBlobsPerTransaction check, I’m fine either removing it entirely or not treating L1s and L2s differently. The protocol doesn’t define that behaviour, so Besu shouldn’t enforce it. If we keep the check, L2s can bypass it by setting the blob schedule to zero and --max-blobs=0, so the current logic doesn’t actually enforce anything meaningful.