MEV SIP (v2) #25

moshe-blox · 2023-05-10T09:11:15Z

This PR supersedes #20 to solidify the specifications for supporting the proposal of blinded blocks in SSV.

sips/mev.md

alonmuroch · 2023-05-10T15:00:52Z

sips/mev.md

+
+Unlike standard validator clients, gas limits are not set by validators, but rather by their operators.
+
+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.


In validator clients, it's configurable with a default of 30 million. In SSV it's currently hardcoded to the same value: https://github.com/bloxapp/ssv/blob/38193908b145dbe29186de34a6c60df1085c92e4/beacon/goclient/proposer.go#L27

Do you think it should be configurable? @alonmuroch

That's ethereum dependent so not sure

We can let operators configure this, but if they differ, they will not be able to reconstruct signatures for ValidatorRegistration because it contains this value.

Social consensus on gas limit hasn't changed (at least) since The Merge, and if it does we'd want operators to switch at roughly the same time to avoid differing ValidatorRegistration, so maybe waiting for this to change and then releasing a version with a transition scheduled at a specific epoch/slot is safer?

If they configure it differently it can cause consensus issues?

Not QBFT consensus, they will just fail to aggregate signatures in pre-consensus of ValidatorRegistration: https://github.com/nkryuchkov/ssv-spec/blob/d0730a175f4543f325f4e798a047084a28744000/ssv/validator_registration.go#L67

The only reason I can think it is good to have it configurable is for testnets.
Other than that the operator shouldn't touch this value.
But the only reason to test different gas limit, is if ethereum will have a fork.

So I agree with @moshe-blox and have it non-configurable.
If someone disagrees please say so, because the spec will make it a constant.

sips/mev.md

alonmuroch · 2023-05-10T15:02:18Z

sips/mev.md

+
+Therefore, for unblinding to succeed, operators' Beacon nodes must share the same builder(s) with the round leader's Beacon node.
+
+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.


what happens if there is a mix of both ssv operators proposing blinded and non blinded blocks in the same cluster?

Currently nodes with blinded proposals disabled are not rejecting blinded blocks.

and viceversa?

I think we discussed it should be strict.
If Im an operator that doesn't want to support MEV, I should not participate in the Consensus if the leader proposed MEV

viceversa should be allowed

Updated: https://github.com/bloxapp/SIPs/pull/25/files#diff-ffa7094aebeadab838e68f9af7d1be31bb06e525d5b9436cf8732dff04ab62bbR17-R21

@lior-blox
Let say in a 4 node cluster 2 operators don't want to support MEV?
So no block will ever be produced?

Also why would some operators oppose to use MEV? I can only think of idealogical reasons or deep mistrust of relays. In this case, I think it is more of the validator's choice and not the operator.

@GalRogozinski
In the scenario, only proposals that the leader is non mev will be successful.
It could be various reasons like ideology or legal etc.

The operators will use metadata to let the validators If they MEV support and which relays

I think we need to have a writeup somewhere on why we are doing this.
When I talked to @lior-blox and @moshe-blox they both gave me different reasons.

This feature may break consensus. Maybe there are good reasons to add the feature despite the risk, but they should be super clear to us!

This discussion can continue here:
#25 (comment)

sips/mev.md

GalRogozinski · 2023-05-11T12:20:17Z

sips/mev.md

+
+Therefore, for unblinding to succeed, operators' Beacon nodes must share the same builder(s) with the round leader's Beacon node.
+
+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.


@lior-blox
Let say in a 4 node cluster 2 operators don't want to support MEV?
So no block will ever be produced?

Also why would some operators oppose to use MEV? I can only think of idealogical reasons or deep mistrust of relays. In this case, I think it is more of the validator's choice and not the operator.

sips/mev.md

Co-authored-by: Nikita Kryuchkov <[email protected]>

alonmuroch · 2023-05-15T07:41:37Z

sips/mev.md

+
+### Configuration
+
+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.


