zkCasper

Do not index

Special thanks to Alistair Stewart, Oana Ciobotaru and Sergey Vasilyev (authors of the “Accountable Light Client Systems for PoS Blockchains” paper) for the helpful discussions and feedback that were instrumental in making this article possible.

In this research article, I present a protocol for efficiently verifying the Ethereum Beacon chain's Casper FFG consensus proofs using a SNARK-based approach. With this scheme, computationally constrained environments, such as on-chain or off-chain consensus clients, can securely follow the Casper FFG protocol and benefit from the crypto-economic security provided by the over 17 million ETH ($34 billion at the time of writing) staked on the Beacon chain. This protocol offers full node-level security that is orders of magnitude more secure than the sync committee, and is fully Byzantine fault-tolerant.

Motivation

The sync committee was introduced to the beacon chain in the Altair hard-fork and it consists of a randomly selected subset of 512 validators from the full validator set. The motivation for this committee was consensus proofs that could be verified cheaply. Unfortunately, this protocol introduces new security assumptions that are completely orthogonal to the security of the beacon chain. More specifically, it has much lower crypto-economic security, as well as a lack of slashing for byzantine behavior, which is critical to the safety of POS consensus.

Therefore, bridges and off-chain consensus clients that rely on the beacon chain consensus proofs must trust that the sync committee will not collude to perform eclipse or data withholding attacks, even when there are no consequences for such actions. We find this blind-faith security model to be completely unacceptable. Consequently, we have opted for the more ambitious approach of directly verifying the Casper FFG consensus proofs.

Preliminaries

We let be a bilinear pairing function such that . All groups have some prime-order . Let and be the generators for and respectively.

Next we define the hash function . This function simply takes an arbitrary length message and maps it to an element of the group.

BLS Signatures

BLS signatures enable consensus proofs that are very efficient to verify as it supports both public key and signature aggregation. So a verifier only needs to verify a single aggregate signature rather than signatures.

Choose a random and output and

outputs . This signature is a single group element in .

This reduces a set of signatures to a single group element . Outputs .

This reduces a set of public keys to a single group element . Outputs .

Checks the equality of the pairing:

This works because our pairing is bilinear:

This also extends to aggregate signatures:

Homomorphic KZG Commitments

I’ve reviewed the technical definition of the KZG commitment scheme in a previous article. One great feature of KZG commitments is that they are homomorphic. What this means is that we can update the values in a commitment to some polynomial without needing the full polynomial. Recall that a KZG commitment to any set is of the form:

Where is the secret value, , and is the polynomial that interpolates all the coordinates derived from the Lagrange basis:

Notice that we can rewrite our commitment as:

So that updating a value in this commitment from can be seen as

where is given as:

This works because:

Unfortunately for the verifier, naively using equation to update it’s commitment requires computing the Lagrange base which has a runtime complexity of . This complexity comes from evaluating the terms for both the numerator and denominator. An optimization that can be made here is to have the prover compute and provide the value instead, which the verifier can use to compute the update. But how can the verifier trust the correctness of this value? i.e . This is where KZG proofs come in. First we define the polynomial as the sum of all Lagrange bases in :

This allows us create a KZG commitment to this polynomial as part of the KZG set up ceremony. Since we know that , thus the prover can can compute a KZG proof for the -th coordinate using the quotient.

so that the verifier can verify by using the pairing check:

But what if the prover wants to update multiple points in the commitment? Then they’ll have to submit the terms where is the set of all points to be updated. So updating our commitments becomes

What about verifying these terms? This is possible with KZG multi-proofs. Dankrad's article on KZG commitments outlines that to verify batch KZG proofs, the verifier needs to compute some Lagrange bases themselves. However, the complexity for the bases is now reduced to . In our case, the prover has already supplied those Lagrange bases. Let's define as follows:

Using the polynomial in , We can come to the following conclusions:

Since the prover provides the individual terms , the verifier can use them to compute:

Finally the prover provides the KZG multi-proof which is still a single group element, but allows us to verify multiple points using the pairing check:

Casper FFG

