This paper proposes the creation of public good, permissionless protocol for cross-rollup communication, aligned with Ethereum’s rollup-centric future. The creation of a public good infrastructure involves and requires the participation of multiple unrelated parties and forming it into a collective. It is the intention of the authors to help facilitate the creation of both the infrastructure and the social collective around this initiative. Additionally, this document elaborates on the economic incentives for the actors inside CRC, presents a CRC message flow, and reviews the security and scalability implications of the protocol.

A “succinct” description of the proposed protocol can be:

Much like IBC, the proposed system involves relayers that transfer data from a source rollup into a destination rollup and get paid for that service. Unlike IBC, the data transfer is actually a transfer of the Ethereum mainnet state. The mainnet state is enough to be able to prove the state of the source rollup and the CRC messages sent. The state that is brought into the destination network is proven via SNARK similar to Proof of Consensus.

We’ve defined the following requirements for a viable Cross-Rollup communication protocol to exist:

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

The proposed solution incorporates a new permissionless role - Relayer. The relayer is an actor that relays the state of L1 inside a rollup. Additionally, the relayer can optionally finalise CRC transactions as a service to the user.

The flow of operations of the CRC protocol has four stages: Initiation, State Relay, Delivery and State 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.

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

In order to initiate the CRC communication, the user sends a $CRC_{Init}$ message to $C_{CRC}$ inside $R_{Source}$. The detailed format of the message will be discussed in the next section but generally, the message will include the destination rollup, details about the payment for the relay service and details about the intended recipient of the communication.

Importantly, anyone can initiate $CRC_{msg}$ by sending an initiation message to the smart contract (both EOAs and smart contracts).

In our bridge example, the user sends a “deposit” transaction to a “bridge” application smart contract ($A_{SourceRollup}$). $A_{SourceRollup}$ crafts and sends a $CRC_{msg}$ to $C_{CRC}$ on $R_{Source}$.

This concludes this phase from the perspective of the user. However, from the perspective of the rollup, the transaction needs to be sequenced in $C_{Source RollupState}$. The process of sequencing and verification of the rollup state is outside of the scope of this phase but will become important consideration later when deciding on the reaction to the $CRC_{msg}$.

Once the user transaction (containing $CRC_{msg}$) is (at least) sequenced in $C_{Source RollupState}$, the second phase kicks in. In this phase, relayers monitor $C_{Source RollupState}$ for $CRC_{msg}$. Once a such message is detected, a relayer can decide to create an L1 Light Client State SNARK (referred to as $SNARK_{L1State}$ ) and provide it to $C_{L1LightClient}$ on $R_{Destination}$ via $CRC_{StateRelay}$ transaction. Sending $SNARK_{L1State}$ to $C_{L1LightClient}$ allows the contract to verify the state of $L1$ and by proxy the state of $R_{Source}$ (the state of $R_{Source}$ is rolled up and verified in $C_{Source RollupState}$ which is part of the verified state of $L1$). The method of producing $SNARK_{L1State}$ and execution of $CRC_{StateRelay}$ can be completely trustless.

If and when a relayer will decide to create the $SNARK_{L1State}$ and execute $CRC_{StateRelay}$ depends on their own consideration. These considerations will be influenced by:

At the end of this phase, $R_{Destination}$ has a verified state of $L1$ and by proxy the state of $R_{Source}$.

With the state of $L1$ and $R_{Source}$ available in $R_{Destination}$ the end user, or a relayer on their behalf, can trigger $CRC_{Delivery}$ transaction inside $R_{Destination}$. The delivery transaction is a transaction sent to the $C_{CRC}$ on $R_{Destination}$ and must include proof that the corresponding $CRC_{msg}$ is in the state of $R_{Source}$. The proof is going to be based on merkle tree inclusion and is trivial to validate by $C_{CRC}$ based on the currently available and verified $L1$ and $R_{Source}$ state.

Once the proof is verified, the data transfer is completed. This would result in triggering the corresponding $A_{DestRollup}$ contract on $R_{Destination}$ (specified inside the $CRC_{msg}$).

In our bridge example, the user (or a relayer in exchange for an additional fee on top of the relaying fee) will trigger the $CRC_{Delivery}$ transaction providing proof that the corresponding $CRC_{Init}$ transaction has been executed when the user deposited the tokens inside $R_{Source}$. The $C_{CRC}$ will verify the proof validity and subsequently trigger the bridge application smart contract ( $A_{DestRollup}$) “mint” transaction, thus releasing the wrapped tokens to the user.

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

