shutter-node - shutter P2P-network and shop-contracts integration

[ezdac]

The shutter node will be a separate application that serves as a gateway to the shutter P2P network and reading the shutter contract's state for the op-node.
It will expose an HTTP API where the op-node can poll for the decryption-key of a certain L2 block-number.

• define the HTTP API's technology (push/pull/longpoll, RPC/REST, WS, etc.):

  • The shutter-node exposes a blocking GET endpoint, so that the op-node can long-poll for a block-numbers decryption-key. The op-node can remotely call (however implemented) getDecryptionKey(blocknumber int). The endpoint will either return immediately when a key has been received already, or it will block until it receives the key and then return.
    Like that, the op-node can already call getDecryptionKey(n+1), when n is the current block-number to be build.
    Keyper's then wait for their op-geth to return n from eth_blockNumber and release their key for n+1. Once the key is received by the shutter node, it will return the key immediately to the blocking http request.

• define the HTTP API's methods / state-transfer model

• P2P Handler / Validator functions

• L2 JSON RPC client

  • contract event subscription worker (shutter paused, new keyper sets, public keys)
  • eth_blockNumber new unsafe head event worker

• internal promise based event listening for long-polling GET requests

• concurrency safe data-structure for received events & data persistence (database)

[fredo]

Shutter node

The shutter node is the instance which connects the Keyper network with the OP node. It is responsible for storing the decryption keys published by the keyper network.

information flow

• The shutter node listens to new keys generated by the keypers
• The shutter node will verify the integrity and validity of the message
• The shutter node listens to the chain to read the latest state of the shutter contracts
• The shutter node verifies if the validated key corresponds to the chain state (is shutter enabled? Is it based on the correct EON key)
• The key will be written in a database
• The OP node will query a specific key via long polling to an exposed endpoint

Verification

There is a two step process

1) Message validation

The received message containing the decryption key, epoch ID (block number) and eon ID will validate if the key is valid for the eon key stored on chain for the given ID, and the epoch id.
If the eon key is not on chain validation will fail and the key will be dropped.

2) Verification against the chain state

This verification of the key for block N must run against the state for block N-1. So if block N-1 has not been seen by the shutter node, the shutter node must wait until Block N-1 has been seen.
It will be checked if shutter is active and if the eon key is aktive for the next block.

DB content

The shutter node will only write the key into the DB (and thus provide this key to the endpoint for the OP node) iff the key validated successful both steps. I.e. if shutter is disabled keys will not be written into the DB.
The content of the DB will not make any statement of completeness. Keys could be missing if i.e. the shutter node were offline or the shutter node didn't see the eon key yet, thus validation would fail.

Endpoint

The endpoint will be a long polling GET endpoint. getDecryptionKey requires a block number as input. In case the key has not been written into the DB, but could be in the future the call will be blocking until one of the following events occur the key for the requested block number is available.

The requester (currently the OP node) is responsible for handling requests which do not return.

@ezdac will suggest an API standard.