@felipeargento @augusto We at the Kleros Cooperative have also had some thoughts on these topics that conceivably could be of interest to you: research-docs/interactivecomputationgamesnotes.pdf at master · kleros/research-docs · GitHub (We are not rollup-builders; Kleros is an application layer project, so these questions aren’t our main research focuses. Correspondingly the linked notes are pretty drafty.)
If the attacker has x resources, then the total number of periods that are required for the game to resolve in our proposal are O((logx)^3), so asymptotically it is worse than the proposal in your work. We don’t have an implementation of this, but I would be curious to see how it compares practically. We don’t use the hashing idea you do, so players are able to strategically lie about the intermediate states of their calculation. Instead, our approach is to have a matching algorithm that places different players into many-vs-1 games against each other, and if the answers of the many diverge they get rematched into subgames. The matching algorithm itself can be implemented optimistically so that every time the verifier needs to match participants together, you need to wait for a challenge period. Though the specific optimistic game of verifying matches doesn’t need to be interactive. The on-chain verifier can compare each new submission it gets to whatever its current best submission is and if the new submission is better it becomes the pending match. Then, in the notes linked above, we provide an analysis of how many periods an attacker with x resources can delay, for example, by forcing the match function to be called.
I also look forward to seeing more information about “protocol 3”!