The final state of the $CRC_{msg}$ transfer involves acknowledging the state relay and paying the relayer for the work done. In order for the relayer to “unlock” the fees deposited by the User in the initiation phase, the Relayer needs to be able to showcase that they did the state relay work.

Any Relayer that has enough incentive can relay the $L1$ state inside $R_{Source}$ thus, by proxy, relaying the state of $R_{Destination}$ too (remember that $R_{Destination}$ state will be rolled up in $L1$). With the $L1$ state updated inside $R_{Source}$, the relayer that did the original state relay work can submit $CRC_{StateRelayAck}$ transaction with proof (merkle tree inclusion) that they did update the state in $R_{Destination}$ and are entitled to the corresponding fees that the user locked up. The $R_{Source}$ $C_{CRC}$ now can safely release the fees owed to the Relayer, thus concluding the CRC process.

Similarly, any Relayer that has delivered a $CRC_{Delivery}$ and is owed a fee for the service can submit $CRC_{DeliveryAck}$ transaction with proof that they did the work, and are entitled to the corresponding delivery fee.

This section analyses the extent to which the proposed CRC protocol satisfies the requirements we introduced.

The protocol derives its security from the Ethereum main chain and SNARKs. The verification of the $L1$ state in both $R_{Source}$ and $R_{Destination}$ is based either on the strong cryptographic premise of SNARKs or the crypto economical assumptions of the Ethereum mainnet Proof of Stake and Sync Protocol process. Furthermore, if we think about it, even the SNARKs verification inside $R_{Source}$ and $R_{Destination}$ is ultimately performed by the Ethereum mainnet, via the validity proofs verified inside $C_{Source RollupState}$ and $C_{DestRollupState}$.

The protocol is significantly cheaper compared to the “$L1$ messaging” alternative. This is due to skipping the withdrawal from $R_{Source}$ and the costly “data input” transaction to move the data inside $R_{Destination}$ (executed on L1).

The protocol is also somewhat faster than the “$L1$ messaging” alternative. Two scenarios exist with their own speed components. Both of these depend on the security requirements of the receiving application inside $R_{Destination}$.

The most secure version of CRC that might be required by an application needs to wait for the $R_{Source}$ validity proof to be included inside $C_{Source RollupState}$ and the $L1$ state to be relayed to $R_{Destination}$. This will guarantee to the receiving application that the $CRC_{msg}$ really did happen and that is non-reversible. Although this version needs to wait for the validity proof (ZKRollups) or delay period (Optimistic Rollups) for $R_{Source}$ much like in “$L1$ messaging”, it is still faster as it does not require a “data input” transaction for the data inside $R_{Destination}$.

A less secure, but much faster version of CRC, is similar to the so-called virtual state of rollups. A virtual state of rollups is an optimistic state of the rollup that is applied as soon as the transactions are sequenced. It has much weaker guarantees than the validated state but can still find broad applications when speed is a hard requirement. This version is as quick as the time to sequence the $CRC_{Init}$ transaction inside $R_{Source}$ plus the time to relay the $L1$ state inside $R_{Destination}$.

The proposed protocol requires no changes to either the source or destination rollups. It utilises the programmability of smart contracts and no protocol changes are needed.

The protocol is completely decentralised and does not rely on any single (or small set) trusted parties. Any actor can perform the role of a Relayer.

In this section, you can find the specifications of the different messages and the way they are generated and stored in the state of the rollups.

All messages used in the CRC flow have a version field indicating the version of the protocol used. This will enable further modifications and augmentations of the protocol.

The CRC initiation message is the message that is sent by the user and starts the CRC Process. The message should be sent via a transaction towards the $C_{CRC}$ on $R_{Source}$.

While the exact scope and fields of this message can vary between versions, some of the important fields, that are unlikely to change, include:

Additionally, the message can be sent by the user directly to the $C_{CRC}$ or via an intermediary $A_{SourceRollup}$. This means that the message sender and the actual user that intended to send the message might vary and should be accounted for in the message format.

