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
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.
may I ask about the latest solution/proposal on the expensive cost incurred by the periodical commits to the root chain, if there are?
One thing that Plasma spec does not specify exactly is who stores which signatures. May be one can edit the description at the beginning of this thread to specify this.
Lets consider an example where
Alice deposits 1000 dollars and creates a 100,000 transactions each time paying 1 cent to herself.
2, In process of doing so Alice generates 100,000 confirmation signatures (several megabytes of data). The question is
a) are these signatures stored longterm by any party except Alice?
It seems that unrelated people will have little incentive to store these signatures.
b) If no-one stores these intermediate signatures, then it seems like Alice can exit all the intermediate UTXOs without a challenge (since to maintain a challenge it seems that one is required to present the signature? The challenge function does require a signature as one of its arguments. If Alice was dealing with herself to create a chain of self-dealing UTXOs, I am not sure who the party will be that will possess the signatures …
The original Plasma paper required these signatures to be broadcast onto the Plasma chain, so you’d avoid (2) at a large data cost to everyone. In your example (off-chain conf sigs), Alice must reveal the one conf sig to spend the next, but this is also broken if Alice is coordinating with the operator, unless these conf sigs must be published on-chain to spend, but then we’re basically back at what the original paper called for.
Basically, you’re right, it’s why I’m trying to get rid of confirmation signatures entirely.
Kelvin - I see, so in the original spec the signatures are part of the chain, so everything is fine unless the operator starts witholding them since the operator is the only entity that stores them …
I am not sure if it has been proposed already, but I would like to propose a simple Proof-Of-Burn modification to plasma MVP
Before a user exits a UTXO, the user burns (marks as invalid) this UTXO. A proof of burn is then used to exit the UTXO on the main chain. Plasma operator enforces the rule that burnt UTXOs can not be used.
This seems to solve a significant number of exit problems - in particular, users can not do bad things unless the Plasma operator becomes malicious.
Then you can submit the burn request as a complaint directly to the Plasma smart contract,
Once the request is accepted by the Plasma smart contract, the Plasma smart contract will not accept further Merkle roots from the operator, unless the operator
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 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.
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?
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.)
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.
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?
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
