Wisp Messages

Wisp Message Flow

As part of their flow, the Wisp $CRC_{msg}$ goes through three stages until delivered.

Sending

The first stage of the flow for a $CRC_{msg}$ is the sending of the message by the user or the representing contract. Once a message is sent, the rollup saves it in its state in the $C_{Outbox}$ contract.

On the smart contract level, this stage is marked by the emitting of the MessageSent event from the $C_{Outbox}$ contract inside $R_{Source}$. This event notifies the state and message relayers to start monitoring the necessary conditions for the relay of this message and rollup state.

In Transit

The second stage of the flow for a $CRC_{msg}$ is when it "enters the L1". This stage begins when the rollup anchors state that includes the message in L1. This allows the later verification of the $CRC_{msg}$ inside the source rollup via the L1.

On the smart contract level, this stage is marked by the emitting an event by $C_{Source RollupState}$ showcasing the anchoring of $R_{Source}$ inside L1. In the case of Optimism Bedrock this is the OutputProposed of the L2OutputOracle.

This event notifies the state relayers that a$SNARK_{L1 State}$ can be produced and submit it inside $R_{Destination}$ (obviously subject to their economic incentive and willingness to do so). This event also notifies the message relayers to start monitoring the $C_{L1 Light Client}$ for $SNARK_{L1 State}$ updates refering a block which is >= than the L1 block in which the rollup state was posted that contains the $CRC_{msg}$.

Delivery

The third stage of the flow for a $CRC_{msg}$ is when it is getting delivered. This flow can only kick in when the state relayers have relayed an L1 block >= of the block that anchored the $R_{Source}$ state containing the message. The beginning of this stage is marked by the HeadUpdate event inside the Wisp $C_{L1 Light Client}$.

Once such a block is relayed, the message relayer can gather all the necessary proofs and submit them to $C_{Inbox}$contract on $R_{Destination}$. The $C_{Inbox}$ contract will query $C_{L1 Light Client}$ and using the L1 Execution State root, verify the existance of $CRC_{msg}$. Once the message is verified , $C_{Inbox}$ triggers the execution of the $CRC_{msg}$ effectively performing the $CRC_{Delivery}$ operation.

Further States of the CRC Flow

While the above stages conclude the life of the $CRC_{msg}$ from the perspective of the end user, some post-effects of its delivery are still present and are part of the flow of the relayers.

While the user has paid its fees for delivery in the first stage of the flow, to this point the relayers have not claimed their fees. The last state of the CRC flow involves the state relayers generating the $SNARK_{L1 State}$ that includes the state of $R_{Destination}$ in order to prove the $CRC_{State Relay}$ and $CRC_{Delivery}$ inside $R_{Source}$. This allows them to collected the fees they are owed and creates a positive feedback loop of $CRC_{State Relay}$.

Properties / Format

For the alpha version of the protocol, the $CRC_{msg}$ format can be found here. For future versions, the following format is considered to be used EIP-5164.