fix: Parse blocks sent by builder with fork version. by bharath-123 · Pull Request #63 · bharath-123/mev-boost-relay

bharath-123 · 2025-07-31T16:34:50Z

📝 Summary

Make parsing of blocks sent via SubmitNewBlocks to VersionedSubmitBlockRequest dependent on fork version.

⛱ Motivation and Context

When receiving blocks from the builder via SubmitNewBlocks API, we parse the block to its corresponding fork specific VersionedSubmitBlockRequest. With the Fusaka hard fork, the VersionedSubmitBlockRequest for Fulu and Electra are the same since the only change is the addition of cell_proofs which are just extended blob proofs. The current way of unmarshalling the payload unmarshalls an Electra VersionedSubmitBlockRequest to a Fulu one.

To avoid such incidents, we want to parse the incoming block specifc to the fork.

The builder doesn't send the Eth-Consensus-Version like the proposers do, so we need to infer the fork version to parse the VersionedSubmitBlockRequest. To do this, we parse the value of the slot from the raw payload bytes. Based on the slot, we parse the payload according to the corresponding fork version.

✅ I have run these commands

make lint
make test-race
go mod tidy
I have seen and agree to CONTRIBUTING.md

jtraglia · 2025-08-01T19:40:37Z

services/api/service.go

+func (api *RelayAPI) getForkFromSlot(slot uint64) spec.DataVersion {
+	if api.isFulu(slot) {
+		return spec.DataVersionFulu
+	} else if api.isElectra(slot) {
+		return spec.DataVersionElectra
+	} else if api.isDeneb(slot) {
+		return spec.DataVersionDeneb
+	} else if api.isCapella(slot) {
+		return spec.DataVersionCapella
+	}
+	return spec.DataVersionPhase0
+}


This would be a little cleaner as a switch:

func (api *RelayAPI) getForkFromSlot(slot uint64) spec.DataVersion { switch { case api.isFulu(slot): return spec.DataVersionFulu case api.isElectra(slot): return spec.DataVersionElectra case api.isDeneb(slot): return spec.DataVersionDeneb case api.isCapella(slot): return spec.DataVersionCapella default: return spec.DataVersionPhase0 } }

jtraglia · 2025-08-01T19:41:19Z

services/api/service.go

