How does Layer 2 achieve fast withdrawals? Let's learn about "conditional transactions."

This article was published on Ethereum Enthusiasts, authored by Starkware, translated by A Jian.

This article aims to explain the solution proposed by StarkEX to support Fast Withdrawal (withdrawing from Layer-2 to any Layer-1 address within a block time). The advantage of this solution is that its speed is completely independent of the speed at which the L2 operator generates validity proofs.

The Fast Withdrawal module has been running on the Ethereum mainnet's StarkEx (since the release of StarkEx 2.0 in October 2020) and has empowered the DeversiFi exchange and dYdX exchange.

The solution we will explain below has many use cases beyond just fast withdrawals. Let's first understand what the requirements are.

Requirements

Blockchain enables trustless interactions between two parties. Alice wants to execute a transaction that can only be performed when specific conditions are met; Bob wishes to execute Alice's transaction directly when the conditions are satisfied, without needing to obtain Alice's permission again. We refer to the components that support such interaction modes as "Conditional Transactions (CT)."

Implementing CT on L1 does not require any ingenious ideas, as smart contracts can ensure the coupling of time and transaction execution. However, if it needs to be implemented on L2, it becomes a challenge. For example, in StarkEx, after the transaction initiator signs the transaction and passes it to the operator, the operator is responsible for executing the transaction. But how can you prevent the operator from executing the transaction before the required conditions are met?

In this article, we will focus on implementing CT on L2 that relies on L1 events (denoted as L2 | L1). In other words, this CT must ensure that the operator can only execute a signed transaction after a certain on-chain event occurs. Furthermore, we will introduce a CT that relies on an event from another L2 (denoted as L21 | L22) to support interoperability between StarkEx instances and within StarkNet.

Next, we will formalize the concept of on-chain events and see how we can utilize them in CT on StarkEx.

Introduction to Conditional Transactions

Registration of On-Chain Events

CT uses a Fact Registry contract to track on-chain events. In fact, only events registered in a Fact Registry contract can "unlock" CT. For example, if Alice directly transfers 1 ETH to Bob on the Ethereum chain (instead of through the Fact Registry contract), the CT cannot satisfy the execution prerequisites.

In the above case, the Fact Registry contract requires a function transfer(), where Alice inputs Bob's address as the recipient. The transfer() function does two things: (1) sends the ETH to the recipient; (2) saves a record of the transfer, such as storing the hash of the parameters related to this transfer (sender, recipient, amount) in the contract's storage. The Fact Registry contract also includes an isValid() function that accepts a hash as a parameter and returns a boolean value ------ if the input hash equals a recorded hash in the contract, it returns True. Thus, the hash recorded in the contract can serve as proof of a fact (that a certain event has occurred). This process of introducing a new fact into the Fact Registry contract is commonly referred to as "fact registration."

A signed CT contains the fingerprint of the on-chain event with two fields (actually the hashes of these two parameters): (1) the address of a Fact Registry contract; (2) the fact that should be recorded in the aforementioned contract.

StarkEx Conditional Transactions

StarkEx batches transactions from Layer-2 and uses a STARK proof sent to the chain to settle these transactions. If a batch contains CT, StarkEx will ensure that the relevant facts have been registered to settle the batch of transactions; otherwise, the entire batch will roll back.

Examples of Conditional Transactions

In this section, we will present some application scenarios and indicate how CT can be used in these scenarios.

Detailed Example - Fast Withdrawal

In any L2 solution, the most basic method of withdrawing funds from L2 to L1 is to finalize an L2 state update (which includes a withdrawal transaction). In validity proof-based systems (like StarkEx), finalizing an L2 state update requires submitting a corresponding validity proof on-chain, which generally takes about 10 minutes. This means that if users use this method to withdraw, they must wait at least 10 minutes.

The purpose of Fast Withdrawal is to decouple this (withdrawal dependency on L2 state updates), allowing users to trustlessly withdraw funds within "block time," just like using a regular Ethereum contract.

So what is the process? If Alice wants to withdraw 1 ETH from L2 to L1, she can sign a CT on L2 to transfer 1 ETH to a liquidity provider (LP), on the condition that the LP transfers 1 ETH (minus some fees) to Alice on L1. Alice's CT can only be executed after she receives the transfer on L1, so she does not face counterparty risk.

Let's look at a simple Fact Registry contract that can assist CT:

We can see that this contract has a payable function transfer(), which has two functionalities:

1. Transfer a certain amount of ETH to a specific address
2. Register keccack(amount, address, nonce)

Alice's issued CT can only be executed after keccack(1 ETH, Alice, nonce) is registered in the Fact Registry. And this fact can only be successfully registered after the transfer of 1 ETH to Alice has occurred. Alice can trustlessly withdraw 1 ETH, and the entire process only requires her signature and the transaction initiated by the LP on the Ethereum chain.

More Application Scenarios

Similar processes can capture the following types of events, allowing L2's CT to have more uses, such as:

• If the price of ETH drops to 1010 DAI (which can be registered on-chain through a known information input service), Alice wishes to sell 1 ETH on L2 for 1000 DAI on L1.

• Alice wishes to give Bob 10 ETH on L2, as long as Bob deposits 9.5 ETH in Alice's name in a dApp specified by Alice (such as Aave or Compound).

• Alice wishes to give Bob 10 ETH on DeversiFi's L2, as long as Bob deposits 9.5 ETH into Alice's account on dYdX's L2.

Conclusion

The first use of CT is fast withdrawal, but StarkEx operators can use this component to achieve many types of L2-L1 interactions.