The implementation details are not specified within this paper, but one optimisation that could be implemented is to hash all these parameters within the $C_{CRC}$ and only store the hash in the state in order to reduce costs. Later these parameters can be brought by the relayer to $C_{CRC}$ on $R_{Destination}$ and their correct hashing can be part of the proving process.

The state relay transactions can be triggered by any relayer in the destination network. The goal of this message is to bring the new L1 consensus header and proof that the new header is correct. Additionally, this message would need to carry the fee receiver - the address of the receiver of the state relay fees in the source network.

Upon completion of the state relay, $C_{CRC}$ on $R_{Destination}$ must store a hash of the header and the address of the relayer fee receiver, so that they can withdraw the relay fee at the source network.

The $CRC_{Delivery}$ message can be sent either by a relayer or the user. Note that it is perfectly possible for a relayer to be just a $CRC_{msg}$ relayer and not a state relayer (and vice versa). The parameters needed to trigger this transaction are as follows.

The $CRC_{Delivery}$ message would need to include the message that is being delivered and proof that this message is part of the $R_{Source}$ state and inside $C_{Source RollupState}$.

Upon completion of the delivery, $C_{CRC}$ on $R_{Destination}$ saves a hash of the message and the address of the relayer or user that sent the transaction. This can be used as a delivery receipt when claiming fees inside $R_{Source}$.

The State Relay Acknowledge Message can be triggered by anyone but the relayers have the most incentive to do so. As long as the latest state of $L1$ is relayed to $R_{Source}$ - the rollup where the payments were locked - the relayers can send $CRC_{StateRelayAck}$ and unlock the owed fees. This creates a nice efficiency effect, where a relayer that brings a state of $R_{Destination}$ inside $R_{Source}$ in order to withdraw their fees, also updates the latest $R_{Destination}$ state and can claim fees inside $R_{Destination}$.

Importantly, the $CRC_{StateRelayAck}$ message is a separate message from the $CRC_{StateRelay}$ message (although, they can possibly happen in the same transaction).

The message must contain delivery proof that the relayer has executed $CRC_{StateRelay}$ on $R_{Destination}$. The proof can be as simple as proving that a hash of the fee recipient and the block header was saved in the $C_{CRC}$ in accordance with the flow of the $CRC_{StateRelay}$.

Similarly to the $CRC_{StateRelayAck}$, the $CRC_{DeliveryAck}$ can be triggered by anyone but the relayers have the most incentive to do so.

The message should contain delivery proof that the relayer has delivered the message in $R_{Destination}$. The proof can be as simple as proving that a hash of the fee recipient and the message was saved in the $C_{CRC}$ in accordance with the flow of the delivery transaction.

In order to support the robustness and security of the CRC, certain fees and incentives are embedded as part of the various actions through the protocol. In this section, you can find an outline of these and their intended purpose. These fees are mainly aimed at incentivising the relayers to perform their job, as they incur transaction costs inside the rollups and computational costs for generating proofs.

The state relay fee is paid by the user as an incentive for the relayers to relay the $L1$ state, and respectively the $R_{Source}$ , inside $R_{Destination}$. This fee is locked and earmarked for the first relayer that brings the $L1$ block header that contains the message inside $R_{Destination}$. The state relay fee is the main driver of the economy of the CRC protocol.

Furthermore, this fee also ends up driving the CRC towards becoming a public good - an $L1$ state oracle that any $R_{Destination}$ app can use. Somewhat similar to how DEXes like Uniswap, became public goods as a “price oracle” (with all related caveats), the CRC state relay, ensured and driven by the relay fee, will become an $L1$ state oracle.

A naive first version of the State Relay Fee structure can be done via price discovery auction, similar to the workings of Ethereum pre-EIP1559. The similarity to the gas auction means that the users can pay as much as they see fit, depending on the urgency of the message and the willingness and profit desires of any particular relayer.

Unlike the pre-EIP1559 gas auctions for Ethereum, this behaviour does not necessarily lead to overpaying. While in the $L1$, the users were competing for block space, in the CRC protocol, the users are accumulating their fees together. A relayer that brings the latest state inside $R_{Destination}$ brings all the messages together and can claim the fees for any and all of them. This creates an interesting crypto economical game where the users are actually in advantage as Relayers can accumulate many “cheap” transactions instead of waiting for fewer but more profitable ones. This naturally increases the robustness of the system as different relayers will have different profit goals and thresholds.

