Partnered With:

Interoperability of Layer 2 Expansion

Read this article in 12 Minutes

Layer-2 interoperability means users can move funds between Layer-2 systems with as little friction as possible on Layer-1

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

Original Source: Ethereum Enthusiast

Summary in four sentences

Layer-2 interoperability means that users can migrate funds between Layer-2 systems, and in Layer-1 friction is as small as possible.

The Layer-2 interoperability solutions mentioned in this article are all based on our previous proposal to use "conditional transaction cryptographic components".

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).

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 have made rapid progress. 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: Allowing users to efficiently transfer funds between application 1 (initial environment) and application 2 (target environment)

Composability: App_1, app_2, ..., app_n can be operated 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 deal. This important element is the key to interoperability.

Conditional-Tx:

This is a Cryptographic components (here we first propose such a scheme) 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 , users can always transfer funds from the initial L2 back to L1, and then invest in the 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" 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.

- Figure 1: Quick withdrawal process-

< p>Process: (1) The user sends a conditional transaction to LP, promising to pay 1eth (plus LP’s handling fee), the condition is that LP sends 1eth to Alice’s L1 address on L1; After sending 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) Waiting for the next batch of transactions to be proved; After the proof is submitted to L1 and verified, the LP's L2 balance increases to reflect the funds he received from Alice.

Periodic rebalancing: The LP needs to take its own (gradually accumulated) in the L2 account on a regular basis Funds to supplement the (gradually depleted) funds in your own L1 account.

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

Maximum StarkEx started off hosting one application per instance. 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 put her dYdX account in L2_1 The 1eth on the network is transferred 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)

Initial environment The StarkEx operator in (in the above example dYdX)

< blockquote>- Figure 2: Off-chain conditions Transaction process-

Process: (1) Alice sends a signed conditional transaction to LP, promising to pay 1eth on L2_1 (plus LP’s handling fee), the condition is that LP transfers 1eth to Alice’s L2_2 account; (2) the LP pays Alice on L2_2; (3) the payment transaction is packaged into a certain batch by the operator of L2_2 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, The latter will pack 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 account balance of the LP on L2_1 Update 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 LP funding Cost; it should be noted that it takes a period of time for their capital costs to be recovered, that is, the period from providing liquidity to users to when operators package 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, Allow funds to be migrated between any L2, whether it is a system using proof of validity, or a system using 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 trust (in the initial environment) Operators, trusting the latter to process their valid conditional transactions, i.e. not censoring 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-chain and receive funds directly from that contract.

Plan

Phase I will land on Ethereum in November 2020 Fangzhunet (i.e. StarkEx 2.0), and Phase II will come 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.