這篇文章介紹的是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互動，用來豐富產品功能。
