/eth/v3/validator/blocks/{slot_id} inserting default graffiti

[mcdee]

Describe the bug

Sending a request to the /eth/v3/validator/blocks/{slot_id} endpoint with an explicitly empty graffiti returns a block with default graffiti.

To Reproduce

curl -s http://localhost:5052/eth/v3/validator/blocks/$(ethdo --connection=http://localhost:5052 chain status | grep 'Current slot' | sed -e 's/Current slot: //')'?graffiti=0x0000000000000000000000000000000000000000000000000000000000000000&skip_randao_verification&randao_reveal=0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' | jq -r .data.body.graffiti
0x4e696d6275732f7632342e322e302d3734326631352d73746174656f66757300

Additional context

nimbus_beacon_node --version
Nimbus beacon node v24.2.0-742f15-stateofus
Copyright (c) 2019-2024 Status Research & Development GmbH

eth2 specification v1.4.0-beta.6

Nim Compiler Version 1.6.18 [Linux: amd64]

[etan-status]

The reproduction instructions can't be correct, as the graffiti is in .data.block.body.graffiti not in .data.body.graffiti.

Running this against my local Nimbus-BN also suggests that this is not an issue:

% curl -s http://localhost:5052/eth/v3/validator/blocks/$(~/Downloads/ethdo --connection=http://localhost:5052 chain status | grep 'Current slot' | sed -e 's/Current slot: //')'?graffiti=0x0000000000000000000000000000000000000000000000000000000000000000&skip_randao_verification&randao_reveal=0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' | jq -r '.data.block.body.graffiti'
0x0000000000000000000000000000000000000000000000000000000000000000

I suspect that something is going wrong with your inlined shell expression for ethdo, maybe there is an extra space somewhere, messing up the request so that the parameters are not properly sent.

[mcdee]

The reproduction was a quick attempt to show the issue, which could be incorrect, but there is definitely some issue. For example, on holesky a recent call to nimbus was:

/eth/v3/validator/blocks/1112275?randao_reveal=0xa020788cc586dbeec83f96afd96eacc5f435325708ba161e5d609a18513d52e508d77381d3de9cb9e3fd6a78aec663af19c3a335b3124c68c4622c623902fec6e24644d01262f701e1dd18a5c42e378ff4133ca7d8f25af7ce82b2d7c455c4d9&graffiti=0x417474657374616e742f566f7563680000000000000000000000000000000000&builder_boost_factor=100

and Vouch flagged an error for the data nimbus returned:

beacon block proposal has graffiti 0x4e696d6275732f7632342e322e322d6663396337322d73746174656f66757300; expected 0x417474657374616e742f566f7563680000000000000000000000000000000000

I'm pretty sure that there is no error with the URL, because the same URL to other beacon nodes returned valid blocks and ultimately one of these blocks was proposed with the correct graffiti:

ethdo block info --blockid=1112275 | grep Graffiti
Graffiti: Attestant/Vouch

In case it matters, the endpoint returned a blinded block.