Furthermore, the synergy grows even stronger with the adoption of the CRC protocol and the increase in the number of CRC messages passed. The Relayers will have increased profit per relay (albeit for the same amount of work) and the users will pay lower fees for the same speed of relay.

The state relay fee is received by the state relayer upon submission of the $CRC_{StateRelayAck}$ message. This allows the relayer to claim the state relay fees of all the messages in the blocks since the last state relay into $R_{Destination}$.

The delivery fee is an optional fee paid by the user as an indication that they want the $CRC_{Delivery}$ message to be delivered by a relayer.

If this fee is 0, this indicates that the user will be doing a “self-delivery” - they will perform the send transaction that verifies the delivery inside $C_{CRC}$ on $R_{Destination}$ and trigger $A_{DestRollup}$ themselves. If the fee is non-zero, any relayer can decide on taking up the job of delivering the message.

Similarly to Cosmos IBC relayers, it makes sense for the relayers to publish a minimum fee they are willing to accept in order to carry out the delivery. This will act as a delivery marketplace.

The delivery fee is received by the state relayer upon submission of the $CRC_{DeliveryAck}$ message. This allows the relayer to claim the delivery fees of all the messages they have sent the delivery transaction inside $R_{Destination}$.

In this section, you can find different important topics and considerations around the security of the CRC protocol. While the security of the protocol is an end product of balanced-out cryptographic and crypto-economical tools (similar to any blockchain network), in this section you can find more information on the proofs that will be needed and used in order to secure the protocol. Additionally, in this section, you can find some possible attacks on the protocol and their possible mitigations.

Two types of proofs exist in the protocol in order to achieve the communication between the rollups - SNARKs (STARKs can also work) and Merkle Inclusion Proofs. This section does not take into account the native proof generation that each rollup has, but rather the proofs needed for the CRC to be executed.

The most important SNARK of the whole communication is $SNARK_{L1State}$. It proves the validity of the delivered block header inside $C_{CRC}$ on $R_{Destination}$. The mode of operation is similar to the way Proof of Consensus works. Importantly, regardless of which rollup this proof is given to it will be valid as it proves the validity of the execution of the Ethereum network.

The Merkle Inclusion Proofs are used in several places throughout the CRC system and can vary based on the way $R_{Source}$ and $R_{Destination}$ store their data. Merkle inclusion proofs are used for:

In case any of these becomes too complicated to be executed inside a smart contract, they can be combined or converted into SNARKs themselves.

Below you can find some possible attacks on the protocol and their mitigation.

One of the actors most at risk is the State Relayer since they commit (significant) resources to the production of $SNARK_{L1State}$. One possible attack on this actor can be front running inside $R_{Destination}$. A malicious actor (e.x. sequencer inside $R_{Destination}$) can submit the same transaction as the state relayer and be eligible to claim the fees for the state relay, without doing the costly computation.

In order to mitigate this, the state relayer address should be part of the SNARK.

$CRC_{Init}$ message that originated in $R_{Source}$ can be delivered once $R_{Source}$ state has been verified on $R_{Destination}$. In certain scenarios (e.g., bridges), if the message delivery is replayed, an attacker can benefit. To mitigate this, a nonce is included as part of the message. The consuming application ($A_{DestRollup}$) can access the nonce and can choose their own way of guarding against delivery replay attacks.

Due to the nature of the rollups, certain messages might be part of the source or destination rollup in different states. For example, in, Proposer-Builder separated Rollups, the $CRC_{Init}$ message might be in a sequenced state. Different applications might choose to react differently if a message is delivered in different states. The CRC protocol does not need to enforce the state of the rollup message, but rather inform $A_{DestRollup}$ of the state of the delivered message.

The CRC Protocol outlined above is defined in terms of two roll-up networks. This section outlines which components will be applicable when multiple rollup networks are introduced and how the system will look when multiple rollups are part of the protocol.

While the flow of information stays the same between any two rollups that join the CRC protocol, the process of enabling a rollup to be a receiver of the $L1$ state and the configuration of a protocol to be able to receive $CRC_{msg}$ from specific other rollup requires the deployment of specific architecture pieces.

Any rollup that wants to be able to receive the $L1$ state would need to deploy the $C_{L1LightClient}$ contract. This contract will be reusable in the CRC Protocol with any other rollup anchoring to Ethereum.

