REST API produceBlockV3 implementation

[cheatfate]

No description provided.

[github-actions]

Unit Test Results

         9 files  ±0    1 098 suites  ±0   27m 0s ⏱️ -24s
  3 953 tests +1    3 606 ✔️ +1  347 💤 ±0  0 ❌ ±0 
16 072 runs  +3  15 674 ✔️ +3  398 💤 ±0  0 ❌ ±0 

Results for commit 4d8ed25. ± Comparison against base commit ab5343d.

♻️ This comment has been updated with latest results.

[tersec]

Would be good to either note as explicitly non-spec, or if it's derived from, e.g., a Beacon API requirement fairly directly (it's the type required by or returned by some REST endpoint), link to a stable, not master/main/etc URL for that.

[tersec]

Why would the REST server ever have to read a BlindedBeaconBlock it doesn't know the specific fork of already? It's for proposing, in the moment, and if it doesn't match the current slot/epoch it's not relevant to the node.

[cheatfate]

This is not for REST server it is made for VC, because VC will use this readValue procedure to decode produceBlockV3 response.

[tersec]

The VC knows too though. It knows the fork schedule and if it's asking for a produceBlockV3 response during Capella, anything except a Capella response is simply an error.

[etan-status]

The REST library uses a single type for each API, so the Forked type is needed here I think.

[tersec]

It apparently needs ForkedAndBlindedBeaconBlock here primarily because it's storing one as message, but then it immediately does two things with this message:

1. calls getHeaders (defined above); and
2. calls RestApiResponse.sszResponse, not even on the Forked type per se, but on each specific case object field. See question there about why writeValue is defined on ForkedAndBlindedBeaconBlock, as a result.

But neither really requires storage of a forked/"any fork" version of a BlindedBeaconBlock or BlindedBeaconBlockContents, because what this produceBlockV3 endpoint returns is neither, but a bytestring of some sort (e.g., SSZ). So it's still unclear to me why have all this infrastructure for a ForkedAndBlindedBeaconBlock which seems not to be necessary to begin with.

The result is hundreds of lines of

[etan-status]

I think you need some form of ForkedBlindedBeaconBlock, because v3 may return either forked or non-forked depending on which one is better. And that is not known at call-time.

This, unless you want to do that logic inside the REST layer, which doesn't seem correct, because it makes it non-reusable, e.g., for the non-VC local block proposal flow.

Also having a Forked type instead of forky MaybeBlindedBeaconBlock makes it consistent with the existing v1/v2 makeBeaconBlockForHeadAndSlot which also returns a ForkedBeaconBlock.

[tersec]

Is this entire loop, with its specifically handwritten multiple-field detection, etc, not basically equivalent to something like

type
  RestForkedAndBlindedBeaconBlockSkeleton = object
    version: Opt[string]  # because it otherwise has to do a special conversion
    blinded: Opt[bool]
    executionValue: Opt[UInt256]
    consensusValue: Opt[UInt256]
    data: Opt[JsonString]

and then letting the JSON parser handle this, or would it not detect multiple fields with each name?

It seems like recreating logic that exists elsewhere.

[etan-status]

there's also strictParse for the other fields and so on.