There are very few frauds that A_1 himself cannot submit a proof on.

This would require A_1 to be live and running a validator node, which sounds impractical for 99% of users no matter how light-weight the validator node is (have to download separate software, keep it always running, etc.)

I can see having a separate group of people, who have much more at stake in the DEX, running these validator nodes with a TrueBit-style incentive scheme. Again, this is possible in Plasma MVP/Cash as I describe below.

Exit games are interactive steps mediated by the smart contract and have the following issues: can be manipulated by spam attacks to prevents the other party from responding in time Possibly get miners to exclude challenge responses. A sudden surge of challenges that empty eth preventing you from challenging more claims.

Unclear what you meant by #3, could you please clarify?

The first two problems are not mitigated in Gluon. Consider a case where a G-block with fraudulent transactions has been submitted (e.g., a “Withdraw” transaction with the wrong amount of Z tokens). Validators will be able to catch that problem quickly, but will have to submit the fraud proof on-chain. The first two problems you mention still hold:

Spam attacks on-chain could prevent a validator from submitting the fraud proof or halting the chain in time (before the next G-block). You can get miners to exclude the fraud proof or the voting process to halt the chain.

Non-interactive proofs are not games in the sense that once submitted, there is little room for manipulation.

How is this different than existing Plasma constructions? What kinds of “manipulation” are you referring to that Gluon prevents vs. MVP/Cash? Per your whitepaper, it seems like if fraud is detected, it results in a vote to halt the chain (the equivalent of a “challenge”). In MVP/Cash, challenges are issued against individual exits, which prevent the exit from going further. The definitions and outcomes of a challenge may be different, but the requirement of monitoring the operator and on-chain proofs is the same.

Quite the opposite. MVP validation is onerous: every user has to validate the chain every week or they are at a risk of loss. Any system where only the victim can protect himself is weak. In Gluon, a single validator provides security for everyone . This is far more robust than MVP

Dissecting this further:

It seems like only having one validator provide security for everyone is possible because of an account-based scheme as it reduces the amount of data the validator needs to check through, making it feasible for one validator to do the job for everyone. Looking at the implementation of the account-based scheme in your whitepaper, it seems like it’s modeled as a UTXO-based system, where each user has one UTXO per token type (the token’s balance) with on-chain checkpointing effectively happening every G-block. By having each G-block act as a checkpoint, you remove the need to store the UTXO history because anything before the G-block is unchallengeable, and so so there’s no point in storing the history.

You can get a similar benefit with MVP and Cash if you exit the coin and deposit it back to the Plasma chain (“checkpointing”). Of course, doing so is much more inefficient, so having the operator do the checkpointing (reducing the UTXO set to a single balance every time, i.e. an account-based system) without requiring a round-trip cost of going on-chain and back off-chain is a clever optimization. This does require an honest set of validators that have much more stringent requirements to verify correctness of each G-block to ensure that the operator is not acting maliciously. I believe the Plasma MVP/Cash constructions were made to not have any reliance on third parties. There is a perceived security benefit with the MVP/Cash model (each user is responsible for their own security so no need to trust any third party), and there’s a practicality benefit with Gluon (trust a group of incentivized third party validators to do the job since they have something on the line as well).

Detection of frauds in Gluon immediate on seeing a new entry, even before it goes into a block. In MVP, you would need to trace the history of every coin.

[…]

A 10 minute MVP will implode since one can create a fraudulent coin whose history takes longer than 10 minutes to verify.

The benefit you’re touting in Gluon is because of the requirement of always having one live, incentivized, honest validator. This lets any validator (even a new one that just joins the network) assume that everything up until the last G-block does not need to be re-validated. This argument also holds in an MVP world. If you have the same validator requirement, you could have the validator creating checkpoints (the equivalent of G-blocks) that reduce the amount of data someone doing transaction history verification in the future needs to analyze (it would only be data from the latest checkpoint onwards). The key point here is that this is only possible if you introduce a requirement of a live, incentivized, honest validator.

Plasma cash in non-fungible, leading to a knapsack problem when trying to construct transactions that match desired quantities.

Be on the lookout for Plasma Cashflow, which solves this problem.

How will you match […] million utxo history?

I’m curious what your answers are for each of these questions with Gluon as that’ll elucidate some of the tradeoffs you considered and how you made you decision. I’m sure some of them are scattered in the whitepaper, but would be good to get it succinctly included here.

–

(All of this is not meant as a knock to the Gluon construction. It describes a clever, practical Plasma abstraction and is similar to many of the things we’re doing in our Plasma construction to make things more practical. My goal here is to dig deeper to understand the nuances and motivations behind some of the decisions taken, especially as we’ve considered many of these ourselves.)