Due to the differences that the various rollups use in their storage format and structure, $R_{Destination}$ would need to deploy a $C_{CRC}$ for each enabled $R_{Source}$. These contracts will have the $R_{Source}$-specific logic for the Merkle inclusion proofs.

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.

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.

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.

Below you can find some of the questions asked by preliminary reviewers of CRC, and their answers.

Q: How is the Wisp Protocol aligned with the Ethereum Foundation Rollup-centric roadmap?

A: Rollups have been the centre of the Ethereum Roadmap over the past several years. As part of this vision, multiple rollups exist. While the users can choose to reside on any single rollup, it is likely that different applications will live on different rollups and users will need to quickly and seamlessly move data between them. This is where the Wisp Protocol becomes the natural “glue” of the Ethereum rollups ecosystem. Furthermore, evidence based on the latest Layer 2 Grants wishlist, Ethereum Foundation cares deeply about topics like “cross-rollup transaction execution”, “trustless bridging”, and “Solutions for liquidity fragmentation on L2”. Based on that, Wisp Protocol is aligned with the Ethereum rollup-centric roadmap.

Last, but not least, the CRC Protocol is aligned to Ethereum by the decision to use ETH as the payment token for the Relayers service. We believe this accrues further value for the Ethereum ecosystem and allows ETH to be the cross-rollup currency of the rollups ecosystem.

Q: What unexplored aspects of the protocol are there?

A: While most of the major aspects of the protocol are covered in this paper, there are some “downstream” effects that need to be explored. We welcome researchers to join in and explore areas they feel are crucial to be explored. Some shortlist of such topics are:

Efficiency -> Promoting healthy yet resource-efficient competition between relayers - while the relayer's work is mainly for liveness rather than security, it is important to explore possible inefficiencies and the overspending of resources for proof generation. This topic is somewhat similar to the topics of the synchronization of decentralised sequencers and verifiers in ZK/Optimistic rollups.

Fee Market - What type of fee discovery logic would be best for all the stakeholders overall? Could a “legacy” transaction-fee price auction actually be better than an EIP1559-like price auction?

Finality Guarantees - What should be the CRC Protocol guidance in accordance with the finality of the supported rollups? Should this be a decision of the apps integrating, or be enforced on a protocol level?

Implications of L1 reorgs - What are the implications of the L1 reorgs on the system and how should they be mitigated?

Q: What are the MEV considerations and implications for Wisp Protocol?

A: We can see 3 different types of privileges that can be used in order to extract MEV - Sequencer Privileges, State Relay Privileges and Message Relayer Privileges. It is interesting to consider also the cases where one actor assumes more than one of these roles (hence has all of these privileges).

Sequencer privileges are not necessarily directly connected with the cross-rollup communication, but it seems important to highlight the major MEV points sequencers have access to.

The sequencer's design plays a major role so not all privileges apply to all rollups, however, in most cases the sequencers are the ones ordering the incoming transactions in the rollup. This means that they can extract maximal value due to the ordering. This includes the ordering of the transactions for the Wisp State and message relayers.

In a centralised sequencer setup, if the sequencer is also a state relayer, they can monopolise the state relay and censor the state relay transactions by any other actor and only include their own. This way they can increase their revenue by getting all the fees for state relay towards their roll-up.

In a centralised sequencer setup, if the sequencer is also a message relayer, they can completely monopolise the message relay and take all the profits from the message relay.

In a decentralised sequencer setup, all the privileges are somewhat shared between all the sequencers. There is an opportunity for sequencers coordination similar to Flashbots in order to extract the MEV of state relay and messages relay. This way the message relayers can signal MEV opportunity for message relay.

At this point, we can't see a way for state relayers to extract MEV on their own.

In combination with being a message relayer, however, they can bundle together the state and message relay and be the “default” message relayer.

The message relayers have the privilege of ordering the CRC Messages and extracting the MEV out of this order. This privilege is somewhat heightened compared to traditional L1 MEV аs the message relayers can reorder messages not only within L1 blocks but also within L1 epochs.

Q: As the system uses the “native” rollup state, does this mean that each destination rollup will need to have an adapter for verifying the messages based on where they come from?

A: Yes. Every rollup has a different storage structure and anchoring mechanism. This means that unless a common rollup standard exists (which seems unlikely and inefficient) each “Inbox” contract will be specific to the source rollup it services.

