Architecture Overview

How does it work?

In a nutshell, Wisp is a combination of an on-chain light client and a verification mechanism for data inclusion inside a rollup. The on-chain light client makes sure that the destination rollup can trust and reason about a specific execution state root at a specific height of the Ethereum L1. Based on this root, smart contracts can reason about the inclusion (or not) of a certain piece of information inside any rollup anchoring with Ethereum L1. The way that the data inclusion reasoning happens is specific to each source rollup.

The proposed system involves relayers that transfer data from a source rollup into a destination rollup and are paid for that service. The data transfer is two-fold:

  1. ZK proof proving the Ethereum L1 execution state root within the on-chain Light Client contract. The L1 state is enough to give the protocol the ability to prove the state of the source rollup and the CRC messages sent. In the alpha version and the demo, the state that is brought into the destination network is proven via SNARK similar to Proof of Consensus.

  2. 2x Merkle Inclusion Proofs. The first MIP is proving the state of the source rollup posted on L1 using the already proven L1 execution root (step 1). The second MIP is proving the state of the outbox contract within the Source rollup, containing the raw data that must be transported to the destination rollup given the already proven state of the source rollup (1st MIP).

Technical Architecture

Keep in mind that the “Anchor Rollup State” process is performed by Rollups independently of the Wisp Protocol.

The proposed solution incorporates a new permissionless role - Relayer. The relayer is an actor that generates ZKPs of the state of L1 and posts it inside a rollup. Additionally, the relayer can optionally finalise Wisp CRC transfers as a service to the user.

The flow of operations of the Wisp Protocol has four stages: Initiation, State Relay, Delivery and Relay Payment.

As an example of the protocol and how the different architectural pieces fit together, we will use the application of a decentralised cross-rollup token bridge. The token bridge receives and locks some tokens in the source rollup, and mints and releases a wrapped version of the token in the destination rollup.

Initiation Phase

The initiation phase is the phase where the user triggers message transfer through the Wisp protocol. Normally this is done with the intent to perform some business logic operation across rollups.

State Relay Phase

Delivery Phase

This concludes the Delivery phase and the CRC process from the perspective of the User.

State Relay Acknowledge Phase

Inbox & Outbox Contracts

The alpha version of Wisp Protocol and the demo have Inboxes supporting Optimism Bedrock rollups - Optimism and Base.

Relayers

Importantly, both of the relayers' described below ensure the liveness of the system and not the security of the system. The protocol security is derived from cryptography and verified through smart contracts. As long as there is at least one relayer willing to perform the job, the system will continue to be secure under the standard technological risks (circuits and smart contract bugs).

There are two types of relayers in the system - state relayer and message relayer.

Both roles are permissionless and can be played by any actor. Any willing actor can assume one or both roles.

Trust Assumptions

Due to the design of Wisp no new trust assumptions are introduced apart from the ones already in place for the rollups. The communication is secured by a combination of Computational Integrity proofs and Merkle Inclusion proofs.

Possible Improvements Exploration

Aggregating Public State Relay

While the initial version of the protocol highlights state relayers as actors running the software for generating $SNARK_{L1State}$ and submitting it towards $C_{L1LightClient}$, this also introduces a software risk - a bug inside this software can cause complete failure of the whole system.

Furthermore, this positions Wisp as a competitor inside the “Onchain Light Client” space, rather than the aligning initiative it strives to be.

As a means, to address this risk, Wisp can move into “State Relay Aggregation”. Public State Relayers can be delivering their L1 state proofs to the destination rollups and the protocol can start using these and utilizing these. Due to the deterministic nature of the Sync Protocol, the aggregation of multiple Light client sources will further enhance the security, lower the trust assumptions and lower the risk for the system.

In addition, the State Relay fees will now be flowing back to the community and to the actors doing the state relay work. This creates a new revenue stream for these actors and aligns the whole system together.

Utilizing Available Anchors

The proposed protocol specifies the Light client-based, state relay phase as a necessary phase for the communication to occur. While this is generally correct, there are cases like Optimism Bedrock and Taiko, where the L1 state is immediately available.

In these cases, it makes sense for the protocol to use them as a source of the L1 state rather than forcing the existence (and the costs) of running onchain L1 Light Client.

Optimising Delivery Message

The biggest cost factor for most rollups is the size of the calldata they need to anchor inside L1. With this in mind, the Delivery Message transaction is quite a bulky one and almost all of it eventually goes to L1. This makes the message delivery a costly process and risks the scalability of the system.

A possible improvement is the creation of Computational Integrity Proof to minimize the calldata footprint inside the L2s and respectively the L1s. Moving into ZK proving system (f.e. Groth16) that produces a minimally sized proof will enable the overhead of Wisp to be as little as possible.

Last updated