Simple Fast Withdrawals

Is this generally because the operator won’t include a double spend if they’re the one who’d lose out by including it?

Because the operator is both (i) the best party to internalize gains from increasing usability of the plasma chain, and (ii) the party that most easily and quickly knows that some exit-in-progress is valid and not challengeable.

1 Like

Got it, both make sense.

While this could work technically, I wouldn’t characterize this as simple economically.

This scheme could be simply seen as a hefty withdrawal fee if the plasma operator is the one most likely to accept the offer. The plasma operator can run out of funds and therefore an auction market as you suggested is necessary.

The exit fee needs to be balanced such that its attractive to the bond purchaser but affordable for the exiter. In my experience anything other than a flat, nominal fee would be a disincentive to use this plasma chain. Just imagine Binance charging 10% for withdrawals. Nobody would go there anymore. However, the operator would need to charge a percentage fee since locking large amounts of money for small fixed amounts does not make sense. In general, the charges have to reflect the borrowing cost for a 2-week period. Bitfinex borrowing rate for ether is around 0.0416%. Compounded over two weeks is about 1.77%

This may be acceptable cost for a lot of parties who trade occasionally for plasma speed and security. There would be many who would simply be priced out of the system who need to get in and out often (market makers, arbitrageurs, frequent traders). Think about it this way, if I move my money out 28 times, the 1.77% cost would cut my bankroll in half.

The real issue here is the two week delay on the main chain. This amplifies all costs and UX issues with plasma. If plasma could reduce this to say one day, the cost would be 0.04%, which may be acceptable to most people.

In Gluon Plasma we enable the UTXO owner to mark an output as retired, which prevents all operations on it except withdrawal to main chain. This enables withdrawal once the retirement is included in a plasma block. This enables withdrawals in a few minutes (except in Byzantine cases when the longer bonded exit can be used.)

How do you handle the case where an operator creates an invalid (“out of nowhere”) utxo, marks it as retired, and withdraws it? You can prioritize slow bonded exits, but a user could then make many (continuous) slow bonded exits to grief the fast exits.

operator creates an invalid

Good question.

I guess our scheme only works for an account model. An account begins with zero balance and every change to it (deposit, withdrawal, trade) are made from signature proofs and the prior state. There are fraud proofs for every transition any attempt to create an invalid transition can be proven.

Withdrawals cannot simply come from nowhere, since they need to point to a valid previous balance.

Do you have details on how this account model works?

Basically, Nth Plasma has both economical bottle-neck and computational bottle-neck. And more strict condition might rate-limit the “depth N” of Plasma nest.

Then, regarding this fast withdrawal’s discount rate, N=27 is the economical bottle-neck of Plasma. Because the exitee(= the person who accepts the other’s exit) expects 10%~ profit per year and N=27 means he need to wait 1yr(54weeks) until he can unlock exiting fund. And this “27 times nested fast exit” costs exiter 10%+ discount. This is the economical bottle-neck of Plasma and this topic enlighten me. (There were no discussion regarding maximum depth of Plasma nest)

P.S. This fast withdrawal enables Plasma-fans to think about “Plasma MapReduce”. I’m quiet exciting about that.

1 Like

Im finishing up the details including economic and game theory reasons for our model. Will post it here in a few days. Meanwhile, we have this bit online:

Also, how are accounts credited when someone deposits into the chain?

Working on the same thing. The difference is - the stakeholders vote on checkpoints. Once votes exceed the threshold level, you propose checkpoint on the main chain. If checkpoints won’t happen in a certain amount of time, the chain goes into “withdraw the only mode” (same as chain halting) and people can withdraw their tokens using the last checkpoint without any urgency.

You can also restart the chain with different authorities. That would be better I guess.


Also, how are accounts credited when someone deposits into the chain?

It’s special kind of transaction where operator inputs senders’ balance (latest UTXO) and deposit amount (with deposit id - tracked on mainchain), and generates total amount as output. That way anyone can challenge if operator uses same deposit id in multiple transactions. Apart from that, proof of existence in required from operator if sender challenges on main chain regarding deposit transaction.

I think this is a good proposal, but it may be imho rephrased even simpler.

1 Since it takes long time time to exit a Plasma, the value of ETH on Plasma is always less than the value of ETH on the main chain.
In other words, these are two different currencies. Lets call Plasma token PETH.

Then at particular moment of time you have something like

1 PETH = 0.98 ETH where the difference is risk of the Plasma operator becoming bad, plus decrease in value coming from a two-week lock.

So in my opinion what Kelvin is designing is an automic-swap-based market of PETH vs ETH.

These markets will exist for sure immediately once Plasma chains run, and once they exist then in my opinion, no one will use plasma default way of moving ETH into PETH for a very interesting reason - if you use the atomic swap market that Kelvin is proposing, you will get more PETH. Very interesting!

Right, but an operator can update the balance with a fake deposit amount, send it to themselves a few times (masking the initial fake deposit), and then do a fast exit, all within a single withheld block. So you can prove that a single state transition is invalid if the block is available, but you can’t prove it if blocks are withheld. You also can’t efficiently prove that a chain of TXs is invalid.

Nitpick, there is no risk if the PETH is properly verified before purchasing (verifying the main chain up until the exited TX).

But yep, you basically get a market that trades withdrawal-locked Plasma ETH for liquid ETH.

In case of block withhold, stakeholders won’t sign the checkpoint and that’s why it won’t be the part of main chain. In @bharathrao model, stakeholders can vote for halt without any new checkpoint. So operator won’t be able to exit with fake deposit.

The operator can do this within the “fast exit” time (whatever that is, 2hrs?), so the vote would necessarily have to occur before this time is complete.

I think this is possibly broken. I can now halt the chain and force withdrawals by controlling > threshold of stake. If I hold > threshold of stake + I’m the operator, then I can just include invalid blocks and steal funds.

Even with (or without) case of “single operator with the threshold of stake”, the system must have “propose, wait for the challenge and commit” process while submitting the checkpoint. And allow anyone to challenge the invalid transaction. There are two issues here though:

  1. The challenge period must be long enough. Mitigation would be - use smaller block time and longer checkpoint time (and use partial confirmations). Similar to Plasma checkpoint cost and block time
  2. Data availability. I think that is being discussed on Minimal Viable Plasma

Well I agree here. If the checkpoint challenge period is long enough (2 wks, for example), then everyone can exit if a withheld checkpoint is proposed.

1 Like


Well I agree here. If the checkpoint challenge period is long enough (2 wks, for example), then everyone can exit if a withheld checkpoint is proposed.

One way is to avoid priority queue as much as possible to avoid emergency mass exit (perhaps cannot avoid it :). Instead just halt chain and turn into “withdraw only mode” for now, and user can exit without urgency or priority. One can do that in one transaction with vote sigs in short period (no need > 2 weeks. Around 2-6 hours would be enough for that).

1 Like