Add EIP: Execution layer triggerable exits #7002

djrtwo · 2023-05-09T13:14:28Z

Add a cross-layer method to trigger validator exits from the execution layer.

Note, the consensus layer spec is just a sketch and will be implemented on the CL specs repo soon

eth-bot · 2023-05-09T13:15:15Z

File `EIPS/eip-7002.md`

Requires 1 more reviewers from @axic, @g11tech, @gcolvin, @lightclient, @Pandapip1, @SamWilsn

micho · 2023-05-09T13:27:00Z

This is massive for liquid staking protocols and DVT setups.

We've been very looking forward to this at Diva specifically

This EIP would allow to manage risk much better for scenarios like loss of private keys, or scenarios where DVT validators have lost connectivity to a majority of their key shares, which could occur if there's mass censorship or downtime in a popular AWS region for example.

I agree with @djrtwo that no solution I've heard of relies on this not being possible, and that a SC is an elegant workaround for any cases which might.

alonmuroch · 2023-05-09T14:02:37Z

EIPS/eip-7002.md

+
+#### Exit precompile
+
+The precompile requires a single `8` byte big-endian `uint64` input, aliased to `validator_index`.


Most, if not all, staking pools keep track of validator public key not validator_index.
Can it be triggered by the pub key (considering it takes more space)?

Interesting. And EL does not trustlessly have this info without something like BEACON_ROOT.

The beacon chain does not maintain a mapping of pubkey to validator so would require a full sweep to search for the validator when validating and performing the exit. This full sweep would just be in the spec -- the clients would maintain a pubkey -> index mapping to do so efficiently. This functionality exists in some form in due to pubkey requirements of process_deposit so it's probably okay

I'll ask around about functionality and then make the spec change

Definitely doable by some oracle, just another step pools (and others) will need to add before they can ensure EL withdrawal.

Better to use pubkey if possible. Getting a validator index for pubkey on EL is complex but needed for staking protocols; and extra complexity here only brings gains in form of a few bytes per exit.

Pubkey would be a strong preference for Rocket Pool.

alonmuroch · 2023-05-09T14:05:09Z

Really useful. Opens up a lot of possibilities, specifically DKG validators running on DVT.

MicahZoltu · 2023-05-09T15:44:24Z

EIPS/eip-7002.md

+## Motivation
+
+Validators have two keys -- an active key and a withdrawal credential. The active key takes the form of a BLS key, whereas the withdrawal credential can either be a BLS key (0x00) or a execution layer address (0x01). The active key is "hot", actively signing and performing validator duties, whereas the withdrawal credential can remain "cold", only performing limited operations in relation to withdrawing and ownership of the staked ETH. Due to this security relationship, the withdrawal credential ultimately is the key that owns the staked ETH and any rewards. 
+
+As currently specified, only the active key can initiate a validator exit. This means that in any non-standard custody relationships (i.e. active key is separate entity from withdrawal credentials), that the ultimate owner of the funds -- the possessor of the withdrawal credentials -- cannot independently choose to exit and begin the withdrawal process. This leads to either trust issues (e.g. ETH can be "held hostage" by the active key owner) or insufficient work-arounds such as pre-signed exits. Additionally, in the event that active keys are lost, a user should still be able to recover their funds by using their cold withdrawal credentials.
+
+To ensure that the withdrawal credentials (owned by both EOAs and smart contracts) can trustlessly control the destiny of the staked ETH, this specification enables exits triggerable by 0x01 withdrawal credentials.
+
+Note, 0x00 withdrawal credentials can be changed into 0x01 withdrawal credentials with a one-time signed message. Thus any functionality enabled for 0x01 credentials is defacto enabled for 0x00 credentials.


Consider adding a note to the motivation that withdraw credentials can have complex recovery mechanisms that simultaneously protect users from both loss and theft which are not possible to private keys (e.g., time based recovery, social recovery, survivorship, etc.).

Also worth noting that by making the validator keys unnecessary for exiting, a validator can favor "protection from theft" exclusively with their validator keys without having to concern themselves with "protection from loss". At the moment, validators MUST (game theoretically) prioritize protection from loss over protection from theft and these two are often in direct opposition to each other. This means someone could have their validator keys on disk only on their heavily locked down validator node, and if the node is destroyed they can exit to recover. Right now this would be an absolutely terrible idea.

EIPS/eip-7002.md

vshvsh · 2023-05-09T17:34:32Z

EIPS/eip-7002.md

+
+The alternative designs are (1) to utilize a precompile or opcode for the functionality and write a separate specified space in the EVM -- e.g. `0xFF..FF` -- or (2) to place the required state into the block and require the previous block header as an input into the state transition function (e.g. like 1559 `base_fee`).
+
+Alternative design (1) is essentially using a stateful precompile but dissociating the state into a separate address. At first glance, this split appears unnecessarily convoluted when we could store the location of the `CALL` and the associated state in the same address. That said, there might be unexpected engineering constraints around precompiles in existing clients that make this a preferable path.


One more consideration here is that it'd be nice to be able to know the current fee in a smart contract, so it'd be nice to have a stateful precompile with view functions for state. That would make it pretty complex for a precompile.

I think a prerompile + separate address for storage and view functions is not a bad option.

We were discussing having two precompiles:

A precompile where to perform the exit (reads and writes to (2))

A precompile with a fee-read that has all of the state utilized by (1)

I think this reasonable. CC: @adietrichs for input

Might have been answered before...when precompile vs when opcode?

EIPS/eip-7002.md

hwwhww · 2023-05-09T15:29:00Z

EIPS/eip-7002.md

+Sketch of spec:
+
+* New operation `ExecutionLayerExit`
+* Will show up in `ExecutionPayload` as a vector bound by length `MAX_EXITS_PER_BLOCK`


"vector" is a special term in SSZ. just to clarify:

Suggested change

* Will show up in `ExecutionPayload` as a vector bound by length `MAX_EXITS_PER_BLOCK`

* Will show up in `ExecutionPayload` as an SSZ List bound by length `MAX_EXITS_PER_BLOCK`

EIPS/eip-7002.md

hwwhww · 2023-05-09T19:06:10Z

EIPS/eip-7002.md

+
+### Consensus layer
+
+In progress.


FYI
[WIP] CL specs side PR: ethereum/consensus-specs#3349

github-actions · 2023-05-09T21:52:49Z

The commit d75602c (as a parent of fa0b79a) contains errors.
Please inspect the Run Summary for details.

vshvsh · 2023-05-10T07:47:07Z

EIPS/eip-7002.md

+
+### Stateful precompile
+
+This specification utilizes a *stateful* precompile for simplicity and future-proofness. While precompiles are a well-known quantity, none to date have associated EVM state at the address.


I think it'd be useful to explicitly list what parts of that mechanism will be more future proof (more interface-y) vs which ones are expected to be more malleable (more of an implementation) so that smart contract developers would understand what can be relayed upon.

Similar how to it's clear deposit smart contract is expected to be a staple for a long time or maybe forever, but the exact mechanism to relay deposits to beacon chain is under talks to be simplified a lot, I think implementation details can change here too. There's a decent chance that fee mechanism could change if we find out that in practice it's too high (e.g. we see that making trustless protocol is less efficient than trustful bc they have to pay a lot more for EL triggered exits) or too low (e.g. if we see it is effectively DOS'ed). The plethora of el-cl communication bands might get refactored for simplicity and uniformity as well.

E.g. as far as far as my intuition goes it would be:

More reliable parts:

withdrawer credential owner can initiate an exit by paying a fee and providing a public key of a validator

you can read the current fee using fee view precompile

you provide the fee by making a call with value >= the fee

excess ether will be returned to the address that makes the call

there's a limited amount of exits that fit into the block

Malleable parts:

Fee are calculated using formula ...

amount of exits per block is ...

exits are communicated to beacon chain using a particular mechanism ...

mkalinin · 2023-05-11T04:51:57Z

EIPS/eip-7002.md

+        SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1)
+        + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1)[0:16]


Suggested change

SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1)

+ SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1)[0:16]

SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 2)[0:16]

xanatos · 2023-05-16T08:58:52Z

My 2 cents... For sure there are persons that had their withdrawal keys compromised while they are retaining control of their validator keys. At this time, they are at an impasse: their profits can be stolen through the compromised withdrawal keys (it is a race for the first one that moves them out from the compromised withdrawal address) while their 32 ETH are "protected", because the hacker doesn't have the validator key and/or the mnemonic. Clearly this proposal would give the possibility for the hacker to gain access to the 32 ETH (it would be a race for whoever is then able to "extract" first the 32 ETH from the withdrawal address). I think that organizing a CLWP for this particular case BEFORE passing this EIP would be a good idea (and/or thinking about other solutions).

hwwhww · 2023-05-23T17:04:58Z

EIPS/eip-7002.md