Q: Will there be a token?

A: As part of the alignment with Ethereum, the transaction fees will be paid in ETH. In the future, it may make sense for the collective to form some kind of decentralised organisation in order to govern the public good. There are properties of the protocol that must be managed such as updating forkId's of the On-chain Light Client or migrating Inbox contracts based on Rollups upgrading their storage structure. In that case, having governance over the procotol is necessary.

Q: Is Wisp Protocol a bridge between rollups?

A: While Wisp can be used to develop a bridging solution on top of it, the Wisp Protocol is a roll-up communication protocol. This means that it is not a bridge but a transport relayer between rollups secured by Ethereum L1.

Q: Can the CRC be used for communication between L1 and L2?

A: CRC has two main components - the Light Client and the mechanism for data extraction from within a rollup from the point of view of the Ethereum L1. In the context of L1 to L2 communication, the data extraction mechanism can be used to reason about the state of a rollup. This portion of the system is already available and open-sourced via the https://github.com/LimeChain/extractoor-contracts solidity library.

Q: What are some common use cases that can be built on top of Wisp?

A: Some straightforward use cases are the ones where the moving of the data is the actual service. This involves bridging and multi-rollup governance. Another less obvious use case is for dApps wanting to be homogenous between multiple rollups - for example, a DeFi app accepting deposits and liquidity from multiple rollups but concentrating liquidity on one chain for providing a better service.

Q: What would the integration with Wisp look like?

A: On the sending side, the integration with Wisp will require the dApps contracts to send a message towards the CRCOutbox contract in the source rollup. On the receiving side, the integration requires the dApps to deploy a smart contract confirming the interface for receiving messages and further reacting based on their business logic.

Q: What would be the price of a Wisp Message relay?

A: The price of Wis[ message relay is unknown and will be a function of market discovery. However, logically, we can extrapolate that similarly to rollups, the price per message will go down with the adoption of the protocol. Furthermore, it is perfectly possible for a dApp/user to send a 0 fee message as long as they are not concerned with the speed of this cross-rollup communication. In the alpha version, during high L1 gas prices (80 GWei), it costs 0.012 ETH.

Q: Where does the Security of Wisp come from?

A: The security of Wisp comes from the cryptographical promises - the ZK proofs for the light client and the Merkle Inclusion Proofs for data existence.

Q: Is proof generation cost-effective?

A: The cost of Wisp messages includes ZKP generation costs + TX submission costs. In the alpha version, ZKP generation cost accounts for 0.63% of the Wisp message, leaving 99.37% to the TX submission costs. Keep in mind that ZKP generation cost is shared between messages, thus in practice, it would be even lower than 0.63%. The majority of the costs are coming from the size of the MIP (calldata posted on L1). In future versions, Merkle Inclusion Proofs can be executed using ZKPs, reducing the Wisp message transfers by order of magnitudes!

Q: Do any DOS or denial of service attacks exist?

A: We've examined that and at this point, we don't believe there are such. Here are some of the reasons why:

Any DoS attack is actually either an attack on the rollup or on Ethereum L1. Both these systems are (theoretically) designed against DoS. So if someone spams CRC messages on rollup 1 they would need to pay the fees to rollup 1 and make the attack costly.

Any attacker would need to pay for the messages relay, so they can try griefing but this will be the normal (profitable) mode of operation for relayers. Furthermore, the Relayers batch these grieving messages together and relay them with a single ZKP, thus amortising the cost - so this is even better for the relayer.

On the receiving side, griefing is only subjective to the business logic of the receiving dApp as the receiving rollup will treat the CRC messages as normal transactions (that will be paid directly or not by the attacker)

Communicating across rollups is a foundational requirement for the further adoption of L2s. The ability to transfer data across rollups in a trust-minimised setup will enable many new use cases and alleviate possible UX issues. Having the rollup communication problem solved has implications ranging from token transfers and liquidity fragmentation to remote contract executions.

The usage of L1 Light Client SNARK as a proving system for relaying data is the only solution that delivers the necessary security guarantees for the described CRC protocol. Recent advancements in Computational Integrity (ZK) show that the implementation of L1 Light Client inside SNARK/STARKs is becoming more of an implementation problem and not a theoretical one.