Discussion topic for EIP-7002
3 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)
2 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, but I think (hope) any actual changes to 7002 would be relatively small, 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.