Plasma Cash without any blockchain at all

Layer 2 Plasma
21

What’s the mechanism for this?

22

Given current designs, it seems like using state roots instead of transaction roots might avoid redundant computation when combined with plasma-XT-style checkpoints. The operator posts “non-authoritative” state roots (which are subject to the full exit game) and the operator or any user can attach a cryptoeconomic aggregate signature against any state root as in XT checkpoints. After a certain timeout the state root is considered “authoritative” for the particular coinids signed by the aggregate signature (in the sense that you cannot use transactions from before the signed root in the exit game, and you can use the signed root to start an exit).

cc @kfichter

23

I think you need the tree to be either sparse or ordered.

24

Does this force users to exit if the state corresponding to that root is withheld? Not sure exactly what you mean here.

25

So there are 2 assertions I’m making here:

  1. (pointed out by @danrobinson) you can replace transaction roots in plasma cash with state roots and keep everything else the same (same exit game, client procedures)
  2. (made by me) with plasma-cash-with-state-roots you can do XT-style checkpoints just by cryptoeconomically signing an existing state root
  3. (made by me) plasma XT requires modifying the exit game slightly to take into account checkpoints (which is not described explicitly in the original post); I can write out a concrete spec if needed.
1 Like
26

@ldct Can you elaborate? I don’t see apparent benefits of using state roots over transaction roots.
Are you referring to the computation of creating checkpoint hash?
I think the computation effort is just shifted from the one who request checkpoint to the operator, who need to always keep a Merkle tree of state in order to compute the next state root.

27

Yeah

the operator, who need to always keep a Merkle tree of state in order to compute the next state root.

I guess I imagined that the operator has to do this even with transaction roots, to avoid committing double-spends (with almost all designs, after you commit a double-spend, the honest user eventually cannot spend his coin and must exit)