Skip to content
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

Open
shaspitz opened this issue Jul 8, 2024 · 4 comments
Open

Lack of BLS pubkey validation #213

shaspitz opened this issue Jul 8, 2024 · 4 comments

Comments

@shaspitz
Copy link
Contributor

shaspitz commented Jul 8, 2024

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.

@shaspitz
Copy link
Contributor Author

shaspitz commented Jul 8, 2024

Note the current solution assumes builders set extradata to a "builder name" string similar to something like: beaverbuild.org (Hex:0x6265617665726275696c642e6f7267). However we could ask builders to change their extradata field to something like a 32 byte hash of their BLS pubkey signature, if it helps in robust BLS pubkey validation

@ckartik
Copy link
Contributor

ckartik commented Oct 10, 2024

Maybe we can look into adding a precompile on the mev-commit chain for BLS-signature verification.

@Rassska
Copy link

Rassska commented Nov 28, 2024

You guys can just simply ask a user to sign some data upon registering blsKeys, exactly how it's done on Eth CL.
Current implementation is vulnerable to signature rogue attack.
https://medium.com/@coolcottontail/rogue-key-attack-in-bls-signature-and-harmony-security-eac1ea2370ee

PS... I wanted to submit this bug via cantina contest, but was busy at that time

@shaspitz
Copy link
Contributor Author

You guys can just simply ask a user to sign some data upon registering blsKeys, exactly how it's done on Eth CL. Current implementation is vulnerable to signature rogue attack. https://medium.com/@coolcottontail/rogue-key-attack-in-bls-signature-and-harmony-security-eac1ea2370ee

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants