这篇文章介绍的是StarkEx提供的快速取款的解决方案：在区块链时间内从L2提取资金到任何L1地址，并且该解决方案与L2运营商生成有效性证明的频率无关。StarkEx是L2扩容技术服务商StarkWare的二层交易应用。
目前，快速取款功能已经在StarkEx的以太坊主网上运行，并为DeversiFi和dYdX的交易所提供支持。
下面的解决方案可以应用于行业内广泛的用例，首先我们来看场景需求。
场景需求
区块链允许Alice和Bob两方之间的无信任交互。Alice可能希望发布一个只有在某个条件事件发生时才能执行的交易；Bob希望在满足条件后执行Alice的交易，而无需再次获得她的批准。我们将这样的规范称为条件事务(CT)。
在L1上实施CT很简单，因为智能合约可以加强事件和交易执行之间的耦合。也就是事件发生自动执行。并且把执行条件固定。但当迁移到L2系统时，这将成为一个挑战。例如，在StarkEx中，签名者将签署的交易传递给运营商，运营商负责执行它，在满足请求的条件之前，没有什么可以阻止运营商执行这个交易。
在这篇文章中我们提到的在L2上指定的CT，它依赖于L1事件。也就是说，CT确保操作员只有在发生某些链上事件时才能执行签名交易。如果我们再添加一个CT，它依赖于另一个L2事件上的事件，这将实现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在L1上转移1ETH给Alice。
Alice的CT只有在她首先在L1上获得资金时才能执行，因此她也不会面临交易对手风险。
更多其他用例
类似的流程可以通过L2CT事务捕获以下类型的事件，及为以下提供证明，就可以在L1上进行一些关联操作，例如：
ETH的价格跌至1010DAI，Alice想在L2上以1000DAI的价格出售她在L2上的1ETH。
Alice希望在L2上给Bob10ETH，Bob在她选择的dApp中以Alice的名义存入9.5ETH。
Alice想在DeversiFi的L2上为Bob提供10ETH，Bob在dYdX的L2中将9.5ETH存入Alice的账户。
这些其他操作用例代表着虽然CT的第一个用例是快速提款，但StarkEx运营商可以使用这个方式实现更多L2-L1交互，用来丰富产品功能。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。