原文：Conditional Transfers — The Key to Interoperability 作者：Michael Riabzev, Ohad Barta, Tom Brand 翻译：「StarkNet 中文」社区

这篇文章将介绍 StarkEx 为支持快速提款而提出的解决方案：在区块链时间内从 L2 提取资金至任意 L1 地址的功能。该解决方案与 L2 运营节点生成有效性证明的频率无关。

快速提款功能已经在以太坊主网的 StarkEx 上运行（StarkEx 2.0 于 2020 年 12 月启动），并为 DeversiFi 和 dYdX 的交易所提供支持。

以下解决方案可以应用于快速提款以外的广泛用例。让我们首先描述一下抽象的需求。

区块链使得 A 和 B 双方之间的信任变得可能。A 想发布一笔在特定条件满足时才能够执行的交易；而 B 希望在条件满足时不必再次获得 A 的许可就能直接执行 A 的交易。我们把支持此类交互模式的简单称为 「限定条件交易」（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。举个例子，如果 A 直接在以太链上转账 1 ETH 给 B（并未通过 Fact Registry 合约），那 CT 是不会满足执行前提的条件。

在上述例子中，Fact Registry 合约需要一个函数 transfer()，A 传入 B 的地址作为收款方。函数 transfer() 有两个作用：1）将需要转移的 ETH 发送给收款方；2) 保留对这笔转账的记录，比如说存储这笔转账参数（发送者、收款方、数额）的哈希值到合约的存储项中。Fact Registry 合约还带有一个 isValid() 这样的函数，它接收一个哈希值作为参数，在当且仅当参数是该合约记录的交易哈希值时返回一个布尔值 True。交易哈希值（在上述例子中为转移参数），被称为 Fact，它代表了事件的发生。向 Fact Registry 引入一个新的 Fact 的过程一般就被称为事实登记。

一笔 CT 签过名的链上事件有两个字段（实际上是这两个参数的哈希值）：（1）一个 Fact Registry 合约的地址；（2）执行交易前注册的 Fact。

StarkEx 会批量打包 L2 中的交易，并使用发送到链上的 STARK 证明来结算。如果某批次中包含 CT，且 StarkEx 将保证相关的 Fact 也已注册以结算批次；否则，整批交易都会回滚。

在本小节我们会提出一些应用场景，并描述 CT 如何应用其中。

在任何 L2 解决方案里，L2 到 L1 之间跨链转移资金的原生方法是完成 L2 状态更新，包括 L1 的提款交易。在 StarkEx 等基于有效性证明的系统中，当链上接受证明 L2 状态更新的有效证明时，就会发生最终性确定，一般需要 10 分钟。这就意味着，如果用户想要将资金从 L2 转移到 L1，就必须要等待。

快速提款的目的是解耦这种依赖性，并允许用户在「区块链时间」，即在一次以太坊交易中，无需信任地将资金提到 L1 上。

这该如何运作？如果 A 想从 L2 上提 1 ETH 到 L1，A 可以在 L2 上签署 CT，将 1 ETH 转移到流动性提供者（LP），条件是 LP 在 L1 上 把 1 ETH（扣除一些费用）转给 A。A 的 CT 只有在她首先在 L1 上获得资金时才能执行，因此她没有面临交易对手风险。让我们看一个简单的 Fact Registry 合约，该合约可以推进这种转移。

我们可以看到，合约中有一个应付的函数 Transfer()，它做了以下两件事

1. 将 ETH 的数量转移到地址

2. 将 kecack (amount, address, nonce) 注册为 true

由 A 签名的 CT 只有在 Fact kecack (1 ETH, Alice, nonce) 在 Fact Registry 中注册时才能执行。而在这笔交易中，只能存在于之前有发生过向 A 转移 1 ETH 的交易时被注册。A 可以在未获取信任的情况下提取 1 ETH 到自己的地址，只需要签名和 LP 的一笔以太坊交易。

类似的流程可以通过 L2 的 CT 交易捕获以下类型的事件：

• 如果 ETH 的价格下降到 1010 DAI（根据已知的预言机在链上的注册），A 出售 L2 上的 1ETH 换取 L1 上的 1000 DAI。

• 如果 B 在 A 选择的 dApp（如 Aave 或 Compound）中以 A 的名义存入 9.5 ETH，A 在 L2 上给 Bob 10 ETH。

• 如果 B 向 A 的 L2 dYdX 帐户中存入 9.5 ETH，A 在 DeversiFi 的 L2 上给 B 10 ETH。

CT 的第一个应用场景是快速提款，但 StarkEx 运营节点可以使用该基础构件实现许多 L2-L1 交互。

