Security & Risks

Cryptographic Proofs

The system is secured by cryptography rather than crypto-economics. No actor is required to put a value at stake or a well-known entity betting on its credibility in order for the system to operate.

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 cross-rollup communication to be executed.

SNARKs & Light-Client Security Guarantees

The most important part of the communication is the $SNARK_{L1 State}$. It proves the validity of the delivered block header inside $C_{L1 Light Client}$ (later used by $C_{Inbox}$) on $R_{Destination}$. The mode of operation is similar to the way on-chain light clients work. 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 system security is comparable to the one defined and proposed by the Ethereum sync protocol. Therefore, the same risks apply to Wisp as the ones to Ethereum sync protocol.

Merkle Inclusion Proofs

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

• Proving the executionStateRoot given the beaconStateRoot during $CRC_{State Relay}$
• During $CRC_{Delivery}$

  • Proving the state of $R_{Source}$ posted on L1
  • Proving that the $CRC_{Init}$ message is part of the $C_{Source RollupState}$ storage (thus that it is part of the $R_{Source}$ state)
• During $CRC_{State Relay Ack}$

  • Proving the $CRC_{State Relay}$ send on $R_{Destination}$
• During $CRC_{Delivery Ack}$

  • Proving the state of $R_{Destination}$ posted on L1
  • Proving the $CRC_{Delivery}$ send on $R_{Destination}$

In the alpha of the protocol, all of these are pure executions on-chain. In future versions, they can be converted into SNARKs themselves in order to reduce $CRC_{msg}$costs.

Ethereum Forks & Finality

Due to the nature of Wisp having an on-chain Light-Client, the protocol is also subject to risks related to Ethereum Forks and the Ethereum Finality.

Firstly, when Ethereum introduces a new fork (and changes the fork-id) the Light Client smart contracts would need to be updated accordingly within all supported rollups.

Secondly, finalizing a block takes ~2 Ethereum epochs (12 minutes). This means that the production version of the protocol and the consuming applications would need to take into account the $CRC_{msg}$ latency being at least 12 minutes if they want to consume only finalised state changes. The other option would be to consume the Optimistic L1 state and react to changes once the state is finalised.

Rollup Upgrades

Rollups, being living and evolving ecosystems tend to change. Them changing their storage patterns, verification patterns or anchoring patterns will require changes in Wisp Protocol too. Depending on the complexity of the change it can temporarily cause Wisp to stop supporting the rollup.