-	if contentType == ApplicationOctetStream {
+	if contentType == "application/octet-stream" {


Can we revert this change?

jtraglia · 2025-08-01T19:50:19Z

services/api/service.go

+	builderEthConsensusVersion := req.Header.Get(HeaderEthConsensusVersion)
+	if builderEthConsensusVersion == "" {
+		// don't reject a builder submission if the Eth-Consensus-Version header is not present
+		builderEthConsensusVersion = api.getForkFromSlot(latestSlot).String()
+		log.Warnf("builder did not send the Eth-Consensus-Version header, using latestSlot %d to infer the fork version: %s", latestSlot, builderEthConsensusVersion)
 	}


Instead of using the latest slot, I think we should try to use SubmitBlockRequest.message.slot (where message is BidTrace). This should solve this fork boundary issue; where a builder submits a Fulu block while latestSlot is still in Electra. This idea would require partial decoding, should be possible though.

ya ideally latestSlot would never be in electra, since payload attributes ideally always reflects the latest slot. But partially decoding the payload could be much more accurate.

bharath-123 · 2025-08-04T12:59:26Z

services/api/service.go

-			// SSZ decoding failed. try JSON as fallback (some builders used octet-stream for json before)
-			if err2 := json.Unmarshal(requestPayloadBytes, payload); err2 != nil {
-				log.WithError(fmt.Errorf("%w / %w", err, err2)).Warn("could not decode payload - SSZ or JSON")
+	builderEthConsensusVersion := req.Header.Get(HeaderEthConsensusVersion)


I am contemplating whether we should even have this header since we already have the fallback logic?

Yeah honestly might not even be necessary for submitNewBlock... Might prevent a bug though so I'd be in favor of keeping it. Eg a builder forgets to update their client and continues to build electra payloads in fulu.

bharath-123 · 2025-08-04T13:14:49Z

Tests are failing because the new submitBlock json payloads which are added can't be found in the CI run for some reason? And the lint is failing due to some dynamic return types. will look into them.

jtraglia · 2025-08-04T13:28:27Z

services/api/service.go

+	case api.isCapella(slot):
+		return spec.DataVersionCapella
+	default:
+		return spec.DataVersionPhase0


I think I missed this before. This should be bellatrix.

faheelsattar · 2025-08-05T08:22:26Z

common/types_spec.go

 }

+func (r *VersionedSubmitBlockRequest) UnmarshalWithVersion(input []byte, contentType, ethConsensusVersion string) error {
+	if contentType == "application/octet-stream" {


i think it will be better to replace it with ApplicationOctetStream variable? We can move it from service to constants inside the common package so it resolves in other places as well

ya thats a good idea

faheelsattar · 2025-08-05T10:31:12Z

services/api/utils.go

+}
+
+func getSlotFromBuilderSSZPayload(input []byte) (uint64, error) {
+	if len(input) < 4 {


shouldn't this be if len(input) < 8 since it might cause a panic when accessing input[4:8]

ya you are right. the check should be there.

faheelsattar · 2025-08-05T10:33:40Z

services/api/utils.go

+
+	messageOffset := binary.LittleEndian.Uint32(input[4:8])
+
+	slot := binary.LittleEndian.Uint64(input[messageOffset : messageOffset+8])


probably also need to add a check here before accessing
if messageOffset + 8 > len(input) throw error

jtraglia · 2025-08-06T12:44:15Z

services/api/service.go

-			return
+			slot, err := getSlotFromBuilderJSONPayload(requestPayloadBytes)
+			if err != nil {
+				log.WithError(err).Warn("could not get slot from builder ssz payload")


These error messages should be swapped right?

good catch! will do it

jtraglia

LGTM but you need to fix the CI checks.

bharath-123 added 3 commits July 24, 2025 17:16

add some debug logs

2043022

unmarshall submitted block based on fork

068e30c

devnet-3 related fixes

86268ac

jtraglia reviewed Aug 1, 2025

View reviewed changes

bharath-123 force-pushed the bharath/fulu-payload-parsing branch from 6e87b09 to 9a51a31 Compare August 4, 2025 09:24

bharath-123 commented Aug 4, 2025

View reviewed changes

jtraglia reviewed Aug 4, 2025

View reviewed changes

partially parse payload to infer fork version

d06635e

bharath-123 force-pushed the bharath/fulu-payload-parsing branch from b2fb3a0 to d06635e Compare August 4, 2025 16:25

faheelsattar reviewed Aug 5, 2025

View reviewed changes

bharath-123 added 4 commits August 6, 2025 14:40

address review comments

de388b1

add test

066f636

add ssz block payload

67a8de7

add tests for submitBlockPayload

8af3fbf

jtraglia reviewed Aug 6, 2025

View reviewed changes

jtraglia approved these changes Aug 6, 2025

View reviewed changes

faheelsattar approved these changes Aug 6, 2025

View reviewed changes

fix fmt + lint

a2ad020

bharath-123 force-pushed the bharath/fulu-payload-parsing branch from 064e0ec to a2ad020 Compare August 6, 2025 15:55

bharath-123 merged commit a657181 into bharath/fulu Aug 6, 2025
1 of 2 checks passed

bharath-123 deleted the bharath/fulu-payload-parsing branch August 6, 2025 16:02

bharath-123 mentioned this pull request Aug 6, 2025

feat: Add Fusaka support for MEV-Boost relay flashbots/mev-boost-relay#745

Merged

4 tasks

		if contentType == ApplicationOctetStream {
		if contentType == "application/octet-stream" {


		messageOffset := binary.LittleEndian.Uint32(input[4:8])

		slot := binary.LittleEndian.Uint64(input[messageOffset : messageOffset+8])

Conversation

bharath-123 commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📝 Summary

⛱ Motivation and Context

✅ I have run these commands

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 commented Aug 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

faheelsattar Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jtraglia left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bharath-123 commented Jul 31, 2025 •

edited

Loading

faheelsattar Aug 5, 2025 •

edited

Loading