金色观察｜Layer1与Layer2互操作性举例：条件事务

这篇文章介绍的是StarkEx提供的快速取款的解决方案：在区块链时间（即交易时间内或出块时间内）内从L2提取资金到任何L1地址，并且该解决方案与L2运营商生成有效性证明的频率无关。StarkEx是L2扩容技术服务商StarkWare的二层交易应用。

目前，快速取款功能已经在StarkEx的以太坊主网上运行（从StarkEx2.0开始，2020年12月），并为DeversiFi和dYdX的交易所提供支持。

下面的解决方案可以应用于行业内广泛的用例，首先我们来看场景需求。

场景需求

区块链允许Alice和Bob两方之间的无信任交互。Alice可能希望发布一个只有在某个条件事件发生时才能执行的交易；Bob希望在满足条件后执行Alice的交易，而无需再次获得她的批准。我们将这样的规范称为条件事务(CT)。

在L1上实施CT很简单，因为智能合约可以加强事件和交易执行之间的耦合。也就是事件发生自动执行。并且把执行条件固定。但当迁移到L2系统时，这将成为一个挑战。例如，在StarkEx中，签名者将签署的交易传递给运营商，运营商负责执行它，在满足请求的条件之前，没有什么可以阻止运营商执行这个交易。

在这篇文章中我们提到的在L2上指定的CT，它依赖于L1事件（即L2|L1）。也就是说，CT确保操作员只有在发生某些链上事件时才能执行签名交易。如果我们再添加一个CT，它依赖于另一个L2事件（即L21|L22）上的事件，这将实现StarkEx实例和StarkNet之间的互操作性。

下面，我们将此类链上事件的概念形式化，并了解如何将它们用于StarkEx中的CT。

条件事务

CT使用FactRegistry合约来跟踪链上事件。特别是，除非在事实登记处注册，否则CT不能以事件为条件。例如，如果Alice直接在Ethereum上向Bob转账1ETH，则没有可以用作CT的链上事件。

也就是需要进行一次单独的定义某些事件为条件。

在上面的例子中，FactRegistry合约需要一个函数transfer()，Alice使用Bob的地址作为接收者参数调用该函数。

transfer()函数做两件事：(a)将传输的ETH发送给接收者，(b)保留传输的记录，例如合约中存储传输参数（发送者、接收者和金额）的哈希值。

FactRegistry也有一个isValid()函数，它接收一个哈希值作为参数，并返回一个布尔值——True当且仅当它是这个合约记录的交易哈希值。

交易的哈希（上面的例子中是传输参数）被称为事实—代表事件的发生。向事实登记处引入新事实的过程称为事实登记。

在CT中签署的链上事件包会含两个字段（实际上是哈希）：(a)一个事实登记合约的地址，(b)一个应该在执行交易之前注册的事实。

StarkEx中的条件交易

StarkEx对交易进行批量处理，并使用单个STARK证明在链上进行结算。如果批次中的交易之一是CT，StarkEx将确保关联的Fact确实已注册登记，以便对批次进行结算；否则，整个批次将被还原。

条件事务示例

快速提款

在任何L2解决方案中，在L2到L1之间转移资金的理想方法是完成L2状态更新和L1上的提款交易。

在基于有效性证明的系统中，如StarkEx，L2状态更新的最终确定发生在链上接受证明它的有效证明时，这通常需要10分钟。这意味着如果用户想要将他们的资金从L2转移到L1，他们将被迫等待。

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

这将如何运作？如果Alice想从L2提取1ETH到L1，Alice可以签署CT将1ETH转移到L2上的流动性提供者（LP），条件是LP在L1上转移1ETH（减去一些费用）给Alice。

Alice的CT只有在她首先在L1上获得资金时才能执行，因此她也不会面临交易对手风险。

更多其他用例

类似的流程可以通过L2CT事务捕获以下类型的事件，及为以下提供证明，就可以在L1上进行一些关联操作，例如：

ETH的价格跌至1010DAI（由已知在链上注册预言机提供数据），Alice想在L2上以1000DAI的价格出售她在L2上的1ETH。

Alice希望在L2上给Bob10ETH，Bob在她选择的dApp（例如Aave或Compound）中以Alice的名义存入9.5ETH。

Alice想在DeversiFi的L2上为Bob提供10ETH，Bob在dYdX的L2中将9.5ETH存入Alice的账户。

这些其他操作用例代表着虽然CT的第一个用例是快速提款，但StarkEx运营商可以使用这个方式实现更多L2-L1交互，用来丰富产品功能。