Fast Withdrawals In Optimistic Rollups — Part 2
Note: We have written several articles related to cross-layer transfer, and the below list will help the readers to navigate through them quickly.
An Introduction to Cross Layer Transfer
Fast Withdrawals In Optimistic Rollups — Part 1
This post is the second part of our Fast withdrawal in optimistic rollup series, where we discuss possible ways to reduce withdrawal delay. If you haven’t read Part 1 of this series, it won’t be easy to follow along with Part 2. Part 1 gives you a fair idea about the problem that we are trying to solve.
QUICK RECAP
Let’s begin with a quick nutshell.
- In Rollups, Data availability of layer 2 transactions are ensured by publishing data on Ethereum.
- A sequencer “rolls up” the layer 2 transactions as a batch and publishes them to a layer 1 contract (Canonical Transaction Chain).
- A FIFO queue is also present to publish data to CTC. The queue is used if the user wants to make a transaction from L1 to L2 (e.g., Moving asset from layer 1 to layer 2), or when the sequencer censors its users (i.e. doesn’t include their published transactions in a batch)
- Users use token bridges to transfer assets across layer 2 rollups and the base layer. These token bridges make L1/L2 communication with the help of Messenger contracts.
- The deposits are usually instant, but the withdrawal takes time due to the fraudproof window.
- We identified that anyone could verify the batches logged into a CTC and it leads us to the clue for the fast withdrawal.
We appreciate the work done by MakerDAO in initiating the talks related to the fast withdrawal mechanism in optimism. Their thoughts also influenced us to figure out an optimal fast withdrawal architecture for the Tokamak network.
Liquidity Provider Assisted Fast Withdrawal
Let’s try to reduce the withdrawal delay by introducing a naive scheme. We will try to analyze how this scheme works and discuss some potential drawbacks related to it. Eventually, we will build on top of these concepts and introduce newer techniques to solve the problem.
Okay, the most simple and easiest one for reducing the withdrawal delay is introducing liquidity providers(LP). Like we said before, these liquidity providers can verify the outcome of the initiateWithdrawal transaction in the CTC. They can do it by running a verifier node (or full L2 Node) and applying the CTC transactions to the local state. So, the liquidity providers can ascertain whether a transaction will succeed or has a chance to get disputed in the fraud proof window.
The liquidity provider can either reject or accept the user request for instant withdrawal based on the verification status. If LP decides to serve the request, they provide liquidity to the user by charging a fee. The LP has a claim on the user tokens in the token bridge, which will get released to the LP after the fraud proof window is over. It’s a win-win situation for both the user and LP.
The below GIF helps you understand this scheme.
You should also notice that for serving a withdrawal request,the liquidity provider doesn’t need to wait for the sequencer to publish the state root for a transaction batch. Even if the sequencer publishes a false state root, the liquidity provider doesn’t need to worry since the sequencer claim will get disputed by a verifier in the fraud proof window. So, the decisions made by the liquidity provider should be purely based on the transaction batches that are logged into the CTC. Any mistake made by the LP during the verification of CTC might result in fund loss for the LP.
Drawbacks
- Liquidity provision may be expensive for low liquidity tokens
- Chance for liquidity crunch during significant withdrawals
Unlimited Liquidity by MakerDAO
Liquidity crunch is going to be a significant drawback for our naive scheme. Low liquidity will affect the user experience and make the naive method not practical. Is there any way to improve this?
The liquidity provider can try to pool more liquidity from an unlimited liquidity source. Okay, Hold on, the term unlimited liquidity might be pretty confusing. Let’s try to understand w.r.t how Maker protocol (MakerDAO) can implement such a scheme. The Maker can provide cheap unlimited liquidity by minting DAI for one week ( something like a flash mint for one week). Users receive the newly minted DAI, and after one week, the DAI from the token bridge will be returned to the liquidity pool and burned. Even though we mentioned it as unlimited liquidity, please note that a valid withdrawal request backs the DAI minting unless the system fails.
DAI minted without valid collateral will result in more DAI in circulation, affecting the DAI holders. We need to address two main critical points if we want to improve this scheme.
- Can we introduce a new mechanism to improve the verification of the withdrawal requests in the CTC?
- Can we shift the risk from DAI holders to MKR holders in the event of validation failure?
Please note that unlike in Maker, the Tokamak network doesn’t have the provision to mint new TONs.
Can Oracles verify the CTC?
Instead of the liquidity providers verifying the CTC, the previous scheme can be improved by introducing Oracles in the network to validate the transaction in the Canonical Transaction Chain. The tokens escrowed in the token bridge will be released and given to the user once the oracle confirms the genuineness of the withdrawal request.
But, please be aware of the potential danger in this scheme. If by chance, the oracle fails, then this architecture would lead to double spend. Let’s try to understand it with an example.
Suppose, let’s assume Alice has a total of 100 ABC tokens in Layer 2 optimism. She sends these 100 ABC tokens to Bob in layer 2, and then later, she initiates a withdrawal request of 100 ABC tokens to layer 1. Clearly, she is trying to perform double-spending
- Transfer Request
2. Withdrawal Request
At first, a transfer() request will be logged into the CTC and then later a withdrawalRequest(). The second transaction should fail since it is an attempt to double spend the tokens. In a standard scenario, the token bridge would wait for the sequencer to publish the state root and wait for one week (fraud proof window). It will be evident that the initiateWithdrawal() transaction will not succeed, and the bridge will not release tokens to the user.
Key takeaway : Having a initiateWithdrawal() request on CTC is not enough evidence to release tokens from the token bridge. It should be made sure that the initiateWithdrawal() will succeed and then release tokens from the bridge.
Our current scheme is that the oracle executes the CTC transactions and validates the withdrawal requests. Based on the response from Oracle, the bridge releases tokens to users. If the oracle fails, then double spend can happen and Alice will be able to spend 100 ABC tokens in layer 2 and withdraw 100 tokens in layer 1. It forces the ABC holders to take a loss.
Coming back to our MakerDAO example, if the double-spend happens for DAI tokens due to oracle failure, the DAI holders should take the loss.
So, how can we shift the risk from DAI holders to MKR holders (responsible for the Maker protocol’s governance)?
Who will take the loss if the Oracle fails?
Now you have understood that it is not a clever technique to release the tokens directly from the bridge upon withdrawal verification.
Let’s try to analyze how Maker introduced the Maker vault to solve this problem.
A user who wants to perform instant withdrawal would request the token bridge for assistance. The bridge interacts with the Maker vault, and the Maker vault would ask the oracle to verify the genuineness of the withdrawal request. If the oracle confirms that the withdrawal request is genuine, the Maker Vault will mint new DAIs and give them to the user. As a result, a debt is created in the Maker vault, which will get repaid when the token bridge gives back the escrowed DAI to the vault (after fraud proof window).
What would happen if the oracle fails in this architecture?
As you already know, an oracle failure would result in double-spending, but the critical point to understand here is who will take the loss during such an event. Here, the Maker Vault (governed by Maker protocol) minted the new DAI, assuming there is valid collateral that backs the request(withdrawal claim). As a result, the Maker protocol and the MKR holders have to bear the loss if there is no valid collateral for the freshly minted DAI. So, it is the responsibility of the Maker protocol to define a robust oracle system for the network.
Key Takeaway : Notice how the risk shifted from DAI holders to MKR holders.
Now can we adopt such a system in the Tokamak network?
As you might have already figured out, we don’t have a provision to directly mint TON using a vault and then share it with the user. Also, we don’t have a stable coin like DAI in our system. It forces us to pool the TON liquidity from other sources to serve the user request. In subsequent posts, we will describe a more detailed overview of how we tackle this in the Tokamak network.
Is there any scope to improve this scheme further? You might have noticed that whenever a user needs to perform an instant withdrawal, the token bridge needs to interact with the Maker vault and ask to mint DAI. These frequent calls are actually gas consuming, and next, we will try to improve on this scope.
Improving design by tokenizing the Withdrawal claims
In this version, the user can tokenize the withdrawal claims and use them for instant withdrawals. The user can now interact directly with a minter component instead of going to the bridge or vault and request the minter to tokenize the withdrawal request. The minter could request the oracle to verify the genuineness of the withdrawal request and then tokenize the withdrawal requests. The below image helps you understand how this scheme can work in Maker protocol.
The user can now use these tokenized claims (fDAI) to swap it across a secondary market or else collect it and then use it as collateral with the vault. The vault accepts the fDAI collateral and mints the DAI for the user. The user can also collect all the tokenized claims and do a bulk mint with the vault, which costs less gas.
Key Takeaway: Withdrawal requests can be tokenized, and they can be used as collateral to receive the desired token.
In the upcoming posts, we will discuss the schemes that are best suited for the Tokamak network.
