-
-
Notifications
You must be signed in to change notification settings - Fork 306
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
verifying remote signing / web3signer #7174
Comments
I am curious what's the expected / best UX for this, in the Nimbus docs it is noted that you have to set an extra flag
but I don't think this should be required as you could determine based on I am wondering if it's useful to enforce to only send verified message via such a flag but on the other hand it's the w3s that needs to enforce it and reject requests without proofs. |
@franjoespejo something else to consider, the keymanager api allows to manage remote signer keys, should consider updating that as well |
Thanks for checking in detail. Regarding UX, IMO once the verifying w3s is accepted, the pubkeys endpoint can send the verifying options, but meanwhile the options can be set in the validator client, because it seems more simple and compatible with the current w3s standard. Regarding keymanager api, yes that's also an option, I understand that the pubkey endpoint is an alternative to that in which w3s service doesnt have to consume validator service but the other way around. We are in favour of using the pubkey endpoint. |
There is no standard to set this on the validator client other than the keymanager api to manage remote signers or what are you referencing? The file config Nimbus uses seems like a custom format
yes I agree, all clients should just keep keys in sync with w3s by polling /pubkeys endpoint but for spec completeness this would have to be updated.
Could you please elaborate a bit on this and the usefulness / requirement of this feature in general? In a common node setup, the w3s <> validator client is a trusted setup and shouldn't require this, so would be good to add a bit more context for motivation / rationale. In general, I think there should be a rough consensus on the spec to move forward with this first. |
Right, there is not, nimbus does take it from a config file or a flag
Yes, at diva we build a DVT, so 1 validator is signing using 5 different diva nodes, each with its vc/bc/ec. Each vc needs to send the signing duties to its w3s (diva-node). For each validator duty, one out of the 5 diva nodes aggregates the 5 bls signatures, (diva nodes talk to each other). For block proposals we need to be able to verify the fee recipient field of the block proposal message. Happy to chat about it more in detail if needed. It can be useful also for plain w3s where the setup is not trusted. |
the cli flag option would be simple for us to add but seems better to let the w3s drive this and return the new format including the block properties in /pubkeys api, or alternatively configure it via keymanager api which is standardized
ah thanks got how it works now, was missing the part that you select one to do the aggregation
so this is limited to local blocks for now? we can't proof this in case of blinded block but I see you have another PR open that seems to solve this Thanks for the clarifications! |
The other PR implies changes to the Beacon api to forward the relayer signature to the vc, so tbh we don't think it is going to be accepted. Right now with the verify-w3s we are able to validate that the fee recipient of a blinded block belongs to one of our whitelisted builders. |
but how does the validator client create a proof for fee recipient of a blinded block? it does not have access to |
I think It doesnt have access to the tx list but a hash instead, and the rest info remains. Pls check: BlindedBlock, it drives to ExecutionPayloadCommon For the w3s there wouldn't be difference between block/blindedblock, pls check BeaconBlockRequest |
Ah right, |
Right, that would be the correct path. Looking at the nimbus code it seems they use it as a kind of selector and map execution_payload-execution_payload_header. |
Problem description
Lodestar already implements the w3signer standard https://chainsafe.github.io/lodestar/run/validator-management/external-signer
The standard assumes the w3s trusts the validator client, since there is no way for the w3s to verify the payload to be signed.
Solution description
The proposal to fix that is: ethereum/remote-signing-api#10
Nimbus has implemented this: https://nimbus.guide/web3signer.html#verifying-web3signer, it is specially useful for diva which distributes the w3s signatures.
The text was updated successfully, but these errors were encountered: