Pessimistic Validation

This grant was approved through the Quadratic Funding (QF) program. The Atom Accelerator DAO contributed to the matching pool for the QF program, and any amount contributed from the matching pool to this particular project is based on public voting and contributions. As such, AADAO is neither endorsing nor otherwise indicating support for this project. Learn more about the Quadratic Funding program. Some projects might have also been funded through another of our funding programs. View our FAQs on how we deal with potential double-funding.

Pessimistic Validation to enable IBC for Optimistic Rollups.

Description

Main goal: to allow optimistic rollups to IBC without having to wait for the dispute period.

The problem of bridging in reasonable time from optimistic rollups are required to be solved in order for them to be useful in an interchain context, where token bridging over IBC is one of the main use cases.

Solution

Allow a receiver chain (like a hub of some sort) to have some of their validators (so a partial validator set) pessimistically validate the rollup. They just need to run a full node of the Rollup and sign off on the heights they have validated.

Current work

The work right now is figuring out the best technical design for a fully secure production ready version of pessimistic validation. There are multiple options on the table:

Using IBC Middleware for filtering packets instead of creating a new light client
Creating a new conditional IBC (recent functionality added to ibc) light client that uses an additional “prover light client” that can be extended to support ZK proofs in the future
Plugging into Interchain Security to use the Cosmos Hub’s partial set security

Designs are being made and discussed with core teams.

Initial version deep dive

This is done by having optional validation objectives with some target validation power on the receiver chain, where validators can sign up. After the validation objective gets enough validators, a pessimistic light client is created, and the validators use ABCI++ Vote Extensions to agree on heights and updates for the new light client. The light client also uses a dependent light client (for instance 07-tendermint) to verify the state, memberships and so on, in addition to the height of the packets actually having been validated pessimistically.

The implementation of pessimist validation is done by combining the following:

A custom SDK module that has “validation objectives” where validators can sign up to validate a rollup chain.
A custom light client that can be updated with new rollup heights that have been signed off by the validators.
Implementation of ABCI++ VoteExtensions to allow the light client to be updated with new rollup heights easily (and quickly).

The system sketch above shows how the system works:

A new validation objective is created on the receiving chain with a given “required consensus power” requirement
- The objective also needs a “dependent light client” that is used for the pessimistic light client to prove memberships and stuff like that
Validators sign up for the validation objective
Once enough validator power has signed up, the validation objective is started and a new pessimistic light client is created
The validators set up a config for reading the headers from a full node they control
The validators automatically read headers from their full node and sign off on the height by putting them in an ABCI++ VoteExtensions message
VoteExtensions are validated (this part is not implemented much in this PoC, just some basic stuff)
VoteExtensions are sent to the Pessimistic Light Client in the form of an UpdateClient with a ClientMessage
Connections, channels and packets can now be set up between the rollup chain and the receiving chain

Side note: The VoteExtension implementation could easily be extended to also perform all the relaying on both chains directly.

The pessimistic light client depends on another light client (like 07-tendermint) to do the inclusion proofs and so on, which can be seen in the slightly more detailed system design sketch below:

Work done during the initial phase

There are a lot of things that were done to make this work, but some of them are:

Custom SDK module for validation objectives (hub/x/pessimist/)
Custom IBC Light Client for the pessimistic validation (hub/x/pessimist/lightclient/)
ABCI++ Vote Extensions for coordination of light client updates (hub/app/app.go)
A minimal Rollkit chain (with some hacks to get the light clients to play nice) (rolly/)
A full e2e test using Interchaintest (interchaintest/)
Updates to Interchaintest (upstreamed in PR as well) to enable Rollkit and Celestia to work (https://github.com/gjermundgaraba/interchaintest/tree/rollkit-celestia-example)
Some hacks to the Relayer to make it work for the new client (https://github.com/gjermundgaraba/relayer/tree/pessimistic-rollkit)
Some minor hacks to a few docker builds here and there, but nothing major. All docker containers are here: https://github.com/gjermundgaraba?tab=packages

Economic model

The goal is that this should be economically feasible to run from day 1 without running at a loss. So there should be incentives to run this validation. And the cost should probably be reflected on the required security.

There will also be native slashing to incentivise validators to actually run the nodes (and not just take updates from others).