原文：Conditional Transfers — The Key to Interoperability 作者：Michael Riabzev, Ohad Barta, Tom Brand 翻译：「StarkNet 中文」社区

这篇文章将介绍 StarkEx 为支持快速提款而提出的解决方案：在区块链时间内从 L2 提取资金至任意 L1 地址的功能。该解决方案与 L2 运营节点生成有效性证明的频率无关。

快速提款功能已经在以太坊主网的 StarkEx 上运行（StarkEx 2.0 于 2020 年 12 月启动），并为 DeversiFi 和 dYdX 的交易所提供支持。

以下解决方案可以应用于快速提款以外的广泛用例。让我们首先描述一下抽象的需求。

区块链使得 A 和 B 双方之间的信任变得可能。A 想发布一笔在特定条件满足时才能够执行的交易；而 B 希望在条件满足时不必再次获得 A 的许可就能直接执行 A 的交易。我们把支持此类交互模式的简单称为 「限定条件交易」（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。举个例子，如果 A 直接在以太链上转账 1 ETH 给 B（并未通过 Fact Registry 合约），那 CT 是不会满足执行前提的条件。

在上述例子中，Fact Registry 合约需要一个函数 transfer()，A 传入 B 的地址作为收款方。函数 transfer() 有两个作用：1）将需要转移的 ETH 发送给收款方；2) 保留对这笔转账的记录，比如说存储这笔转账参数（发送者、收款方、数额）的哈希值到合约的存储项中。Fact Registry 合约还带有一个 isValid() 这样的函数，它接收一个哈希值作为参数，在当且仅当参数是该合约记录的交易哈希值时返回一个布尔值 True。交易哈希值（在上述例子中为转移参数），被称为 Fact，它代表了事件的发生。向 Fact Registry 引入一个新的 Fact 的过程一般就被称为事实登记。

一笔 CT 签过名的链上事件有两个字段（实际上是这两个参数的哈希值）：（1）一个 Fact Registry 合约的地址；（2）执行交易前注册的 Fact。

StarkEx 会批量打包 L2 中的交易，并使用发送到链上的 STARK 证明来结算。如果某批次中包含 CT，且 StarkEx 将保证相关的 Fact 也已注册以结算批次；否则，整批交易都会回滚。

在本小节我们会提出一些应用场景，并描述 CT 如何应用其中。

在任何 L2 解决方案里，L2 到 L1 之间跨链转移资金的原生方法是完成 L2 状态更新，包括 L1 的提款交易。在 StarkEx 等基于有效性证明的系统中，当链上接受证明 L2 状态更新的有效证明时，就会发生最终性确定，一般需要 10 分钟。这就意味着，如果用户想要将资金从 L2 转移到 L1，就必须要等待。

快速提款的目的是解耦这种依赖性，并允许用户在「区块链时间」，即在一次以太坊交易中，无需信任地将资金提到 L1 上。

这该如何运作？如果 A 想从 L2 上提 1 ETH 到 L1，A 可以在 L2 上签署 CT，将 1 ETH 转移到流动性提供者（LP），条件是 LP 在 L1 上 把 1 ETH（扣除一些费用）转给 A。A 的 CT 只有在她首先在 L1 上获得资金时才能执行，因此她没有面临交易对手风险。让我们看一个简单的 Fact Registry 合约，该合约可以推进这种转移。

我们可以看到，合约中有一个应付的函数 Transfer()，它做了以下两件事

1. 将 ETH 的数量转移到地址

2. 将 kecack (amount, address, nonce) 注册为 true

由 A 签名的 CT 只有在 Fact kecack (1 ETH, Alice, nonce) 在 Fact Registry 中注册时才能执行。而在这笔交易中，只能存在于之前有发生过向 A 转移 1 ETH 的交易时被注册。A 可以在未获取信任的情况下提取 1 ETH 到自己的地址，只需要签名和 LP 的一笔以太坊交易。

类似的流程可以通过 L2 的 CT 交易捕获以下类型的事件：

• 如果 ETH 的价格下降到 1010 DAI（根据已知的预言机在链上的注册），A 出售 L2 上的 1ETH 换取 L1 上的 1000 DAI。

• 如果 B 在 A 选择的 dApp（如 Aave 或 Compound）中以 A 的名义存入 9.5 ETH，A 在 L2 上给 Bob 10 ETH。

• 如果 B 向 A 的 L2 dYdX 帐户中存入 9.5 ETH，A 在 DeversiFi 的 L2 上给 B 10 ETH。

CT 的第一个应用场景是快速提款，但 StarkEx 运营节点可以使用该基础构件实现许多 L2-L1 交互。