The Road to L2 Interoperability

TL;DR

• L2 Interoperability means allowing users to move funds between L2 systems with minimal L1 friction.
• The proposed L2 interoperability solution relies on our previously suggested Conditional Transaction (Tx) cryptographic primitive.
• StarkEx 2.0 (Nov 2020) will offer L2-L1 interoperability (Fast Withdrawals), using on-chain Conditional Txs.
• StarkEx 3.0 (Feb 2021) will offer L2-L2 interoperability across StarkEx systems, using off-chain Conditional Txs.

Background

Layer-2 (L2) scaling solutions are evolving rapidly. There are already multiple validity proof systems on Mainnet, as well as fraud proof systems on testnet. L2 solutions solve scalability, but do so at a cost: they might break or diminish various characteristics we’ve come to expect when operating strictly on L1.
We don’t expect one L2 solution to rule them all: the needs of applications requiring scaling are varied. Applications will pick solutions from a rich L2 design space.

Before moving forward, let us provide our definition for two important terms:

• Interoperability: The ability to allow users to move funds efficiently from app1 (the Origin environment) to app2 (the Destination environment).
• Composability: The ability to send a tx involving operations on app_1, app_2,…, app_n.
  Note: composability will be the topic of a separate, later, post.

In addition to these loose definitions, we’ll rely on a beefed up version of Conditional-Tx, an important primitive, which will power interoperability.

Conditional-Tx:

This is a cryptographic building block (we first discussed here) used in implementing interoperability for permissionless blockchains. A Conditional-Tx is a transaction conditioned upon some event (e.g. a payment, a state change) taking place. Conceptually, we define a Conditional-Tx in the Origin environment, and it becomes valid once its condition is satisfied in another environment (typically, the Destination environment).

A Stepwise Approach

Absent a better solution, the user always has the ability to naively move funds from the Origin L2 back to L1, and from there to the Destination L2. This naive approach is both slow and expensive, and will become even slower and more expensive as demand for interoperability grows.
We need to do better. In particular, we plan the following stepwise approach.

Phase I: StarkEx (L2) → Ethereum (L1) — Fast Withdrawals

Fast Withdrawals address users need to quickly withdraw funds from StarkEx, an L2 system, back to L1. This is not merely to the user’s own L1 address, but rather to any destination on L1, such as Compound, Aave, etc. Importantly, it allows users to withdraw funds in “blockchain time”, independent of the frequency with which StarkEx proves batches of transactions.

Use-case: Alice wishes to move 1 ETH from her dYdX account on L2, to her L1 address.

Participants:

• Alice (a user with ETH on L2)
• LP (a liquidity provider with funds on L1)
• The StarkEx Operator in the Origin environment (in the above example, dYdX)

Flow: (1) Alice gives the LP a Conditional Tx for 1 ETH (+ the LP’s fee), conditioned upon the LP transferring 1 ETH to Alice’s L1 address. (2) After the LP pays Alice on L1, the Conditional Tx becomes valid, and (3) the LP submits it to the Operator, to be included in the next batch it proves. (4) Once the next proof is submitted to L1 and verified there, the LP’s L2 balance reflects the transfer of funds from Alice.
Periodic Rebalancing: The LP needs to periodically replenish funds in their dwindling L1 account, from the funds that have accumulated in their L2 account.

Phase II: StarkEx (L2) → StarkEx (L2)

The first StarkEx deployments will each host a single application. In this phase, we wish to allow users to move funds fast across these different applications. Much like Fast Withdrawals, we want to minimize on-chain costs for users, and to spare them the need to wait for the next batch to be proven.

Use-case: Alice wishes to move 1 ETH from her dYdX account (L2_1) to her DeversiFi account on (L2_2).

Participants:

• Alice (a user with ETH on L2_1)
• LP (a liquidity provider with funds on L2_2)
• The StarkEx Operator in the Origin environment (in the above example, dYdX)

Flow: (1) Alice gives the LP a signed Conditional Tx for 1 ETH (+ the LP’s fee) in L2_1, conditioned upon the LP transferring 1 ETH to Alice’s L2_2 account. (2) The LP pays Alice on L2_2 and (3) a batch containing that payment is proven by the L2_2 Operator, and verified on L1. After the batch is accepted on L1, the Conditional Tx becomes valid, and (4) the LP submits it to the L2_1 Operator, to be included in the next batch it proves. (5) Once the next batch from L2_1 is proven and submitted to L1 for verification, the LP’s L2_1 balance reflects the transfer of funds from Alice.

Periodic Rebalancing: The LP needs to periodically rebalance funds in their L2_1 and L2_2, depending on the net flow of funds across these two systems.

The dominant cost in supporting interoperability will be paying LPs for their capital cost; note their capital cost spans a very limited timeframe, namely, the time that passes between the provision of liquidity to the user and the processing of the next batch by the Operator. We anticipate this timeframe to start off at a few hours (at most) and then decrease to proof generation time (minutes) as throughput — across all StarkEx applications — scales up.

Phase III: L2 → L2

Expand on Phase II, by allowing the transfer of funds across any L2 solution, whether a validity system, or a fraud proof system (Optimistic Rollups, Plasma). It is worth reminding here the inherent capital efficiency disadvantage that OR systems will face in supporting an interoperability solution using LPs (see here)

Trust Model

We now articulate the trust model we rely on.

For the user
Entirely trustless.

For the LP
The LP needs to trust the Operator (in the Origin environment) to include their valid Conditional Tx, i.e. not to censor them, in the next batch processed. This trust requirement can be removed in several ways.
If the LP’s Conditional Tx is not processed promptly by the Operator, the LP can:

• Counter-Censorship: submit the censored Conditional Tx to the Operator’s smart-contract on-chain, which will consequently freeze further processing of the Operator’s proofs.
• Security Deposit: submit the censored Conditional Tx to a security deposit smart contract on-chain, and receive payment directly from it.

The Road Ahead

• Phase I is coming to Mainnet Ethereum in November 2020 (StarkEx 2.0), and Phase II will follow on Mainnet in Q1 2021 (StarkEx 3.0). We already have LPs lined up to power these services.
• Phase III will follow soon thereafter. We anticipate demand from the various applications on L2 to interoperate with applications operating on other L2 solutions, and are eager to discuss these integrations with other L2 players.

For more, watch Tom Brand’s Lecture on L2 Scaling — Interoperability with Shared State at the Liquidity 2020 conference (sign-in required).

Tom Brand & Uri Kolodny

¹Further down the road, this will likely be one of a few deployment options. We envision a world where different applications may well have different preferences, in this regard.