![](https://cdn.dorahacks.io/static/files/18f80f17881e86a470796974c80bb454.jpeg@256h.webp)
Pessimistic Validation
![](https://cdn.dorahacks.io/static/files/190749ffed9becf18a7a3654da1a0026.png)
![](https://cdn.dorahacks.io/images/hacker-avatar/2.jpg)
![](https://cdn.dorahacks.io/static/files/18e00904659250f97991fae4de8bb06c.jpeg)
![](https://cdn.dorahacks.io/static/files/19028073051887481fedeb647a4bc513.jpeg)
![](https://cdn.dorahacks.io/static/files/18e000b55608cea50ccb90349e6a444e.png)
Pessimistic Validation to enable IBC for Optimistic Rollups
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.
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.
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:
Designs are being made and discussed with core teams.
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:
The system sketch above shows how the system works:
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:
There are a lot of things that were done to make this work, but some of them are:
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).
I go through the whole solution and run a demo of the system running locally.