Minimal Viable Plasma

new-extension

#89

What happens if the operator doesn’t let you burn the coin?


#90

Then you can submit the burn request as a complaint directly to the Plasma smart contract,

Once the request is accepted by the Plasma smart contract, the Plasma smart contract will not accept further Merkle roots from the operator, unless the operator

  • submits a burn proof

or

  • submits a proof that the UTXO has been spent.

#91

If the Plasma operator is enforcing this rule, then there doesn’t seem to be a difference between this and having the Plasma operator refuse to include double spends - users already can’t do anything bad unless the operator is malicious.


#92

submits a burn proof

We call this retiring an utxo, but “burn” is better

smart contract will not accept further Merkle roots from the operator

We call this “chain halt” and is used to address all provable byzantine behavior by the operator


#93

I think “chain halt” should mean that if someone submits a complaint, the Plasma operator should answer the complaint before the next root is accepted.

If the Plasma operator is not answering the complaint for say 1000, the operator should be marked as tainted and everyone should be allowed to exit according to the holdings based on the last accepted root.

This looks like a pretty reasonable procedure to me and one can extend it to include more complaint types.

Is this a mechanism that you guys are using ?


#94

Putting aside the denial-of-service concerns this raises, what happens if the Plasma operator has already created unavailable blocks? The proof-of-burn will be placed after the unavailable blocks, so it will not be safe to exit from it, right?


#95

Whats the denial of service concern ? :smiling_imp::smiling_imp::smiling_imp:

The Plasma operator has already created unavailable blocks

If there is an unavailable block, you can create a complaint on the blockchain, and ask the operator to post the block to the blockchain.

Or you can use an outside storage network like filecoin, and then, to satisfy a complaint, the operator will need a proof of publishing this block on an outside network.


#96

You could snipe every attempted submission of a state root by submitting a burn request with a higher gas price. (You could probably avoid this problem by giving the operator a multi-block grace period to respond to a burn request.)

This would have griefing problems that as far as we know are probably intractable (see https://www.youtube.com/watch?v=OJT_fR7wexw).

Generally speaking, if you assume that a solution is in place for assuring data availability, you can do much more powerful things, but it isn’t Plasma anymore.


Simple Fast Withdrawals
#97

I have a question about the exit challenge periods.
Would the exited ETH be essentially frozen for weeks? If not frozen, how is there going to be a rollback if the ETH was spent before the first valid challenge?


#98

The halting should only be done by non-interactive proof of byzantine behavior.


#99

To add on to the points brought up by dan:

  1. It’s not just a griefing problem, there’s literally no capacity; if the plasma chain runs at a very reasonable 50tps, no amount of fees can place that amount of data on-chain
  2. Filecoin, swarm etc do not provide data availability, they just provide file storage

#100

How do you prove withholding non-interactively?


#101

This is non-trivial and generally relies on an honest majority assumption of some external (non-root chain) mechanism. Any fundamental reliance on external mechanisms breaks the basic Plasma assumptions, IMO.


#102

In the case of a burn proof the exit would happen immediately, you do need to wait


#103

Then it has to be published on ETH main chain.

What could help BTW is introduction of some type of a temp storage facility on ETH main chain


#104

Once can have a set of Casper like validators for each Plasma operator. After a complaint, the plasma validator would submit the block to each of the validators, and submit the threshold signature of the validators to the blockchain.

One could use Casper validators for that, especially having that they will be implementing threshold signatures anyway. Note, that each validator would be required to store the block for a finite time (say one day)

So what about the solution described above (proof-of-burn plus block-hosting validators with threshold signatures). It seems to address the problem


#105

How do you prove withholding non-interactively?

This is the only thing that cannot be proven non-interactively and needs a vote to halt on the mainchain


#106

If you choose to use Casper validators, in the worst case, every validator would be forced to download and check the availability of every plasma block; if there are 20 plasma chains each with 50 tps and each transaction is 200 bytes then this is 1.6 Mb/s. If you use a separate set of “availability validators” then the plasma block producer and the availability validators can collude to steal user’s money


#107

It would not be like that - the Plasma operator would only submit a block to the Casper validators if some one complains that the block is not available


#108

So my worst case is if someone complains that every block is unavailable