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)
1 Like