Closed timbeiko closed 2 years ago
arwer13
commented
2 years ago We'd like to mention here a pair of (draft) proposals answering sort of a complimentary question "how to initiate a partial withdrawal" (and more). Hope it may be of use in the discussion.
ralexstokes
commented
2 years ago interesting proposal @arwer13 !
what is the rationale to have these messages originate from the EL (instead of the CL)? and moreover to allow for generic types of messages?
i hear you that it would be nice to avoid having to build out a discrete message type for each operation we may want to process on the CL but we have to effectively do a dispatch on the event/contract type anyway with the GMB from what I can tell so it seems isomorphic to doing so at the CL layer (and there will be a lot more "stuff" along the critical path if these start from the EL which means more testing, review, etc.). For example, we could even just include the GMB you have written as a bit of EVM bytecode on the beacon chain and avoid touching the EL at all...
i also think that having to spec/build a new message type for each new operation has a nice "backpressure" as there is a high cost to doing so and if we make it easier, we may be tempted to make more, when fewer would do -- and the reason we want fewer is that it means less attack surface so easier testing, auditing, review, etc. imo this is a time when security trumps convenience.
on top of the general comments about the GMB idea, i don't think we need this kind of generic infrastructure to implement partial withdrawals. the general withdrawal flow that has the most traction amongst core devs right now is the one described here: https://notes.ethereum.org/@ralexstokes/Skp1mPSb9
it introduces a pipeline from the CL to the EL to supply (full) withdrawals that are processed as expected. we can re-use the entire pipeline downstream of the withdrawals queue on the CL (see here for more detail: https://github.com/ethereum/consensus-specs/pull/2836) for full or partial withdrawals. which means we don't need to test this pathway and an entirely separate pathway (possibly originating from the EL!) for both full and partial withdrawals.
the distinction b/t partial vs full is simply based on the validator's status on the beacon chain so it would make sense to unify implementation for both types of withdrawals; and in fact to implement partial withdrawals on top of the changes in this meta-spec i've listed you would just need to add a few extra validations to do the correct balance accounting on the beacon chain.
i'd want to hear a stronger rationale for adding the GMB architecture before pursuing this route in clients further...
arwer13
commented
2 years ago Thank you a lot for such a detailed feedback @ralexstokes !
I've caught up with the discussion and I do agree now there is no need of flow from EL for doing full and partial withdrawals. Regular automatic withdrawals are even more preferable from the point of view of liquid staking protocol.
Speaking about GMB. I'm trying to understand now is there a room for the proposal improvement/transformation. As far as I understand now there is still a need for a solution for conveying a number of intentions from EL, described here https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021/4 : voluntary exits, exits, various withdrawal credentials change, ... Am I missing something on the problem statement here? Could you please point to some other proposal / discussions on the solution?
djrtwo
commented
2 years ago Agreed that there are currently operations that only the active key can perform where it is very natural (and prevents some withholding attacks -- e.g. voluntary_exit) for the withdrawal key to actually trigger it.
I have not yet reviewed your GMB proposal, but will soon. Something like that (if complexity is relatively low) is of value to stakers and pools (especially constructions where active and withdrawal creds are split between parties)
axic
commented
2 years ago Just for historical reference, here was a discussion from a month ago (based on discussions with @djrtwo and @ralexstokes) about a pull approach with a "system contract": https://notes.ethereum.org/@ipsilon/H1lC5OAJ5
It was motivated by minimizing block/client changes, with the downside of more interaction requirement from the users, hence it superseded by the push options above.
timbeiko
commented
2 years ago On ACD134 we agreed to go with EIP-4895 as CFI for Shanghai. PR: https://github.com/ethereum/execution-specs/pull/477
Issue to track the progress towards beacon chain proposals and the various proposals.
A few links: