Minimal Viable Plasma

new-extension

#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


#109

Xuanji - I see, thank you.

What do you think about the following answer

  1. one can charge a little bit for each complaint and pass each charge to the validators (similar to gas costs). Then cryptoeconomically, if the fee is more than validator storage costs, then validators should not complain.

  2. Since the Plasma operator needs to pay gas costs for each complain response, then if will be costly for the operator to make each block in a long range unavailable.

  3. Finally, the validators will only need to store each block for a single day (or a single hour)


#110

So the resource you’re paying these trusted availability providers / validators for is real-time data availability, in other words to download the data, store it for some short amount of time, and upload it if requested. The ethereum network provides a small amount of this resource currently. If you’re willing to increase this capacity in order to support plasma chains, this seems equivalent to paying the validators directly to increase the block gas limit, with the same problems (can’t validate on a laptop anymore, etc).


#111

It is a bit different because storage is temporary - you are only paying for one day (hour) of storage - on blockchain it is stored forever … So it is going to be a cheap service imho.


#112

It’s not about the price IMO, there’s a limited capacity and you can’t pay to increase it. Even placing stuff in calldata and not in storage is not that cheap currently.


#113

IMHO If a Plasma operator starts witholding data an there are lots of complaints then a lot then people will start exiting pretty fast … So the period of witheld blocks cant last for long …


#114

Sure, you just have to make sure that it is possible to exit without requiring that a lot of data be placed on-chain.


#115

Maybe i’m missing something, but if Plasma assumes that only operators will submit blocks isn’t this essentially a permissioned blockchain or at best lead to some sort of reverse DPoS architecture?

In practice, the plasma chain will likely be run by some entity who will determine with bias who can/cannot be an operator. I guess you could determine operators using a more decentralized process like a token vote but am failing to see how this differs from DPoS.


#116

You can pretty much replace the operator with any reasonable consensus mechanism (some work better than others), but generally I expect that most Plasma chains will be run by some sort of operator, yes.

The point of Plasma is that the consensus mechanism can censor you, but can’t steal your money.


#117

In our network (Skale), each Plasma-like chain is run by a cluster of nodes randomly picked out of a large p2p network. So in our case “Plasma operator” is actually decentralized.


#118

I have a question about exited UTXOs. Please correct if the following understanding is wrong.

In Minimal Viable Plasma (ex. https://github.com/omisego/plasma-mvp), I think it seems that the child chain does not know which UTXO has been exited, because exit requests can be submitted to Plasma contract directly. So the operator should check exited UTXOs stored in the Plasma contract on the parent chain before accepting transactions on the child chain.


#119

Correct. When an exit occurs on the root chain, an event is sent to the child chain and the operator “burns” the UTXO so it can’t be spent further.


#120

I see. Thank you for your reply :wink: