Minimal Viable Plasma


#41

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.


#42

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.


#43

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?


#44

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.


A DEX on Plasma
#45

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

    1. full transaction that produced an UTXO that A is spending
    2. Merkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.
    3. Other required parameters such a signature from A
      Such approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.
  • 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

    1. transaction is included in Plasma block
    2. Plasma block is included in the main chain
      so the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.

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:

  1. entity who is signing claims to have ownership of inputs 1 and 2
  2. agrees with new owners and denominations.

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!


#46

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.


#47

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?


#48

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


#49

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.


#50

Hello Vitalik.

Thank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.

Sincerely, Alexander


#51

Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.


#52

Thnx for the reponse. I think I now understand.

I have the following suggestion:
After Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.

Rationale:

  • only the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.
  • keeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.
  • in case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.
  • users are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.

#53

The plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.

I don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.


#54

What if Bob, Alice and chain operator are a single entity :slight_smile: ? Chain operator deposits 1ETH and gets 2ETH out :slight_smile: .

Alice (operator) first exits the chain while Bob doesn’t challenge her.
After that Bob (operator) exits the chain by using Alice’s commitment.

Nobody else can challenge Alice’s (operator) and Bob’s (operator) exit.

After exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.


#55

Alice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.

You are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.


#56

Hi @denett,

thanks on your help with all of this. :smile: Really appreciate it.

Could you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.

As far as I can tell there is only one method to challengeExit.

After Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.

Let us assume some UTXOs where made after this.

So then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.

@denett Could you please help me to understand this?


#57

As I said here:

To proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.
I think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.


#58

One thing which is unclear in my head is why does one need to allow bad exits at all?

One can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …

This seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …

Why is a validator-based approach good for Casper and bad for Plasma ?

Actually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …


#59

@denett Oh, I’m sorry, I’ve missed that part of your previous answer.

Correct, you’ve said it :smile: It’s hard for me to discuss these things over forums.

It would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.

I believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.

What is the downside of a solution to have two colored UTXOs on plasma chain?

  • Commited = red
  • Uncommited = blue.

One can exit both red and blue UTXOs.
Only red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.

If exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.


#60

I guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.