引子随着二层扩容方案如 Polygon、Arbitrum 等纷纷上线，以太坊二层生态呈现百花齐放的格局。与此同时，越来越多的 DeFi 协议宣布与 L2 方案进行合作，将其协议部署或迁移到 L2 上。不同 DeFi 协议对于扩容的需求不同，亦可能选择不同的 L2 方案。在这种趋势下，如何在 L1 和 L2 之间进行交互，或是在不同的 L2 之间高效地转移资金成为一个不小的问题。 例如，如果用户需要在 L2 的 dYdX 和 L2 的 DeversiFi 之间转移资金，他需要先将资金从 L2 的 dYdX 提取到 L1，再将资金从 L1 存入 L2 的 DeversiFi。这样，用户将不得不支付两次 gas 费，并耗费大量的等待时间。对于采用欺诈证明的 L2 方案，提现到 L1 的时间甚至可能长达数天。 为此，实现 L2 之间的互操作性是很有必要的。StarkWare 提出了 L2 互操作性 (Interoperability) 的概念，即在 L2 之间转移资金，且使得转移过程中在 L1 上的摩擦尽可能小。不同 L2 方案对于互操作性的设计思路各有不同，以下对 StarkEx、Loopring、Hermez 和 Connext 的互操作方案作简要的叙述。 StarkExStarkEx 定义了一个称为条件交易 (Conditional Transaction) 的原语，即一笔交易的生效与否，取决于其该交易的前置条件是否得到满足。 条件交易使用 Fact Registry 合约来监听链上事件。某个事件在使用条件交易之前必须首先在 Fact Registry 合约中「登记」。例如，如果 Alice 不经过 Fact Registry 合约，而是直接在以太坊链上给 Bob 转账了 1 ETH，则无法满足用于条件交易的事件。 如果 Alice 需要给 Bob 转账 1 ETH，则将 Bob 的地址作为参数传给 transfer() 函数，这时 transfer() 函数做两件事。首先把 1 ETH 转账给 Bob；其次，保存这笔转账的记录到合约的存储项中，例如保存发送方、收款方、转账金额的哈希值等信息。 isValid() 函数接受哈希值作为参数，如果输入哈希值等于 Fact Registry 合约中先前记录的某哈希值，则返回 True。这样一来，记录在合约中的哈希值可以当成是一个「Fact」，代表着某个事件已经发生。这个过程通常称为「Fact Registration」(本文译作事实登记)。 条件交易中一笔签过名的链上事件包含两个字段 (哈希值)：Fact Registry 合约的地址以及在执行这笔条件交易前应该登记的「Fact」。
上图展示了条件交易在 Fact Registry 合约的工作流程。在 StarkEx 的 zkRollup 中，如果某批次的交易中包含条件交易，将确保其相关的 Fact 是做过登记的，否则整批次的交易都将被回滚。 在 L1/L2 的互操作性中，条件交易有两个用例： (责任编辑：admin) |
