Minimal Viable Plasma

[kfichter]

@kladkogex

the operator will need a proof of publishing this block on an outside network.

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.

[kladkogex]

@Niboon

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?

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

[kladkogex]

@kfichter

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.

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

[kladkogex]

@ldct

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

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)

@danrobinson

This would have griefing problems that as far as we know are probably intractable

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

[bharathrao]

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

[ldct]

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

[kladkogex]

@ldct

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;

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

[ldct]

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

[kladkogex]

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)

[ldct]

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).

[kladkogex]

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.

[ldct]

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.

[kladkogex]

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 …

[ldct]

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

[everhusk]

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.

[kfichter]

@everhusk

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?

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.

[kladkogex]

@everhusk

In practice, the plasma chain will likely be run by some entity who will determine with bias who can/cannot be an operator

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.

[m0t0k1ch1]

@kfichter

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.

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

In Minimal Viable Plasma (ex. GitHub - omgnetwork/plasma-mvp: OmiseGO's research implementation of Minimal Viable Plasma), 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.

[kfichter]

@m0t0k1ch1

In Minimal Viable Plasma (ex. GitHub - omgnetwork/plasma-mvp: OmiseGO's research implementation of Minimal Viable Plasma), 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.

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.

[m0t0k1ch1]

@kfichter

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.

I see. Thank you for your reply