https://medium.com/starkware/the-road-to-l2-interoperability-718ff69ec822
13/06/2022 @Jing Guijia Oct/22/2020
Layer-2 (L2) scaling solutions are evolving rapidly. There are already multiple validity proof systems on Mainnet, as well as fraud proof systems on testnet. L2 solutions solve scalability, but do so at a cost: they might break or diminish various characteristics we’ve come to expect when operating strictly on L1.We don’t expect one L2 solution to rule them all: the needs of applications requiring scaling are varied. Applications will pick solutions from a rich L2 design space.
Before moving forward, let us provide our definition for two important terms:
In addition to these loose definitions, we’ll rely on a beefed up version of Conditional-Tx, an important primitive, which will power interoperability.
This is a cryptographic building block (we first discussed here) used in implementing interoperability for permissionless blockchains. A Conditional-Tx is a transaction conditioned upon some event (e.g. a payment, a state change) taking place. Conceptually, we define a Conditional-Tx in the Origin environment, and it becomes valid once its condition is satisfied in another environment (typically, the Destination environment).
Absent a better solution, the user always has the ability to naively move funds from the Origin L2 back to L1, and from there to the Destination L2. This naive approach is both slow and expensive, and will become even slower and more expensive as demand for interoperability grows.We need to do better. In particular, we plan the following stepwise approach.
Fast Withdrawals address users need to quickly withdraw funds from StarkEx, an L2 system, back to L1. This is not merely to the user’s own L1 address, but rather to any destination on L1, such as Compound, Aave, etc. Importantly, it allows users to withdraw funds in “blockchain time”, independent of the frequency with which StarkEx proves batches of transactions.
Use-case: Alice wishes to move 1 ETH from her dYdX account on L2, to her L1 address.
Participants:
https://miro.medium.com/max/1400/0*BJh-4u1Jn6olaN07
Diagram 1: Fast Withdrawal Flow
Flow: (1) Alice gives the LP a Conditional Tx for 1 ETH (+ the LP’s fee), conditioned upon the LP transferring 1 ETH to Alice’s L1 address. (2) After the LP pays Alice on L1, the Conditional Tx becomes valid, and (3) the LP submits it to the Operator, to be included in the next batch it proves. (4) Once the next proof is submitted to L1 and verified there, the LP’s L2 balance reflects the transfer of funds from Alice.Periodic Rebalancing: The LP needs to periodically replenish funds in their dwindling L1 account, from the funds that have accumulated in their L2 account.
The first StarkEx deployments will each host a single application. In this phase, we wish to allow users to move funds fast across these different applications. Much like Fast Withdrawals, we want to minimize on-chain costs for users, and to spare them the need to wait for the next batch to be proven.
Use-case: Alice wishes to move 1 ETH from her dYdX account (L2_1) to her DeversiFi account on (L2_2).
Participants:
Diagram 2: Off-chain Conditional Tx Flow
Flow: (1) Alice gives the LP a signed Conditional Tx for 1 ETH (+ the LP’s fee) in L2_1, conditioned upon the LP transferring 1 ETH to Alice’s L2_2 account. (2) The LP pays Alice on L2_2 and (3) a batch containing that payment is proven by the L2_2 Operator, and verified on L1. After the batch is accepted on L1, the Conditional Tx becomes valid, and (4) the LP submits it to the L2_1 Operator, to be included in the next batch it proves. (5) Once the next batch from L2_1 is proven and submitted to L1 for verification, the LP’s L2_1 balance reflects the transfer of funds from Alice.
Periodic Rebalancing: The LP needs to periodically rebalance funds in their L2_1 and L2_2, depending on the net flow of funds across these two systems.
The dominant cost in supporting interoperability will be paying LPs for their capital cost; note their capital cost spans a very limited timeframe, namely, the time that passes between the provision of liquidity to the user and the processing of the next batch by the Operator. We anticipate this timeframe to start off at a few hours (at most) and then decrease to proof generation time (minutes) as throughput — across all StarkEx applications — scales up.
Expand on Phase II, by allowing the transfer of funds across any L2 solution, whether a validity system, or a fraud proof system (Optimistic Rollups, Plasma). It is worth reminding here the inherent capital efficiency disadvantage that OR systems will face in supporting an interoperability solution using LPs (see here)
We now articulate the trust model we rely on.
For the userEntirely trustless.
For the LPThe LP needs to trust the Operator (in the Origin environment) to include their valid Conditional Tx, i.e. not to censor them, in the next batch processed. This trust requirement can be removed in several ways.If the LP’s Conditional Tx is not processed promptly by the Operator, the LP can:
For more, watch Tom Brand’s Lecture on L2 Scaling — Interoperability with Shared State at the Liquidity 2020 conference (sign-in required).
¹Further down the road, this will likely be one of a few deployment options. We envision a world where different applications may well have different preferences, in this regard.
L2 互操作性意味着允许用户以最小的 L1 摩擦在 L2 系统之间转移资金。
建议的 L2 互操作性解决方案依赖于我们之前建议的条件交易 (Tx) 加密原语
。
StarkEx 2.0（2020 年 11 月）将使用链上
条件 Txs 提供 L2-L1 互操作性（快速提款）。
StarkEx 3.0（2021 年 2 月）将使用链下
条件 Txs 提供跨 StarkEx 系统的 L2-L2 互操作性。
第 2 层 (L2) 扩展解决方案正在迅速发展。主网上已经有多个有效性证明系统，测试网上也有欺诈证明系统。L2 解决方案解决了可扩展性问题，但这样做是有代价的：它们可能会破坏或削弱我们在严格地在 L1 上运行时所期望的各种特性。我们不指望一种 L2 解决方案来统治所有这些：需要扩展的应用程序的需求是多种多样的。应用程序将从丰富的 L2 设计空间中挑选解决方案。
在继续之前，让我们提供两个重要术语的定义：
互操作性
：允许用户有效地将资金从 app1（Origin 环境）转移到 app2（Destination 环境）的能力。
可组合性
：发送涉及 app_1、app_2、...、app_n 操作的 tx 的能力。
注意：可组合性将是稍后单独发布的主题。
除了这些松散的定义之外，我们还将依赖 Conditional-Tx 的增强版本，这是一个重要的原语，它将增强互操作性。
这是一个加密构建块（我们首先在此处讨论），用于实现无许可区块链的互操作性。Conditional-Tx 是一种以发生某些事件（例如支付、状态更改）为条件的交易。从概念上讲，我们在 Origin 环境中定义了一个 Conditional-Tx，一旦它的条件在另一个环境（通常是 Destination 环境）中得到满足，它就会变得有效。
如果没有更好的解决方案，用户总是能够天真地将资金从 Origin L2 转移回 L1，然后从那里转移到 Destination L2。这种幼稚的方法既缓慢又昂贵，并且随着互操作性需求的增长将变得更加缓慢和昂贵。我们需要做得更好。特别是，我们计划采用以下逐步方法。
快速取款解决了用户需要将资金从 L2 系统 StarkEx 快速提取回 L1 的问题。这不仅仅是针对用户自己的 L1 地址，而是针对 L1 上的任何目的地，例如 Compound、Aave 等。重要的是，它允许用户在“区块链时间”提取资金，而与 StarkEx 证明批次的频率无关的交易。
用例：Alice 希望将 1 ETH 从她在 L2 上的 dYdX 账户转移到她的 L1 地址。
参与者：
https://miro.medium.com/max/1400/0*BJh-4u1Jn6olaN07
图 1：快速提款流程
流程：（1）Alice 给 LP 一个 1 ETH 的条件 Tx（+ LP 的费用），条件是 LP 将 1 ETH 转移到 Alice 的 L1 地址。(2) LP 在 L1 上向 Alice 付款后，Conditional Tx 生效，并且 (3) LP 将其提交给 Operator，以包含在它证明的下一批中。(4) 一旦下一个证明提交到 L1 并在那里验证，LP 的 L2 余额反映了来自 Alice 的资金转移。定期重新平衡：LP 需要定期从其 L2 账户中积累的资金中补充其日益减少的 L1 账户中的资金。
第一个 StarkEx 部署将分别托管一个应用程序。在这个阶段，我们希望允许用户在这些不同的应用程序之间快速转移资金。就像快速提款一样，我们希望最大限度地减少用户的链上成本，并让他们不必等待下一批被证明。
用例：Alice 希望将 1 ETH 从她的 dYdX 账户 (L2_1) 转移到她在 (L2_2) 上的 DeversiFi 账户。
参与者：
图 2：链下条件 Tx 流程
流程：（1）Alice 在 L2_1 中为 LP 提供 1 个 ETH（+ LP 费用）的签名条件 Tx，条件是 LP 将 1 个 ETH 转移到 Alice 的 L2_2 账户。(2) LP 在 L2_2 上向 Alice 支付款项；(3) 包含该付款的批次由 L2_2 运营商证明，并在 L1 上进行验证。在 L1 上接受该批次后，Conditional Tx 变为有效，并且 (4) LP 将其提交给 L2_1 Operator，以包含在它证明的下一个批次中。(5) 一旦L2_1 的下一批被证明并提交给L1 进行验证，LP 的L2_1 余额就反映了Alice 的资金转移。
定期重新平衡：LP 需要定期重新平衡其 L2_1 和 L2_2 中的资金，具体取决于这两个系统中的资金净流量。
支持互操作性的主要成本将是支付 LP 的资本成本；请注意，他们的资本成本跨越了一个非常有限的时间范围，即从向用户提供流动性到运营商处理下一批产品之间的时间。我们预计这个时间范围从几个小时（最多）开始，然后随着吞吐量（跨所有 StarkEx 应用程序）的增加而减少到证明生成时间（分钟）。
通过允许跨任何 L2 解决方案（无论是有效性系统还是防欺诈系统（Optimistic Rollups，Plasma））转移资金，扩展第二阶段。值得提醒的是，OR 系统在支持使用 LP 的互操作性解决方案时将面临固有的资本效率劣势（请参阅此处）
我们现在阐明我们所依赖的信任模型。
对于用户完全不信任。
对于 LPLP 需要信任运营商（在 Origin 环境中）以在下一批处理中包含其有效的条件 Tx，即不审查它们。可以通过多种方式删除此信任要求。如果运营商没有及时处理 LP 的 Conditional Tx，LP 可以：
有关更多信息，请观看 Tom Brand 在 Liquidity 2020 会议上关于 L2 扩展的讲座——与共享状态的互操作性（需要登录）。