Plasma withdrawal time is a major hindrance to adoption

#1

Using Plasma hands on, once me/my app users want to withdraw, having to wait for a day/week is too much of a lock in period. It causes enough discomfort to lose users.

With fast withdrawals, I see the following problems

  1. Liquidity lock in for 1 to 2 weeks could be too much for liquidity providers/makers due to crypto volatility.
  2. On top of this, liquidity is required across the many erc20 tokens.
  3. The cost and benefit for fast withdrawals needs to be balanced between what is beneficial for users and liquidity providers.

To me problems 1 & 2 appear to be quite challenging to solve while problem 3 is quite solvable. It appears this could be a big hindrance to adoption.

Is this correct? If so, how can this be solved?

#2

These are great points. I think your analysis of fast withdrawals is spot on.

1& 2 are indeed difficult to work around. For 1), the only way to shorten the liquidity lock is by shortening the withdrawal time & thereby increasing the online assumption / increasing the need for watch towers. Dan Robinson has suggested withdrawal times of less than 3 days–which could be considered. 2) is also troubling & fast withdrawals may only make sense for erc20 tokens with relatively high liquidity [Update: I’m much more bullish on fast withdrawals & think that they will generally provide minimal value loss during a transfer from one chain to another].

Agreed that 3) is the easiest as there is a built-in incentive for operators to buy withdrawals to provide users a better UX. However, I think longterm the solution to 1, 2, & 3 is avoiding withdrawals all together except in exceptional cases.

Ideally users will seldom need to withdraw from plasma. However, to achieve this plasma must be: 1) general purpose enough to support a broad variety of use cases, and 2) depositing into a plasma chain does not limit you to that chain’s plapps or liquidity.

With predicates we can support a large number of use cases, and with native cross chain transactions it won’t matter which plasma chain/operator you choose–plapps are not isolated to a single chain & liquidity is shared.

In its ultimate form you could almost think of depositing a coin into plasma as depositing a coin into Eth2. It’s a new scalable trusted enviornment. You shouldn’t want to leave the land of scalability unless something goes really wrong (eg. an operator is malicious). Still, if you really want to, you have the option. And only then will you need a fast withdrawal.

#3

@karl , greatly reducing the need for withdrawal, by onboarding users directly and keeping them on Plasma as much as possible is definitely a different and interesting perspective. The preconditions for that to happen are also helpful. I hope to think further along this path.

For the other method of using watchtowers,

. It seems like, for plasma use cases like a DEX with deposits and withdrawals, a watchtower(with increased online assumptions) based fast withdrawal might help.

. If watch towers were provided sufficient incentives to be continuously online, they can challenge the fraud immediately and can the withdrawal time then be reduced to an hour or lesser?

#4

Hey @Thilagavathy I forgot to mention an important point that may better address your concern.

It should be the case that a “fast withdrawal” is not actually “buying an exit”. Instead it is better to consider it an on chain swap between a plasma coin & an on chain asset. For instance one may send ETH to a smart contract & then on Plasma they are sent PETH.

This is important for fast withdrawals because it should be the case that this fast withdrawal problem is only an issue when more people want to exit plasma than enter. If there is a constant influx of new users, then that provides a natural pool of liquidity which may buy plasma exits.

So if I want to exit what I will do is I will list my PETH to be traded for an equal quantity of ETH, and then the next time someone wants to deposit into the plasma chain they first check if there’s any open PETH orders & swap with them instead of depositing a new coin. This reduces the fast exit problem without adding on any trust assumptions.

We have already specced out a predicate which handles these sorts of swaps.

#5

@karl , that’s a neat idea. It seems that a queue of non fraudulent withdrawals can be formed and matched based on the rate of influx of user deposits. This could provide for immediate to relatively better withdrawal speeds.

I had another roughly formed idea which I posted in a separate thread and am also giving it below

It is an attempt at an approximate mechanism to do fast withdrawals by incentivizing a set of watchers.

  1. Since Plasma can be considered an optimistic approach to consensus, we can say, the need for consensus arises when a user attempts to exit (rather than when a block is produced) and the set of watchers provide the consensus.

  2. A PoS based validator set is formed.

  3. From  the validator set, PoS elects a leader/operator for a period, who then produces blocks and earns rewards. The remaining validators are designated as watchers in that period. In different future periods, the previous watchers will get the opportunity to become the leader/operator to produce blocks and earn a reward. In a period in which a validator is a watcher, they can also earn from successfully challenging fraudulent bonded exits. This could provide sufficient incentive for watchers to be continuously online.

  4. Whenever a user attempts to exit, all the currently designated watchers in the validator set, verify it by explicitly communicating a “challenge” or “no challenge” as given below

  • If every watcher explicitly communicates a “no challenge”, the exit happens

  • If some watchers communicate “no challenge” and the other watchers challenge then If even one challenge is successful, the exit is prevented

  • If some watchers communicate “no challenge” and the other watchers challenge then If all challenges are unsuccessful, the exit proceeds

  • If a watcher does not communicate anything then the watcher can be slashed and/or evicted from the validator set based.

  1. A complete chain exit when a leader/operator produces an invalid block or a block is withheld, it can be handled using a separate function in which the leader/operator can be slashed. This step is not for fast withdrawals and It can follow the 1 or 2 week withdrawal process for all to exit the chain.

Is this correct?

#6

This construction is quite interesting because it does explore different security tradeoffs. I’d say that it straddles the tradeoff space between PoS sidechains & plasma. Here you have safety under N-1 byzantine validators/watchtowers without sacrificing liveness if you have byzantine watchtowers. Basically, this quote:

implies that if any one watchtower is honest then funds are safe. However, you don’t need to couple this safety with liveness as you do in normal BFT protocols (because this is already piggy-backing on Ethereum main-chain consensus). Plus, you do indeed achieve fast withdrawals as you set out to do.

This construction seems most interesting if it could be applied to arbitrary sidechain smart contracts. This way for state transitions that are hard to protect with a normal predicate, we could at least achieve this level of security. It’s unclear to me if the property of N-1 safety without allowing a single validator to halt the chain is possible, but if it was it would be great.

That said, for normal custody of funds & exchange my personal preference is provide safety even under 100% malicious validators & watchtowers. Then for functionality that isn’t supported temporarily rely on stronger security assumptions like this side chain/plasma chain hybrid construction. Still looks very cool!

#7

Thanks @karl for the feedback. Many valuable points in there. Hope to understand the details and get back.

#8

Wait. I though assets were locked in mainchain and then voucher/pETH was available immediately.

Is this a special process?

[Retrospective] Plasma Implementers Call #21!