-
Notifications
You must be signed in to change notification settings - Fork 1
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
Lack of BLS pubkey validation #213
Comments
Note the current solution assumes builders set |
Maybe we can look into adding a precompile on the mev-commit chain for BLS-signature verification. |
You guys can just simply ask a user to sign some data upon registering blsKeys, exactly how it's done on Eth CL. PS... I wanted to submit this bug via cantina contest, but was busy at that time |
Thanks for the comment here! Users signing to prove bls ownership has been identified as too much friction for opt in to our protocol. Current solution to our vanilla registry is this function which allows the owner to force withdraw pubkeys if needed |
Both validators and builders in the mev pipeline are identified by 48 byte BLS pubkey (incompatible w/ normal EOA keypair). Currently we do not fully validate the ownership of a particular BLS pubkey that's passed to the provider registry or validator registry during opt-in. We merely check that the pubkey arg is indeed 48 bytes in length.
We need a well thought out mechanism to validate the ownership of BLS pubkeys for builders and validators. This could involve some form of off-chain validation, or requiring builders and validators to sign over a particular message with their BLS key to then submit their signature onchain.
The oracle could also periodically iterate through opted-in actors and confirm they have an active BLS pubkey with the beacon chain. Non-active keys could be blacklisted or slashed depending on the type of actor.
The text was updated successfully, but these errors were encountered: