Background: the XDM (short for cross domain message) is a special domain extrinsic:
Initiated by the user of domain A and included in the runtime state of domain A
The relayer extracts the XDM from domain A and relayed it to the transaction pool of domain B
Included in the bundle of domain B and executed on domain B
In step 2, the relayer needs to construct a storage proof to prove that a specific XDM is accepted by domain A (by proving the XDM is included in domain A’s runtime state), it also provides a state root of domain A so that domain B can verify the storage proof.
The problem: currently, the state root of domain A is getting from the consensus chain which is submitted by the operator of domain A through ER (short for execution receipt). Even domain B can verify that the state root is getting from the consensus chain, both the integrity and availability of the state root are not guaranteed:
Integrity: since the state root is coming from the ER, as long as the ER is still in the challenge period, the state root of the ER can be proved to be invalid by potential fraud proof
Availability: the state root of domain A may not exist in the consensus chain at the time the relayer trying to relay the XDM
The operator of domain A may not submit the ER in time
The ER can be pruned by fraud proof and the new ER has not yet submitted
The ER may be confirmed and pruned from the consensus chain permanently
The current solution: currently, the XDM is not relayed immediately after it is accepted by domain A, instead the relayer will wait for RelayConfirmationDepth number of blocks (which is much shorter than the ER challenge period) and assuming that by then both the integrity and availability of the state root should be satisfied, i.e. if an invalid ER was submitted, after waiting RelayConfirmationDepth number of block, the invalid ER should be pruned by fraud proof and a valid ER is submitted.
Since the XDM is the same as other regular domain extrinsic, there is no special treatment for the ER that is derived from bundle that contains XDM, so the challenge period of such ER should be the same as other regular ER instead of RelayConfirmationDepth, otherwise the assumption may not hold.
Temporary state in the source domain, it will be cleared when the response is received. Besides, there is a max_outgoing_messages limit for each channel, new outbox messages will be rejected when the limit is met.
Yes, the challenge period is indeed necessary for XDM (without any additional mechanism involving operators). Note that if ER is correct, then it will not be replaced by another ER at the same height. On the other hand, if ER is incorrect, then it will be replaced by a correct ER within the challenge period (according to our security assumption). These two properties suggest that we can achieve both integrity and availability as long as we keep the Merkle root of ER in the block header.
What if we want to have fast XDM verification (say, much shorter than the challenge period)? Since an honest operator can verify ER way before the challenge period, it can “sponsor” a valid XDM and charge some processing fee. This gives us some hope to achieve fast verification via a crypto-economic argument, which is our ongoing research.
We would like to move from normal cross-domain transfer to fast cross-domain transfer with as little modification as possible.
First, let us recall what is a normal cross-domain transfer. @ning gave us a very good summary in his first post.
Step 1: An XDM extrinsic is initiated by a user of domain A and included in the runtime state of domain A.
Step 2: The relayer extracts the XDM from domain A and relays it to the transaction pool of domain B together with its inclusion proof (showing that it is indeed accepted by domain A).
Step 3: The XDM is included in the bundle of domain B and executed on domain B.
Step 4: The relayer sends domain A a proof that the XDM is indeed executed on domain B.
Although some concerns were raised by Ning, they can be addressed by making two changes:
Keeping the state root of ER (called ER root for short) in the block header.
However, these two changes imply that a user has to wait for two challenge periods!
Next, let us outline an idea for fast cross-domain transfer. An operator on domain A “sponsors” an XDM extrinsic by providing an inclusion proof with respect to an ER root. In Step 2, the relayer will wait for Relay_Confirmation_Depth number of blocks (which is now set to be much shorter than the challenge period) and forward the XDM together with the proof of sponsoring. In Step 3, operators on domain B verify both Relay_Confirmation_Depth and the sponsoring proof (assuming that the ER root is correct). Similarly, an operator on domain B will sponsor the XDM execution. In this way, we move from two challenge periods to two confirmation delays.
Note that the assumption of correct ER root can be easily verified after the challenge period. This gives a simple slashing condition for malicious sponsors. Of course, honest sponsors should get paid for their service. We will explore more in this direction.
The previous sponsoring operations are in spirit similar to the pre-confirmations discussed in Vitalik’s recent post. See below
Another type of partial guarantee worth mentioning is pre-confirmations . Pre-confirmations are messages signed by some set of participants in a rollup or validium that say “we attest that these transactions are included in this order, and the post-state root is this”. These participants may well sign a pre-confirmation that does not match some later reality, but if they do, a deposit gets burned. This is useful for low-value applications like consumer payments, while higher-value applications like multimillion-dollar financial transfers will likely wait for a “regular” confirmation backed by the system’s full security.
In our case, waiting for two challenge periods gives us full security.