All milestones are set to zero in the devnet network genesis file due to engine_getPayloadV3 not being enabled

[thinkAfCod]

Description

auto generated genesis file by ethpandaops/optimism-package:

{
  "config": {
    "chainId": 2151908,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "muirGlacierBlock": 0,
    "berlinBlock": 0,
    "londonBlock": 0,
    "arrowGlacierBlock": 0,
    "grayGlacierBlock": 0,
    "mergeNetsplitBlock": 0,
    "shanghaiTime": 0,
    "cancunTime": 0,
    "bedrockBlock": 0,
    "regolithTime": 0,
    "canyonTime": 0,
    "ecotoneTime": 0,
    "fjordTime": 0,
    "graniteTime": 0,
    ...
}

All block or timestamp milestone will be zero.

In besu:

  private NavigableMap<Long, BuilderMapEntry> buildFlattenedMilestoneMap(
      final List<BuilderMapEntry> mileStones) {
    return mileStones.stream()
        .collect(
            Collectors.toMap(
                BuilderMapEntry::blockIdentifier,
                b -> b,
                (existing, replacement) -> replacement,
                TreeMap::new));
  }

It will only contain last time milestone.

In ExecutionEngineJsonRpcMethods:

if (protocolSchedule.anyMatch(p -> p.spec().getName().equalsIgnoreCase("cancun"))) {
  executionEngineApisSupported.add(
      new EngineGetPayloadV3(
          consensusEngineServer,
          protocolContext,
          mergeCoordinator.get(),
          blockResultFactory,
          engineQosTimer,
          protocolSchedule));
}

The EngineGetPayloadV3 will be included in the supported list only if p.spec() equals to cancun.

Could there be a range, or something else?

[matkt]

The issue seems to come from the fact that we don't have an inheritance mechnaism similar to the one used for GasCalculator when adding EngineAPIs. Currently, we add the Engine APIs fork by fork, meaning that if we have the Cancun fork, we add the APIs specific to Cancun.

if (protocolSchedule.anyMatch(p -> p.spec().getName().equalsIgnoreCase("cancun"))) {
  executionEngineApisSupported.add(
      new EngineGetPayloadV3(
          consensusEngineServer,
          protocolContext,
          mergeCoordinator.get(),
          blockResultFactory,
          engineQosTimer,
          protocolSchedule));
}

The problem is that we also have another mechanism that conflicts with this logic. If multiple forks are activated at the same time, we perform a flattening and only retain the last one. For example, if Cancun=0 and Prague=0, we would end up only with Prague. This is a scenario that can occur in testnets, for instance.

This is not an issue for the GasCalculator because PragueGasCalculator inherits from CancunGasCalculator, meaning that we retain the rules from previous forks. The problem with the Engine API part is that if we add a specific API in Cancun, it won't be included because Prague will be detected as the only one active fork.

In my opinion, we need to revisit the logic of this part to create something similar to the GasCalculator mechanism, with an inheritance model for defining APIs. what do you think @daniellehrner @siladu

[matkt]

@thinkAfCod Can you use a workaround to unblock yourself and move forward while we work on adding a fix on our end? I think it might take some time, and I don’t want this to block you.

[daniellehrner]

I've created a PR that should fix the issue: hyperledger/besu#8136