Cryptography

Babylon uses a combination of cryptographic primitives to achieve its goals.

Standard Bitcoin BIP-340 Schnorr signatures are used to interact with the Bitcoin network through Taproot scripts. Adaptor signatures and extractable one-time signatures (EOTSs) both extend Schnorr signatures, such that adversaries deviating from Babylon's protocol automatically reveal required signatures to effect state machine changes on the Bitcoin network.

Boneh--Lynn--Shacham signatures are used by validators to record their votes for Babylon blocks in a way that can be efficiently aggregated into checkpoints that are submitted to the Bitcoin network.

Overview of transaction structure

There are three kinds of parties that participate in signing staking transactions: stakers, covenant emulation committee members, and finality providers (FPs).

FPs vote on Babylon blocks to provide finality to consensus, signing the blocks with an EOTS, with voting power proportional to how much BTC is delegated to them. If they sign two different blocks for the same height, their delegators are slashed, losing a fraction of their stake (currently 10%↗) to a burn address, with the remainder returned to the stakers.

Stakers delegate their Bitcoin to FPs by signing the staking and slashing transactions with Schnorr signatures. They can specify a maximum amount of time in blocks to delegate for (up to 65,535 blocks↗, approximately 1.25 years), during which time their BTC is locked in the staking output. They can choose to unbond before the maximum time elapses by signing an unbonding transaction, which moves their BTC to an unbonding output (which is locked for 101 blocks↗, approximately 17 hours), after which they can move it to a normal address.

The covenant emulation committee checks that transactions satisfy constraints that cannot currently be checked in Bitcoin script, such as that the slashing transactions send the specified fraction of the staked amount to the burn address and that the unbonding transaction commits to the unbonding output. Their signatures on the unbonding path are normal Schnorr signatures, but their signatures on the slashing path are adaptor signatures encrypted towards the FPs' keys in order to guarantee atomic slashing.

A staking transaction on the Bitcoin network commits to a Taproot output recognized by Babylon, the staking output, consisting of three paths:

1. The timelock path, which requires the staker's signature and a timelock for the staking time (through OP_CHECKSEQUENCEVERIFY, which enforces that a number of blocks have passed)

2. The unbonding path, which requires the staker's signature and a threshold of the covenant emulation committee members' signatures

3. The slashing path, which requires the staker's signature, a threshold of the covenant emulation committee members' signatures, and the signature of the FP being delegated to.

The covenant emulation committee presigns the unbonding transaction, which consumes the staking output and produces the unbonding output, consisting of two paths:

1. The timelock path, which requires the staker's signature and a timelock for the unbonding time

2. The slashing path, with the same requirements as the staking output's slashing path

The staker presigns both slashing transactions, which spend the staking and unbonding outputs, and sends 10% to the burn address and 90% to the staker, and the covenant emulation commitee presigns the slashing transactions with adaptor signatures encrypted towards each FP. This ensures that if an FP signs two different blocks with the same height, revealing their key, sufficient information is public to submit one of the slashing transactions (which one depends on whether the staker is in the process of unbonding) to the Bitcoin network. So long as the staker keeps their key secure, no one else can spend the timelock or unbonding paths.

The covenant emulation committee's presigning of the unbonding transaction ensures that the staker has sufficient information to initiate unbonding by submitting the unbonding transaction to the Bitcoin network.

If the FPs sign at most one block for each height on the Babylon chain, their key is never revealed, and the slashing transactions will not be spendable. If they do sign two distinct blocks at the same height, their key is revealed, allowing anyone to decrypt the covenant emulation committee's adaptor signatures for the slashing transaction for all delegators to that FP.

Schnorr signatures

BIP-340 Schnorr signatures use the Secp256k1 curve, denoted $\mathbb{G}$, as their group. A generator $G\in \mathbb{G}$ is common knowledge, as is the order $n$. Private keys are random integers $x\in {\mathbb{Z}}_n$, with corresponding public key $X=xG\in \mathbb{G}$.

