-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add validator voluntary exit endpoint #58
Conversation
Converting back to draft as I just realised that I need to update the |
I've just went through the docs and not sure if extra info is need for this endpoint - I think the description and spec of the endpoint seems adequate, but please let me know otherwise! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copying from Discord:
I don't really see the purpose of the confirmation query parameter. In CLI apps we usually issue a warning after the user initiates an operation, and confirming is a second step. The warning is there to allow the user to back out from the operation. The semantics of an API query parameter are different. We only have a single step, so you either go through with the operation when including the query param or you don't when not including it - the param doesn't add any value. I don't ever see a reason for anyone to invoke the endpoint without the query parameter because it will just fail (which, again, doesn't work that way in a CLI app). In my opinion it is redundant.
Agree with the reasoning above, I would drop confirm param too |
Thanks @dapplion - there's some discussions on this topic in the #api channel on R&D, and it looks like the consensus so far is to drop the query param. The alternative proposal is to change the API, so that it returns a If there's no strong objections I'll update this PR shortly. |
@dapplion and Adrian also raised that web3signer implements keymanager API but can't fetch the current epoch like VC does, so we'll have to make epoch a mandatory param. |
Updated the endpoint based on discussion in api channel:
|
Discussion from Discord (R&D, #api) - given that remote signers already supports signing voluntary exits, and does not implement the full keymanger API, this endpoint doesn't seem necessary for remote signer. I've made the |
…quirements." This reverts commit 2efcd2c.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
## Issue Addressed Addresses #4117 ## Proposed Changes See ethereum/keymanager-APIs#58 for proposed API specification. ## TODO - [x] ~~Add submission to BN~~ - removed, see discussion in [keymanager API](ethereum/keymanager-APIs#58) - [x] ~~Add flag to allow voluntary exit via the API~~ - no longer needed now the VC doesn't submit exit directly - [x] ~~Additional verification / checks, e.g. if validator on same network as BN~~ - to be done on client side - [x] ~~Potentially wait for the message to propagate and return some exit information in the response~~ - not required - [x] Update http tests - [x] ~~Update lighthouse book~~ - not required if this endpoint makes it to the standard keymanager API Co-authored-by: Paul Hauner <[email protected]> Co-authored-by: Jimmy Chen <[email protected]>
## Issue Addressed Addresses sigp#4117 ## Proposed Changes See ethereum/keymanager-APIs#58 for proposed API specification. ## TODO - [x] ~~Add submission to BN~~ - removed, see discussion in [keymanager API](ethereum/keymanager-APIs#58) - [x] ~~Add flag to allow voluntary exit via the API~~ - no longer needed now the VC doesn't submit exit directly - [x] ~~Additional verification / checks, e.g. if validator on same network as BN~~ - to be done on client side - [x] ~~Potentially wait for the message to propagate and return some exit information in the response~~ - not required - [x] Update http tests - [x] ~~Update lighthouse book~~ - not required if this endpoint makes it to the standard keymanager API Co-authored-by: Paul Hauner <[email protected]> Co-authored-by: Jimmy Chen <[email protected]>
## Issue Addressed Addresses sigp#4117 ## Proposed Changes See ethereum/keymanager-APIs#58 for proposed API specification. ## TODO - [x] ~~Add submission to BN~~ - removed, see discussion in [keymanager API](ethereum/keymanager-APIs#58) - [x] ~~Add flag to allow voluntary exit via the API~~ - no longer needed now the VC doesn't submit exit directly - [x] ~~Additional verification / checks, e.g. if validator on same network as BN~~ - to be done on client side - [x] ~~Potentially wait for the message to propagate and return some exit information in the response~~ - not required - [x] Update http tests - [x] ~~Update lighthouse book~~ - not required if this endpoint makes it to the standard keymanager API Co-authored-by: Paul Hauner <[email protected]> Co-authored-by: Jimmy Chen <[email protected]>
Addresses #57.
I've incorporated inputs from the discussions in the above issue and the R&D #api channel.