+])
+```
+
+#### Exit precompile


In programming, "Exit" typically conveys a system shutdown. How about renaming "Exit" to "Validator Exit"?

ralexstokes · 2023-06-26T17:36:22Z

EIPS/eip-7002.md

+rlp_encoded_exit = RLP([
+    RLP(source_address),
+    RLP(validator_pubkey),
+])


I have learned in the past that the editors' preference is to write this like so:

Suggested change

rlp_encoded_exit = RLP([

RLP(source_address),

RLP(validator_pubkey),

])

rlp_encoded_exit = RLP([

source_address,

validator_pubkey,

])

+1, only top rlp is prefered

ralexstokes · 2023-06-26T17:39:32Z

EIPS/eip-7002.md

+    # Latest block body field before `exits`
+    rlp_encoded_field_n,
+
+    RLP([rlp_encoded_exit_0, ..., rlp_encoded_exit_k]),


ditto

Suggested change

RLP([rlp_encoded_exit_0, ..., rlp_encoded_exit_k]),

[rlp_encoded_exit_0, ..., rlp_encoded_exit_k],

timbeiko · 2023-06-26T21:09:20Z

@g11tech I see you've reviewed this a while back - it'd be nice if we could merge it given the amount of discussion that's happened on the PR

g11tech · 2023-06-27T03:12:25Z

@g11tech I see you've reviewed this a while back - it'd be nice if we could merge it given the amount of discussion that's happened on the PR

👍
I think there are new relevant comments to be addressed.

Will incorporate them wherever they seem straightforward and see if the PR can be merg e

g11tech · 2023-06-29T08:17:15Z

EIPS/eip-7002.md

+2. The list of exit operations contained in the block body **MUST** be equivalent to list of exits at the head of the exit precompile's exit message queue up to the maximum of `MAX_EXITS_PER_BLOCK`, respecting the order in the queue. This validation **MUST** be run after all transactions in the current block are processed and **MUST** be run before per-block precompile storage calculations (i.e. a call to `update_exit_precompile()`) are performed. To illustrate:
+
+```python
+class ValidatorExit(object):


have updated to ValidatorExit rather than just exit,

should the field names be update to validatior_exits in block/payload etc. although exits in the block is pretty clear to what is being refereed , so letting it stay

g11tech · 2023-06-29T08:31:00Z

have added a bit of TODOs based on the conversations which could be resolved/cleaned when moving post draft stage

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

g11tech

gtg for draft 👍

lightclient · 2023-06-29T14:13:21Z

bot doesn't seem to working right now, going to go ahead and merge

fabriciomirandabr · 2023-07-11T12:23:59Z

Waiting for that on @staketogether 👀

* add EL exits EIP * update to EIP 7002 * add discussions-to url * fix typo on body name * quick add * lint * Apply suggestions from code review Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> * EIP 7002 feedbacl * add links to referenced EIPs * eip 7002: change validator_index to validator_pubkey * fix rlp encoding * update precompile var reference * fix body rlp * apply corrections * add todos to be addressed post draft stage --------- Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> Co-authored-by: gajinder <develop@g11tech.io>

Gemrav

Scammers fraud alert

* add EL exits EIP * update to EIP 7002 * add discussions-to url * fix typo on body name * quick add * lint * Apply suggestions from code review Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> * EIP 7002 feedbacl * add links to referenced EIPs * eip 7002: change validator_index to validator_pubkey * fix rlp encoding * update precompile var reference * fix body rlp * apply corrections * add todos to be addressed post draft stage --------- Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> Co-authored-by: gajinder <develop@g11tech.io>

djrtwo requested a review from eth-bot as a code owner May 9, 2023 13:14

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-core labels May 9, 2023

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels May 9, 2023

github-actions bot added the w-ci Waiting on CI to pass label May 9, 2023

djrtwo force-pushed the el-exits branch from b2129e2 to 668d53c Compare May 9, 2023 13:31

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels May 9, 2023

alonmuroch suggested changes May 9, 2023

View reviewed changes

MicahZoltu reviewed May 9, 2023

View reviewed changes

g11tech reviewed May 9, 2023

View reviewed changes

EIPS/eip-7002.md Show resolved Hide resolved

ariskk reviewed May 9, 2023

View reviewed changes

EIPS/eip-7002.md Outdated Show resolved Hide resolved

g11tech reviewed May 9, 2023

View reviewed changes

EIPS/eip-7002.md Show resolved Hide resolved

vshvsh reviewed May 9, 2023

View reviewed changes

hwwhww mentioned this pull request May 9, 2023

EIP-7002: Execution layer triggerable exits ethereum/consensus-specs#3349

Merged

1 task

hwwhww reviewed May 9, 2023

View reviewed changes

github-actions bot removed the w-ci Waiting on CI to pass label May 9, 2023

vshvsh reviewed May 10, 2023

View reviewed changes

mkalinin reviewed May 11, 2023

View reviewed changes

hwwhww reviewed May 23, 2023

View reviewed changes

boulder225 mentioned this pull request Jun 1, 2023

Document the 0x04 withdrawal contract exit in a design doc for Ethereum Foundation ObolNetwork/obol-splits#38

Closed

ralexstokes reviewed Jun 26, 2023

View reviewed changes

g11tech reviewed Jun 29, 2023

View reviewed changes

djrtwo and others added 15 commits June 29, 2023 14:01

add EL exits EIP

19b5a5d

update to EIP 7002

50a5a93

add discussions-to url

22bf716

fix typo on body name

36ffd2f

quick add

5d8e53c

lint

2d633e0

Apply suggestions from code review

570a11e

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

EIP 7002 feedbacl

af00622

add links to referenced EIPs

8234bfb

eip 7002: change validator_index to validator_pubkey

0dcd0df

fix rlp encoding

e477f7f

update precompile var reference

87e42bc

fix body rlp

d40d5ed

apply corrections

912c981

add todos to be addressed post draft stage

b22c25a

g11tech force-pushed the el-exits branch from f658cdf to b22c25a Compare June 29, 2023 08:32

g11tech approved these changes Jun 29, 2023

View reviewed changes

lightclient closed this Jun 29, 2023

lightclient reopened this Jun 29, 2023

lightclient merged commit 28cbb01 into ethereum:master Jun 29, 2023

Gemrav reviewed Apr 5, 2024

View reviewed changes


		#### Exit precompile

		The precompile requires a single `8` byte big-endian `uint64` input, aliased to `validator_index`.


		The alternative designs are (1) to utilize a precompile or opcode for the functionality and write a separate specified space in the EVM -- e.g. `0xFF..FF` -- or (2) to place the required state into the block and require the previous block header as an input into the state transition function (e.g. like 1559 `base_fee`).

		Alternative design (1) is essentially using a stateful precompile but dissociating the state into a separate address. At first glance, this split appears unnecessarily convoluted when we could store the location of the `CALL` and the associated state in the same address. That said, there might be unexpected engineering constraints around precompiles in existing clients that make this a preferable path.

	* Will show up in `ExecutionPayload` as a vector bound by length `MAX_EXITS_PER_BLOCK`
	* Will show up in `ExecutionPayload` as an SSZ List bound by length `MAX_EXITS_PER_BLOCK`


		### Stateful precompile

		This specification utilizes a stateful precompile for simplicity and future-proofness. While precompiles are a well-known quantity, none to date have associated EVM state at the address.

		SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1)
		+ SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1) + SLOAD(EXIT_PRECOMPILE_ADDRESS, queue_storage_slot + 1)[0:16]

	RLP([rlp_encoded_exit_0, ..., rlp_encoded_exit_k]),
	[rlp_encoded_exit_0, ..., rlp_encoded_exit_k],

Add EIP: Execution layer triggerable exits #7002

Add EIP: Execution layer triggerable exits #7002

Uh oh!

Conversation

djrtwo commented May 9, 2023

Uh oh!

eth-bot commented May 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

File EIPS/eip-7002.md

Uh oh!

micho commented May 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djrtwo May 9, 2023 • 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!

Choose a reason for hiding this comment

Uh oh!

vshvsh May 9, 2023 • 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!

Choose a reason for hiding this comment

Uh oh!

alonmuroch commented May 9, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented May 9, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xanatos commented May 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

timbeiko commented Jun 26, 2023

Uh oh!

g11tech commented Jun 27, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

g11tech commented Jun 29, 2023

Uh oh!

g11tech left a comment

Choose a reason for hiding this comment

Uh oh!

lightclient commented Jun 29, 2023

Uh oh!

fabriciomirandabr commented Jul 11, 2023

Uh oh!

Gemrav left a comment

Choose a reason for hiding this comment

eth-bot commented May 9, 2023 •

edited

Loading

File `EIPS/eip-7002.md`

micho commented May 9, 2023 •

edited

Loading

djrtwo May 9, 2023 •

edited

Loading

vshvsh May 9, 2023 •

edited

Loading

xanatos commented May 16, 2023 •

edited

Loading