I think this is right. It would seem that ERC20 is achievable in plasma in theory since all of the stored state has some clear owner and you see that expressed in a UTXO way in MVP.
The hard part is dealing with state that matters to multiple people, though this may actually be rare state so to speak, I can think of a few simple examples of it (i.e. a score count that marks a global record like total sales in a token sale or number of wins in a game for a group). Consider the case of a contract that takes one state transition to increment an integer counter, if there was no account ownership of this integer, then we have no clear owner of the integer. If it is found that the operator decided to say decrement the integer in a state transition present in a block, we would want to revive our communal progress on incrementing this integer back to a safe validator set. In order to handle what I am now calling “commons” type state, we have to think of more clever mechanisms perhaps.
If we want to extend this simple contract to nested chains, i believe we still have to be sure these nested chains respect that ownership is clearly defined in the application. I am currently speculating on what can be done about this commons state…
EDIT: First thoughts
Forking plasma exits: A democratic approach to state exits
Maybe we can construct the exit rules of the plasma parent contract to handle communal state exits by allowing the exit to fork. To do this we will require that an exit from a plasma chain comes with a snapshot of the state. This snapshot will come in the form of the block height of the plasma chain at which it is no longer valid to process transactions. I.e. if we have a plasma chain contract with the following state updates.
T-1: correct state
T-0: state withheld by operator, suspect invalid transition
T+1-n: Suspected invalid plasma chain continues
Here, the honest party will want to exit on state T-1 and not allow the exit to process any transactions beyond that block height. This first request to limit the height to T-1 will flag to the community of some alarm and allow others to exit under this height. Each height chosen to exit will create a separate on-chain state storage object to house the exit and essentially fork the plasma chain into multiple chains on the parent. If the operator is byzantine or colluding with a small set of accounts on the child chain then they will want to exit on a fork that the rest of the community does not want to exit on so they will only be able to exit with incorrect transitions to their block height fork. This fork could later be determined invalid by the community.
Considerations:
This requires the majority of honest participants to know when an operator is byzantine.
Forks are generally not nice to deal with though I am not sure if we have any examples to draw on of a fork like this (the dApp space wasn’t mature enough to be really affected by the ETC fork?).
Maybe voting on a canonical chain with a CAS exit could be done.