Manage the lifecycle of new nodes

[guyz]

New nodes should not be able to start syncing blocks UNTIL they are confirmed as a registered node. We should look into InitChainer and EndBlocker.

New node

• register node
  • generate report for enclave
    Get quote - SafeTrace ref
  • using enigmad generate key pair inside of the enclave
  • seal + backup private key
  • handle loading of private key on node init
  • using IAS (proxy node) get report for public key (signed quote)
  • enigmacli send tx with public key as a param + report
  • bootstrap node handling (only happens for the first node)
    Initialization logic for the enclave. See the logic described here in Phase 1 (register_node()): https://forum.enigma.co/t/network-key-management-agreement/1324
    Check whether this can happen automatically inside the global InitChainer (also whether this can listen to new blocks and block execution until the new node is confirmed).

Existing nodes

• confirm node
  • get register_node() tx
  • pass (new_node_public_key, report) to the enclave
  • verify report locally (using hard coded intel's pub key)
    Discovery ref #1
    Discovery ref #2
  • take sk_io with new_node_public_key and derive a new symmetric key (using derive_key https://forum.enigma.co/t/input-output-state-encryption-decryption-protocol/1325)
  • encrypt seed with the new symmetric key from the previous step
  • return from the enclave with the encrypted seed
  • write the encrypted seed to chain
    Initialization logic for the enclave. See the logic described here in Phases 2+3: https://forum.enigma.co/t/network-key-management-agreement/1324

New node again

• register_node()
  • decrypt seed with pk_io and my private key (using derive_key https://forum.enigma.co/t/input-output-state-encryption-decryption-protocol/1325). With the single shared 256-bit seed generated above, we can run the CSPRNG several times to get other 256-bit pseudo-random keys:
  • First 256 bits: used to generate (sk_io, pk_io) --> a key pair whose pubkey can be used by users to derive new symmetric encryption keys for encrypting input/outputs. The protocol above needs to be changed so that the first validator also broadcasts pk_io to the network.
  • Next 256 bits: used to generate master_state_key --> a symmetric key used to encrypt contract state. In practice, this is a seed we can use to derive further keys.
  • Next 256 bits: used to generate master_iv --> this is a seed that can be used to generate fresh IVs for encrypting outputs. That’s how the network can avoid non-determinism and still maintain the security of symmetric ciphers.
  • Next 256 bits: used to generate master_rand_seed --> this is a seed that can be used to generate randomness.
  • check how to pass this to my InitChainer to be able to sync blocks

[assafmo]

In InitChainer a node should check whether they're the first node and if so then call ecall_bootstrap (better name TBD) which runs the bootstrap protocol and returns encrypted "registration values" to be recorded on-chain.

[assafmo]

From https://forum.enigma.co/t/network-key-management-agreement/1324:

1. When the first validator joins in, they need to look at the blockchain’s state and determine that there are no existing registered validators.

2. In the enclave, call register_validator(first_validator=True).

This should always happen for each node in InitChainer.

[assafmo]

3. Outside of the enclave, the validator should send the quote to Intel’s Attestation Service (IAS) - potentially through Enigma’s proxy as was the case with Discovery, and get a signed report.

We need to check whether this can happen offline.
Or whether we can reach a chain-of-trust without using the IAS.

[assafmo]

4. Broadcast a register_validator(pk_v, report) transaction.

I'm not sure this is still needed, as we decided the at first all nodes will share the master key, so after the initial node registration becoming a validator is the same as in a vanilla tendermint chain.

[assafmo]

5. On-chain: check that the report is valid on-chain. If it is, and because there are no other validators, immediately approve this validator.

Also isn't needed anymore ☝️

[assafmo]

Any registered validator can see the pending validator’s request on chain. Let’s say the pending validator is called v2 and the registered validator is called v1. v1 should then call share_key(pk_v2, report)

This might be done in the global EndBlocker and be part of the consensus. WIll be a much better UX.