Minimal Viable Plasma

new-extension

#21

At the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.
I assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).
Drawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.
Therefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.
Another solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.


#22

Personally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.


#23

How does this passive loop work? Is it a function everybody can call that processes all exits which are due.


#24

How does this passive loop work? Is it a function everybody can call that processes all exits which are due.

Pretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.


A DEX on Plasma
#25

This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.


#26

OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp


#27

@AFDudley Do you have a link or reference to what you are referring to?


#28

I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be

  1. the world state
  2. list of transactions

The program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).

Here is some untested code: https://github.com/mrsmkl/truebit-plasma

Basically everything is supposed to work the same as in David’s implementation, the world state is just different.


#29

I’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.

For data availability one can use log shards, which is basically sharding for data availability.

Congrats for whipping something out this fast!


#30

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?


#31

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.


#32

Can smart contracts run under UTXO model?:rofl: 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 ?:wink:


#33

Can smart contracts run under UTXO model?:rofl:

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 ?:wink:

CryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.


#34

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.


#35

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.


#36

Thank you - this explains lots of things :slight_smile:

One thing that remains unclear in my head is when you talk about the contract owner “signing off”.

  1. Alice owns a account which contains her possessions of smart tokens X, Y, Z.

  2. Bob owns another account which contains his possessions of smart tokens X, Y, Z

  3. 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? )


#37
  1. Bob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.
  2. Alice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.

#38

Hi,

Can somebody please clarify this situation for me :blush: 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?


#39

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.


#40

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?