fix: allow BLOB_SCHEDULE: [] field

[barnabasbusa]

Now empty blob schedules from config.yaml (like BLOB_SCHEDULE: []) will be preserved and included in the /eth/v1/config/spec beacon API endpoint response instead of being omitted.

Issue Addressed

Which issue # does this PR address?

Proposed Changes

Please list or describe the changes introduced by this PR.

Additional Info

Please provide any additional information. For example, future considerations
or information useful for reviewers.

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[barnabasbusa]

CI fails for kurtosis because the new array datatype requires assertoor to run ethpandaops/assertoor:fulu-support image.

We are looking into merging fulu supported branch into our master next week.

[mergify]

This pull request has been removed from the queue for the following reason: checks failed.

The merge conditions cannot be satisfied due to failing checks:

• ☑️ local-testnet-success

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[pawanjay176]

Waiting for assertoor fulu support to get merged.

[barnabasbusa]

@pawanjay176 I have added a condition to only set the blob schedule in the api if fulu is not far away epoch, so it should now pass without needing to have to update assertoor (unless you test fulu case with assertoor)

Assertoor latest release is out. Should have fixed this issue.

[jimmygchen]

for any client that does not yet return BLOB_SCHEDULE from /eth/v1/config/spec, I would suggest to only return it if FULU_FORK_EPOCH != FAR_FUTURE_EPOCH as otherwise you might run into interop issues with older client releases, at least I know that Vouch is not able to parse the array right now

from Nico (https://discord.com/channels/595666850260713488/1392770505387409449/1397145131387453512)

[michaelsproul]

haha called it

[michaelsproul]

@barnabasbusa Trying to understand whether we should merge this.

What is your goal in making blob_schedule: [] appear in the response? AFAICT the blob_schedule is irrelevant if Fulu is not scheduled, so it would be conceptually OK for us to avoid serializing it in when the Fulu fork epoch is not set (as Nico suggests). Unless that is exactly the case where you want to test for consistency between different client impls?

I think we have two options:

• Merge your PR as-is
  • Pros: simple, consistent with other CLs
  • Cons: probably breaks compatibility with current/old Vouch versions on pre-Fulu networks
• Merge my change from here michaelsproul@ea31631
  • Pros: maintains Vouch compatibility by not including Fulu params before Fulu, still shows blob_schedule: [] on Fulu networks
  • Cons: more complex implementation, doesn't allow testing blob_schedule: [] in the case where the Fulu fork epoch is not set.

Let me know if the second solution would be acceptable for your use case, as I think it's better to avoid breaking Vouch, and more consistent with how we usually handle future forks.

[barnabasbusa]

I'm happy with more complex solution to only have blob schedule when fulu is scheduled.

[michaelsproul]

Niiice, thanks

Closing in favour of:

• Skip serializing blob_schedule before Fulu #7779

Sorry to deny you a nice little green contribution dot @barnabasbusa 😭