Reviewer number: 1
In section III-D, you describe a set of desirable properties for side chains. The first few are essentially identical to those in the framework developed by Adler et al. in Building Scalable Decentralized Payment Systems (see: definitions 2.4 and 3.4). You should actually be using that paper as a baseline metric for the quality of layer-2 systems. Pay close attention to the last paragraph on page 8, though. The latter few properties are more specific to your design, or follow from the rest.
One important point that arises from the above is that Plasma Go is permissioned, as opposed to rollups which are permissionless. This facet needs to be discussed, as it’s a property that rollups make a sacrifice to have.
Another important point is that rollups allow for arbitrary state transitions, so long as validity proofs or compact fraud proofs can be made. ZK rollups are constrained by the practicality of prover time, but there’s nothing stopping them in theory from allowing arbitrary state transitions. In addition to smart contracts, this means you can do atomic swaps to immediately withdraw funds. You can’t close a channel immediately, so consumers in your proposal need to wait a potentially long time to withdraw their funds. This is a downside that needs to be including when comparing to other proposals, such as ZK or optimistic rollups.
A few more issues I see:
- Your proposal is custodial/vulnerable to griefing, or degenerates to a rollup. The operator can withhold a payment from a consumer to a provider. The only recourse would then be to force this transaction to be processed by posting it on-chain. You can’t penalize the operator or the provider in this case since data unavailability is a non-uniquely attributable fault, the system degenerates into a rollup with extra steps.
- Exits are large. Each exit needs to be accompanied by a significant amount of data that must be posted on-chain.
Overall, your proposal is a simple modification on Plasma Cash: rather than having channels whose ownership is transferred and using a blockchain to prevent double-spending of ownership transfer, you set up channels and use the operator as an intermediary to route payments. This has the advantage over Plasma Cash that transaction sends are instant, though receives are not. Which isn’t much of an improvement over Plasma Cash, which you should have compared your system to rather than Plasma MVP. The disadvantage is that the operator can block payments, which causes degeneration to a rollup unless you want to allow griefing or make the operator a custodian.
This recent paper by Dziembowski et al. proves some lower bounds on Plasma constructions, namely either mass exits (and therefore not trust-minimized) or large exits. Your proposal falls under the latter category, except for where it degenerates to a rollup.
Reviewer recommendation: reject.