Partnered With:

Introduction | The Road to Layer-2 Interoperability

Read this article in 12 Minutes

Liquidity provider, to solve the L2 fund migration problem.

Original title: "Introduction | The Road to Layer-2 Interoperability"

Original source: Ethereum Enthusiast

Summary in four sentences

1. Layer-2 interoperability means that users can Migrate funds between layers, and the friction on Layer-1 is as small as possible.

2. The Layer-2 interoperability solutions mentioned in this article are all based on the "conditional transaction cryptographic components" we suggested before.

3. StarkEx 2.0 (expected to launch in November 2020) will use on-chain conditional transactions to provide Layer-2 to Layer-1 interoperability (fast withdrawals).

4. StarkEx 3.0 (expected to launch in December 2020) will use off-chain conditional transactions to provide Layer-2 to Layer-2 interoperability (fast withdrawals).

Background

Layer-2 (L2) scalable solutions are progressing rapidly. There are already many validity proof systems on the Ethereum mainnet, and many fraud proof systems have been launched on the testnet. L2 schemes offer scalability, but there is a trade-off: with L2 schemes, some of the benefits of running entirely on L1 are broken, or at least diminished. We do not believe that one L2 solution is perfect for all needs: different applications have very different needs for throughput scaling. Apps themselves will choose their own suitable ones from the rich L2 design library.

Before going further, let's define two important terms:

Interoperability: Allows users to efficiently transfer funds between application 1 (initial environment) and application 2 (target environment)

Composability : Can operate app_1, app_2, ..., app_n in one transaction. (Composability is not the topic of this article. We will talk about it next time.)

In addition to these loose definitions, we also need an enhanced version of conditional transactions . This important element is the key to interoperability.

Conditional-Tx:

This is a cryptographic element (which we propose for the first time here) that can be used to achieve interoperability on trustless blockchains. A conditional transaction is a transaction that depends on the occurrence or non-occurrence of some events (for example: a certain payment, a certain state change) to determine whether it will take effect. The basic concept is that we can define a conditional transaction in the initial environment, and then wait for the conditions specified in it to be met in another environment (that is, the target environment) before it takes effect.

Step by step

In the absence of a better solution, at least, the user will always Ability to transfer funds from initial L2 back to L1 and then reinvest in target L2. This crude way is slow and expensive, and gets slower and more expensive as demand increases.

So we have to do better. In fact, we plan to follow the steps below to achieve a better solution step by step.

Phase I: StarkEx (L2) → Ethereum (L1)—Quick Withdrawal "Quick Withdrawal"

It can solve the problem that users need to quickly withdraw funds from the StarkEx system to L1. It can not only send funds to the user's own L1 address, but also send funds to any target address of L1, such as Compound, Aave, etc. Importantly, the latency of user withdrawals will be measured in "block time", independent of how often StarkEx generates proofs for batches of transactions.

Use scenario: Alice wants to send the 1eth in her dYdX account in L2 to her address in L1.

Participants:

Alice (a user with a deposit on L2)< /p>

LP (a liquidity provider with funds on L1)

StarkEx operator in the initial environment (dYdX in the above example)

- Figure 1: Quick withdrawal process-

Process: (1) The user sends a conditional transaction to LP, promising to pay 1eth (plus LP's handling fee), The condition is that LP transfers 1eth to Alice’s L1 address on L1; (2) After LP transfers money to Alice on L1, the conditional transaction takes effect; (3) LP sends the conditional transaction to the operator , waiting for it to be packaged into the next batch of transactions to be proved; (4) After the next proof is submitted to L1 and verified, the LP's L2 balance increases to reflect the funds he received from Alice.

Regular rebalancing: The LP needs to supplement its own L1 account with its own (gradually accumulated) funds in the L2 account on a regular basis (gradually consumed) funds.

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

StarkEx at the beginning Yes, each instance hosts one application. At this stage, we want users to be able to move funds quickly between these different applications. Much like fast withdrawals, we also hope to help users minimize on-chain overhead without having to wait for their withdrawal transactions to be packaged and proven on L2.

Use scenario: Alice wants to transfer her 1eth from her dYdX account on L2_1 to her DeversiFi account on L2_2.

Participants:

Alice (a user with a deposit on L2_1)< /p>

LP (a liquidity provider with funds on L2_2)

StarkEx operator in the initial environment (dYdX in the above example)

- Figure 2: Off-chain conditional transaction process-

Process: (1) Alice sends a signed conditional transaction to LP, promising to pay on L2_1 Pay 1eth (plus LP's handling fee), the condition is that LP sends 1eth to Alice's L2_2 account; (2) the LP pays Alice on L2_2; (3) the payment transaction is packaged by the operator of L2_2 Enter a certain batch and submit the certificate, which is verified on L1; after the batch of transactions is published on L1, the conditional transaction can take effect; (4) The LP submits the conditional transaction to The operator of L2_1, who will package it into the next batch to be proved; (5) After the next batch of transactions of L2_1 is published on L1 and its proof has been verified by the contract, the LP will The account balance on L2_1 is updated to reflect the amount TA received from Alice.

Regular rebalancing: LP needs to periodically balance the funds in L2_1 and L2_2, depending on the flow of funds in the two systems.

At this stage, the main cost of supporting interoperability will be the capital cost of LPs; be aware that their capital cost will take some time to recoup , that is, the period from providing liquidity to users to when operators pack and process conditional transactions. We expect this time to be a few hours at first (most of the time), and then decrease to proof generation time (minutes) as throughput increases (in all StarkEx applications).

Phase III: L2→L2

Phase II based extension, allowing funds to Migrate between arbitrary L2s, whether systems using proof-of-validity or proof-of-fraud (Optimistic Rollup, Plasma). What I want to remind here is that (compared to zkRollup) Optimistic Rollup will have some disadvantages in terms of capital efficiency when using LP to achieve interoperability, which is inevitable (see here) (Chinese translation)

< p>

Trust Model

Let us now summarize the required trust model.

It is completely trustless for users

For LP

LP needs to trust (in the initial environment) to operate , trusting the latter to process their valid conditional transactions, i.e. not to censor them. This need for trust can be removed in several ways.

If the LP's conditional transaction is not processed by the operator in a timely manner, the LP can:

Anti-censorship: Submit the censored conditional transaction to the "operator" smart contract on the chain, allowing the latter to freeze the operator, so that the certificate submitted by the operator cannot be processed.

Security deposit: submit the reviewed conditional transaction to a security deposit smart contract on the chain, and receive funds directly from the contract.

Plan

Phase I will be launched on Ethereum in November 2020 Network (i.e. StarkEx 2.0), and Phase II will arrive in the first quarter of 2021 (i.e. StarkEx 3.0).

Phase III will follow. We anticipate that different applications on L2 will have the need to interoperate with other L2 applications, and are eager to discuss solutions with other L2 solution providers.