The road to L2 interoperability
source|StarkWare
Summary
source|
The L2 interoperability solution proposed in this paper builds on our previous proposal
StarkEx 2.0 (launched in November 2020) will provide L2-L1 interoperability (i.e. fast withdrawals) using on-chain conditional transactions.
background
StarkEx 3.0 (launching in February 2021), will provide L2-L2 interoperability between StarkEx systems using off-chain conditional transactions.
background
Layer-2 expansion solutions are developing rapidly. There are already multiple validity proof systems on the Ethereum mainnet, and some fraud proof systems have also launched testnets. L2 solutions, while providing scalability, come at a price: some of the advantages we had of operating entirely on L1 may suffer.
We don't want a certain L2 solution to dominate: Different apps have different requirements for scalability, so you can choose a suitable L2 solution according to your own needs. Next, let us explain two important terms to you:
Interoperability: Allow users to efficiently transfer funds between app1 (initial environment) and app2 (target environment).
Composability: the ability to combine the operations contained in app1...appn into a single transaction to send.
Note: Composability will be discussed in detail in a future article.
conditional transactiondiscussA conditional transaction is a block constructed from a password (we first
discuss
Through this concept), it aims to achieve interoperability for permissionless blockchains. A conditional transaction means that whether a transaction takes effect or not depends on whether certain events occur (such as whether payment occurs or the state changes). Conceptually, we first set up a conditional transaction in the initial environment, which takes effect once certain conditions are met in another environment (ie, the target environment).
step by step
We need to do better. For this reason, we have specially made the following plan to achieve L2 interoperability step by step.
“Quick withdrawalPhase I: StarkEx (L2) → Ethereum (L1) — Fast Withdrawal
"(Fast Withdrawals) can solve the problem that users need to quickly withdraw money from L2 system StarkEx to L1. Through fast withdrawal, users can not only transfer funds to their own L1 address, but also transfer funds to any target address of L1 Among them, such as Compound, Aave, etc. Importantly, this allows users to make withdrawals measured in "block time", regardless of how often StarkEx attests to batch transactions.
Participants:
Use case: Alice wants to transfer 1 ETH from her dYdX account on L2 to her L1 address.
Participants:
LP (Liquidity Provider who holds funds on L1)
The StarkEx operator in the initial environment (dYdX in the above example)
image description
Figure 1: Quick withdrawal process
Process: (1) Alice sends a conditional transaction worth 1 ETH to LP (plus a handling fee for LP), the condition is that LP needs to transfer 1 ETH to Alice's L1 address; (2) LP is in After L1 transfers to Alice, the conditional transaction takes effect, and then (3) LP submits the conditional transaction to the operator, and then it is packaged into the next batch of transactions waiting to be proved; (4) Wait until these proofs are submitted After arriving at L1 and being verified, LP's account in L2 received Alice's transfer.
Regular rebalancing: LPs need to regularly take out the funds they gradually accumulated in the L2 account to supplement the funds they gradually consumed in the L1 account.
Initial StarkEx deployments will each host an application. At this stage, we want users to be able to move funds quickly between these different applications. Much like fast withdrawals, we want to minimize on-chain costs for users and save them the time of waiting for the next batch of transactions to be packaged for proof.
Participants:
Use case: Alice wants to transfer 1 ETH from her dYdX account (L2_1) to her DeversiFi account (L2_2).
Participants:
LP (liquidity provider who holds funds on L2_2)
The StarkEx operator on the initial environment (dYdX in the above example)
image description
Figure 2: Off-chain conditional transaction process
Process: (1) Alice sends a signed conditional transaction worth 1 ETH to LP on L2_1 (plus a handling fee for LP), the condition is that LP needs to transfer 1 ETH to Alice's L2_2 account; (2) After LP transfers money to Alice's L2_2 account; (3) The payment is packaged into a batch of transactions, which is then certified by the operator of L2_2 and verified on L1. After these transactions are published on L1 and accepted, the conditional transaction sent by Alice will take effect; (4) LP submits the conditional transaction to the operator of L2_1 and packs it into the next batch of transactions waiting to be proven ; (5) Once the batch of transactions on L2_1 is certified and submitted to L1 for verification, the LP's account on L2_1 receives Alice's transfer.
Regular rebalancing: LP needs to periodically rebalance the funds between the two systems, L2_1 and L2_2, according to the flow of funds between the two systems.
Expanding on Phase 2 to allow funds to be transferred between arbitrary L2 solutions, be it proof-of-validity or proof-of-fraud systems (e.g. Optimistic Rollup, Plasma). The caveat here is that Optimistic Rollups face inherent capital inefficiencies when using LPs to support interoperability (seehere)。
here
first level title
trust model
Now to summarize the trust model we rely on.
for users
Totally trustless.
for LP
LPs need to trust the operator (in the initial environment) that it will package their valid conditional transactions, that is, not censor them during processing. This trust can be removed in several ways.
If the operator fails to process LP's conditional transactions in a timely manner, LP can:
Anti-censorship: Submitting a censored conditional transaction to the smart contract of the operator on the chain will freeze the operator so that the proofs submitted later cannot be processed.
Security Collateral: Submit the reviewed conditional transaction to a security collateral smart contract on the chain, and receive funds directly from the contract.
Phase 1 will be released on the Ethereum mainnet in November 2020 (i.e. StarkEx 2.0), and phase 2 will be released in the first quarter of 2021 (i.e. StarkEx 3.0). There are already a number of LPs lining up for service.
Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.
