gloas: add new execution payload bid processing by terencechain · Pull Request #15638 · OffchainLabs/prysm

terencechain · 2025-08-27T14:03:04Z

This PR implements process_execution_payload_bid and spec tests

james-prysm · 2025-12-04T15:11:02Z

+		return fmt.Errorf("invalid signature format: %w", err)
+	}
+
+	currentEpoch := slots.ToEpoch(bid.Slot())


should this be from the bid or form the state slot? or do they need to be checked against each other?

we verified bid.Slot() == block.Slot() and in process_block_header, we also verified state.Slot() == block.Slot() so they all are consistent

james-prysm · 2025-12-04T15:15:22Z

+		if amount != 0 {
+			return fmt.Errorf("self-build amount must be zero, got %d", amount)
+		}
+		if wrappedBid.Signature() != common.InfiniteSignature {


I think this should be !bytes.Equal(wrappedBid.Signature(),common.InfiniteSignature)

both of them are [96]byte..
wrappedBid.Signature() != common.InfiniteSignature wouldn't work?

yeah actually i'm probably wrong on this i just usually see bytes.Equal when comparing bytes but checked myself that this should be fine

james-prysm · 2025-12-04T15:23:43Z

+	if err != nil {
+		return fmt.Errorf("failed to get randao mix: %w", err)
+	}
+	if bid.PrevRandao() != [32]byte(randaoMix) {


what about doing something like

bidPrevRandao := bid.PrevRandao() if !bytes.Equal(bidPrevRandao[:], randaoMix) {

any real concern with casting? at this point we know randaoMix is 32 bytes and casting is a bit easier to read / very marginally faster, we also use this [32]byte cast in a bunch of places in prysm already

I think similiar to the previous one I was just more used to seeing bytes.Equal comparison because most were slices vs arrays for bytes. but as a follow up when do we [32]byte cast this way vs using bytesutil.ToBytes32( I think we usually use the latter

james-prysm · 2025-12-04T15:27:20Z

+			},
+		}
+		slotIndex := params.BeaconConfig().SlotsPerEpoch + (bid.Slot() % params.BeaconConfig().SlotsPerEpoch)
+		if err := st.SetBuilderPendingPayment(slotIndex, pendingPayment); err != nil {


since the underlying value is a slice when you set builder pending payment, do we need any safety checks on slotIndex so that it's not some out of bound index compared to the underlying slice

i think it makes sense to bound check in SetBuilderPendingPayment

I don't think i see a bounds check added for this one yet

james-prysm · 2025-12-04T17:38:04Z

 }
+
+// CopyBuilderPendingPayment creates a deep copy of a builder pending payment.
+func CopyBuilderPendingPayment(original *BuilderPendingPayment) *BuilderPendingPayment {


not sure if it's part of another pr but some stuff is missing maybe due to updated gloas proto?

- copySignedExecutionPayloadBid missing PrevRandao and ExecutionPayment - copyPayloadAttestation shallow-copies AggregationBits - genExecutionPayloadBidGloas test helper missing those same fields

we'll do them in later prs

satushh · 2025-12-04T18:18:09Z

+
+	builderIndex := bid.BuilderIndex()
+	proposerIndex := block.ProposerIndex()
+	amount := bid.Value()


What's the difference between value and executionPayment?

one is in protocol, through consensus,
one is out of protocol, optional

Add Gloas execution payload header processing and state integration Implement Gloas fork support in consensus-types/blocks Add Gloas state fields to beacon state implementation

james-prysm · 2026-01-09T15:37:10Z

+		return true
+	}
+
+	if len(h.payload.ParentBlockHash) != 32 ||


checks for prev randao and feerecipient are missing here

james-prysm

all my comments have been addressed

potuz

The model likes fmt.Errorf("my error %w", err) when most of our code likes errors.Wrap.

Left a few comments about unnecessary copies in getters in the state. We should try to avoid these early in the fork to avoid piling performance issues.

potuz · 2026-01-12T18:39:23Z

+func ProcessExecutionPayloadBid(st state.BeaconState, block interfaces.ReadOnlyBeaconBlock) error {
+	signedBid, err := block.Body().SignedExecutionPayloadBid()
+	if err != nil {
+		return fmt.Errorf("failed to get signed execution payload bid: %w", err)


Why not wrapping the error instead?

%w in fmt.Errorf wraps an error

potuz · 2026-01-12T18:43:23Z

+			return fmt.Errorf("self-build amount must be zero, got %d", amount)
+		}
+		if wrappedBid.Signature() != common.InfiniteSignature {
+			return errors.New("self-build signature must be point at infinity")


Suggested change

return errors.New("self-build signature must be point at infinity")

return errors.New("self-build signature must be the point at infinity")

potuz · 2026-01-12T18:47:27Z

+	b.lock.RLock()
+	defer b.lock.RUnlock()
+
+	builder, err := b.builderAtIndex(builderIndex)


I don't like that this is an internal beacon state getter that is copying a builder when it doesn't. This applies to others in the state package, even away from Gloas.

in particular I think we should stick to non exported methods to NOT copy the structure or at least agree on a common convention.

potuz · 2026-01-12T18:50:51Z

+	b.lock.RLock()
+	defer b.lock.RUnlock()
+
+	builder, err := b.builderAtIndex(builderIndex)


Same here, another copy.

potuz

Second pass, looks good to me, need a last pass on the last files.

potuz · 2026-01-13T14:30:42Z

+}
+func (s stubBlock) HashTreeRootWith(*fastssz.Hasher) error { return nil }
+
+func buildGloasState(t *testing.T, slot primitives.Slot, proposerIdx primitives.ValidatorIndex, builderIdx primitives.BuilderIndex, balance uint64, randao [32]byte, latestHash [32]byte, builderPubkey [48]byte) *state_native.BeaconState {


Why do we have these functions here? we typically have a deterministic state builder for tests in the testing package.

I find that hand crafting the block and state is a better exercise than using a deterministic state. Doing it by hand forces you to think carefully about which fields are required and which are not, rather than taking everything for granted. That said, I may revert back to a deterministic since this is a lot of work

potuz · 2026-01-13T14:34:27Z

+func (s stubBlock) UnmarshalSSZ([]byte) error                { return nil }
+func (s stubBlock) SizeSSZ() int                             { return 0 }
+func (s stubBlock) Version() int                             { return s.v }
+func (s stubBlock) AsSignRequestObject() (validatorpb.SignRequestObject, error) {


The intention is that stubBlock and stubBlockBody satisfy the right interfaces? in this case perhaps it's good to add an assert right here that they do.

potuz · 2026-01-13T14:47:41Z

+		return false, nil
+	}
+
+	return balance-minBalance >= uint64(bidAmount), nil


I'm surprised this passes the linter, I thought gofmt would write this as balance - minBalance

i wrote balance - minBalance and they changed back to balance-minBalance

potuz · 2026-01-13T18:27:40Z

+)
+
+func blockWithSignedExecutionPayloadBid(blockSSZ []byte) (interfaces.SignedBeaconBlock, error) {
+	var block ethpb.BeaconBlockGloas


The next two functions have either var block ethpb.BeaconBlockGloas or block := &ethpb.BeaconBlockGloas{}. Why the difference?

No reason, i didnt care too much about being consistent and nit in test, I can stick to one if you want, but i think that's hard to enforce across prysm with different authors

potuz · 2026-01-13T18:29:15Z

+	for _, folder := range testFolders {
+		t.Run(folder.Name(), func(t *testing.T) {
+			if folder.Name() != "process_execution_payload_bid_self_build_non_zero_value" {
+				t.Skip("skipping other tests for now")


Why is this? are there no more bid processing tests?

No, i wanted to debug one test and forgot to uncomment to test the rest

This PR implements [process_execution_payload_bid](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/beacon-chain.md#new-process_execution_payload_bid) and spec tests

terencechain force-pushed the process-exec-header branch from db6c8de to 2344512 Compare August 27, 2025 14:13

terencechain added the gloas label Aug 27, 2025

terencechain force-pushed the process-exec-header branch from 2344512 to 24afb03 Compare September 20, 2025 16:13

terencechain force-pushed the process-exec-header branch 6 times, most recently from 9b74781 to 1f182f1 Compare November 25, 2025 18:02

terencechain marked this pull request as ready for review November 25, 2025 18:03

terencechain force-pushed the process-exec-header branch 7 times, most recently from 7fdffad to 62b5aba Compare November 25, 2025 18:51

potuz self-assigned this Nov 26, 2025

james-prysm reviewed Dec 4, 2025

View reviewed changes

satushh reviewed Dec 4, 2025

View reviewed changes

terencechain force-pushed the process-exec-header branch from 62b5aba to 34a4aa4 Compare January 3, 2026 04:22

terencechain changed the title ~~Add Gloas execution payload header processing~~ gloas: add new execution payload bid processing Jan 5, 2026

satushh mentioned this pull request Jan 5, 2026

Gloas (EIP-7732) Implementation Tracker #16213

Closed

terencechain force-pushed the process-exec-header branch 3 times, most recently from 00fc4a7 to 0816f23 Compare January 9, 2026 00:05

terencechain force-pushed the process-exec-header branch from 40a2e53 to ec80c47 Compare January 9, 2026 06:02

Add gloas payload header processing

3343ce7

Add Gloas execution payload header processing and state integration Implement Gloas fork support in consensus-types/blocks Add Gloas state fields to beacon state implementation

terencechain force-pushed the process-exec-header branch from ec80c47 to 3343ce7 Compare January 9, 2026 07:09

james-prysm reviewed Jan 9, 2026

View reviewed changes

James's feedback

926f2ad

james-prysm previously approved these changes Jan 9, 2026

View reviewed changes

terencechain dismissed james-prysm’s stale review via e6eec11 January 11, 2026 22:37

Use builder pubkey getter to avoid copy

3dd766f

terencechain force-pushed the process-exec-header branch from e6eec11 to 3dd766f Compare January 11, 2026 23:55

james-prysm previously approved these changes Jan 12, 2026

View reviewed changes

potuz added the blocked label Jan 12, 2026

potuz requested changes Jan 12, 2026

View reviewed changes

potuz removed the blocked label Jan 12, 2026

fix builderAtIndex to not copy

fee4b6e

terencechain dismissed james-prysm’s stale review via fee4b6e January 12, 2026 21:22

Use errors.wrap instead of standard error library with %w

18073f4

potuz reviewed Jan 13, 2026

View reviewed changes

unskip spec tests, assert stubBlock matches interface

f2d4cec

potuz approved these changes Jan 15, 2026

View reviewed changes

terencechain added this pull request to the merge queue Jan 15, 2026

Merged via the queue into develop with commit a08f185 Jan 15, 2026
19 checks passed

terencechain deleted the process-exec-header branch January 15, 2026 11:21

james-prysm added this to Gloas Feb 11, 2026

github-project-automation Bot moved this from Backlog to Done in Gloas Feb 11, 2026

github-project-automation Bot moved this to Backlog in Gloas Feb 11, 2026

terencechain assigned terencechain and unassigned potuz Feb 12, 2026

	return errors.New("self-build signature must be point at infinity")
	return errors.New("self-build signature must be the point at infinity")

Uh oh!

Conversation

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

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

james-prysm Dec 4, 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!

james-prysm Dec 4, 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!

james-prysm Dec 4, 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!

Choose a reason for hiding this comment

Uh oh!

james-prysm left a comment

Choose a reason for hiding this comment

Uh oh!

potuz left a comment

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!

potuz left a comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

terencechain commented Aug 27, 2025 •

edited

Loading

james-prysm Dec 4, 2025 •

edited

Loading

james-prysm Dec 4, 2025 •

edited

Loading

james-prysm Dec 4, 2025 •

edited

Loading