Introducing Zipline Casper

ChainSafe is excited to announce the release of our prototype of Zipline Casper, a project developed under a grant from the Gnosis Builders program.

Introduction

Zipline Casper is an optimistic, trust-minimized, cross-chain, block header oracle. It allows anyone to take block headers from a chain using the Casper finality protocol (e.g., Ethereum/Gnosis) and submit them on another EVM chain while providing the guarantee that headers not finalized by the origin chain will eventually be rejected on the destination.

The novelty of Zipline Casper compared with other cross-chain solutions is that it verifies the origin chain finality protocol in full. In other words, it inherits the economic security of the origin chain.

Other solutions either introduce additional trusted actors (e.g., multisig or MPC-based solutions) or downsample the validator set using the sync committee protocol. In this regard, Zipline is unique and an important step toward a trust-minimized cross-chain future.

Zipline can be used as a building block for all kinds of cross-chain applications or add an additional layer of security to existing ones. It's also inexpensive to run. Under normal operations, it requires only 94k gas per epoch to stay in sync, and this can likely be reduced further.

History of Zipline

Zipline originated from a hackathon project at EthBogota 2022. In this early version, our team from ChainSafe developed a prototype that used the Ethereum sync committee protocol.

Gnosis Builders took an interest and awarded us a grant to continue the work to answer one question: Can the same process work for the finality protocol? The answer, it turns out, is yes, but a number of tricks were required to deal with the very large validator set sizes used in Ethereum and Gnosis.

Our contributions

Zipline uses the fault-proving system from the OP stack to prove execution of a program that verifies Casper finality. It specifies a processor architecture (MIPS) and a way by which an honest observer can prove fraud in an assertion about the result of executing a program with certain inputs.

If fraud is observed, any account can submit a transaction to challenge a result. This initiates an interactive challenge game that reduces the problem of executing the whole program to executing just a single contested instruction onchain. The challenge game is constructed such that an honest player will always win against a dishonest player.

To ensure that everyone can verify the result themselves, the inputs to the program need to be public and available, typically submitted in calldata. This was the first challenge we encountered when designing Zipline. There are >600k validators on Ethereum, and it needs a public key and attestation from every validator. This is a lot of calldata needed as inputs to the finality program!

We used a number of strategies to make this manageable. Most insights were gained by exploiting the properties of a finalized chain.

Namely:

• There can only be a single finalized block for a given height

• Recent blocks must be publicly available.

Inverting the challenge game

In an optimistic rollup, the state transition program accepts a state commitment and some transactions to produce a commitment to the new state. In order to prove fraud, an honest observer must prove that the proposed new state commitment is not the result of correctly executing the program with those inputs.

Because there is only a single correct block header for a given slot, we had the insight that another way to prove that a particular header is not part of the finalized chain is to prove that a different header at the same height is.

Doing so allows us to shift the point at which the computation inputs are posted on-chain from when block headers are submitted to when a challenge is opened. Since challenges are expected to be a very, very rare occurrence, this effectively reduces the ongoing gas costs to just that of submitting and storing a single header root plus metadata.

Origin chain state availability

A sovereign chain must guarantee its data availability of transactions and state so that new participants can join the network. Zipline can take advantage of this by not requiring additional data availability for data rooted in finalized blocks.

Data rooted in finalized blocks can be loaded by hash into the provable execution runtime using the Cannon pre-image oracle. This allows the runtime to access the entire validator set as of the previous epoch to validate the attestations without requiring it to be posted on-chain.

Since the protocol requires checking validator attestations from more than a single epoch, we introduce the concept of state diffs. These contain the minimal data needed to patch the old state to be able to validate attestations in the next epoch. This is composed of the RANDAO commitment and any validator entries/exits that took place. These diffs are very small in practice, thanks to the limit on how many validators can enter and exit per epoch.

Attestation compression

The bulk of the remaining data that needs to go onchain is the attestations themselves. Because of how committees work in the beacon chain protocol, this requires 64 96-byte BLS committee signatures per block, 32 blocks per epoch, and at least two epochs worth of attestations (but possibly more in the case where finality is delayed).

This adds up to at least 393KB for the signatures alone, plus additional data for the committee indices, etc. Each signature is over a different message, so simple signature aggregation cannot work in this case as it does within the committee.

Fortunately, the BLS signature scheme is capable of verifying aggregate signatures over different messages provided the original messages and the information of who signed what can be reconstructed.

This allows compressing the collection of BLS signatures into a single signature, plus the committee indices and the participation flags. This also has the added bonus of reducing the number of pairings required in the verification by half.

This optimization to the protocol has not been implemented in the PoC but will be part of the production implementation.

Summary

These tricks combined make conducting a challenge game on the destination chain feasible, even with hundreds of thousands of validators. The data required to be submitted onchain for a challenge is still large but can fit within a single Ethereum block. Remember, we expect these challenges to be extremely rare events, so this does not factor into the cost calculations of operating the oracle.

Furthermore, honest challengers will always be able to recoup the gas cost of a challenge from the share of the fraudulent challengers' bond they win.

Going forward

ChainSafe is excited to continue the development of Zipline with the intention of having a simplified version production ready by the end of 2023.

We hope it will be a valuable addition to any cross-chain application wanting to add an extra security backstop. It is also planned to be a core component of the upcoming Sygma cross-chain offering.

If you wish to dig deeper, visit the Zipline protocol specification. If you're interested in collaboration, feel free to get in touch 👉 info@chainsafe.io

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, and more, ChainSafe creates solutions for developers and teams across the web3 space utilizing expertise in gaming, interoperability, and decentralized storage.

As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter