Minimal Viable Plasma

[ldct]

It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH

[kladkogex]

Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …

Another question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …

[kz]

I believe the solution for

Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …

is

You could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.

You can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.
In that way the reporter of fraud proof could actually earn fee for doing work for common good.

That should align the incentives in that regard as far as I can tell.

[kz]

Could a combination of this

deposit(): generates a block that contains only one transaction, generating a new UTXO into existence with denomination equal to the msg.value deposited

and

startExit must arrange exits into a priority queue structure, where priority is normally the tuple (blknum, txindex, oindex) (alternatively, blknum * 1000000000 + txindex * 10000 + oindex)

create a potential issue?

There is a potential race condition between:

• Alice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate
• Bob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).

Because of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.

This could be solved in a simple way by treating ETH deposit on main chain with weight of -1.

def ordering(blknum, txindex, oindex):
weight = blknum if not deposit(blknum) else -1
return weight * 1000000000 + txindex * 10000 + oindex

The deposit UTXO could be:

• not spent -> then there could be no problems with changing the ordering.
• spent -> then one could again submit a fraud proof.

[denett]

I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.

I don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.

An other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.
If the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.
So maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.

[vbuterin]

The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.

The signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.

Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?

If we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.

You should even check all blocks for validity

Exactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).

If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …

This is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.

There is a potential race condition between:

You’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.

[denett]

Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect

So if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.

[kz]

So something like: weight = blknum-X where X is the number of blocks in a day.

I’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.

The speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.

wouldn’t that allow Alice to withdraw straight without a waiting period?

Ah yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.

I think that ETH main block number or time stamp will need to be stored in priority queue anyway:
(Plasma block number, txindex, outindex, **mainBlockNumber**)
… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.

I’m not sure does the proposed solution have some additional flaws .

You’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.

@vbuterin Thnx for your time
I wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.

[kz]

If the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.

Oooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.

How would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?

[kz]

I’m just trying to wrap my head around this.

Does entering plasma chain requires validating entire plasma chain history?
It seems to me that otherwise one risks entering insolvent plasma chain.

If so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?

[denett]

I’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.

At the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.
I assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).
Drawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.
Therefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.
Another solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.

[denett]

If we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.

Personally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.

[denett]

There is a passive loop that finalizes exits that are more than 14 days old, always processing exits in order of priority (earlier to later).

How does this passive loop work? Is it a function everybody can call that processes all exits which are due.

[vbuterin]

How does this passive loop work? Is it a function everybody can call that processes all exits which are due.

Pretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.

[AFDudley]

This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.

[ltfschoen]

OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp

[MicahZoltu]

@AFDudley Do you have a link or reference to what you are referring to?

[mrsmkl]

I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be

1. the world state
2. list of transactions

The program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).

Here is some untested code: https://github.com/mrsmkl/truebit-plasma

Basically everything is supposed to work the same as in David’s implementation, the world state is just different.

[JustinDrake]

I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions

I’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.

Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output.

For data availability one can use log shards, which is basically sharding for data availability.

Here is some untested code: https://github.com/mrsmkl/truebit-plasma

Congrats for whipping something out this fast!

[mewwts]

So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?

A Plasma block can be created in one of two ways. First, the operator of the Plasma chain can create blocks.

What are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?