The road to Layer-2 interoperability
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Ethereum enthusiasts (ID: ethfans)
, Author: Tom Brand & Uri Kolodny, translation: A Jian, reprinted by Odaily with authorization.
four sentence summary
Layer-2 interoperability means that users can move funds between Layer-2 systems with as little friction as possible on Layer-1.
The Layer-2 interoperability solutions mentioned in this article are all based on the "conditional transaction cryptographic element" we previously suggested.
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
background
Layer-2 (L2) scalability 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. The L2 scheme offers scalability, but it comes with a trade-off: with an L2 scheme, 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. The applications themselves will choose the suitable ones from the rich L2 design library.
Before going any 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: 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 transactions. This important element is the key to interoperability.
text
step by step
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 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) — fast withdrawal
Participants:
"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.
Usage scenario: Alice wants to send 1eth in her dYdX account in L2 to her address in L1.
Alice (a user with a deposit on L2)
LP (a liquidity provider with funds on L1)
The StarkEx operator in the initial environment (dYdX in the above example)
- Figure 1: Quick withdrawal process -
Phase II：StarkEx (L2) → StarkEx (L2)
Process: (1) The user sends a conditional transaction to LP, promising to pay 1eth (plus LP’s handling fee), on the condition that LP calls 1eth to Alice’s L1 address on L1; After sending money to Alice, 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 proof After being committed to L1 and verified, the LP's L2 balance increases to reflect the funds he received from Alice.
secondary title
Participants:
The original StarkEx hosted 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 reduce the overhead on the chain as much as possible, and do not have to wait for their withdrawal transactions to be packaged and proved on L2.
Usage scenario: Alice wants to transfer 1eth from her dYdX account on L2_1 to her DeversiFi account on L2_2.
Alice (a user with a deposit on L2_1)
LP (a liquidity provider with funds on L2_2)
The StarkEx operator in the initial environment (dYdX in the above example)
image description
Process: (1) Alice sends a signed conditional transaction to LP, promising to pay 1eth (plus LP's handling fee) on L2_1, on the condition that LP transfers 1eth to Alice's L2_2 account; ( 2) The LP pays Alice on L2_2; (3) The operator of L2_2 packs the payment transaction into a batch 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, and the latter will package it into the next batch he wants to prove; (5) etc. After the next batch of transactions of L2_1 are published on L1 and its proof has been verified by the contract, the account balance of the LP on L2_1 is updated to reflect the amount TA received from Alice.
Phase III：L2→ L2
secondary titleChinese translation）
An extension on the basis of Phase II, allowing funds to be migrated between any L2, whether it is a system that uses a validity proof or a system that uses a fraud proof (Optimistic Rollup, Plasma). What I want to remind here is that (compared to zkRollup) Optimistic Rollup will have some disadvantages in capital efficiency when using LP to achieve interoperability, which is inevitable (see here)(
trust model
for users
secondary title
for users
It is completely trustless.
secondary title
For LP
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 proof submitted by the operator cannot be processed.
plan
Security Deposit: Submit the vetted conditional transaction to a security deposit smart contract on-chain, from which funds are received directly.
first level title