The Casper FFG consensus protocol defines the finality rule for the Ethereum beacon chain. It does this by introducing what it refers to as "source" and "target" checkpoints. These checkpoints are 32 slots apart and correspond to the epoch boundaries of the beacon chain. This means that Casper FFG finalizes whole epochs, rather than arbitrary block sequences.

An epoch according to the protocol goes through three stages: unjustified, justified, and finalized. The genesis block is a special case, as it is already finalized by the protocol rules. Moreover, an epoch (source) can only be considered finalized if there exists a direct descendant epoch (target) that has been justified by a supermajority of the authority set.

Blocks b1 & b2 are finalized, while b3 is only justified.

As stated in my article on the sync committee, there are simply too many authorities in the Ethereum beacon chain (Currently 560k and rising). Passing around a epoch checkpoint to sign would degrade the network. To solve this issue, the authorities are split up into committees with a maximum count of 2048 per committee. These attestation committees produce signed Casper FFG votes. The Casper FFG protocol uses BLS signature which allows signatures from individual committee members to be aggregated into a single signature per committee.

Attestation messages are published in the beacon chain blocks and contains: Casper FFG votes, a bitlist of the validators in the committee who signed the attestation and a BLS signature over the AttestationData. The BLS signatures for the attestation messages use the group for public keys, while it’s signatures are in the group. A consensus client observing the attestation messages can conclude that some epoch is justified (and it’s parent finalized) if they collect enough messages from a supermajority of the validator set confirming the epoch.

struct Attestation {
    aggregation_bits: Bitlist<MAX_VALIDATORS_PER_COMMITTEE>
    data: AttestationData
    signature: BlsSignature
}

struct AttestationData {
    slot: u64
    index: u64
    // LMD GHOST vote
    beacon_block_root: H256
    // FFG vote
    source: Checkpoint
    target: Checkpoint
}

Validators can join the validator set by locking up 32 ETH. The beacon chain adds their BLS public key as well as other protocol metadata (such as their activation_epoch, exit_epoch and a boolean flag that tracks if they’ve been slashed ) to the “validator registry” an ssz list object on the BeaconState . Once added to the validator set, their initial activation_epoch and exit_epoch is set to a constant FAR_FUTURE_EPOCH [source]. This triggers the epoch transition function to schedule them for activation for the next epoch once the current epoch ends. [source]. It's worth noting that the beacon chain does NOT remove any validators from its registry. Instead, it updates their activation_epoch, exit_epoch, or slashed values.

If a validator is found to have either proposed two competing beacon blocks for the same height [source] or signed an attestation that violates casper FFG's rules [source]. Then their validator.slashed will be updated to true immediately, meaning they can no longer propose blocks or sign attestations. Validators may choose to voluntarily exit the active set after some minimum period, after which their exit_epoch will be changed from FAR_FUTURE_EPOCH to some near future epoch. [source]. Hence, all inactive validators will satisfy the condition exit_epoch < current_epoch < activation_epoch or slashed = true.

It is critical to note that both the BeaconState and the "validator registry" list are SSZ objects that can be merkleized. As a result, it is possible to obtain SSZ merkle multi-proofs of validator state changes, such as deposits (new deposits), exits, and slashings, which can be verified against the BeaconState root. This will be important later on.

Aggregate Public Key Proofs

The Accountable Light Client Systems for PoS Blockchains paper by Web3 Foundation researchers presents a SNARK that can verify whether the constituent public keys in an aggregate BLS public key exist as a subset of a list of potential signers. Using this SNARK the verifier only needs to maintain a KZG commitment to the BLS public keys of all potential signers.

More formally, Given a set of potential signers . The verifier holds a commitment to the list of public keys in . The prover can then send a bitlist which represents a subset of the signers in , an aggregate BLS signature , aggregate public key and a succint proof that .

After verifying the aggregated public key SNARK proof , the verifier can simply perform the naive aggregate BLS signature verification. This SNARK construction removes the requirement for the verifier to know the individual public keys in making it perfect for truly light clients.

The SNARK circuit itself simply performs elliptic curve affine additions of the BLS public keys and constrains these additions using a custom PLONK gate.