A signature $\sigma =(R,s)\in \mathbb{G}\times {\mathbb{Z}}_n$ for a message $m$ satisfies the equation $R+eX=sG$, where $e=\text{hash}(\text{bytes}(R)||\text{bytes}(X)||m)$ is a synthetic challenge that binds the signature to the message, public key, and randomness. To avoid malleability, $R$ must have an even y-coordinate, since otherwise both $(R,s)$ and $(R,n-s)$ would be valid signatures for the same message (a similar constraint applies to ECDSA signatures; see Finding ref↗).

To sign a message, $R$ is generated by choosing a uniformly random, secret nonce $k\in {\mathbb{Z}}_n$ and computing $R=kG$. If $R$ has an odd y-coordinate, $k$ is negated and $R$ is recomputed, which guarantees that $R$ has an even y-coordinate and does not introduce bias to $k$'s bit representation. The $s$ value is computed as $s=e\ast x+k$ modulo $n$.

So long as $k$ is uniformly random and secret and $\text{hash}$ is preimage-resistant, a signature $(R,s)$ that is valid for public key $X$ must have been produced with knowledge of $x$, since otherwise finding a discrete logarithm with respect to $G$ that satisfies the verification equation is infeasible.

If $k$ is revealed, the private key $x$ can be computed as $\frac{s-k}{e}$. Likewise, if the same $k$ is used to sign multiple messages $(m_1,m_2)$, the $R$ value is the same for both signatures, and the private key $x$ can be computed as $\frac{s_2-s_1}{e_2-e_1}$, where $e_i=\text{hash}(\text{bytes}(R)||\text{bytes}(X)||m_i)$.

BIP-340 instantiates $\text{hash}(x)=\text{SHA256}(\text{SHA256}(\text{tag})||\text{SHA256}(\text{tag})||x)$, with $\text{tag}=\text{"BIP340/challenge"}$ to avoid its signatures being valid for other signature schemes, and it additionally requires $X$ to have an even y-coordinate to support efficient batch verification.

Babylon uses the btcd library's implementation of Schnorr signatures, which does not have constant-time signing; see Finding ref↗.

Adaptor signatures

Adaptor signatures↗ over the Secp256k1 curve, in addition to the parameters that Schnorr signatures have, have an encryption key pair, with private key $y\in {\mathbb{Z}}_n$ and public key $Y=yG\in \mathbb{G}$. The implementation refers to the encryption key as $\text{t}$ instead of $y$ or $Y$.

An adaptor signature for a message $m$, $\hat{\sigma }=(\hat{R},\hat{s})\in \mathbb{G}\times {\mathbb{Z}}_n$ satisfies $\hat{R}+eX=\hat{s}G$, where $e=\text{hash}(\text{bytes}(\hat{R}+Y)||\text{bytes}(X)||m)$. The verification that an adaptor signature is valid can be done with only public information (this operation is called encVerify↗). This is used to ensure that covenant emulation committee members signed the slashing transactions without making the signatures immediately available.

With the encryption key pair's private key, adaptor signatures can be decrypted↗ into Schnorr signatures with $(R,s)=(\hat{R}+Y,\hat{s}+y)$. Given an adaptor signature $(\hat{R},\hat{s})$ and its corresponding decrypted signature $(R,s)$, the encryption key can be recovered with $y=s-\hat{s}$. This allows someone observing a slashing transaction published to the Bitcoin network to extract the FP key to ensure that the remainder of that FP's delegators are slashed, even if they did not observe the double-signing directly.

In order to ensure that decrypting and then verifying as a BIP-340 Schnorr signature produces the same result as verifying an encrypted adaptor signature, the same sign conventions must be enforced (which involves keeping track of whether $\hat{R}+Y$ or $\hat{R}-Y$ has an even y-coordinate); see Finding ref↗.

Producing an adaptor signature is similar to producing a Schnorr signature, choosing a uniformly random, secret nonce $k$ and computing $(\hat{R},\hat{s})=(kG,e\ast x+k)$. The same concerns about revealed or reused nonces apply to adaptor signatures, and since Babylon uses deterministic synthetic nonces but does not include the encryption key in the derivation of the nonce, nonces are reused when the same message is signed with different keys; see Finding ref↗.

