This document describes what would be necessary to use an aggregated BLS signature for MsgSettleEscrow, rather than collecting individual signatures. Using BLS signatures would allow for smaller transaction sizes (see Memory Usage below). We also believe it would boost performance as we’d check just 1 signature rather than 128 of them.
All code provided in this document are drafts for example purposes and should be reviewed and refactored before going to production.
Let $\sigma_i$ represent the signature for participant $i$ and $n$ be the total number of signatures. Take the signatures and perform elliptic curve point addition on them, resulting in an aggregated signature $\sigma_{agg}$:
$$ \sigma_{agg}=\sum_{i=0}^n\sigma_i $$
The summation $\Sigma$ here represents elliptic curve point addition.
Let $pk$ represent a public key and $sk$ a secret key with a generator $g$ such that $pk = sk \times g$. The aggregated public key $pk_{agg}$ is computed in the same manner:
$$ pk_{agg}=\sum_{i=0}^n pk_{i} $$
Let $e : G1 \rightarrow G2 \rightarrow GT$ be the pairing function with $G1$, $G2$, and $GT$ corresponding to the two elliptic curves points and the target point. We can validate the signatures against the public keys with:
$$ e\;\sigma_{agg}\;g = e\;(H\;m)\;pk_{agg} $$
$H\;m$ computes the hash of message $m$.
According to the design document, a user may use a cold key or a warm key to sign:
A host can sign with either its cold key (validator's own account key) or its warm key (operational key authorized via authz grant on mainnet). Both are secp256k1. Cold key signing requires no grant -- the validator is acting directly.
As secp256k1 keys are incompatible with BLS signatures, we’d need to require a dedicated BLS12-381 signing key for hosts, rather than secp256k1. This new BLS key may be stored as a warm key in the keyring.
Participant should be able to use BLS12-381 public keys in different subnets. To allow this, we suggest that the public BLS keys be registered on mainnet automatically, so that participants in the devshard are able to query for such keys.
We propose to add a new message, MsgRegisterDevshardBLS12_381PublicKey containing the creator’s address, its proposed BLS12-381 public key, and a proof of possession according to section 4.2.3 of the BLS signatures proposal.
The API should automatically send MsgRegisterDevshardBLS12_381PublicKey to the mainnet in case of a warm key rotation, updating the user’s BLS key. The associated BLS key must not remain valid. If a host has not registered a BLS key on mainnet (unlikely as the registration should be automatic), they should be forbidden from participating in the devshard.