Wisp Protocol
Search
K

Wisp Messages

Wisp Message Flow

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

Sending

The first stage of the flow for a
CRCmsgCRC_{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
COutboxC_{Outbox}
contract.
On the smart contract level, this stage is marked by the emitting of the MessageSent event from the
COutboxC_{Outbox}
contract inside
RSourceR_{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
CRCmsgCRC_{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
CRCmsgCRC_{msg}
inside the source rollup via the L1.
On the smart contract level, this stage is marked by the emitting an event by
CSourceRollupStateC_{Source RollupState}
showcasing the anchoring of
RSourceR_{Source}
inside L1. In the case of Optimism Bedrock this is the OutputProposed of the L2OutputOracle.
This event notifies the state relayers that a
SNARKL1StateSNARK_{L1 State}
can be produced and submit it inside
RDestination R_{Destination}
(obviously subject to their economic incentive and willingness to do so). This event also notifies the message relayers to start monitoring the
CL1LightClientC_{L1 Light Client}
for
SNARKL1StateSNARK_{L1 State}
updates refering a block which is >= than the L1 block in which the rollup state was posted that contains the
CRCmsgCRC_{msg}
.

Delivery

The third stage of the flow for a
CRCmsgCRC_{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
RSourceR_{Source}
state containing the message. The beginning of this stage is marked by the HeadUpdate event inside the Wisp
CL1LightClientC_{L1 Light Client}
.
Once such a block is relayed, the message relayer can gather all the necessary proofs and submit them to
CInboxC_{Inbox}
contract on
RDestination R_{Destination}
. The
CInboxC_{Inbox}
contract will query
CL1LightClientC_{L1 Light Client}
and using the L1 Execution State root, verify the existance of
CRCmsgCRC_{msg}
. Once the message is verified ,
CInboxC_{Inbox}
triggers the execution of the
CRCmsgCRC_{msg}
effectively performing the
CRCDeliveryCRC_{Delivery}
operation.

Further States of the CRC Flow

While the above stages conclude the life of the
CRCmsgCRC_{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
SNARKL1StateSNARK_{L1 State}
that includes the state of
RDestination R_{Destination}
in order to prove the
CRCStateRelayCRC_{State Relay}
and
CRCDeliveryCRC_{Delivery}
inside
RSourceR_{Source}
. This allows them to collected the fees they are owed and creates a positive feedback loop of
CRCStateRelayCRC_{State Relay}
.

Properties / Format

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