Call 0: Key design discussion around BLS and ECDSA

[DrewVanderWerff]

Background:

• A proposer commitment can be thought of as a signature from the proposer. The options for how the signature is requested is a core part of Commit-Boost. There are various ways / structures to provide this signature, Generally there is agreement that the signature should not be the validators “consensus key”, but rather a proxy key or domain specific key
• Two of the key design discussions needed is whether ECDSA or BLS is preferred (or both) and if BLS, whether we leverage domains or proxy keys (or both)
• Commit-Boost has the ability to support some or all these options, with the trade-off mostly in complexity of the Commit-Boost software
• Generally we have received feedback that the best design for validators is BLS with separate signing domain being the most straight forward, but the best design for modules is ECDSA (due to more gas efficient on-chain verifications)
• We wanted to present some of the trade-offs, confirm we aren’t missing trade-offs, get more feedback, and start to chat across validators and modules on the best path forward

Design complexity:

• We likely won’t solve for all use cases / set-ups, but threading the needle to capture as many validators as possible + not limiting module design + not having overly complex Commit-Boost software
• From Commit-Boost, complexity is a spectrum, but generally the least complex is BLS with domain support, next BLS with domain and proxy support, then the most complex being BLS domain + BLS proxy + ECDSA proxy

BLS and ECDSA

ECDSA trade-offs:

• Cheaper to verify onchain
• Clearly is not the private key of the validator / clear separation from BLS key
• Doesn’t have native aggregation like BLS
• Would require additional storage considerations for the validators
• Increases complexity if required to support
• Not compatible out of the box with all validator key managers which support BLS

BLS trade-offs:

• Can be sharded
• Can leverage the currently supported concept of domains across different commitments (i.e., this is not new to validators)
• Can be more easily supported
• Can be more easily compatible with validator key managers, eg Web3 signer and Dirk
• More costly to verify until BLS precompiles are shipped

If we do have alignment on supporting BLS, another design decision is using BLS custom domains or BLS proxy keys (this would be new).

Custom domain and proxy

Custom domain trade-offs:

• Use same validator pubkey (ie, no need to associate other BLS pubkeys)
• Not slashable since only a few domains can lead to slashing
• Requires agreement on whether to have a single “Commit boost” domain (which is shared with all modules) vs multiple ones (eg, one per module, we feel this may not be worth the complexity)
• Likely easier to be integrated by key managers

BLS Proxy trade-offs:

• Added complexity of storing BLS private keys (though easier than ECSDA)
• Added complexity of associating new proxy keys with validator
• Potentially safer as avoids accessing the consensus key (eg what if there’s a bug and a signature happens on a “wrong” domain)
• Potentially more lightweight on the key manager as it doesn’t mix consensus keys and module keys

[DrewVanderWerff]

This was discussed on Community Call #0. The discussion can be found here. https://youtu.be/jM3uL00UoKk?si=0dGlEV34OgEt45tP&t=540