transfer()函数做两件事：(a)将传输的ETH发送给吸收者，(b)保存传输的记录，譬喻合约中存储传输参数（发送者、吸收者和金额）的哈希值。
也就是需要举办一次单独的界说某些事件为条件。
条件事务示例
这些其他操纵用例代表着固然CT的第一个用例是快速提款，但StarkEx运营商可以利用这个方法实现更多L2-L1交互，用来富厚产物成果。
快速提款
在基于有效性证明的系统中，如StarkEx，L2状态更新的最终确定产生在链上接管证明它的有效证明时，这凡是需要10分钟。这意味着假如用户想要将他们的资金从L2转移到L1，他们将被迫期待。
生意业务的哈希（上面的例子中是传输参数）被称为事实—代表事件的产生。向事实挂号处引入新事实的进程称为事实挂号。
这篇文章先容的是StarkEx提供的快速取款的办理方案：在区块链时间（即生意业务时间内或出块时间内）内从L2提取资金到任何L1地点，而且该办理方案与L2运营商生成有效性证明的频率无关。StarkEx是L2扩容技能处事商StarkWare的二层生意业务应用。
在L1上实施CT很简朴，因为智能合约可以增强事件和生意业务执行之间的耦合。也就是事件产生自动执行。而且把执行条件牢靠。但当迁移到L2系统时，这将成为一个挑战。譬喻，在StarkEx中，签名者将签署的生意业务通报给运营商，运营商认真执行它，在满意请求的条件之前，没有什么可以阻止运营商执行这个生意业务。
在上面的例子中，FactRegistry合约需要一个函数transfer()，Alice利用Bob的地点作为吸收者参数挪用该函数。
Alice的CT只有在她首先在L1上得到资金时才气执行，因此她也不谋面对生意业务敌手风险。
下面，我们将此类链上事件的观念形式化，并相识如何将它们用于StarkEx中的CT。
在这篇文章中我们提到的在L2上指定的CT，它依赖于L1事件（即L2|L1）。也就是说，CT确保操纵员只有在产生某些链上事件时才气执行签名生意业务。假如我们再添加一个CT，它依赖于另一个L2事件（即L21|L22）上的事件，这将实现StarkEx实例和StarkNet之间的互操纵性。
区块链答允Alice和Bob两方之间的无信任交互。Alice大概但愿宣布一个只有在某个条件事件产生时才气执行的生意业务；Bob但愿在满意条件后执行Alice的生意业务，而无需再次得到她的核准。我们将这样的类型称为条件事务(CT)。
CT利用FactRegistry合约来跟踪链上事件。出格是，除非在事实挂号处注册，，不然CT不能以事件为条件。譬喻，假如Alice直接在Ethereum上向Bob转账1ETH，则没有可以用作CT的链上事件。
FactRegistry也有一个isValid()函数，它吸收一个哈希值作为参数，并返回一个布尔值——True当且仅当它是这个合约记录的生意业务哈希值。
快速取款的目标是解耦这种依赖性，并答允用户在“区块链时间”（即在一次以太坊生意业务中）无需信任地将资金提取到L1。
这将如何运作？假如Alice想从L2提取1ETH到L1，Alice可以签署CT将1ETH转移到L2上的活动性提供者（LP），条件是LP在L1上转移1ETH（减去一些用度）给Alice。
场景需求
ETH的价值跌至1010DAI（由已知在链上注册预言机提供数据），Alice想在L2上以1000DAI的价值出售她在L2上的1ETH。
今朝，快速取款成果已经在StarkEx的以太坊主网上运行（从StarkEx2.0开始，2020年12月），并为DeversiFi和dYdX的生意业务所提供支持。
Alice但愿在L2上给Bob10ETH，Bob在她选择的dApp（譬喻Aave或Compound）中以Alice的名义存入9.5ETH。
在任何L2办理方案中，在L2到L1之间转移资金的抱负要领是完成L2状态更新和L1上的提款生意业务。
在CT中签署的链上事件包会含两个字段（实际上是哈希）：(a)一个事实挂号合约的地点，(b)一个应该在执行生意业务之前注册的事实。
StarkEx中的条件生意业务
StarkEx对生意业务举办批量处理惩罚，并利用单个STARK证明在链长举办结算。假如批次中的生意业务之一是CT，StarkEx将确保关联的Fact确实已注册挂号，以便对批次举办结算；不然，整个批次将被还原。
条件事务
Alice想在DeversiFi的L2上为Bob提供10ETH，Bob在dYdX的L2中将9.5ETH存入Alice的账户。
雷同的流程可以通过L2CT事务捕捉以下范例的事件，及为以下提供证明，就可以在L1长举办一些关联操纵，譬喻：
下面的办理方案可以应用于行业内遍及的用例，首先我们来看场景需求。
更多其他用例
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
