Signature Schemes in Consensus Protocols
- date: 2023-02-05
- last updated: 2023-02-04
Overview
Both sides of the bridge need to verify what happened on the other side. To do that, the verification logic is often encapsulated inside a light client, manifested as a smart contract on the chain which the verification needs to be executed. The light client needs to follow consensus and signature verification mechanisms based on the signing algorithm and the elliptical curve used on the other side. For example, if chain A has 21 validators signing each block using ECDSA algorithm on secp256k1 curves, then chain A's light client, executed on chain B, must extract the signatures from the block headers presented to the light client, and follow the ECDSA signature verification algorithm to verify the content of the block header indeeds produces the 21 signatures contained in the block header, given the public keys of the 21 validators.
Here, we present a reference table for these signature schemes and how they are used in the consensus protocols of different blockchains. We limit our initial scope to Ethereum, Polygon, Avalanche, BSC, Harmony, Cosmos, and Polkadot only (and their undelying technologies). Note that we are only looking at how signatures are used in consensus, not elsewhere in the blockchain stack, as all these protocols use ECDSA on secp256k1 for accounts in EVM interactions.
Algorithm | Curve | Protocol | Code | Note |
---|---|---|---|---|
ECDSA | secp256k1 | Polygon | lib | Modified Tendermint validator signature scheme |
BSC | lib usage | Derived from Clique, then improved | ||
BLS | BN254 | Ethereum | EVM | Added by EIP-196,197; Mainly for use in smart contracts, such as zk-snark verification. See explainer |
BLS12-381 | Ethereum | prysm lighthouse | See PoS design and explainer | |
Harmony | lib usage | See design and protocol review | ||
RSA | N/A | Avalanche | verification generation | Uses X.509 certificate which potentially allows many algorithms; Moving towards BLS12-381 and added implementations recently |
EdDSA | Curve25519 | IBC | lib usage | Used by all chains in Cosmos network, including Cosmos Hub |
Schnorr | Curve25519 | Substrate | lib | See also brief intro from Polkadot |
Resources
Algorithms
ECDSA
BLS
- Wikipedia
- Paper: Short Signatures from the Weil Pairing
- Tutorial: BLS signatures: better than Schnorr
- Analysis: Secret Sharing and Threshold Signatures with BLS
- Deep dive: BLS Signatures in Solidity
EdDSA
Curves
secp256k1
- Bitcoin Wiki
- Tutorial: A Bluffer’s Guide to secp256k1
BLS12-381
- Deep dive: BLS12-381 For The Rest Of Us
- Intro: BLS12-381: New zk-SNARK Elliptic Curve Construction
- Paper: Fast and simple constant-time hashing to the BLS12-381 elliptic curve
- Benchmark: BLS: Is it really that slow
- EIP: EIP-2537: Precompile for BLS12-381 curve operations
- EVM launch: Targeting Shanghai upgrade May 2023
BN254
- Definition
- Paper: Pairing-Friendly Elliptic Curves of Prime Order
- Deep Dive: BLS Signatures in Solidity
- Speed Optimization: New software speed records for cryptographic pairings
Usage in ZKP
Signing Implementations
The Standard Curve Database is a good starting point for existing signing algorithms. Base implementations such as golang crypto and rust crypto provide good reference codebases.
- bcrypt
- bip-0039
- lighthouse (rust)
- bls
- bls-12-381
- ethereum EIP-2537: Precompile for BLS12-381 curve operations
- ethereum-go-ethereum (go)
- harmony bls (go): uses harmony bls repository
- bls Harmony forked from herumi/bls_: written in C++, supports Go, Rust, WebAssembly (Node.js)
- prysm (go)
- lighthouse (rust): provides a wrapper around several BLS implementations to provide Lighthouse-specific functionality.
- lighthouse (rust): Provides path-based hierarchical BLS key derivation, as specified by EIP-2333.
- Aurora Rainbow Bridge Implementation: Implementations
- blst
- fake_crypto
- milagro: support for Apache Milagro
- Aurora Rainbow Bridge Implementation: Implementations
- lighthouse (rust): Provides a JSON keystore for a BLS keypair, as specified by EIP-2335.
- bsc bls12381 (go)
- blst: blst (pronounced 'blast') is a BLS12-381 signature library focused on performance and security. It is written in C and assembly.
- bn256
- ethereum-go-ethereum (go)
- bsc bn256 (go)
- ecdsa
- bsc crypto (go): toECDSA creates a private key with the given D value. The strict parameter controls whether the key's length should be enforced at the curve size or it can also accept legacy encodings (0 prefixes).
- paritytech ecdsa (rust)
- cosmos-sdk ecdsa
- ed25519 golang
- tendermint ed25519 (go): GenPrivKey generates a new ed25519 private key. It uses OS randomness in conjunction with the current global random seed in tendermint/libs/common to generate the private key.
- paritytech ed25519 (rust)
- Ed25519: Ed25519.sol
- cosmos-sdk ed25519
- secp256k1
- ethereum-go-ethereum (go)
- prysm (go)
- bsc secp256k1
- tendermint secp256k1 (go): GenPrivKeySecp256k1 hashes the secret with SHA2, and uses that 32 byte output to create the private key.
- cosmos-sdk secp256k1
- snowbridge secp256k1
- secp256r1
- sr25519: schnorr over ristretto25519
- chainsafe go-schnorrkel (go): This repo contains the Go implementation of the sr25519 signature algorithm (schnorr over ristretto25519). The existing Rust implementation is here.
- paritytech substrate-bip39 (rust): his is a crate for deriving secret keys for Ristretto compressed Ed25519 (should be compatible with Ed25519 at this time) from BIP39 phrases.
- paritytech sr25519 rust
- tendermint sr25519 (go): GenPrivKeyFromSecret hashes the secret with SHA2, and uses that 32 byte output to create the private key.
- snowbridge sr25519