From 6fcc45e696535d801213731ff131af66f831802a Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Tue, 22 Nov 2022 14:39:59 +0200 Subject: [PATCH 01/25] first draft --- sips/mev.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 sips/mev.md diff --git a/sips/mev.md b/sips/mev.md new file mode 100644 index 0000000..47de298 --- /dev/null +++ b/sips/mev.md @@ -0,0 +1,74 @@ +| Author | Title | Category | Status | +|---------------------------|----------------------------------|----------|----------------------| +| Moshe Revah (@moshe-blox) | Support externally built blocks | Core | open-for-discussion | + +## Summary +Support the production and proposal of blocks built by external entities, allowing operators to access blocks from a marketplace of builders such as [Flashbots](https://boost-relay.flashbots.net/). + +## Rational & Design Goals +Block building is a computationally intensive task, and even more so when blockspace utilization and profit maximization are in mind. Additionally, many of the more profitable transactions, so-called MEV, are private and only accessible to validators through external block builders. + +Currently, operators wishing to offer competitive returns must be sophisticated block builders with private transaction flows. This SIP aims to change that by allowing them to register with and propose blocks from external builders who comply to [ethereum/builder-specs](https://github.com/ethereum/builder-specs). + +## Specification + +### MEV-supporting operators + +Operators who wish to support blinded blocks must configure their node to do so, otherwise their node will reject signing those. + +Validators who want to propose MEV blocks would have to avoid registering with a combination of MEV and non-MEV operators, as the latter would reject any blinded blocks and result in a missed duty. + +> TODO: can't MEV-supporting leaders just fall back to non-blinded blocks if at least one of the other operators is non-MEV supporting? This should allow such combinations. + +### Validator registration + +Upon registration of a validator to SSV, it's operators construct a `SignedValidatorRegistration` message with it's preferred `fee_recipient`, sign it, and finally submit it to their Beacon node with [/eth/v1/validator/register_validator](https://ethereum.github.io/beacon-APIs/#/Validator/registerValidator). + +This prepares the Beacon node which also relays this information to it's configured builder(s). + +Note: producing a `BlindedBeaconBlock` before and shortly thereafter (delay depends on the builder) the registration may result in either: + +1. Beacon node falls back to locally-built block from it's execution layer. +2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it, or rewards a potentially different `fee_recipient` from the validator's latest registration. + +> TODO: if we choose to repeat this periodically, it might make it redundant to do so upon validator registration as well? + +### Blinded block proposals + +#### Scenario A: all operators share the same builders + +1. Leader produces a `BlindedBeaconBlock` from their Beacon node with [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it. + +2. Operators sign the `BlindedBeaconBlock`. + +3. Operators publish the `SignedBlindedBeaconBlock` to their Beacon node with [/eth/v1/beacon/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlindedBlock). + + The Beacon node reveals the signature to the builder, which (ideally) reveals the transactions in return, after which it unblinds the block and publishes it to the network. + + ##### Issues + + Unrealistic? + +#### Secnario B: operators bypass the Beacon node to unblind from builders directly + +1. Leader produces a `BlindedBeaconBlock` from their Beacon node with [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it together with the endpoint of it's builder as `BuilderBlindedBeaconBlock`. + + ```go + type BuilderBlindedBeaconBlock { + BuilderEndpoint string + BlindedBeaconBlock *spec.VersionedBlindedBeaconBlock + } + ``` + +2. Operators sign the `BlindedBeaconBlock`. + +3. Operators submit the `SignedBlindedBeaconBlock` to the builder's endpoint with [/eth/v1/builder/blinded_blocks](https://ethereum.github.io/builder-specs/#/Builder/submitBlindedBlock) to reveal the transactions and unblind the block into a `SignedBlindedBlock`. + +4. Operators publish the `SignedBeaconBlock` to their Beacon node with [/eth/v1/beacon/blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlock). + + ##### Issues + + ###### Unknown builder + When producing blinded blocks with a Beacon node connected to multiple builders (currently possible via mev-boost), the block's builder is unspecified. So the leader can't determine which builder endpoint to share with the other operators, and only he can unblind & publish it. + + We can mitigate this by requiring leaders to share the full list of builders they're working with, so that the other operators can try to unblind with each of them (ideally in parallel). \ No newline at end of file From 9b5bd2af0a632f4f99a8158a925ed5bda9fab3a5 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 23 Nov 2022 09:36:31 +0200 Subject: [PATCH 02/25] wip --- sips/mev.md | 58 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index 47de298..222e70d 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -14,34 +14,52 @@ Currently, operators wishing to offer competitive returns must be sophisticated ### MEV-supporting operators +#### Metadata +Operators advertise whether they intend to build blinded blocks and which MEV relays they work with. + +Since blinded blocks can't be validated for their `fee_recipient`, some validators may be willing to compromise on potential profits from MEV in return for the guaranteed block reward. + +#### Node behaviour Operators who wish to support blinded blocks must configure their node to do so, otherwise their node will reject signing those. Validators who want to propose MEV blocks would have to avoid registering with a combination of MEV and non-MEV operators, as the latter would reject any blinded blocks and result in a missed duty. -> TODO: can't MEV-supporting leaders just fall back to non-blinded blocks if at least one of the other operators is non-MEV supporting? This should allow such combinations. +> TODO: can't leaders just fall back to propose non-blinded blocks if at least one of the other operators is non-MEV supporting? This should allow such combinations. ### Validator registration -Upon registration of a validator to SSV, it's operators construct a `SignedValidatorRegistration` message with it's preferred `fee_recipient`, sign it, and finally submit it to their Beacon node with [/eth/v1/validator/register_validator](https://ethereum.github.io/beacon-APIs/#/Validator/registerValidator). +When a validator registers to the SSV contract, he may attach a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) including his `fee_receipient` and `gas_limit` preferences. + +The SSV contract must allow validators to update this attachment, as their preferences may change over time. + +Operators must validate the signature and keep track of their validators' latest attachment (by highest `timestamp`), and periodically publish it to their Beacon nodes at [/eth/v1/validator/register_validator](https://ethereum.github.io/beacon-APIs/#/Validator/registerValidator). + +An operator may publish for his entire validator set in bulk, however a single invalid signature may cause the request to fail and other attachments to be ignored, so a prior signature validation is crucial. + +> Note: producing a `BlindedBeaconBlock` before and shortly thereafter (delay depends on the builder) the registration may result in either: +> 1. Beacon node falls back to locally-built block from it's execution layer. +> 2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it. +> 3. Builder rewards a potentially different `fee_recipient` from the validator's latest registration (such as a registration prior to onboarding to SSV.) -This prepares the Beacon node which also relays this information to it's configured builder(s). +#### Issues -Note: producing a `BlindedBeaconBlock` before and shortly thereafter (delay depends on the builder) the registration may result in either: +##### Gas limit -1. Beacon node falls back to locally-built block from it's execution layer. -2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it, or rewards a potentially different `fee_recipient` from the validator's latest registration. +Within the proposed construction, the gas limit is set by validators only and relies on them to update it if needed. -> TODO: if we choose to repeat this periodically, it might make it redundant to do so upon validator registration as well? +If gas limit is likely to change to adjust to network conditions, then this isn't ideal because validators would have to track of it, and when it changes — produce a new signature and publish an update transaction to the contract (which may be very expensive when the network is congested). + +> TODO: examine the code of validator clients such as Lighthouse and Prysm to figure this out. ### Blinded block proposals -#### Scenario A: all operators share the same builders +#### Scenario A — Block is published only by operators who share builder with leader -1. Leader produces a `BlindedBeaconBlock` from their Beacon node with [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it. +1. Leader produces a `BlindedBeaconBlock` from their Beacon node at [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it. 2. Operators sign the `BlindedBeaconBlock`. -3. Operators publish the `SignedBlindedBeaconBlock` to their Beacon node with [/eth/v1/beacon/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlindedBlock). +3. Operators publish the `SignedBlindedBeaconBlock` to their Beacon node at [/eth/v1/beacon/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlindedBlock). The Beacon node reveals the signature to the builder, which (ideally) reveals the transactions in return, after which it unblinds the block and publishes it to the network. @@ -49,9 +67,9 @@ Note: producing a `BlindedBeaconBlock` before and shortly thereafter (delay depe Unrealistic? -#### Secnario B: operators bypass the Beacon node to unblind from builders directly +#### Secnario B — Block is published by all operators -1. Leader produces a `BlindedBeaconBlock` from their Beacon node with [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it together with the endpoint of it's builder as `BuilderBlindedBeaconBlock`. +1. Leader produces a `BlindedBeaconBlock` from their Beacon node at [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it together with the endpoint of it's builder as `BuilderBlindedBeaconBlock`. ```go type BuilderBlindedBeaconBlock { @@ -62,13 +80,23 @@ Note: producing a `BlindedBeaconBlock` before and shortly thereafter (delay depe 2. Operators sign the `BlindedBeaconBlock`. -3. Operators submit the `SignedBlindedBeaconBlock` to the builder's endpoint with [/eth/v1/builder/blinded_blocks](https://ethereum.github.io/builder-specs/#/Builder/submitBlindedBlock) to reveal the transactions and unblind the block into a `SignedBlindedBlock`. +3. Operators submit the `SignedBlindedBeaconBlock` to the builder's endpoint at [/eth/v1/builder/blinded_blocks](https://ethereum.github.io/builder-specs/#/Builder/submitBlindedBlock) to reveal the transactions and unblind the block into a `SignedBlindedBlock`. -4. Operators publish the `SignedBeaconBlock` to their Beacon node with [/eth/v1/beacon/blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlock). +4. Operators publish the `SignedBeaconBlock` to their Beacon node at [/eth/v1/beacon/blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlock). ##### Issues ###### Unknown builder When producing blinded blocks with a Beacon node connected to multiple builders (currently possible via mev-boost), the block's builder is unspecified. So the leader can't determine which builder endpoint to share with the other operators, and only he can unblind & publish it. - We can mitigate this by requiring leaders to share the full list of builders they're working with, so that the other operators can try to unblind with each of them (ideally in parallel). \ No newline at end of file + We can mitigate this by requiring leaders to share the full list of builders they're working with, so that the other operators can try to unblind with each of them (ideally in parallel). + +#### Scenario C — Leader publishes revealed transactions for others to submit + +This increases both network traffic and delay to publish, so we'll probably not do it. + +#### Blinded block validation + +Nowadays, there's no meaningful validation we can do on blinded blocks, but there's [active discussion](https://github.com/flashbots/mev-boost/issues/99) about requiring builders to attach payment proofs on bids so that they can't cheat and reward themselves instead of the validator's `fee_recipient`. + +Ideally, payment proof validation should be handled by mev-boost, as it already examines the builders' bids, in which case operators would only have to ensure their Beacon nodes are always updated with the latest [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration). \ No newline at end of file From 00f1cd0ecfcfe5ac043f5db5dd0134cbecb26517 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 23 Nov 2022 11:27:33 +0200 Subject: [PATCH 03/25] wip --- sips/mev.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index 222e70d..2115589 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -17,15 +17,24 @@ Currently, operators wishing to offer competitive returns must be sophisticated #### Metadata Operators advertise whether they intend to build blinded blocks and which MEV relays they work with. -Since blinded blocks can't be validated for their `fee_recipient`, some validators may be willing to compromise on potential profits from MEV in return for the guaranteed block reward. +Since blinded blocks can't be validated for their `fee_recipient`, some validators may be willing to compromise on potential profits from MEV in return for the guaranteed block reward, and even more during adversarial conditions in which some previously trusted operators/builders are now defrauding validators. #### Node behaviour -Operators who wish to support blinded blocks must configure their node to do so, otherwise their node will reject signing those. + +##### Scenario A — Soft restriction +Operators who wish to support blinded blocks must configure their node to do so, otherwise it will reject signing those. Validators who want to propose MEV blocks would have to avoid registering with a combination of MEV and non-MEV operators, as the latter would reject any blinded blocks and result in a missed duty. > TODO: can't leaders just fall back to propose non-blinded blocks if at least one of the other operators is non-MEV supporting? This should allow such combinations. +##### Scenario B — Hard restriction +Operators set whether they propose blinded blocks in the SSV contract. + +Other operators verify this and forbid non-blinded block operators from proposing blinded blocks. + +Operators can update this setting in the contract, but there's a cooldown period of 7 days until this becomes effective to prevent operators from gaming this without their validators' knowledge. + ### Validator registration When a validator registers to the SSV contract, he may attach a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) including his `fee_receipient` and `gas_limit` preferences. From bf06ad92cac17bd8eff7e920f1df0a47c03aac28 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 10 May 2023 12:09:50 +0300 Subject: [PATCH 04/25] rewrite --- sips/mev.md | 96 +++++++++++++++++++++-------------------------------- 1 file changed, 38 insertions(+), 58 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index 2115589..07e51db 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -1,11 +1,13 @@ -| Author | Title | Category | Status | -|---------------------------|----------------------------------|----------|----------------------| -| Moshe Revah (@moshe-blox) | Support externally built blocks | Core | open-for-discussion | +| Author | Title | Category | Status | +| ------------------------- | ------------------------------- | -------- | ------------------- | +| Moshe Revah (@moshe-blox) | Support externally built blocks | Core | open-for-discussion | ## Summary + Support the production and proposal of blocks built by external entities, allowing operators to access blocks from a marketplace of builders such as [Flashbots](https://boost-relay.flashbots.net/). ## Rational & Design Goals + Block building is a computationally intensive task, and even more so when blockspace utilization and profit maximization are in mind. Additionally, many of the more profitable transactions, so-called MEV, are private and only accessible to validators through external block builders. Currently, operators wishing to offer competitive returns must be sophisticated block builders with private transaction flows. This SIP aims to change that by allowing them to register with and propose blocks from external builders who comply to [ethereum/builder-specs](https://github.com/ethereum/builder-specs). @@ -14,40 +16,40 @@ Currently, operators wishing to offer competitive returns must be sophisticated ### MEV-supporting operators -#### Metadata -Operators advertise whether they intend to build blinded blocks and which MEV relays they work with. +Operators who wish to propose blinded blocks must configure their node to do so, otherwise it will propose standard locally-built blocks. -Since blinded blocks can't be validated for their `fee_recipient`, some validators may be willing to compromise on potential profits from MEV in return for the guaranteed block reward, and even more during adversarial conditions in which some previously trusted operators/builders are now defrauding validators. +### Validator registration -#### Node behaviour +Builders require validators to publish a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) to set their `fee_recipient` and `gas_limit` preferences. -##### Scenario A — Soft restriction -Operators who wish to support blinded blocks must configure their node to do so, otherwise it will reject signing those. +When building a block for a validator, builders refer only to the registration with the highest timestamp. -Validators who want to propose MEV blocks would have to avoid registering with a combination of MEV and non-MEV operators, as the latter would reject any blinded blocks and result in a missed duty. +In the wild, some Ethereum validator clients currently produce and publish this message every epoch. -> TODO: can't leaders just fall back to propose non-blinded blocks if at least one of the other operators is non-MEV supporting? This should allow such combinations. +#### Fee recipients -##### Scenario B — Hard restriction -Operators set whether they propose blinded blocks in the SSV contract. +Validators may set their preferred `fee_receipient` address by calling `setFeeRecipientAddress` in the `SSVNetwork` contract. Validators may repeat this call as their preference changes over time. -Other operators verify this and forbid non-blinded block operators from proposing blinded blocks. +#### Signing -Operators can update this setting in the contract, but there's a cooldown period of 7 days until this becomes effective to prevent operators from gaming this without their validators' knowledge. +At the start of every slot, operators select their active validators with `ShouldRegisterValidatorAtSlot`, and for those, produce a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) with their preferred `fee_recipient`. -### Validator registration +```go +ValidatorRegistrationSlotInterval = 16 * SlotsPerEpoch -When a validator registers to the SSV contract, he may attach a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) including his `fee_receipient` and `gas_limit` preferences. +func ShouldRegisterValidatorAtSlot(index phase0.ValidatorIndex, slot phase0.Slot) bool { + return (index + slot) % ValidatorRegistrationSlotInterval == 0 +} +``` -The SSV contract must allow validators to update this attachment, as their preferences may change over time. +#### Publishing -Operators must validate the signature and keep track of their validators' latest attachment (by highest `timestamp`), and periodically publish it to their Beacon nodes at [/eth/v1/validator/register_validator](https://ethereum.github.io/beacon-APIs/#/Validator/registerValidator). +At the end of every slot, operators publish registrations for the validators selected for signing in that slot, using their most recent successfully signed registration. -An operator may publish for his entire validator set in bulk, however a single invalid signature may cause the request to fail and other attachments to be ignored, so a prior signature validation is crucial. - -> Note: producing a `BlindedBeaconBlock` before and shortly thereafter (delay depends on the builder) the registration may result in either: -> 1. Beacon node falls back to locally-built block from it's execution layer. -> 2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it. +> Note: Since relays/builders can have some delay with registrations, producing a blinded block before and shortly thereafter publishing the first registration may result in either: +> +> 1. Builder doesn't build a block, and Beacon node falls back to locally-built block from it's execution layer. +> 2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it yet. > 3. Builder rewards a potentially different `fee_recipient` from the validator's latest registration (such as a registration prior to onboarding to SSV.) #### Issues @@ -62,50 +64,28 @@ If gas limit is likely to change to adjust to network conditions, then this isn' ### Blinded block proposals -#### Scenario A — Block is published only by operators who share builder with leader - -1. Leader produces a `BlindedBeaconBlock` from their Beacon node at [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it. - -2. Operators sign the `BlindedBeaconBlock`. - -3. Operators publish the `SignedBlindedBeaconBlock` to their Beacon node at [/eth/v1/beacon/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlindedBlock). - - The Beacon node reveals the signature to the builder, which (ideally) reveals the transactions in return, after which it unblinds the block and publishes it to the network. - - ##### Issues - - Unrealistic? - -#### Secnario B — Block is published by all operators - -1. Leader produces a `BlindedBeaconBlock` from their Beacon node at [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) and broadcasts it together with the endpoint of it's builder as `BuilderBlindedBeaconBlock`. - - ```go - type BuilderBlindedBeaconBlock { - BuilderEndpoint string - BlindedBeaconBlock *spec.VersionedBlindedBeaconBlock - } - ``` +When a validator has a proposal duty, their operators: -2. Operators sign the `BlindedBeaconBlock`. +1. Produce a `BlindedBeaconBlock` from their Beacon node at [/eth/v1/validator/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Validator/produceBlindedBlock) +2. Reach consensus on and sign the round leader's `BlindedBeaconBlock` +3. Submit the `SignedBlindedBeaconBlock` to their Beacon nodes at [/eth/v1/beacon/blinded_blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlindedBlock) -3. Operators submit the `SignedBlindedBeaconBlock` to the builder's endpoint at [/eth/v1/builder/blinded_blocks](https://ethereum.github.io/builder-specs/#/Builder/submitBlindedBlock) to reveal the transactions and unblind the block into a `SignedBlindedBlock`. +Under the hood, each operator's Beacon node would attempt to unblind the block from it's connected builder(s) by revealing the signature to them, which would fail if they haven't built or don't know of this block. -4. Operators publish the `SignedBeaconBlock` to their Beacon node at [/eth/v1/beacon/blocks](https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlock). +Therefore, for unblinding to succeed, operators' Beacon nodes must share the same builder(s) with the round leader's Beacon node. - ##### Issues +Since SSV can't enforce a specific set of builder(s) at the protocol-level, operators would have to reach social consensus on which builder(s) to configure their Beacon nodes with. - ###### Unknown builder - When producing blinded blocks with a Beacon node connected to multiple builders (currently possible via mev-boost), the block's builder is unspecified. So the leader can't determine which builder endpoint to share with the other operators, and only he can unblind & publish it. +#### Locally-built blinded blocks - We can mitigate this by requiring leaders to share the full list of builders they're working with, so that the other operators can try to unblind with each of them (ideally in parallel). +Sometimes, Beacon nodes fallback to a locally-built `BlindedBeaconBlock`, either because it's configured to do so under certain conditions (profitability threshold; chain is unstable) or because the builder(s) are unavailable. -#### Scenario C — Leader publishes revealed transactions for others to submit +Locally-built blinded blocks can only be unblinded by the Beacon node which built it, which unfortunately means that only the round leader would successfully submit the block, thereby reducing the network outreach of the proposal down to a single Beacon node. -This increases both network traffic and delay to publish, so we'll probably not do it. +We should consider pushing operators to configure their node for less harsh fallback conditions, so that more of their blocks are externally-built and can be successfully submitted by other operators' Beacon nodes. #### Blinded block validation Nowadays, there's no meaningful validation we can do on blinded blocks, but there's [active discussion](https://github.com/flashbots/mev-boost/issues/99) about requiring builders to attach payment proofs on bids so that they can't cheat and reward themselves instead of the validator's `fee_recipient`. -Ideally, payment proof validation should be handled by mev-boost, as it already examines the builders' bids, in which case operators would only have to ensure their Beacon nodes are always updated with the latest [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration). \ No newline at end of file +Ideally, payment proof validation should be handled by [mev-boost](https://github.com/flashbots/mev-boost), as it already examines the builders' bids, in which case operators would only have to ensure their Beacon nodes are always updated with the latest [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration). From ac863a84a1c5bceb12361e7189b3a76671e017be Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 10 May 2023 14:45:58 +0300 Subject: [PATCH 05/25] gas limit --- sips/mev.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index 07e51db..f7886a1 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -52,15 +52,11 @@ At the end of every slot, operators publish registrations for the validators sel > 2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it yet. > 3. Builder rewards a potentially different `fee_recipient` from the validator's latest registration (such as a registration prior to onboarding to SSV.) -#### Issues +#### Issue: Gas limits -##### Gas limit +Unlike standard validator clients, gas limits are not set by validators, but rather by their operators. -Within the proposed construction, the gas limit is set by validators only and relies on them to update it if needed. - -If gas limit is likely to change to adjust to network conditions, then this isn't ideal because validators would have to track of it, and when it changes — produce a new signature and publish an update transaction to the contract (which may be very expensive when the network is congested). - -> TODO: examine the code of validator clients such as Lighthouse and Prysm to figure this out. +This SIP proposes to hardcode the gas limit to 30 million (which is the default in Prysm and Lighthouse), but recommends to keep watching it and modify if necessary. ### Blinded block proposals From b01c2885c0fd1a9a17e75656ad5f891892166c7b Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 10 May 2023 17:55:49 +0300 Subject: [PATCH 06/25] perf --- sips/mev.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index f7886a1..8647157 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -35,7 +35,7 @@ Validators may set their preferred `fee_receipient` address by calling `setFeeRe At the start of every slot, operators select their active validators with `ShouldRegisterValidatorAtSlot`, and for those, produce a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) with their preferred `fee_recipient`. ```go -ValidatorRegistrationSlotInterval = 16 * SlotsPerEpoch +ValidatorRegistrationSlotInterval = 10 * SlotsPerEpoch func ShouldRegisterValidatorAtSlot(index phase0.ValidatorIndex, slot phase0.Slot) bool { return (index + slot) % ValidatorRegistrationSlotInterval == 0 @@ -48,13 +48,15 @@ At the end of every slot, operators publish registrations for the validators sel > Note: Since relays/builders can have some delay with registrations, producing a blinded block before and shortly thereafter publishing the first registration may result in either: > -> 1. Builder doesn't build a block, and Beacon node falls back to locally-built block from it's execution layer. +> 1. Builder is unfamiliar with the validator yet and doesn't build a block, and Beacon node falls back to locally-built block from it's execution layer. > 2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it yet. > 3. Builder rewards a potentially different `fee_recipient` from the validator's latest registration (such as a registration prior to onboarding to SSV.) +> Note: Currently, implementation publishes registration differently: right after producing signatures. We're following the performance of that, and will either revise this SIP or the implementation accordingly. + #### Issue: Gas limits -Unlike standard validator clients, gas limits are not set by validators, but rather by their operators. +Gas limits are set by operators rather than validators, unlike in standard validator clients. This SIP proposes to hardcode the gas limit to 30 million (which is the default in Prysm and Lighthouse), but recommends to keep watching it and modify if necessary. @@ -74,9 +76,9 @@ Since SSV can't enforce a specific set of builder(s) at the protocol-level, oper #### Locally-built blinded blocks -Sometimes, Beacon nodes fallback to a locally-built `BlindedBeaconBlock`, either because it's configured to do so under certain conditions (profitability threshold; chain is unstable) or because the builder(s) are unavailable. +Sometimes, a Beacon node falls back to a locally-built `BlindedBeaconBlock` from it's execution layer, either because it's configured to do so under certain conditions (profitability threshold; chain is unstable) or because the builder(s) are unavailable. -Locally-built blinded blocks can only be unblinded by the Beacon node which built it, which unfortunately means that only the round leader would successfully submit the block, thereby reducing the network outreach of the proposal down to a single Beacon node. +A locally-built blinded block can only be unblinded by the same Beacon node which built it, which unfortunately means that only the round leader would successfully submit the block, thereby reducing the total network outreach of the proposal down to a single Beacon node. We should consider pushing operators to configure their node for less harsh fallback conditions, so that more of their blocks are externally-built and can be successfully submitted by other operators' Beacon nodes. From f53811ab9d2bfb5ed0999af8b62c3778a74b8106 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 12:19:57 +0300 Subject: [PATCH 07/25] rejection --- sips/mev.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index 8647157..94121ba 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -14,9 +14,9 @@ Currently, operators wishing to offer competitive returns must be sophisticated ## Specification -### MEV-supporting operators +### Configuration -Operators who wish to propose blinded blocks must configure their node to do so, otherwise it will propose standard locally-built blocks. +Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would reject blinded blocks and only propose standard locally-built blocks. ### Validator registration From 7fe773582f58683ce568402fce205a1342dc1efc Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 13:43:40 +0300 Subject: [PATCH 08/25] consensus --- sips/mev.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 94121ba..caa9066 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -16,7 +16,9 @@ Currently, operators wishing to offer competitive returns must be sophisticated ### Configuration -Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would reject blinded blocks and only propose standard locally-built blocks. +Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would reject QBFT proposals containing blinded blocks and only propose standard blocks. + +Therefore, MEV-averse validators should solely select operators who have disabled blinded proposals, otherwise consensus might be unattainable. ### Validator registration From c96fad83a1f8b9d5aea6f42b885208bc17425f69 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 13:45:25 +0300 Subject: [PATCH 09/25] fix --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index caa9066..0cdf3b7 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -18,7 +18,7 @@ Currently, operators wishing to offer competitive returns must be sophisticated Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would reject QBFT proposals containing blinded blocks and only propose standard blocks. -Therefore, MEV-averse validators should solely select operators who have disabled blinded proposals, otherwise consensus might be unattainable. +Therefore, validators should solely select operators with matching configuration, otherwise consensus might be unattainable. ### Validator registration From 949961550277e3ece51abac7be2569bebf3a9885 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 13:46:44 +0300 Subject: [PATCH 10/25] word --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 0cdf3b7..a7c9bd5 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -18,7 +18,7 @@ Currently, operators wishing to offer competitive returns must be sophisticated Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would reject QBFT proposals containing blinded blocks and only propose standard blocks. -Therefore, validators should solely select operators with matching configuration, otherwise consensus might be unattainable. +Therefore, validators should solely select operators with matching configuration, otherwise consensus might be unreachable. ### Validator registration From ba47a5a9e0dbc0f7296009eaabb578f3b24ccf7a Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 13:48:18 +0300 Subject: [PATCH 11/25] swap --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index a7c9bd5..17dd0f9 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -16,7 +16,7 @@ Currently, operators wishing to offer competitive returns must be sophisticated ### Configuration -Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would reject QBFT proposals containing blinded blocks and only propose standard blocks. +Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would only propose standard blocks and reject QBFT proposals containing blinded blocks. Therefore, validators should solely select operators with matching configuration, otherwise consensus might be unreachable. From ce6003a2516f104a2a9c0b4d6a60d43aaf7cb4ab Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 13:52:17 +0300 Subject: [PATCH 12/25] fix --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 17dd0f9..3eb8649 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -26,7 +26,7 @@ Builders require validators to publish a [`builder-specs/SignedValidatorRegistra When building a block for a validator, builders refer only to the registration with the highest timestamp. -In the wild, some Ethereum validator clients currently produce and publish this message every epoch. +In the wild, some Ethereum validator clients currently publish this message every epoch. #### Fee recipients From d6bb03d6a78f2664e53e5c48485b22ee1ee9d7fd Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 14:50:49 +0300 Subject: [PATCH 13/25] publishing --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 3eb8649..359ad5c 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -46,7 +46,7 @@ func ShouldRegisterValidatorAtSlot(index phase0.ValidatorIndex, slot phase0.Slot #### Publishing -At the end of every slot, operators publish registrations for the validators selected for signing in that slot, using their most recent successfully signed registration. +Every slot, operators should publish the most recent successfully signed registration for `1/SlotsPerEpoch` of their validators, so that all validators are registered at least once per epoch. > Note: Since relays/builders can have some delay with registrations, producing a blinded block before and shortly thereafter publishing the first registration may result in either: > From e4fbdfcea7ee608131e182755ec6d7d1718fbfb3 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 17:48:32 +0300 Subject: [PATCH 14/25] clarify --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 359ad5c..5870875 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -16,7 +16,7 @@ Currently, operators wishing to offer competitive returns must be sophisticated ### Configuration -Operators who wish to propose blinded blocks must configure their node to do so, otherwise it would only propose standard blocks and reject QBFT proposals containing blinded blocks. +Operators who wish to propose blinded blocks must configure their SSV node to do so, otherwise it would only propose standard blocks and reject QBFT proposals containing blinded blocks. Therefore, validators should solely select operators with matching configuration, otherwise consensus might be unreachable. From f555751d2e295fad64b549eba1b4ad7a95b2d048 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 19:31:13 +0300 Subject: [PATCH 15/25] suggestion --- sips/mev.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 5870875..e1dc8c4 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -46,7 +46,9 @@ func ShouldRegisterValidatorAtSlot(index phase0.ValidatorIndex, slot phase0.Slot #### Publishing -Every slot, operators should publish the most recent successfully signed registration for `1/SlotsPerEpoch` of their validators, so that all validators are registered at least once per epoch. +Every epoch, operators should publish the most recent successfully signed registration for their entire validator set. + +This SIP suggests to spread registrations between slots. For example, at every slot, operators may publish for a fraction of their validators (corresponding to `1/SlotsPerEpoch`), ensuring a more evenly distributed load on the Beacon node and builder(s). > Note: Since relays/builders can have some delay with registrations, producing a blinded block before and shortly thereafter publishing the first registration may result in either: > From 03b53d15cd6934f1ebc41eb9b7adfc8fbea4f3f5 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Thu, 11 May 2023 19:32:23 +0300 Subject: [PATCH 16/25] only --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index e1dc8c4..4afcee6 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -48,7 +48,7 @@ func ShouldRegisterValidatorAtSlot(index phase0.ValidatorIndex, slot phase0.Slot Every epoch, operators should publish the most recent successfully signed registration for their entire validator set. -This SIP suggests to spread registrations between slots. For example, at every slot, operators may publish for a fraction of their validators (corresponding to `1/SlotsPerEpoch`), ensuring a more evenly distributed load on the Beacon node and builder(s). +This SIP suggests to spread registrations between slots. For example, at every slot, operators may publish only for a fraction of their validators (corresponding to `1/SlotsPerEpoch`), ensuring a more evenly distributed load on the Beacon node and builder(s). > Note: Since relays/builders can have some delay with registrations, producing a blinded block before and shortly thereafter publishing the first registration may result in either: > From c415c119b726bae523f16c9680f907cbc2983d5c Mon Sep 17 00:00:00 2001 From: moshe-blox <89339422+moshe-blox@users.noreply.github.com> Date: Sun, 14 May 2023 11:31:12 +0300 Subject: [PATCH 17/25] Update sips/mev.md Co-authored-by: Nikita Kryuchkov --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 4afcee6..44ea726 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -30,7 +30,7 @@ In the wild, some Ethereum validator clients currently publish this message ever #### Fee recipients -Validators may set their preferred `fee_receipient` address by calling `setFeeRecipientAddress` in the `SSVNetwork` contract. Validators may repeat this call as their preference changes over time. +Validators may set their preferred `fee_recipient` address by calling `setFeeRecipientAddress` in the `SSVNetwork` contract. Validators may repeat this call as their preference changes over time. #### Signing From 27a0063613bd2872e454ceac53a9108d587c8a05 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Tue, 16 May 2023 19:56:16 +0300 Subject: [PATCH 18/25] clarify fee recipient flow --- sips/mev.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index 4afcee6..a2d9489 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -18,7 +18,7 @@ Currently, operators wishing to offer competitive returns must be sophisticated Operators who wish to propose blinded blocks must configure their SSV node to do so, otherwise it would only propose standard blocks and reject QBFT proposals containing blinded blocks. -Therefore, validators should solely select operators with matching configuration, otherwise consensus might be unreachable. +Therefore, validators should select operators with matching configuration. ### Validator registration @@ -30,7 +30,17 @@ In the wild, some Ethereum validator clients currently publish this message ever #### Fee recipients -Validators may set their preferred `fee_receipient` address by calling `setFeeRecipientAddress` in the `SSVNetwork` contract. Validators may repeat this call as their preference changes over time. +Validators may set their preferred `fee_recipient` address by calling `setFeeRecipientAddress` in the `SSVNetwork` contract, which emits a `FeeRecipientAddressUpdated` event. + +```solidity +function setFeeRecipientAddress(address feeRecipientAddress) external; + +event FeeRecipientAddressUpdated(address indexed owner, address recipientAddress); +``` + +Validators may repeat this call as their preference changes over time. + +Operators should incorporate the `fee_recipient` address from the most recent event emitted by a specific `owner` when constructing `ValidatorRegistration` messages for validators associated with that `owner`. #### Signing @@ -62,7 +72,7 @@ This SIP suggests to spread registrations between slots. For example, at every s Gas limits are set by operators rather than validators, unlike in standard validator clients. -This SIP proposes to hardcode the gas limit to 30 million (which is the default in Prysm and Lighthouse), but recommends to keep watching it and modify if necessary. +Since operators This SIP doesn't specify a gas limit, as it's (which is the default in Prysm and Lighthouse), but recommends to keep watching it and modify if necessary. ### Blinded block proposals From c37e351c87e3616487c5baaed02a4a19c1ef291e Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 17 May 2023 15:57:18 +0300 Subject: [PATCH 19/25] revisions --- sips/mev.md | 48 +++++++++++++++++++++++++++++++----------------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/sips/mev.md b/sips/mev.md index a2d9489..cf75319 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -22,15 +22,17 @@ Therefore, validators should select operators with matching configuration. ### Validator registration -Builders require validators to publish a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) to set their `fee_recipient` and `gas_limit` preferences. +#### Background -When building a block for a validator, builders refer only to the registration with the highest timestamp. +Builders require validators to publish a [`SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) to set their `fee_recipient` and `gas_limit` preferences + +When building a block for a validator, builders pay the `fee_recipient` specified in the registration with the highest timestamp. If there is no registration, the builder would usually not build a block altogether, however nothing prevents them from building a block an arbitrary address. In the wild, some Ethereum validator clients currently publish this message every epoch. -#### Fee recipients +#### Fee recipient addresses -Validators may set their preferred `fee_recipient` address by calling `setFeeRecipientAddress` in the `SSVNetwork` contract, which emits a `FeeRecipientAddressUpdated` event. +Owners may set the preferred `fee_recipient` address for their validators by calling `setFeeRecipientAddress` in the `SSVNetwork` contract, which emits a `FeeRecipientAddressUpdated` event. ```solidity function setFeeRecipientAddress(address feeRecipientAddress) external; @@ -38,13 +40,33 @@ function setFeeRecipientAddress(address feeRecipientAddress) external; event FeeRecipientAddressUpdated(address indexed owner, address recipientAddress); ``` -Validators may repeat this call as their preference changes over time. +Owners may repeat this call as their preference changes over time. + +#### Constructing `ValidatorRegistration` + +```go +type ValidatorRegistration struct { + FeeRecipient bellatrix.ExecutionAddress + GasLimit uint64 + Timestamp time.Time + Pubkey phase0.BLSPubKey +} +``` + +When constructing a `ValidatorRegistration` message for a validator, operators must populate the following fields: -Operators should incorporate the `fee_recipient` address from the most recent event emitted by a specific `owner` when constructing `ValidatorRegistration` messages for validators associated with that `owner`. +- `FeeRecipient`: the `fee_recipient` address from the most recent event emitted by the validator's owner. +- `GasLimit`: determined by social consensus. +- `Timestamp`: the time of the first slot of the current epoch. +- `Pubkey`: the public key of the validator. -#### Signing +Unlike in standard validator clients, in SSV, gas limits are set by operators rather than validators. Since at least `quorum` signatures are needed for BLS aggregation, it is crucial for operators to sign using the same `GasLimit`. -At the start of every slot, operators select their active validators with `ShouldRegisterValidatorAtSlot`, and for those, produce a [`builder-specs/SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) with their preferred `fee_recipient`. +Ideally, operators align their gas limits with the current gas limit in Ethereum and coordinate to modify it at the same time when it changes. + +#### Signing `ValidatorRegistration` + +At the start of every slot, operators select their active validators by `ShouldRegisterValidatorAtSlot`, and for each, begin a pre-consensus flow to sign the `ValidatorRegistration` message. ```go ValidatorRegistrationSlotInterval = 10 * SlotsPerEpoch @@ -54,7 +76,7 @@ func ShouldRegisterValidatorAtSlot(index phase0.ValidatorIndex, slot phase0.Slot } ``` -#### Publishing +#### Publishing `SignedValidatorRegistration` Every epoch, operators should publish the most recent successfully signed registration for their entire validator set. @@ -66,14 +88,6 @@ This SIP suggests to spread registrations between slots. For example, at every s > 2. Builder doesn't reward the validator's `fee_recipient` because it isn't aware of it yet. > 3. Builder rewards a potentially different `fee_recipient` from the validator's latest registration (such as a registration prior to onboarding to SSV.) -> Note: Currently, implementation publishes registration differently: right after producing signatures. We're following the performance of that, and will either revise this SIP or the implementation accordingly. - -#### Issue: Gas limits - -Gas limits are set by operators rather than validators, unlike in standard validator clients. - -Since operators This SIP doesn't specify a gas limit, as it's (which is the default in Prysm and Lighthouse), but recommends to keep watching it and modify if necessary. - ### Blinded block proposals When a validator has a proposal duty, their operators: From 93278c70a9d05276f47da0fe62fd4c7d6e2aed06 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 17 May 2023 16:03:10 +0300 Subject: [PATCH 20/25] gal's revision --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index cf75319..2d5cadb 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -66,7 +66,7 @@ Ideally, operators align their gas limits with the current gas limit in Ethereum #### Signing `ValidatorRegistration` -At the start of every slot, operators select their active validators by `ShouldRegisterValidatorAtSlot`, and for each, begin a pre-consensus flow to sign the `ValidatorRegistration` message. +At the start of every slot, operators select their active validators with `ShouldRegisterValidatorAtSlot`, and for those, collectively produce a [`SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) by aggregating BLS partial signatures. ```go ValidatorRegistrationSlotInterval = 10 * SlotsPerEpoch From 01bfe8e5c76b6c8907f46e0b2cfb994984448c92 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 17 May 2023 16:24:43 +0300 Subject: [PATCH 21/25] revise --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 2d5cadb..73e39ef 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -55,7 +55,7 @@ type ValidatorRegistration struct { When constructing a `ValidatorRegistration` message for a validator, operators must populate the following fields: -- `FeeRecipient`: the `fee_recipient` address from the most recent event emitted by the validator's owner. +- `FeeRecipient`: the `fee_recipient` address from the most recent event emitted by the validator's owner, or a zero address if no event was emitted. - `GasLimit`: determined by social consensus. - `Timestamp`: the time of the first slot of the current epoch. - `Pubkey`: the public key of the validator. From 637207616b08f3df8f085176ff3aa64f5504c7db Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 17 May 2023 16:28:06 +0300 Subject: [PATCH 22/25] fix --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 73e39ef..1517c19 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -26,7 +26,7 @@ Therefore, validators should select operators with matching configuration. Builders require validators to publish a [`SignedValidatorRegistration`](https://ethereum.github.io/builder-specs/#model-SignedValidatorRegistration) to set their `fee_recipient` and `gas_limit` preferences -When building a block for a validator, builders pay the `fee_recipient` specified in the registration with the highest timestamp. If there is no registration, the builder would usually not build a block altogether, however nothing prevents them from building a block an arbitrary address. +When building a block for a validator, builders pay the `fee_recipient` specified in the registration with the highest timestamp. If there is no registration, the builder should refuse to build a block altogether. In the wild, some Ethereum validator clients currently publish this message every epoch. From 48b2e64f36419c362b043771336ce8d2a1f31a63 Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 17 May 2023 16:57:09 +0300 Subject: [PATCH 23/25] fix --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 1517c19..d572bfa 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -55,7 +55,7 @@ type ValidatorRegistration struct { When constructing a `ValidatorRegistration` message for a validator, operators must populate the following fields: -- `FeeRecipient`: the `fee_recipient` address from the most recent event emitted by the validator's owner, or a zero address if no event was emitted. +- `FeeRecipient`: the `fee_recipient` address from the most recent event emitted by the validator's owner, or the validator's owner address (if no event was emitted). - `GasLimit`: determined by social consensus. - `Timestamp`: the time of the first slot of the current epoch. - `Pubkey`: the public key of the validator. From d2fd60cb317101734e191e4ea87e68a3dba4bdcc Mon Sep 17 00:00:00 2001 From: moshe-blox Date: Wed, 17 May 2023 16:58:35 +0300 Subject: [PATCH 24/25] clarify --- sips/mev.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sips/mev.md b/sips/mev.md index d572bfa..3240820 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -42,6 +42,8 @@ event FeeRecipientAddressUpdated(address indexed owner, address recipientAddress Owners may repeat this call as their preference changes over time. +If an owner has never set called `setFeeRecipientAddress`, their execution address would be used instead. + #### Constructing `ValidatorRegistration` ```go From 405b15e48b62e37ad47fb67b5df442fb717beda5 Mon Sep 17 00:00:00 2001 From: Gal Rogozinski Date: Thu, 14 Dec 2023 11:29:52 +0200 Subject: [PATCH 25/25] approved --- sips/mev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/mev.md b/sips/mev.md index 3240820..84f4cf8 100644 --- a/sips/mev.md +++ b/sips/mev.md @@ -1,6 +1,6 @@ | Author | Title | Category | Status | | ------------------------- | ------------------------------- | -------- | ------------------- | -| Moshe Revah (@moshe-blox) | Support externally built blocks | Core | open-for-discussion | +| Moshe Revah (@moshe-blox) | Support externally built blocks | Core | approved | ## Summary