有条件转账 —— 实现 L1-L2 互操作性的关键

本文意在讲解 StarkEX 为支持快速取款（Fast Withdrawel）（在一个区块时间内从 Layer-2 中取款到任意 Layer-1 地址）而提出的解决方案。本方案的优点在于，其速度完全独立于 L2 的运营者生成有效性证明的速度。

快速取款模块已经运行在以太坊主网的 StarkEx 上（自 2020 年 10 月 StarkEx 2.0 发布始），并且赋能了 DeversiFi 交易所和 dYdX 交易所。

而下文我们讲解的方案除了快速取款以外，还有非常多的使用场景。我们先来了解一下需求是什么。

需求

区块链使得两方之间的免信任交互成为可能。Alice 想发布一笔仅在特定条件满足时才能执行的交易；Bob 希望在条件满足时能直接执行 Alice 的交易、不必再次获得 Alice 的许可。我们把支持此类交互模式的元件称作 “有条件交易（Conditional Transaction，CT）”。

在 L1 上实现 CT 不需要什么奇思妙想，因为智能合约可以保证时间和交易执行的耦合。但如果要求在 L2 中实现，那就有些挑战了。比如，在 StarkEx 中，交易发起人签名之后把交易传递给运营者，后者有责任来执行这笔交易，可是你用什么办法来阻止运营者在所需条件满足之前就执行这笔交易呢？

在本文中，我们只聚焦于在 L2 上实现依赖于 L1 事件（记作 L2 | L1）的 CT。也就是说，这种 CT 要能保证，运营者仅能在某个 链上事件 发生之后才能执行某笔签过名的交易。更进一步，我们将加入一种依赖于另一个 L2 中事件（记作L21 | L22 ）的 CT，从而支持 StarkEx 实例之间以及 StarkNet 中的互操作性。

下面，我们来形式化这种链上事件的概念，看看我们如何在 StarkEx 中的 CT 如何利用它。

有条件交易简介

链上事件的注册

CT 使用了 Fact Registry 合约来跟踪链上事件。实际上，只有在一个 Fact Registry 合约中注册了的事件，才能 “解锁” CT。举个例子，如果 Alice 直接在以太坊链上转账了 1 ETH 给 Bob（而不是通过 Fact Registry 合约），那 CT 是不能因此满足执行前提的。

在上面这个案例中，Fact Registry 合约需要一个函数 transfer()，Alice 传入 Bob 的地址作为收款方。transfer() 函数做两件事：（1）把需要转移的 ETH 发送给收款方；（2）保存对这笔转账的记录，比如存储这笔转账相关参数（发送者、收款方、数额）的哈希值，到合约的存储项中。Fact Registry 合约还带有一个 isValid() 函数，接受一条哈希值作为参数，返回一个布尔值 —— 如果该条输入的哈希值等于合约中记录的某条哈希值，就返回 True。如此，这个记录在合约中的哈希值，就可以当成是一个事实（某个事件已经发生）的证明。这个为 Fact Registry 合约引入一个新的事实的过程，通常称为 “事实注册”。

一笔签过名的 CT 所包含的链上事件的指纹有两个字段（实际上是这两个参数的哈希值）：（1）一个 Fact Registry 合约的地址；（2）上述合约中应当记录的事实。

StarkEx 有条件交易

StarkEx 会批量打包 Layey-2 中的交易，并使用一条发送到链上的 STARK 证明来结算这些交易。如果某一批次中包含 CT，StarkEx 将保证相关的事实已经注册，以便能清算该批交易；否则，整批交易都会回滚。

有条件交易的案例

在本部分，我们会提出一些应用场景，并指出 CT 如何能用在这些场景中。

详细案例 —— 快速取款

在任意 L2 方案中，最初级的从 L2 转出资金到 L1 中的办法便是终局化一次 L2 的状态更新（在该次更新中包含一笔取款交易）。在基于有效性证明的系统（比如 StarkEx）中，终局化一次 L2 的状态更新需要在链上提交一个相应（于此次更新）的有效性证明，一般来说需要 10 分钟。这就意味着，如果用户使用这种方式来取款，就不得不等待至少 10 分钟。

而快速取款的用意正是为了解耦这种（取款对 L2 状态更新的）依赖，让用户能够在 “区块时间” 内免信任地将资金取出，也即，就像使用普通的以太坊合约一样。

那到底是怎么个流程呢？如果 Alice 想要从 L2 中取出 1 ETH 到 L1，Alice 可以在 L2 上签名一条将 1 ETH 转移给流动性提供者（LP）的 CT，条件是 LP 在 L1 上转移 1 ETH（减去一些手续费）给 Alice。Alice 的 CT 仅能在她收到 L1 上的转账之后才能执行，所以她不会面临对手方风险。

我们来看一个能够协助 CT 的简易的 Fact Registry 合约：

我们可以看到这个合约有一个 payabe 函数 transfer()，它的功能有两个：

（1）转移一定数量的 ETH 到某个地址

（2）登记 keccack(amount, address, nonce)

Alice 签发的 CT 只有 keccack(1 ETH, Alice, nonce) 在 Fact Registry 中注册之后才能执行。而这个事实，也只有在给 Alice 的 1 ETH 转账发生了之后才能成功注册。Alice 可以无需信任地取出 1 ETH，整个过程只需她的前面，和 LP 在以太坊链上发起的一笔交易。

更多应用场景

类似的流程可以捕捉到下列类型的事件，从而 L2 的 CT 也可以有更多的用途，例如：

• 如果 ETH 的价格跌到了 1010 DAI（可以通过一个已知的信息输入服务在链上注册），Alice 希望在 L2 卖出 1 ETH，换回在 L1 上的 1000 DAI
• Alice 希望在 L2 上给 Bob 10 ETH，只要 Bob 以 Alice 的名义在 Alice 指定的 dApp （比如 Aave 或者 Compound）中存入 9.5 ETH
• Alice 希望在 DeversiFi 的 L2 上给 Bob 10 ETH，只要 Bob 在 dYdX 的 L2 中给 Alice 的账户存入 9.5 ETH

总结

CT 的第一种用途是快速取款，但 StarkEx 运营者可以用这一元件实现许多种类的 L2-L1 交互。

(完)

原文链接: https://medium.com/starkware/conditional-transfers-the-key-to-interoperability-2e1de044fb65 作者: StarkWare 翻译: 阿剑

本文首发于：https://ethfans.org/posts/conditional-transfers-the-key-to-interoperability