FAQ

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 griefing 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)