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 SNARKL1StateSNARK_{L1 State}. It proves the validity of the delivered block header inside CL1LightClientC_{L1 Light Client} (later used by CInboxC_{Inbox}) on RDestination 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 RSourceR_{Source} and RDestination R_{Destination} store their data. Merkle inclusion proofs are used for:

  • Proving the executionStateRoot given the beaconStateRoot during CRCStateRelayCRC_{State Relay}

  • During CRCDeliveryCRC_{Delivery}

    • Proving the state of RSourceR_{Source} posted on L1

    • Proving that the CRCInitCRC_{Init} message is part of the CSourceRollupStateC_{Source RollupState} storage (thus that it is part of the RSourceR_{Source} state)

  • During CRCStateRelayAckCRC_{State Relay Ack}

    • Proving the CRCStateRelayCRC_{State Relay} send on RDestination R_{Destination}

  • During CRCDeliveryAckCRC_{Delivery Ack}

    • Proving the state of RDestination R_{Destination} posted on L1

    • Proving the CRCDeliveryCRC_{Delivery} send on RDestination 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 CRCmsgCRC_{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 CRCmsgCRC_{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.

Last updated