If the chain operator hides the block where step 3 happened from Alice (refusing to make it available), what can Alice do?
And how is Bob supposed to know that the fraud happened if he doesn’t check the previous Merkle state roots? Particularly since there’s no guarantee that there was an “Alice” defrauded in the past—this could just be a fraud on Bob, where Eve and the operator will reveal the prior fraud after Bob has been tricked into accepting the coin.
Also, does your mechanism depend on Alice noticing this unavailability and exiting within a fixed time period? If so, it loses one of the main advantages of Plasma Cash (avoiding mass forced exit).
If the chain operator starts witholding blocks from Alice, Alice will simply exit the system then. This is not much different from Plasma MVP
“A user should continually validate (or validate at least once per 7 days) that the Plasma chain is fully available and valid; if it is not, they should exit immediately.”
Note that the probability of the chain operator becoming malicious is way lower than any user becoming malicious. If a chain operator becomes malicious, it loses all of its business.
In real life, the most attacks will come from users
Yes, but it is different from Plasma Cash (at least if there is a time within which the user must withdraw).
I still don’t understand how a user receiving a coin would know that there are no double spends in the coin’s history (which could invalidate the transaction in which the user received it).
Similar to Plasma cash you could provide non-spend proofs for the previous Merkle trees :–))
The reason why the entire thing is interesting to me is because for Plasma cash you only need history for each particular coin, the relative histories are irrelevant. Therefore, having a global ledger and a global consensus seems an overkill at the conceptual level
Then I don’t think this is significantly distinguishable from Plasma Cash, except that the things being committed are state commitments rather than transactions, right?
But it is interesting to understand what the optimal data structure to commit (transactions vs state as you said or soemthing mixed). For state there are things like Merkle Mountain ranges that people discussed here. It may be that you can to update non-spend proofs less frequently if you use Merkle Mountain ranges plus state roots - it is interesting to understand how this would work. Also it is interesting which data structure is more efficient for concurrent execution by the operator
One problem with using only state roots is that you no longer have an O(1) exit game. The plasma operator could commit N state roots, 1 of which is an invalid state transition (with respect to the previous state root) but withhold all the data, and then exit with the last state root. The proper coin owner cannot construct a fraud proof because the necessary data is unavailable; hence the exit game must take O(\log N) steps. I believe this is necessarily true in your design, but it seems like a description of the exit game has been omitted.
Also, small nitpick: I think you mean “sparse merkle tree” since “merkle tree” as the term is commonly used doesn’t support succint non-inclusion proofs.
I don’t think this is right? The proper coin owner can just reveal their older coin and challenge the exiter to provide a spend of that coin, just as in normal Plasma Cash.
I think potentially a good point of using state roots is it can allow one to run generic EVM contracts on Plasma.
One could use the state root of the internal smart contract state as Plasma root. Then you would need to have some type of a bounty for independent validation of smart contract state root transitions.
Truebit does not fit well because it is vulnerable to front running, one probably needs a more advanced online crypto protocol that allows validators to claim fraud with a provable protection against front running.
For EVM (with the limited state) to work, challenge period is required and it will end up increasing block time.
Truebit does not fit well because it is vulnerable to frontrunning, one probably needs a more advanced online crypto protocol that allows validators to claim fraud with a provable protection against frontrunning.
Yes. but for now, Truebit (game) like challenge will work.
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).
(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)
(made by me) with plasma-cash-with-state-roots you can do XT-style checkpoints just by cryptoeconomically signing an existing state root
(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.
@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.
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)
