So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?
What are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?
Are any changes required to the Ethereum protocol for Plasma to become a reality?
No.
What are the requirements for a sidechain to operate under MVPlasma?
It must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.
If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?
Yes.
Can smart contracts run under UTXO model?
I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …
Is MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?
Can smart contracts run under UTXO model?
Theoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.
How can CryptoKitties be ported to a Plasma chain ?
CryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.
Understood …
Have you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …
Not clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …
Okay … So Plasma will not run SmartContracts compiled for the main chain,
they will need to be “plasmafied” or ported to Plasma in some way.
This is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.
This means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.
Yeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.
This is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.
I don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.
Thank you - this explains lots of things 
One thing that remains unclear in my head is when you talk about the contract owner “signing off”.
Alice owns a account which contains her possessions of smart tokens X, Y, Z.
Bob owns another account which contains his possessions of smart tokens X, Y, Z
Now Bob comes and wants to give Alice more of the token Z. Essentially he needs to
increase the value of variable Z in Alice’s account and decrease his value of Z.
How is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )
Hi,
Can somebody please clarify this situation for me 
I must be missing something.
Let’s assume Alice wants to send money to Bob.
Alice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.
Plasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.
After that plasma chain operator/owner publishes an exit worth 100ETH.
According to this ordering plasma chain operator/owner could pull funds before Bob.
If Bob tried to exit the plasma chain, it would be too late.
If Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.
What is preventing this type of fraud?
Alice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.
Hi @denett
Thank you for your answer.
Is this the 4th point you are referring to?
Could you please help me to understand this better?
I was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.
Could you maybe explain in more detail what does that 4th point mean?
Alice sends whom the confirm message? Plasma operator and Bob?
Does that confirm message end up in plasma chain or not?
Doesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?
I was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.
The confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.
Alice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.
Thnx for the info.
According to @vbuterin
It seems to me that signatures inside the transaction:
sig1
sig2
!=
commitment1
commitment2
sigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?
Are those commitments fields missing from the transaction format documentation or did I again misunderstand something?
If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.
Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.
Otherwise I see few options for such commitment
replacement of the tuple blknum, txindex, oindex in a transaction A -> B with
we should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that
It’s also a little bit not clear in MVP what field signature should cover. May be it just have a form
[blknum1, txindex1, oindex1, # Input 1
blknum2, txindex2, oindex2, # Input 2
newowner1, denom1, # Output 1
newowner2, denom2, # Output 2
fee, signature]
Such transaction implies that:
May be such transaction as it is can be a proper commitment.
P. S. I hope that my reply didn’t bother you too much, Happy Birthday!
Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.
Ah, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?
Hello Vitalik.
I see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.
I’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:
[blknum1, txindex1, oindex1, # Input 1 owned by A
blknum2, txindex2, oindex2, # Input 2 owned by A
newowner1, denom1, # Output 1 to B
newowner2, denom2, # Output 2 change to A
fee, signatureOfA]
I’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator
This ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.
If the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.
Sincerely, Alexander
Not the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.