|
15 | 15 | - [`ExecutionPayloadHeader`](#executionpayloadheader) |
16 | 16 | - [`BlindedBeaconBlockBody`](#blindedbeaconblockbody) |
17 | 17 | - [Building](#building) |
| 18 | + - [Block scoring](#block-scoring) |
| 19 | +- [Relaying](#relaying) |
| 20 | + - [Block scoring](#block-scoring-1) |
18 | 21 | - [Bidding](#bidding) |
19 | 22 | - [Revealing the `ExecutionPayload`](#revealing-the-executionpayload) |
20 | 23 | - [Blinded block processing](#blinded-block-processing) |
@@ -86,9 +89,39 @@ class BlindedBeaconBlockBody(Container): |
86 | 89 |
|
87 | 90 | ## Building |
88 | 91 |
|
89 | | -Builders provide bids as the have in prior forks. |
| 92 | +Builders provide bids as they have in prior forks, with a notable restriction to block scoring. |
90 | 93 |
|
91 | | -Relays have a few additional duties. |
| 94 | +### Block scoring |
| 95 | + |
| 96 | +Builders **MUST** not include the `amount`s from the consensus block's withdrawals when computing the `value` for their `BuilderBid`. |
| 97 | + |
| 98 | +See [the section below on relay verification](#block-scoring-1) for the logic a builder's bid must satisfy. |
| 99 | + |
| 100 | +## Relaying |
| 101 | + |
| 102 | +Relays have a few additional duties to support the features in this upgrade. |
| 103 | + |
| 104 | +### Block scoring |
| 105 | + |
| 106 | +Relays **MUST** ensure the `value` in the `BuilderBid` corresponds to the payment delivered by the builder to the proposer, excluding any withdrawals. |
| 107 | + |
| 108 | +Consider the following validation logic following definitions in the `consensus-specs`: |
| 109 | + |
| 110 | +```python |
| 111 | +def verify_bid_value(execution_payload: ExecutionPayload, fee_recipient: ExecutionAddress, bid_value: uint256, balance_difference: uint256): |
| 112 | + excluded_amount = sum([w.amount for w in execution_payload.withdrawals if w.address == fee_recipient]) |
| 113 | + proposer_payment = balance_difference - excluded_amount |
| 114 | + assert proposer_payment == bid_value |
| 115 | +``` |
| 116 | + |
| 117 | +`verify_bid_value` should execute completely, noting that assertion failures are errors. |
| 118 | +The `execution_payload`, `fee_recipient`, and `bid_value` are all provided by the builder in their payload submission. |
| 119 | +The `balance_difference` is computed by the relay during simulation of the `execution_payload` where |
| 120 | +`balance_difference = post_state_balance - pre_state_balance`. |
| 121 | +`pre_state_balance` is the ether amount at the `fee_recipient`’s address in the execution state before applying |
| 122 | +the `execution_payload` and the `post_state_balance` is the same data after applying the `execution_payload`. |
| 123 | + |
| 124 | +Any block submissions where `verify_bid_value` fails should be considered invalid and **MUST** not be served to proposers requesting bids. |
92 | 125 |
|
93 | 126 | ### Bidding |
94 | 127 |
|
|
0 commit comments