Nice construction! @bbrandtom and myself are also working on a plasma design for data availability along the same lines, but with more relaxed assumptions.
There is a problem with the OP solution even under the assumption that users regularly check and react instantly when data is not available. The problem is that a state transition with no data available can include withdrawals. So even if users track constantly for data availability, the operator can withdraw into an unpublished state, causing it to roll back and then withdraw the same funds again.
Let’s look at an example:
Suppose the state is now S1, with root R1, and data is available for it. The operator publishes a new root R2 for some state S2 without its data and includes some withdrawals W in the state transition as well as some trades T. Users immediately notice that data is unavailable and ask to withdraw. The operator does not respond and after some time those users roll back the state to S1. But in S1 the operator still has the funds he withdrew previously with W! So he can withdraw again from S1, causing the contract to be insolvent (with only fractional reserve) per the state S1.
S1 -> (T+W) S2 ->rollback S1
data-
data-
data- but contract missing W funds:cry:
So even if users watch the chain constantly to ensure data availability, they won’t be able to prevent this from happening.
A possible solution:
Separate trades T and withdrawals W, such that every state transition can be either W-only or T-only. Now, because W’s data is always on chain, any state transition with W that follows a state for which data is available, is also guaranteed to have the data available. If a state transition is of type T-only, it can lead to a state without data but then no withdrawals will be included. This is why this kind of state can be rolled back safely, as no money has left the system since the latest state for which data was available.
Rerun the same example:
Option 1:
S1 -> (T) S2 ->rollback S1
data- | data- | data-
Option 2:
S1 -> (W) S2
data- | data-