Wisp Protocol
Search
K

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.