Minimal Viable Plasma


#81

Kinda late but wanted to address your comments.

Running a validator-based chain is in fact vastly more complex than running a Plasma chain. The beauty of Plasma is that it assumes very little about how the child chain functions. In the simplest form, the child chain can even be a proof-of-authority chain with one single block producer. And yet even in this simple and very much centralized form, Plasma still guarantees that the users can safely exit regardless of how the block producer behaves.

To put it another way: Plasma vastly relieves the burden of the person/company operating the Plasma chain, because they can be the most incompetent programmers writing the most buggy code, and yet as long as the smart contract on the root chain is correct (I would imagine there will be OpenZeppelin-like standard implementations), the users won’t lose money.

On the other hand, a naive validator-based sidechain can lose a user’s fund in a million different ways, unless one of the following conditions is true:

  • You make strong assumptions such as “>50% validators are always honest”, which puts great burden on the chain operator since they now have to worry about buggy code, hacks, etc.
  • You design the bridge contract running on the root chain so that it properly handles exiting, fraud proofs, etc., even when validators go rogue. But at that point you are just reinventing Plasma :slight_smile:

#82

I think this problem is avoided if you require a per-exit deposit, rather than a “per-user” deposit.


#83

Two Questions:

  1. is there a specific reason we don’t put deposits in a queue and mint corresponding balance on plasma chain in batch? instead of 1 exact transaction per block.
  1. may I ask about the latest solution/proposal on the expensive cost incurred by the periodical commits to the root chain, if there are?