You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: specs/_features/eip7732/p2p-interface.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -154,13 +154,13 @@ This topic is used to propagate signed payload attestation message.
154
154
155
155
The following validations MUST pass before forwarding the `payload_attestation_message` on the network, assuming the alias `data = payload_attestation_message.data`:
-_[IGNORE]_the`payload_attestation_message` is the first valid payload attestation message received from the validator index.
160
-
-_[IGNORE]_ The attestation's `data.beacon_block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).
161
-
__[REJECT]_ The beacon block with root`data.beacon_block_root` passes validation.
162
-
-_[REJECT]_ The validator index is within the payload committee in `get_ptc(state, data.slot)`. For the current's slot head state.
163
-
-_[REJECT]_ The signature of `payload_attestation_message.signature` is valid with respect to the validator index.
157
+
-_[IGNORE]_The message's slot is for the current slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance), i.e. `data.slot == current_slot`.
158
+
-_[REJECT]_The message's payload status is a valid status, i.e. `data.payload_status < PAYLOAD_INVALID_STATUS`.
159
+
-_[IGNORE]_The`payload_attestation_message` is the first valid message received from the validator with index`payload_attestation_message.validate_index`.
160
+
-_[IGNORE]_ The message's block `data.beacon_block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).
161
+
-_[REJECT]_ The message's block `data.beacon_block_root` passes validation.
162
+
-_[REJECT]_ The message's validator index is within the payload committee in `get_ptc(state, data.slot)`. The `state` is the head state corresponding to processing the block up to the current slot as determined by the fork choice.
163
+
-_[REJECT]_ The message's signature of `payload_attestation_message.signature` is valid with respect to the validator index.
0 commit comments