Plasma is one of the earliest and among the most popular L2 scaling solutions in Ethereum. Plasma scales Ethereum by moving transactions to a UTXO based “child-chain” (chch) on top of Ethereum. All transactions on the chch are secured as per the consensus of the underlying layer - Ethereum, and a unique Exit Game design construct ensures funds are always protected from any third party-intervention or manipulation by the chch operator.
Part of this exit game design is the crucial component - “withdrawal period”. When users wish to withdraw funds from the Plasma chch, they initiate an exit process, wherein the process includes a time-based challenge period, set to 7 days. During this period, other participants of the network can challenge the validity of the exits by submitting a proof. If no challenges are raised within the timeframe, the exit is considered valid, allowing funds to be safely transferred back to the Ethereum mainnet. Hence, the withdrawal period of 7 days enables to protect the integrity of the L2 by disallowing any faulty withdrawals, with the assumption that 7 days is enough time for a fellow participant to react and submit a proof.
While the 7 day withdrawal period is of the utmost necessity, the same can be perceived as a potential limitation for users who want quick access to funds. That a user would wait 7 days for obtaining their funds when they move from L2>L1 is an unrealistic expecation, and so, a solution in this regard is of the highest order to make Layer2’s synonymous with the ecosystem.
The following article is a proposal to solve the withdrawal problem, or propose a fast withdrawal method. This proposal has been written in the context of the MoreVp implementation of Plasma (OmiseGo), but can be freely applied to any other implentation or even an L2 with similar attributes.
The proposal
This is an approach to have a separate Vault + Exit Game with lower exit period which acts as an extension to the existing network. The main idea however, could be to have several of these Vaults that enable the possibility of having assets(utxo) which are exitable at different exit periods.
The main objectives of the VIP Vault are-
- Reduce Exit Period
which in turn would require reducing the UTXO throughput, and making the vault exclusive by
- Limiting Access(entry barrier) and/or incentivizing efficient output creations
Structure
The VIP Vault can be looked as a bucket within the existing framework and would require adding a vault with a new TxType and Registering an Exit Game for the TxType.
Assume-
VaultId 3
supports TxType 3,4
which supports spending, OutputType 3,4
Vault-3 has a lower exit-period and hence, a decoupling is necessary where the exit period is bound to the exit game for Txtype 3,4.
Depositing to the new vault will generate outputs of type 3 on the childchain. These outputs will be spendable through the Tx type 3. Note that an ETH output on Vault-1 is not the same as an ETH output on Vault-3, though they represent the same asset. TxType 3 uses the new exit game to exit.
Ideally, multiple Vaults with their own exit game independently exist while all the transactions are included in the same chch by the operator.
The prominent reason why someone with adequate funds would deposit in the vault would be to take advantage of fast withdrawing the remaining funds after doing transactions. Someone who would want to provide fast exitable outputs to other users should also find the Vault useful.
Limiting Access
Limiting access for the vault is necessary to keep the number of UTXOs low and -
- make sure there is enough time to challenge invalid exits
- make sure there is enough time for everyone to exit in a mass-exit scenario
Potential ways to reduce number of UTXOs-
Have a lower bound on the deposit amount to the vault. this would only allow certain VIP rollers to access the vault and get their fast-exitable outputs. But the UTXOs can still be broken to several other UTXOs, while this is a good method to limit access, there is still possibility of having UTXOs cross the limit
Have a lower bound on the size of UTXO for the vault. The outputs from the Tx should each be higher than the minimum value. For example, if the lower bound is 5 ETH, an output of size 50 ETH can maximally be split into 10 UTXOs and no further.
Have at least one output from a tx to be of a certain minimum value. Though this could still result in number of UTXOs crossing limit, it is still safer than the first method.
Additionally,
- Have dynamic fee for Tx similar to BTC, where the fee is dependent on the number of outputs. Making it cheaper to send 1 ETH in 1 UTXO than splitting it up into 10 UTXOs of 0.1 ETH each.
Reduce Exit Period
The exit period being the max of-
startExitTime + MFP
utxoCreationTime + MFP + REP
While we may not want to decrease REP too much, giving users time to react in a mass-exit scenario. A suitable time period can be caculated from the approximate expectations about the number of UTXOs for the vault
Approximately,
Time = (0.5 * N) / f
N = number of UTXOs
f = Fraction of a Block available
Reducing MFP, however should be better given there is a cap on the number of UTXOs and the watcher validates every MFP/2
Case 1
MFP is reduced to 4 days. REP is 7 days.
Outputs older than a week can exit within 4 days. Newer Outputs exit in 11 days from their creation. In case of mass exits users have 7 days to exit.
Watcher validates every 2 days.
Case 2
MFP is reduced to 4 days. REP is 3 days.
Outputs older than 3 days can exit within 4 days. Newer ouput exit in 7 days from their creation. In case of mass exits user have 3 days to exit.
Discarded Ideas
Allow optional exits through contract, since outputs sent to a contract cannot be double spent.
Reason: This will not be protected against operator double spends or operator selective withholding tx to the contract. The Operator can also exit an invalid tx using the contract.