Minimal Viable Plasma


#121

You could also play a game where random participants are asked and incentivized to confirm block availability.

The participants selected for the n+1 block are chosen at the nth block. Before the n+1 block is accepted it must be signed or be submitted with signed proofs of specific utxo’s being included in the block by the participants selected in the nth block.


#122

The problem with a design like this is that it break Plasma guarantees by making the protocol dependent on a secondary consensus mechanism. In this example, it’s possible for the operator be (or collude with) a majority of the notaries and “claim” that the block is available when it isn’t.


#123

But how much is it different from Casper ? :smiling_imp::smiling_imp: It looks like Casper makes exactly the same assumptions )


#124

Well, yes, but I’d argue that Plasma is only Plasma exactly because it doesn’t make those assumptions.


#125

Well )) What I am saying is if reliance on a validators is OK for Casper why not to consider this (one can name it differently for the sake of purity )

Imho it seems that a system with burn proofs has lots of advantages in preventing users from doing bad things. Users arguably will try doing bad things way more frequently than plasma operators.

With burn proofs there is a potential problem of the Plasma operator witholding blocks/burn proofs, but it seems that a mechanism where a user can complain and force the operator to publish the block to a set of validators is an interesting alternative to explore …


#126

Will you elaborate on this please?


#127

The family of protocols where you rely on a randomly sampled set of bonded validators to guarantee data availability and/or validity of a separate chain is generally called “sharding.” Such designs introduce many complications and assumptions that Plasma does not have, and provide many benefits that would make most of the mechanisms in Plasma irrelevant.

Most notably, Plasma should be possible even if there is only a single operator for that chain (i.e. an exchange like Coinbase, or an app developer like Cryptokitties).

It’s definitely been explored, but the current thinking is that any challenge-response protocol around data availability is subject to problems around speaker/listener fault equivalence (https://vitalik.ca/general/2017/07/16/triangle_of_harm.html). Try designing such a protocol that is immune to griefing attacks and you will see what we mean.


#128

I don’t think this is correct. While I guess you are taking a subsection of participants and asking them to do certain work, the work is done for the entire set of participants. Sharding is about separating information so that work can be done in across each shard separately.

This seems to be geared towards block producers.

A random group asked to confirm block availability does not need to also be able to produce blocks. The exact responsibility of the group would be to download blocks and collectively prove that as many other members of the chain have seen the block as possible.

A griefing factor can be adjusted and weighted by users who have recently included transactions in the plasma chain. This means that the group of active users who are not censored have seen the data.

Still to be made explicit is the exact cost of data unavailability. The operator could progressively lose a bond while users pay a sort of indirectly and partially refundable (by availability proof) fees for block inclusion. This means their uncensored users can collectively grief them. To me this seems totally acceptable for a plasma chain. The operator controls this set of users and the censored users can exit.

This has little to do with the consensus mechanism of the Plasma chain (i.e. it can still use POA), but more to do with a game that proves data availability. Which will be extremely important in non-UTXO version of plasma.