Discussion topic for EIP-7002
4 Likes
I have two big opinions on the EIP.
Firstly, I think rather that specifically having an âExit Validatorâ precompile, we should instead have a âSend Message to Consensus Layerâ precompile. Itâs entirely possible that we will want the EL to send different kinds of message and it would be annoying to have to add a precompile every time we want to add a new message type. We should also allow messages to carry Ether so we can do things like having new ways to initialise a validator. This gives us a broad scope to make EL-to-CL interaction changes without updating the EL at all.
Secondly, Iâm really confused why this is a precompile, rather that just a smart contract with some special handling rules (if it emits a log put it in the header). The entire logic of the precompile is the sort of accounting computation that is the bread and butter of smart contracts and it seems pointlessly wasteful to make every EL client include a bunch of special case code for it when it could be implemented in Solidity once.
1 Like
Iâm hesitant to implement a general messaging bus here. Itâs not clear to me that we will have a proliferation of messages beyond deposits and exits, and designing generically to try to predict such cases â and handle them appropriately on CL â is a large undertaking with unclear value proposition.
With this message type, validators can now be fully controlled â they can enter and exit the mechanism. And they can have arbitrary logic for performing both as well as governing/updating ownership via smart contracts.
As for the second, I am extremely hesitant to utilize a system-level contract like the deposit contract. This was a good choice at the time, but going this path carries quite a bit of social baggage. For example, weâve discussed potentially modifying the deposit contract logic in proposals and gotten very strong pushback that you canât modify smart contract code as it is an irregular state change akin to the DAO. I see this strongly as a false equivalence but it is certainly a real thing to contend with.
Also, a smart contract here would still need special update logic to manage the message queue at the end of the block as currently specified. Just emitting a log was considered and rejected in our design process because you have no bound to messages going into CL other than the gas limit. Utilizing the in-state queue with the post-TX updates allows for managing the load from EL to CL (and on the size of block body due to the messages)
3 Likes
I wanted to make a record of a conversation we had at DevConnect 2023 about the potential for an additional âpriority queueâ for EL-induced exits (thanks to @SnapCrackle2383 for bringing together all the tech leads from various staking protocols).
This all started because @OisinKyne had a great idea to give 7002-based exits priority over the current exit queue. This is useful for LST protocols which would benefit from better liquidity guarantees and will need to use this mechanism for safety anyway. Processing only up to some portion (half?) of the maximum exits per block from this âpriority queueâ would prevent anyone from using this to grief users in the âfree queueâ.
My tweak of this suggestion is a fee market for determining placement in the priority queue. That is, if I attach more gas to my EL exit, I can get priority ordering over someone who paid less. Practically speaking, this could help fight stETH dominance in LSTfi protocols such as Liquity v2 and Gravita. Currently, they have to give preferential treatment (higher LTVs, lower fees, etc) to LSTs with higher liquidity, but with this idea, they could support low-liquidity LSTs in the same way as high-liquidity LSTs, just with the potential for higher fees on redemption during obscure network conditions. Speaking of those conditions, simply skipping the returning of excess gas would effectively burn ETH when market instability leads to bidding wars on this priority queue.
I will be the first to admit that this is all a bit complicated, and the ideas above would certainly benefit from more modeling and consideration, especially for what could happen during correlated slashing or inactivity leaking. I do think any actual changes to 7002 would be relatively small, however, and the ecosystem benefits would be large. Staking concentration is on everyoneâs mind at the moment, and Iâd love to find a way to empower smaller LSTs with 7002-style exits.
2 Likes
Hi all. I wrote a deep dive on EIP-7002 to help others, especially stakers and staking pool operators, understand the rationale behind introducing execution-layer exits for Beacon Chain validators: EIPs For Nerds #2: EIP-7002 (Execution Layer Triggerable Exits). All feedback and comments are welcome. cc: @djrtwo @petertdavies @Wander
1 Like
Hi all, Iâd like to weigh in here and expand a bit more on my point. I havenât had the bandwidth to formalise this into something actionable, but if I donât say something soon, I wonât have the opportunity to, so hereâs something quick.
The crux of the matter in my eyes is that a simple FIFO exit queue will some day lead to bank-run like behaviour of the validator set around contentious forks, if everybody is piling out, itâs rational to panic first and exit early rather than to leave it too late. We can and should do better here, and the adjustment is, in my eyes relatively minor.
I think this can be fixed with a control-loop mechanism, this EIP already has an escalating basefee like EIP1559, to prevent too many exits, my belief is that these exits should simply be processed first, ahead of the âfree queueâ. This means you can always have your money back immediately(-ish), if you are willing to pay the base fee, this gives you reason to relax and not exit âjust in caseâ.
The upsides of this design would be significant in the context of LSTs. Currently we suffer from a situation where only the largest are materially liquid, and whales wonât allocate to an LSP that they would make up too large of a percentage of. LSPs also have to subsidise an LP pool to convince users these assets are liquid. If they could be redeemed near instantly, the risk of being stuck would be greatly reduced. These protocols could also keep their peg more predictably. Similarly, lending protocols are less likely to see liquidations due to âqueue mismanagementâ, where an LST is under target for longer than the liquidation window, because they didnât foresee a âprofitable trading strategyâ where someone drains the LP for their token, forcing withdrawals, but achieving cascading liquidations faster than the withdrawals can clear the exit queue.
On the implementation side of things, I have had a chance to speak with @djrtwo, @mikeneuder and others, and I acknowledge there is complexity around how to handle huge demand for a priority queue (e.g. if itâs > the amount of processable exits, what do, third queue? fail the tx?) among other things like the statefulness of this feature, but I do think its worth allocating some time towards this. If we donât; we get a feature that costs lots of gas for users, and provides minimal benefits that is only for worst case scenarios. If we do; we fundamentally change the need for LSPs in the market, we make direct staking more palatable to users that are telling and showing us that liquidity is a must, we make competition amongst the long tail of LSPs easier, and we make the game theory of panics more stable, hopefully.
I know everyone (myself included) really really wants this feature soon, but I strongly believe that if we go with a simple FIFO queue, with an added tax for withdrawal key initiated exits, we will be in a worse place than if we do something more forward looking and pre-emptive.
Feedback welcome. 
4 Likes
If EOF gets included, it would be good to make the system contract in EOF format.
Hey-hey!.
This is a highly anticipated update and thanks for the great work!
Since the spec is still being updated (added support for partial withdrawals), I would like to suggest to consider adding an event on EL like WithdrawalRequest(pubkey, amount), what do you think?
To make both deposits and withdrawals look more symmetrical (There is a DepositEvent for deposits).
What is the motivation for having an event? The withdrawal requests will be accessible via the block in the RPC.
The deposit contract has a deposit event because it was the only reasonable way to share the data from the PoW to the PoS chain without modifying PoW clients.