The SNARK requires a pair of pairing-friendly elliptic curves: one for the BLS signature (the inner curve) and one for the SNARK itself (the outer curve). The paper recommends using the curves BLS12-377 and BW6-761. However, for the BLS12-381 keys used in the Casper FFG protocol, we must use the BW6-767 curve for the outer curve to avoid non-native field arithmetic that would significantly increase the number of constraints and, consequently, proving times. The protocol for aggregated public key proofs is formally defined below:

This outputs the proving and verification keys using the powers of and a SNARK preprocessing algorithm, which can be used to commit and prove a maximum number of signers.

Given a set of public keys , outputs a commitment to the public keys .

Computes the SNARK proof for the aggregation of the given public keys and a bitlist that indicates their positions in the original set . Outputs .

Given the commitment, aggregated public key, SNARK proof and bitlist. This verifies that . Outputs .

Protocol

With the preliminaries out of the way, let's take a look the zkCasper protocol. Our approach is to begin by establishing a trusted commitment to the list of all validators in the Beacon chain. However, the validators in the Beacon chain will not sign this commitment as the statuses of the individual validators in the set changes. Instead, they sign the block roots of epoch boundaries. Fortunately, these block roots contain a merkle commitment to all the validators in the validator registry. Therefore, the verifier can leverage the homomorphic property of KZG commitments in order to update their commitment after verifying the merkle proofs of the validator set changes. In this way, the verifier can securely track all validator set changes.

Armed with this commitment, the verifier only needs to know the aggregate of public keys that signed a committee's attestation messages. Using the apk SNARK, the verifier can confirm that the aggregate of these aggregate public keys, along with a bitlist and a SNARK proof, corresponds to the commitment it has to the public keys of the full validator set. This enables the verifier verify as many attestation messages at once in order to take advantage of the performance benefits of equation .

An issue that arises is that the beacon chain uses a combination of Casper FFG and LMD Ghost. A consequence of this decision is that signed attestations do not need to reach super-majority participation before they are published in beacon chain blocks. This means that there may be multiple signed attestation messages from a committee with overlapping participants. The aggregate of these overlapping signers is unfortunately incompatible with the apk SNARK’s constraints. However this just means we cannot verify a supermajority of the beacon chain’s attestations in one go, we can instead prove batches of attestations that have no overlapping committee signatures. Where is the maximum number of times a single committee produced an attestation.

The protocol is formally defined below:

Performs the SNARK set up, . Computes the commitment where is the set of all validator public keys. Computes the update key . Outputs .

Given a set of Casper FFG committee attestations with non-overlapping signatures where is the set of participating public keys in each committee attestation. The prover computes the bitlist for the participating public keys of all the individual validators, then finally they compute the apk proof for the aggregation of these public keys, and outputs . Where:

Where, , . First the verifier computes , where is the bitlist of disabled validators, next they verify the apk proof for the participating public keys:

finally they verify the BLS signatures for each committee’s attestations using equation

If all signature verifications pass, the verifier updates the bitlist for all the signers seen so far by computing . Outputs . A source epoch boundary should be considered final if .

The prover computes the merkle multi-proof for all validators whose status (joined, exit_epoch, activated_epoch, slashed) have changed with respect to the latest finalized epoch block root . Next they compute the KZG proof for the points that pass through defined in . Outputs .

First the verifier verifies the ssz merkle proof for the validator statuses via , where represents the validator struct in the beacon state for the block root of the finalized epoch . If the Merkle verifications pass, the verifier then proceeds to verify using the equation in . If the KZG proof is valid, then the verifier can update their commitment with the set of all new validators in using equation . Finally they compute , where , is the bitlist of all validators who have been disabled (exited, slashed) and is the bitlist of all validators who have been activated. Outputs the updated commitment .

References

Dan Boneh; Ben Lynn & Hovav Shacham. "Short Signatures from the Weil Pairing".

Dan Boneh, Manu Drijvers, and Gregory Neven. "Compact Multi-Signatures for Smaller Blockchains"

Dankrad Feist, Kate Polynomial Commitments

Vitalik Buterin and Virgil Griffith. "Casper the Friendly Finality Gadget"

Oana Ciobotaru, Fatemeh Shirazi, Alistair Stewart , and Sergey Vasilyev. "Accountable Light Client Systems for PoS Blockchains"

Combining Ghost and Casper