doesn't this mean if you mix MEV and non MEV operators it doesn't work?

Yeah, originally I wanted blinded/non-blinded to be a property operators set in the contract with a cooldown period to make them commit to their claim for at least a week or two.

So for example if an operator switches from non-blinded to blinded in the contract, but also switches it in his node before the cooldown period is over, his blocks would be rejected by other operators.

Cooldown period helps validators rest assured that their operators aren't switching modes rapidly.

Eventually, we didn't go this way, so now rejecting blocks sounds less appealing.

Still, I can think of a few reasons for rejections:

Relay/operator theft: imagine a scenario where many relays/operators suddenly stop paying the fee & MEV rewards to validators. Validators start panicking and migrating to non-blinded operators, and because we verify the fee recipient in non-blinded blocks, they should be safe. However, if non-blinded operators don't reject blinded blocks, there is nothing to prevent an operator masquerading as non-blinded from spontaneously proposing a single blinded block that steals fees, every once in a while.

Regulatory Compliance: Operators who wish to be OPAC-compliant may want to avoid signing blinded blocks, as they could hide non-compliant transactions. However, as @GalRogozinski pointed out, this is only a partial solution. Operators would also need to patch their SSV node to inspect non-blinded blocks, making block rejection a less compelling standalone solution.

@moshe-blox
can you please elaborate on the motivation for cool down period?

@GalRogozinski Cooldown period is a commitment between operators to validators. When validators choose a non-blinded operator, they can rest assured that it would not suddenly change it's mind and start proposing blinded blocks. Validators would know of this change a week in advance (or however long the cooldown period is) and can migrate over to other operators before it takes effect.

maybe the relay/operator case be added to the SIP?

Chiming in here to mention that beacon API specs has changed since this SIP, the separate API calls to the beacon node about getting a full or blinded block have been deprecated, the new V3 api call will get you a blinded block if your beacon node is connected to MEV relays and possible and the blinded block is more profitable than a local one, otherwise it will get you a local full block.
this means its not straight forward anymore to config the SSV operator node to support or not support MEV, this responsibility is now on the beacon node.

alonmuroch · 2023-05-15T07:42:46Z

sips/mev.md

+
+### 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.


how and when do they publish it? should it be in the spec?

This section specifies when to publish.

There is no rule in the Ethereum builder-specs regarding when/how often this should be publish, but @lior-blox suggested that we should specify it in the spec so that future SSV implementations would be aligned on it.

alonmuroch · 2023-05-15T07:43:46Z

sips/mev.md

+
+#### Fee recipients
+
+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.


what's the default address?

what's the default address?

Good catch.

Edit: Talked with @nkryuchkov, currently the default in the implementation is the validator's owner address.

Updating this in the SIP.

alonmuroch · 2023-05-15T07:45:14Z

sips/mev.md

+
+Unlike standard validator clients, gas limits are not set by validators, but rather by their operators.
+
+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.


If they configure it differently it can cause consensus issues?

GalRogozinski

There are a few holes in order for the reader to get a good grasp of how this thing should work on SSV.

I would also like to have explanations on what validations we are doing (or not doing) to message registration and why it is fine. This will force us to think about any security issues.

sips/mev.md

GalRogozinski · 2023-05-17T07:59:32Z

sips/mev.md

+
+Therefore, for unblinding to succeed, operators' Beacon nodes must share the same builder(s) with the round leader's Beacon node.
+
+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.


I think we need to have a writeup somewhere on why we are doing this.
When I talked to @lior-blox and @moshe-blox they both gave me different reasons.

This feature may break consensus. Maybe there are good reasons to add the feature despite the risk, but they should be super clear to us!

GalRogozinski · 2023-05-17T08:05:46Z

sips/mev.md

