原文标题：《引介 | 有条件转账 —— 实现 L1-L2 互操作性的关键》
撰文：StarkWare
翻译：阿剑

本文意在讲解 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() 函数，接受一条哈希值作为参数，返回一个布尔值 —— 如果该条输入的哈希值等于合约中记录的某条哈希值，就返回 (责任编辑：admin)