Extractable one-time signatures

EOTSs are a variant of Schnorr signatures that additionally take a height parameter $h$ and reveal the private key via nonce reuse if two distinct messages are signed with the same height. It does this by choosing the nonce as $k=\text{HMAC-SHA256}(\text{bytes}(x),\text{bytes}(h)||\text{chainId})$ and committing to $R=kG$ ahead of time. An EOTS signature is $s=e\ast x+k$, where $e=\text{hash}(\text{bytes}(R)||\text{bytes}(X)||m)$. Since $R$ is published ahead of time, the FP must use the same value of $k$ when computing $s$ in order to satisfy the verification equation to have their vote count towards consensus.

If an FP attempts to double-spend by signing two distinct blocks for the same height, they reveal their key, as $x=\frac{s_2-s_1}{e_2-e_1}$. This is performed by extractFromHashes↗.

So long as an FP only signs one block per height, $k$ is effectively unpredictable, since the output of $\text{HMAC-SHA256}$ keyed with the FP's key is indistinguishable from a uniformly random value in $\left[0,2^{256}\right)$, though there is room for slight improvement; see Finding ref↗.

Boneh--Lynn--Shacham signatures

Babylon uses the blst↗ implementation of Boneh-Lynn-Shacham signatures over the Barreto-Lynn-Scott set of curves BLS12-381. The BLS12-381 set of curves include groups ${\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T$ of order $q$, with generators $G_1\in {\mathbb{G}}_1$ and $G_2\in {\mathbb{G}}_2$ and a pairing function e that maps pairs of elements in ${\mathbb{G}}_1\times {\mathbb{G}}_2$ to ${\mathbb{G}}_T$. Operations in ${\mathbb{G}}_1$ are significantly cheaper than those in ${\mathbb{G}}_2$, and its elements are half the size (48 bytes compressed vs 96 bytes compressed). BLS signatures allow either group to be the key group and the other group to be the signature group, which allows a trade-off of faster signing versus faster key generation; Babylon uses ${\mathbb{G}}_1$ for signatures and ${\mathbb{G}}_2$ for keys, opting for faster signing.

Private keys are random integers in $x\in {\mathbb{Z}}_q$, with corresponding public keys $X=x{G}_2\in {\mathbb{G}}_2$. The signature for a message $m$ is $\sigma =x\text{hash}(m)\in {\mathbb{G}}_1$. The verification equation is $e(\sigma ,G_2)=e(\text{hash}(m),X)$.

BLS signatures support efficient signature aggregation. Given a set of signatures for distinct keys for the same message ${\sigma }_i=x_i\text{hash}(m)$, a composite signature $\sigma ={\Sigma }_i{\sigma }_i$ is a valid signature for the sum of the public keys $X={\Sigma }_i{x}_i{G}_2$. BLS aggregate signatures require key registration with a proof-of-possession to ensure that an attacker cannot forge aggregate signatures by setting their public key to a key that includes the negation of the sum of the remainder of the set of public keys, since if the attacker with index i sets their public key to $X_i=y{G}_2-{\Sigma }_{j\ne i}{X}_j$, the aggregate public key is $X=y{G}_2$ for which the attacker knows the corresponding private key $y$. But they do not know the private key x_i = y - \Sigma_{j\neq i}x_j, so they cannot produce an individual signature for $X_i$. Keys are registered when validators are created with MsgWrappedCreateValidator, whose ValidateBasic↗ verifies a BLS signature of the public key with the public key.

Validators sign Babylon blocks with BLS signatures, submitting them using the CometBFT vote-extension mechanism. These signatures are aggregated and included in checkpoints that are submitted to the Bitcoin network. While there are protocols like MuSig2↗ and FROST↗ that produce aggregate Schnorr signatures that can be similarly validated as if they were a single signature, BLS signatures do not require additional communication to aggregate. Additionally, BLS signatures over BLS12-381 are 48 bytes, compared to Schnorr signatures over Secp256k1, which are 64 bytes, making them cheaper for this usage. This usage also does not require that the signatures be interpreted by the Bitcoin network, which is a requirement of the modified Schnorr constructions.