+#### Fee recipients
+
+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`.
+


This is also how the general registration process is initiated by the user (validator)?
If so, let's make it clear?
If not? then how it is started?

GalRogozinski

There are a few holes in order for the reader to get a good grasp of how this thing should work on SSV.

I would also like to have explanations on what validations we are doing (or not doing) to message registration and why it is fine. This will force us to think about any security issues.

alonmuroch · 2023-05-24T05:52:21Z

@moshe-blox @lior-blox update?

moshe-blox added 4 commits November 22, 2022 14:39

first draft

6fcc45e

wip

9b5bd2a

wip

00f1cd0

rewrite

bf06ad9

moshe-blox requested review from y0sher, alonmuroch and liorrutenberg May 10, 2023 11:18

moshe-blox added 2 commits May 10, 2023 14:45

gas limit

ac863a8

perf

b01c288

alonmuroch requested changes May 10, 2023

View reviewed changes

liorrutenberg requested a review from GalRogozinski May 11, 2023 07:40

moshe-blox added 6 commits May 11, 2023 12:19

rejection

f53811a

consensus

7fe7735

fix

c96fad8

word

9499615

swap

ba47a5a

fix

ce6003a

moshe-blox requested a review from alonmuroch May 11, 2023 11:40

liorrutenberg approved these changes May 11, 2023

View reviewed changes

publishing

d6bb03d

GalRogozinski reviewed May 11, 2023

View reviewed changes

moshe-blox added 3 commits May 11, 2023 17:48

clarify

e4fbdfc

suggestion

f555751

only

03b53d1

moshe-blox requested a review from GalRogozinski May 11, 2023 16:33

nkryuchkov reviewed May 12, 2023

View reviewed changes

sips/mev.md Outdated Show resolved Hide resolved

nkryuchkov reviewed May 12, 2023

View reviewed changes

sips/mev.md Show resolved Hide resolved

Update sips/mev.md

c415c11

Co-authored-by: Nikita Kryuchkov <[email protected]>

moshe-blox requested a review from nkryuchkov May 14, 2023 12:00

alonmuroch requested changes May 15, 2023

View reviewed changes

moshe-blox added 2 commits May 16, 2023 19:56

clarify fee recipient flow

27a0063

merge

ae3eb60

GalRogozinski requested changes May 17, 2023

View reviewed changes

moshe-blox added 6 commits May 17, 2023 15:57

revisions

c37e351

gal's revision

93278c7

revise

01bfe8e

fix

6372076

fix

48b2e64

clarify

d2fd60c

moshe-blox mentioned this pull request May 17, 2023

MEV support ssvlabs/ssv-spec#226

Merged

GalRogozinski approved these changes Nov 15, 2023

View reviewed changes

approved

405b15e

GalRogozinski requested a review from alonmuroch January 23, 2024 09:55


		Unlike standard validator clients, gas limits are not set by validators, but rather by their operators.

		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.


		Therefore, for unblinding to succeed, operators' Beacon nodes must share the same builder(s) with the round leader's Beacon node.

		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.


		### Configuration

		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.


		### 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.


		#### Fee recipients

		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.

MEV SIP (v2) #25

Are you sure you want to change the base?

MEV SIP (v2) #25

Conversation

moshe-blox commented May 10, 2023 • edited Loading

Choose a reason for hiding this comment

moshe-blox May 10, 2023 • edited Loading

Choose a reason for hiding this comment

moshe-blox May 10, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moshe-blox May 15, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moshe-blox May 11, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moshe-blox May 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moshe-blox May 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moshe-blox May 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GalRogozinski left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GalRogozinski left a comment

Choose a reason for hiding this comment

alonmuroch commented May 24, 2023

moshe-blox commented May 10, 2023 •

edited

Loading

moshe-blox May 10, 2023 •

edited

Loading

moshe-blox May 10, 2023 •

edited

Loading

moshe-blox May 15, 2023 •

edited

Loading

moshe-blox May 11, 2023 •

edited

Loading

moshe-blox May 17, 2023 •

edited

Loading

moshe-blox May 17, 2023 •

edited

Loading

moshe-blox May 17, 2023 •

edited

Loading