OP node shutter state machine

[fredo]

OP node state machine

The OP node is responsible for requesting the next block via the engine API. Which type of block in a shutter system is to be requested is determined by the state of the shutter system contracts.
From the OP node's perspective there are three different block types to be requested:

• (1) Shutterized Block (submits the decryption key via engine API)
• (2) Deactivation Block (submits special decryption key via engine which will disable shutter)
• (3) Vanilla Block (without submitting a decryption key)

Requirements

• The rollup should never stall (delayed is ok)
• The rollup should thus fallback to vanilla mode
• The op-node has always the ability to disable shutter
• The op-node should be able to realize that shutter is enabled and give the shutter system enough time to provide decryption keys
• There should be a different set of conditions when to request each block type

Conditions

• If shutter is enabled
  • Wait time X until a decryption key is received
  • Wait at least the minimum block time
• If shutter is disabled
  • Wait the minimum block time
• If time X is passed and shutter is enabled
  • request deactivation block

Internal State

The op node has different conditions to be met to request the the next block.
For that it needs to keep some internal state to know in which mode the rollup is running.
In its easiest form it's a flag of what the op node thinks the next block should be. Shutterized or unshutterized.

However, it is possible that the node's state is not equal to the actual state at any point in time, thus the node could accidentally request a different block type. This must result in an error being returned by op-geth.
This actually is the input to the internal op-node's shutter state transition.

stateDiagram
 direction LR
 s1: Disabled
     note left of s1
        success by engine API => Block could be produced
        error by engine API => expects decryption key
    end note
 s2: Enabled
    note right of s2
        success by engine API => Block could be produced in time with decryption key
        error by Engine API => expects vanilla block 
        timeout => did not receive decryption key during configured shutter timeout 
    end note
 
 s1 --> s2: error / (1)
 s2 --> s1: error / (3)
 s2 --> s1: timeout / (2)
 s1 --> s1: success / (3)
 s2 --> s2: success / (1)

Loading

[fredo]

Optionally we could also trigger a state change when we are in disabled and receive a decryption key. The op node could blindly trust the shutter node and assume that shutter got enabled. It would look like this

stateDiagram
 direction LR
 s1: Disabled
     note left of s1
        success by engine API => Block could be produced
        error by engine API => expects decryption key
    end note
 s2: Enabled
    note right of s2
        success by engine API => Block could be produced in time with decryption key
        error by Engine API => expects vanilla block 
        timeout => did not receive decryption key during configured shutter timeout 
    end note
 
 s1 --> s2: error / (1)
 s1 --> s2: decryption key / (1)
 s2 --> s1: error / (3)
 s2 --> s1: timeout / (2)
 s1 --> s1: success / (3)
 s2 --> s2: success / (1)

Loading

[jannikluhn]

Looks reasonable to me.

Optionally we could also trigger a state change when we are in disabled and receive a decryption key. The op node could blindly trust the shutter node and assume that shutter got enabled. It would look like this

Both could work, the second saves one "cycle" (error returned from op-geth) which is negligible given that shutter hopefully won't be disabled and enabled very frequently. So I'd go with whatever is cleaner to implement (probably the original option).