Please mark the next release as "required for validators", otherwise it may risk users missing slots when using mev-boost

[metachris]

The next Prysm release contains important changes, including a fix for incorrect builder API types encoding:

• Do not omit json fields if empty in builder client #11673

Until the next release, the way Prysm encodes the builder types is not conforming to the standard, and results in errors when decoding with types that enforce correctness.

In preparation for Capella and EIP4844 upgrades, mev-boost and the mev-boost-relay is being upgraded to use the Attestant types, which enforce a standard-compliant encoding:

• Replace go-boost-utils types with Attestant types flashbots/mev-boost#411

If these updates were to be rolled out to mev-boost and the relays, non-conforming payloads fail the decoding step and lead to users missing slots when using the builder API.

We propose that Prysm marks the next release as "required for validators". Doing so would allow us to toll out the changes to mev-boost and the relays after a reasonable wait period without putting Prysm users at risk of missing slots.

[prestonvanloon]

Hi @metachris, thanks for filing this issue. We discussed this a bit in discord and I wanted to summarize the conversation here for record.

We are hesitant to mark the next release as urgent, critical, or anything other than a normal release for prysm users as an elevated release labeling must be used sparingly. However, we will make a call-out in the release notes and issue the next release as a minor release (v3.2.0) rather than a patch release to indicate that there is some change in the API payloads for the builder API requests from prysm.

We ask that your team delays your changes in flashbots/mev-boost#411 until the next hardfork as this be the best approach to releasing breaking changes without deprecating the current API. If that is not possible, then we ask that your team indicates that a Prysm upgrade is a hard requirement for users to use your software since it contains changes that break existing behavior and overly communicate that to your users.

To add some additional context for readers:

• Prior to Do not omit json fields if empty in builder client #11673, Prysm would omit JSON fields that were empty.
• Attestant data types have more strict validation that will reject certain Prysm payloads with missing fields.
• If the builder API rejects these payloads, the user will either miss a block proposal entirely or failover to local block production with an unnecessary delay.

[metachris]

I think it make sense for mev-boost to wait with changes to the types for a while.

We do need to make a new mev-boost release sometime well before the hardfork date to give users a chance to upgrade. This version will need to try to decode the payloads into the Capella/4844 types, and fall back to the Bellatrix types if that fails.

[metachris]

We are currently exploring a third way - to use the Attestant Capella types, with a fallback to the current Bellatrix(go-boost-utils) types (instead of Bellatrix(Attestant)). This should make the changes backwards-compatible with current and previous Prysm-versions.

[terencechain]

We are currently exploring a third way - to use the Attestant Capella types, with a fallback to the current Bellatrix(go-boost-utils) types (instead of Bellatrix(Attestant)). This should make the changes backwards-compatible with current and previous Prysm-versions.

That's great to hear. Thanks @metachris !