Update EIP-7732 #4438

potuz · 2025-07-10T15:24:20Z

This PR updates EIP-7732 in several places. It should be read commit by commit. The list of commits is as follows

Add a Builder withdrawal prefix 0x03 which is a compounding validator, allow any validator to self-build for a zero value, but only 0x03 validators to build for others.
Remove all PTC reward logic and keep the beacon committee as pre-7732.
Add slot to the execution payload envelope (makes implementation easier)
Remove the payload status enumeration and simply use a boolean in the PTCAttestation object.
Update the payment mechanism from a direct transfer of validator balance to a withdrawal to a specific execution layer address (a fee recipient).
Use the attestation data index field to signal payload availability in attestations.
Fix all tests

This PR does not update the forkchoice logic, that will come on a separate PR perhaps from @fradamt

- Adds a new constant '0x03' builder withdrawal prefix. - Fixes `is_compounding_withdrawal_credentials` to also allow builders to compound. - Adds helper predicates to check if a validator is a builder. - When processing a an execution payload header, checks if the builder has builders' withdrawal credentials or if the proposer is self-building with zero value. - Only propagate bids from builders.

- Removes rewards for PTC attestations and for the proposer for including them. - Kees PTC members in the beacon committee.

- Adds a slot to the `ExecutionPayloadEnvelope` structure. - Checks that the slot is compatible with the block when processing the envelope and on p2p when gossiping payloads.

- Remove payload status enumeration and use a boolean `payload_present` instead. - Make payload attestations a maximum of 2 per block. - Remove instances of payload status in forkchoice (defer forkchoice changes until later commit) - Remove instances of payload status in the p2p spec.

- Move some presets to constants - Add a queue of builder pending payments and a queue of builder pending withdrawals to the beacon state - Add a fee recipient to the builder's bid - Modify process epoch to either delete the builder's pending payment if the block was not voted enough, or queue a withdrawal if the block was voted enough. Every epoch the pending payments from the previous epoch are all processed (unless the payload was already included in which case the payment was already processed) and the current epoch payments are moved to the beginning of the queue. - Modify the withdrawal handling by first processing all withdrawals from the builder's pending queue, before any other withdrawal. These withdrawals are processed as follows. If the builder is slashed then they are kept in the queue until the builder is withdrawable, in which case the payments will be fullfilled with the remaining balance. - Modify how to process the bid in the beacon block. Instead of deducting the builder immediately, we set a pending payment in the queue, to be deducted later with the churn when processing the withdrawal. - Modify process attestations to keep track of those attestations that voted for the beacon block when no payload was included.

- Adds a bitvector to track payload availability on the beacon state. - Check for payload compatibility to reward for timely head. - Check that the index is less than 2 and it equals 0 when attesting for the current slot. - Add fork upgrading code to initiate the builder pending payments for the pre-fork epoch. - Add fork upgrading code to make all previous payloads available.

jtraglia

I didn't fully review everything, but I felt that this was enough for now. I'm liking your changes here! Overall very clean and understandable.

jtraglia · 2025-07-10T18:35:57Z

presets/minimal/eip7732.yaml

 # floorlog2(get_generalized_index(BeaconBlockBody, 'blob_kzg_commitments')) + 1 + ceillog2(MAX_BLOB_COMMITMENTS_PER_BLOCK) (= 8 + 1 + 5 = 14)
-KZG_COMMITMENT_INCLUSION_PROOF_DEPTH_EIP7732: 14
+KZG_COMMITMENT_INCLUSION_PROOF_DEPTH_EIP7732: 15


Need to update the comment, it still says 14.

jtraglia · 2025-07-10T18:36:58Z

