Four sentence summary
- Layer-2 interoperability means that users can move funds between Layer-2 systems, and the friction on Layer-1 is as small as possible.
- The Layer-2 interoperability solutions mentioned in this article are all based on the “conditional transaction cryptographic components” we previously suggested.
- StarkEx 2.0 (expected to be launched in November 2020) will use on-chain conditional transactions to provide Layer-2 to Layer-1 interoperability (fast withdrawals).
- StarkEx 3.0 (expected to be launched in December 2020) will use off-chain conditional transactions to provide Layer-2 to Layer-2 interoperability (fast withdrawals).
background
The Layer-2 (L2) scalable solution is making rapid progress. There are already many validity proof systems on the Ethereum mainnet, and many fraud proof systems have launched testnets. The L2 solution provides scalability, but there are also sacrifices: with the L2 solution, some of the benefits that can be obtained by running completely on the L1 will be broken, or at least reduced. We don’t think there is a certain L2 solution that can perfectly solve all needs: different applications have very different needs for throughput expansion. Applications will choose their own suitable ones from the rich L2 design library. Before going further, let us first define two important terms:
- Allows efficient transfer of funds between the user application 1 (initial setting) and the application 2 (the target environment): Interoperability (Interoperability)
- Combination of (Composability): capable of operating in a transaction app_1, app_2, ···, app_n. (Composability is not the subject of this article. We will talk about it next time.)
In addition to these loose definitions, we also need an enhanced version of conditional trading. This important component is the key to interoperability. Conditional transaction (Conditional-Tx) : This is a cryptographic component (here is our first proposal of this kind), which can be used to achieve interoperability on a trust-free blockchain. Conditional transactions are transactions that depend 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 by it to be satisfied in another environment (that is, the target environment) before it takes effect.
Step by step
When a better solution is absent, at least, users can always transfer funds from the initial L2 back to L1, and then invest in the target L2. This crude method is slow and expensive, and will become slower and more expensive as demand increases. So we have to do better. In fact, we plan to follow the steps below to gradually implement a better solution.
Phase I: StarkEx (L2) → Ethereum (L1) — fast 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 destination address of L1, such as Compound, Aave, etc. What is important is that the time delay for users to withdraw funds will be measured by “block time” and has nothing to do with how often StarkEx generates proofs for batch transactions. Usage scenario: Alice wants to send 1eth from her dYdX account at L2 to her address at L1. Participants :
- Alice (a user who has a deposit on L2)
- LP (a liquidity provider with funds on L1)
- StarkEx operator in the initial environment (dYdX in the above example)
– Figure 1: Fast withdrawal process –
Process: (1) The user delivers a conditional transaction to LP, promising to pay 1eth (plus LP’s handling fee), provided that LP calls 1eth on L1 to Alice’s L1 address; (2) Waits for LP to be on L1 After sending money to Alice, the conditional transaction takes effect; (3) LP sends the conditional transaction to the operator and waits for it to be packaged into the next batch of transactions to be certified; (4) wait for the next proof After being submitted to L1 and verified, the L2 balance of the LP increases to reflect the funds he received from Alice. Regular rebalancing: The LP needs to regularly use the funds in its L2 account (gradual accumulation) to supplement the funds in its L1 account (gradual consumption).
Phase II: StarkEx (L2) → StarkEx (L2)
At the very beginning, StarkEx hosted one application per instance. At this stage, we hope that users can quickly move funds between these different applications. Much like quick withdrawals, we also hope to help users reduce the overhead on the chain as much as possible, and do not have to wait for their withdrawal transactions to be packaged and certified on L2. Usage scenario: Aliece wants to transfer 1eth from her dYdX account on L2_1 to her DeversiFi account on L2_2. Participants :
- Alice (a user who has a deposit on L2_1)
- LP (a liquidity provider with funds on L2_2)
- StarkEx operator in the initial environment (dYdX in the above example)
– Figure 2: Conditional transaction flow under the chain –
Process: (1) Alice delivers a signed conditional transaction to LP, promising to pay 1eth (plus LP’s handling fee) on L2_1, provided that LP sends 1eth to Alice’s L2_2 account; ( 2) The LP pays Alice on L2_2; (3) The payment transaction is packaged into a batch by the operator of L2_2 and submits a 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 certified; (5) etc. After the next batch of transactions of L2_1 is published to L1 and its proof is verified by the contract, the LP’s account balance on L2_1 is updated to reflect the amount TA received from Alice. Regular rebalancing: LP needs to balance the funds in L2_1 and L2_2 on a regular basis, depending on how the funds flow in the two systems. At this stage, the main cost of supporting interoperability will be the capital cost of the LP; it should be noted that their capital cost will take a period of time to return to the circulation, that is, from providing liquidity to users, to operators packaging and processing conditions Trading this time. We expect this time to be a few hours at first (most of the time), and then decrease to the proof generation time (a few minutes) as the throughput increases (in all StarkEx applications).
Phase III: L2→ L2
The extension based on Phase II allows funds to be transferred between any L2, whether it is a system that uses proof of validity or a system that uses fraud proof (Optimistic Rollup, Plasma). What I want to remind here is that (compared to zkRollup) Optimistic Rollup has some disadvantages in capital efficiency when using LP to achieve interoperability, which is inevitable (see here) ()
Trust model
Let us now summarize the required trust model.
For users
It is completely trust-free.
For LP
LPs need to trust the operators (in the initial environment), believing that the latter will process their valid conditional transactions, that is, they will not be censored. This need for trust can be eliminated in several ways. If the conditional transaction of the LP is not processed in a timely manner by the operator, the LP can:
- Anti-censorship: Submit the reviewed conditional transaction to the “operator” smart contract on the chain, let the latter freeze the operator, so that the proof 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 land on the Ethereum mainnet (StarkEx 2.0) in November 2020 , and Phase II will arrive in the first quarter of 2021 (StarkEx 3.0).
- Phase III will follow. We expect that different applications on L2 will need to interoperate with other applications on L2, and we are eager to discuss solutions with other L2 solution providers.
(Finish)
Original link:
https://medium.com/starkware/the-road-to-l2-interoperability-718ff69ec822
Author:
Translation: Ah Jian
