In types/testingutils/beacon_node_consts.go, the source comments indicate that the Capella and Deneb proposer fixtures were taken from upstream go-eth2-client tests:
capellaBlockdenebBlockContents
Those upstream fixtures are good codec fixtures, but they contain placeholder-style BLS byte strings such as sequential 0x000102... pubkeys and 0x606162... signatures. These values have the correct byte lengths, but they are not guaranteed to be valid compressed BLS points.
That distinction matters because go-eth2-client treats BLS fields permissively in these paths:
- JSON decode mainly enforces prefix / hex / length
- SSZ decode copies raw bytes into fixed-size fields
So these fixtures are acceptable for codec round-trip tests, but they are not suitable as cross-client proposer/interoperability vectors.
Strict blst-based decoders reject representative Capella/Deneb placeholder values, while a representative Electra signature from the real-block fixture decodes successfully. This suggests the issue is specifically with the copied Capella/Deneb fixture class, not necessarily all proposer fixtures.
Why this matters
ssv-spec is using these fixtures for proposer/spec coverage, not just codec coverage. That means downstream clients with stricter BLS decoding either:
- fail on otherwise reasonable inputs, or
- need test-only crypto bypasses to consume the vectors
That weakens what the fixtures are proving.
Proposed fix
Replace the Capella/Deneb placeholder BLS fields in types/testingutils/beacon_node_consts.go with valid compressed BLS encodings.
If the goal of these tests is decode / block-handling compatibility rather than signature-verification semantics, the values do not need to be meaningful signatures for the block contents, but they should be valid compressed points so that strict implementations can decode them without special-case bypasses.
In
types/testingutils/beacon_node_consts.go, the source comments indicate that the Capella and Deneb proposer fixtures were taken from upstream go-eth2-client tests:capellaBlockdenebBlockContentsThose upstream fixtures are good codec fixtures, but they contain placeholder-style BLS byte strings such as sequential
0x000102...pubkeys and0x606162...signatures. These values have the correct byte lengths, but they are not guaranteed to be valid compressed BLS points.That distinction matters because go-eth2-client treats BLS fields permissively in these paths:
So these fixtures are acceptable for codec round-trip tests, but they are not suitable as cross-client proposer/interoperability vectors.
Strict
blst-based decoders reject representative Capella/Deneb placeholder values, while a representative Electra signature from the real-block fixture decodes successfully. This suggests the issue is specifically with the copied Capella/Deneb fixture class, not necessarily all proposer fixtures.Why this matters
ssv-specis using these fixtures for proposer/spec coverage, not just codec coverage. That means downstream clients with stricter BLS decoding either:That weakens what the fixtures are proving.
Proposed fix
Replace the Capella/Deneb placeholder BLS fields in
types/testingutils/beacon_node_consts.gowith valid compressed BLS encodings.If the goal of these tests is decode / block-handling compatibility rather than signature-verification semantics, the values do not need to be meaningful signatures for the block contents, but they should be valid compressed points so that strict implementations can decode them without special-case bypasses.