specs/_features/eip7732/beacon-chain.md

    - [`bit_floor`](#bit_floor)
-  - [Misc](#misc-1)
+  - [Misc](#misc-2)
    - [`remove_flag`](#remove_flag)
  - [Predicates](#predicates)
+    - [New `is_attestation_same_slot`](#new-is_attestation_same_slot)
+    - [Modified `is_compounding_withdrawal_credential`](#modified-is_compounding_withdrawal_credential)
+    - [New `is_builder_withdrawal_credential`](#new-is_builder_withdrawal_credential)
+    - [New `is_builder`](#new-is_builder)
    - [`is_valid_indexed_payload_attestation`](#is_valid_indexed_payload_attestation)
    - [`is_parent_block_full`](#is_parent_block_full)
  - [Beacon State accessors](#beacon-state-accessors)
+    - [`get_attestation_participation_flag_indices`](#get_attestation_participation_flag_indices)
    - [`get_ptc`](#get_ptc)
-    - [Modified `get_attesting_indices`](#modified-get_attesting_indices)
    - [`get_payload_attesting_indices`](#get_payload_attesting_indices)
    - [`get_indexed_payload_attestation`](#get_indexed_payload_attestation)


A reminder for later, we should add New or Modified to all of these.

jtraglia · 2025-07-10T18:40:11Z

specs/_features/eip7732/beacon-chain.md

+
+| Name                                | Value                         | Unit                        |
+| ----------------------------------- | ----------------------------- | --------------------------- |
+| `BUILDER_PENDING_WITHDRAWALS_LIMIT` | `uint64(2**20)` (= 1,048,576) | builder pending withdrawals |


jtraglia · 2025-07-10T18:43:06Z

specs/_features/eip7732/beacon-chain.md

+
+| Name                    | Value                                          |
+| ----------------------- | ---------------------------------------------- |
+| `DOMAIN_BEACON_BUILDER` | `DomainType('0x1B000000')` # (New in EIP-7732) |


Is there a reason this started with 1? I believe this should be:

Suggested change

| `DOMAIN_BEACON_BUILDER` | `DomainType('0x1B000000')` # (New in EIP-7732) |

| `DOMAIN_BEACON_BUILDER` | `DomainType('0x0B000000')` # (New in EIP-7732) |

I'm carrying this since forever because I didn't know which fork it would collide with, I feel it's better to keep a random number until it's time to ship (if that ever happens)

jtraglia · 2025-07-10T18:44:23Z

specs/_features/eip7732/beacon-chain.md

-| `DOMAIN_PTC_ATTESTER`   | `DomainType('0x0C000000')` # (New in EIP-7732) |
+| Name                       | Value                   |
+| -------------------------- | ----------------------- |
+| `MAX_PAYLOAD_ATTESTATIONS` | `2` # (New in EIP-7732) |


jtraglia · 2025-07-10T19:15:18Z

specs/_features/eip7732/beacon-chain.md

+##### New `should_process_builder_withdrawal`
+
+```python
+def should_process_builder_withdrawal(


Not a fan of "should" here. I think I would prefer is_builder_payment_withdrawable.

jtraglia · 2025-07-10T19:17:02Z

specs/_features/eip7732/beacon-chain.md

+    assert data.target.epoch == compute_epoch_at_slot(data.slot)
+    assert data.slot + MIN_ATTESTATION_INCLUSION_DELAY <= state.slot
+
+    # [Modified in Electra:EIP7549]


There are three comments like this (search Electra:) which should be removed.

jtraglia · 2025-07-10T19:17:55Z

specs/_features/eip7732/beacon-chain.md

+    # Verify the withdrawals root
+    assert hash_tree_root(payload.withdrawals) == state.latest_withdrawals_root
+
+    # Verify the gas_limit
+    assert committed_header.gas_limit == payload.gas_limit
+
+    assert committed_header.block_hash == payload.block_hash
+    # Verify consistency of the parent hash with respect to the previous execution payload


Nit, can we delete the blank lines & add a comment above line 1142?

jtraglia · 2025-07-10T19:19:00Z

specs/_features/eip7732/beacon-chain.md

-        def for_ops(operations: Sequence[Any], fn: Callable[[BeaconState, Any], None]) -> None:
-            for operation in operations:
-                fn(state, operation)
+    # Process Electra operations


Let's remove this comment. I don't want to mention other forks.

specs/_features/eip7732/builder.md

jtraglia · 2025-07-11T16:40:02Z

specs/_features/eip7732/builder.md

+    the bid is accepted. The builder **MUST** have balance enough to fulfill
+    this bid.


This is actually an old change, but it should be:

The builder **MUST** have enough excess balance to fulfill this bid and all pending payments.

jtraglia · 2025-07-11T16:41:26Z

specs/_features/eip7732/builder.md

+10. Set `header.fee_recipient` to be an execution address to receive the
+    payment. This address can be obtained from the proposer directly via a
+    request or can be set from the withdrawal credentials of the proposer.


Maybe worth mentioning that the fallback is the zero-addr / burn-addr.

jtraglia · 2025-07-11T16:42:33Z

specs/_features/eip7732/builder.md

-*withholding boost* to the builder, which would increase the forkchoice weight
-of the parent block, favoring it and preventing the builder from being charged
-for the bid by not revealing.
+should simply act as if no block was ever produced and simply not broadcast the


Can simplify a bit 😄

Suggested change

should simply act as if no block was ever produced and simply not broadcast the

should act as if no block was produced and not broadcast the

jtraglia · 2025-07-11T16:46:56Z

specs/_features/eip7732/p2p-interface.md

+- _[REJECT]_ `aggregate.data.index < 2`
+- _[REJECT]_ `aggregate.data.index == 0` if `block.slot == aggregate.data.slot`
+
+The following validations are removed:
+
+- _[REJECT]_ `aggregate.data.index == 0`


Nit, there should be punctuation here.

Suggested change

- _[REJECT]_ `aggregate.data.index < 2`

- _[REJECT]_ `aggregate.data.index == 0` if `block.slot == aggregate.data.slot`

The following validations are removed:

- _[REJECT]_ `aggregate.data.index == 0`

- _[REJECT]_ `aggregate.data.index < 2`.

- _[REJECT]_ `aggregate.data.index == 0` if `block.slot == aggregate.data.slot`.

The following validations are removed:

- _[REJECT]_ `aggregate.data.index == 0`.

jtraglia · 2025-07-11T16:47:31Z

specs/_features/eip7732/p2p-interface.md

+The following validations are added:
+
+- _[REJECT]_ `attestation.data.index < 2`
+- _[REJECT]_ `attestation.data.index == 0` if
+  `block.slot == attestation.data.slot`
+
+The following validations are removed:
+
+- _[REJECT]_ `attestation.data.index == 0`


Punctuation for these items too.

jtraglia · 2025-07-11T16:50:44Z

specs/_features/eip7732/beacon-chain.md

+    for_ops(requests.withdrawals, process_withdrawal_request)
+    for_ops(requests.consolidations, process_consolidation_request)
+
+    # Queue the proposer payment


For consistency, we refer to these as "builder payments" right?

Suggested change

# Queue the proposer payment

# Queue the builder payment

jtraglia · 2025-07-11T16:52:10Z

specs/_features/eip7732/beacon-chain.md

+    increase_balance(state, get_beacon_proposer_index(state), proposer_reward)
+    # update builder payment weight
+
+    if current_epoch_target:


Suggested change

increase_balance(state, get_beacon_proposer_index(state), proposer_reward)

# update builder payment weight

if current_epoch_target:

increase_balance(state, get_beacon_proposer_index(state), proposer_reward)

# Update builder payment weight

if current_epoch_target:

jtraglia · 2025-07-11T16:53:33Z

specs/_features/eip7732/beacon-chain.md

+
+    proposer_reward_numerator = 0
+    for index in get_attesting_indices(state, attestation):
+        for flag_index, weight in enumerate(PARTICIPATION_FLAG_WEIGHTS):
+            if flag_index in participation_flag_indices and not has_flag(
+                epoch_participation[index], flag_index
+            ):
+                epoch_participation[index] = add_flag(epoch_participation[index], flag_index)
+                proposer_reward_numerator += get_base_reward(state, index) * weight
+                if flag_index == TIMELY_HEAD_FLAG_INDEX and is_attestation_same_slot(state, data):
+                    payment.weight += state.validators[index].effective_balance


There's new code in this section, but it's not clearly marked.

jtraglia · 2025-07-11T17:08:58Z

specs/_features/eip7732/beacon-chain.md

+    # Sweep for builder payments
+    for withdrawal in state.builder_pending_withdrawals:
+        if (
+            withdrawal.withdrawable_epoch > epoch
+            or len(withdrawals) + 1 == MAX_WITHDRAWALS_PER_PAYLOAD
+        ):
+            break
+        if should_process_builder_withdrawal(state, withdrawal):
+            total_withdrawn = sum(
+                w.amount for w in withdrawals if w.validator_index == withdrawal.builder_index
+            )
+            balance = state.balances[withdrawal.builder_index] - total_withdrawn
+            builder = state.validators[withdrawal.builder_index]
+            if builder.slashed:
+                withdrawable_balance = min(balance, withdrawal.amount)
+            elif balance > MIN_ACTIVATION_BALANCE:
+                withdrawable_balance = min(balance - MIN_ACTIVATION_BALANCE, withdrawal.amount)
+            else:
+                withdrawable_balance = 0
+
+            withdrawals.append(
+                Withdrawal(
+                    index=withdrawal_index,
+                    validator_index=withdrawal.builder_index,
+                    address=withdrawal.fee_recipient,
+                    amount=withdrawable_balance,
+                )
+            )
+            withdrawal_index += WithdrawalIndex(1)
+        processed_builder_withdrawals_count += 1


What happens if between the builder's bid being accepted & the builder payment, the builder misses an attestation and no longer has enough funds to fully cover the payment? Based on the code here, it appears that the proposer would get all of the builder's excess balance. The possible difference here would be practically zero, but still sort of annoying for the proposer to not get exactly what was promised.

I can think of two solutions to this:

Add a small buffer. Like min activation balance + 1 ETH + the bid value.

Pull from the builder's min activation balance. You could remove the three cases and simply use withdrawable_balance = min(balance, withdrawal.amount). This would behave as if there were a validator with exactly 32 ETH that missed an attestation; left with a sub-32 ETH balance.

I would prefer option 2, as it's the simplest/cleanest.

This was a design decision of erring in the side of chain security vs proposer payment safety, instead of an attestation the biggest risk is the builder slashing itself. Notice that even if you delay or look at the min activation balance etc. Even after processing the bid, only a withdrawal is churned, and during that time the builder can still lose balance enough to fall below the payment line.

potuz added 7 commits July 10, 2025 12:17

Remove PTC reward logic

e25c5c9

- Removes rewards for PTC attestations and for the proposer for including them. - Kees PTC members in the beacon committee.

Add slot to the envelope

81052a5

- Adds a slot to the `ExecutionPayloadEnvelope` structure. - Checks that the slot is compatible with the block when processing the envelope and on p2p when gossiping payloads.

Fix (some) tests

3672f4f

github-project-automation bot added this to Lodestar Consensus Devnet Planning Jul 10, 2025

This comment has been minimized.

Sign in to view

jtraglia added the eip7732 ePBS label Jul 10, 2025

jtraglia reviewed Jul 10, 2025

View reviewed changes

jtraglia reviewed Jul 11, 2025

View reviewed changes

	\| `BUILDER_PENDING_WITHDRAWALS_LIMIT` \| `uint64(2**20)` (= 1,048,576) \| builder pending withdrawals \|
	\| `BUILDER_PENDING_WITHDRAWALS_LIMIT` \| `uint64(2**20)` (= 1,048,576) \| Builder pending withdrawals \|

	\| `DOMAIN_BEACON_BUILDER` \| `DomainType('0x1B000000')` # (New in EIP-7732) \|
	\| `DOMAIN_BEACON_BUILDER` \| `DomainType('0x0B000000')` # (New in EIP-7732) \|

	\| `MAX_PAYLOAD_ATTESTATIONS` \| `2` # (New in EIP-7732) \|
	\| `MAX_PAYLOAD_ATTESTATIONS` \| `2` \|

		the bid is accepted. The builder MUST have balance enough to fulfill
		this bid.

	should simply act as if no block was ever produced and simply not broadcast the
	should act as if no block was produced and not broadcast the

Update EIP-7732 #4438

Are you sure you want to change the base?

Update EIP-7732 #4438

Conversation

potuz commented Jul 10, 2025

Uh oh!

This comment has been minimized.

jtraglia 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

jtraglia Jul 11, 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!

potuz Jul 11, 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!

Uh oh!

jtraglia Jul 11, 2025 •

edited

Loading

potuz Jul 11, 2025 •

edited

Loading