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.
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
1 Like
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 ?
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?
Whats the denial of service concern ? 
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.
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.
4 Likes
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?
The halting should only be done by non-interactive proof of byzantine behavior.
To add on to the points brought up by dan:
- 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
- Filecoin, swarm etc do not provide data availability, they just provide file storage
How do you prove withholding non-interactively?
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.
In the case of a burn proof the exit would happen immediately, you do need to wait
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
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
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
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
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
So my worst case is if someone complains that every block is unavailable
1 Like
Xuanji - I see, thank you.
What do you think about the following answer
-
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.
-
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.
-
Finally, the validators will only need to store each block for a single day (or a single hour)
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).