[go: up one dir, main page]

Scoru: avoid current state of inbox during the snapshot

When a refutation is started, the protocol takes a snapshot of the current level inbox and put in the game. However, the rollup node will notice that a refutation has started in the next tezos block.

So the problematic situation is when in a tezos level x you have the operations (for the same rollup):

Sc_add_messages -> Sc_add_messages -> Sc_rollup_refute -> Sc_add_messages -> Sc_add_messages
      op0               op1                 op2                op3                 op4

The refutation will start on the op2, the inbox's snapshot for the current level x will contain op0; op1. But, when the rollup node will notice that a refutation has started in the previous block, its inbox will contain op0; op1; op3; op4. Thus, it will most likely produce invalid inclusion proofs and lose the game.

@thomas.athorne found a potential solution which is:

Just occurred to me, to save you a headache in the rollup node, you could change take_snapshot to also take the current level. Then it could include the current level_tree only if it's lower than the current level. This should be possible because that's called in Sc_rollup_refutation_storage where we have access to current level.

Then it could build the snapshot missing out the current level_tree (which avoids the headache-inducing possibility of a snapshot 'half-way-through' a level). The refutation won't depend on the current level, but it might depend on the current level_tree if it's been a long time since the last message.

It seems to be a valid solution. We now need to implement it and test the two potential scenario:

  1. There is a inbox in construction in the current level (i.e. current level_tree is equal to ctxt.level). We need to take the level_tree's predecessor.
  2. There is no inbox in the current_level, we can snapshot the level_tree.
Edited by Valentin Chaboche