Quasar for Interoperable Cross-L2 Fast Exits

8 minute read
#Layer 2 , #Plasma , #Research

With regards to enhancing the experience of using Plasma, entry and exit are two things that often come up to be a barrier for usability. Ideally, both entry and exit should be time and cost effective.
While, entries (deposits) are fast, but not as cheap (which probably is a topic for later), exits are neither.
The Quasar attempts to solve this by allowing fast exits off Plasma, which still isn’t very cheap because of the Ethereum transactions and the gas costs associated with them.

Section - Direct exits to an L2 (Optimsim)

This is an attempt to enforce a way where the Quasar could allow Fast Exits onto a different L2, potentially without touching Ethereum, and removing the gas costs hence, from the equation.

The Process

To do this, out of sheer exuberance and fascination for the Hubble spotting a Double Quasar recently, we try and split our Quasar into two as well!

  1. L2Quasar - rests on Optimism - the main contract, that someone interacts with, holds the storage and the quasar pool
  2. L1QuasarScope - rests on Ethereum - the contract that is used only when required, whose job is to verify and call a method from L2Quasar

The Quasar gives out liquid funds after verifying transaction inclusion proofs, which directly needs the block roots commited to Plasma contract on L1. A contract on L2, which is meant to be the Quasar cannot read these roots, hence the need of the L1QuasarScope contrat that is on L1 and verifies before triggerring the appropriate method on L2Quasar.

The UX is still the same-

  1. Quasar owner loads up the L2Quasar contract with ETH
  2. Alice, who wants to fast exit onto Optimism, obtains a ticket on L2Quasar, providing the UtxoPos and the amount to reserve.

    point of difference
    Additional details like Tx and inclusion proof are not provided in this step. The first iteration of quasar used the tx and proof to extract value of output and to verify Alice owned this UTXO, but doesn’t confirm if she hasn’t spent it.
    Though, this was a good way to stop people from bothering others UTXOs, we can’t do this since we don’t have access to Plasma block roots on L2. So we go without it, asking Alice to specify both the utxoPos and reserved amount (probably increasing the bond size a bit more)

  3. Alice spends the Utxo in a tx to the Quasar owner on Plasma
  4. Now, the Quasar owner verifies off-chain that Alice has spent the utxo with the ticket correctly in a tx to the quasar owner and takes the authority to call the L2Claim method on L2Quasar which would redeem the ticket and transfer equivalent amount to Alice from the L2Quasar Pool.
  5. However, if the Quasar owner doesn’t send the funds to Alice, in other words, doesn’t call the L2Claim method for Alice’s Utxo, the L2Quasar would still have the ticket active and unclaimed. And, only then Alice would have to use the L1Claim from L1QuasarScope which verifies and triggers the L2Quasar contract to send her funds. Alice would provide the Utxo, spending Tx and the inclusion proof to L1Claim. The L1QuasarScope verifies this Tx was correctly formed, valid and calls the L2Quasar through a bridge contract to send Alice her funds and mark her ticket as claimed.

Additional Vectors

  • Ideally Alice wouldn’t have to use the L1QuasarScope contract. The UX is step 2-4. Step 5 is required only when Quasar owner acts malicious. Since there is no advantage for acting malicious here, step 5 is unused.
  • The utxoPos and the amount reserved should be correctly specified by Alice while obtaining ticket. If Alice gives out a false reserved amount, the ticket cannot be correctly claimed by Alice(if needed) and the quasar owner will have no obligation to send Alice her funds.
  • The IFEClaims and ClaimChallenges can be used in the same way, calling the L1QuasarScope where the proofs are verified and calls L2Quasar that updates the state.
  • ProcessClaims, withdrawing unclaimed bonds can all be done throught the L2Quasar. The L1QuasarScope comes in whenever there is a conflict and a proof has to be verified.
  • Optimism’s cross-domain message is used to call L2Quasar from L1QuasarScope
  • Quasar owner/maintainer can be used inter-changeably here, the maintainer can be given the tasks and the owner a sole address for receiving.

Since, for the happy path the transactions happens over L2Quasar, this allows to avoid the gas fees on Ethereum, and makes these exits cheap.

Claim methods

The L2Claim method-

  • to be called only by the Quasar owner
  • transfers funds to Alice
  • mark ticket as claimed

(or)

The L1Claim method-

  • to be called by Alice
  • provided with Utxo to spend, Tx, proofs
  • after verification on L1, calls L2Quasar through bridge
  • L2Quasar transfers funds to Alice
  • mark ticket as claimed

Potential optimizations

  • The automatic safe blocknum logic does not work here, since the L2Quasar doesn’t have access to the Plasma blocks.
    We might have to consider the manual safe blocknum update by the maintainer, or a time based update. a positive point, is the regular safe blocknum updates are not tx on ethereum (saving some cost).
  • Someone who wants to fast exit must have eth on optimism to pay for calling the obtainTicket method.
    Since, the obtainTicket can be called by any one (not limiting to someone owning the UTXO), there could exist relayers who could call obtain tickets on behalf

Section - Exits via hopping through Ethereum

L2s on Ethereum function by depositing assets on L1 which provides the equivalent assets on L2 (a deposit).
The idea is to use the deposit method with a quasar to provide choice of endpoints to receive thier liquid funds. Instead of giving the funds over Eth, the quasar would call the deposits to these other L2s on claiming.
This specifically can be a way to Fast Exit on an L2 which doesn’t have a L1 -> L2 bridge. (for eg. xDAI, Loopring)
Which, however requires Ethereum Transactions and hence gas fees, only saving one transaction if you are willing to switch L2s.

1
2
3
4
5
changing,
Process Exit on Plasma -> funds on Eth -> Deposit on other L2

into
Claim/Process Fast Exit -> Deposit on other L2

The Process

  • Requires the deposit method of the L2 contracts on Ethereum to allow specifying - the recipient/from account. i.e. Depositing to the Layer 2 on someone’s behalf should be possible.

  • The Quasar is exactly the same as the original quasar design, The only difference will be in the way the liquid funds are given out. Contrary to the original quasar design, the way to retrieve the liquid funds depends on the person calling claim() where he specifies the form in which he wants to get the liquid funds. For ex 1-> ETH, 2-> xDAI 3-> Loopring.