allow enclave updates: migrate state to updated mrenclave

[brenzi]

Since the implementation of #47, we can't update enclave code after the state has been initialized because the state encryption key will only be shared with other enclaves with the same MRENCLAVE.

How will we migrate state securely when MRENCLAVE changes?
How can new enclave version convince the old one to provide it with the state? On-chain governance?

PoS voting

We could instantiate a democracy module inside the enclave and let all users vote anonymously on an upgrade of mrenclave. The majority stake wins. the old enclave would then share its state encryption key with any worker enclave that has the new MRENCLAVE

on-chain voting

the enclave registry knows nothing about the users of a worker enclave, so it could only have the workers vote, which doesn't reflect the stakeholder value in "incognito" tokens

MRSIGNER vendor key

The SGX-standard way would be to work with MRSIGNER instead of MRENCLAVE. But this would introduce centralizeation with the VENDOR holding the key for enclave signing.

sudo + update pallet

the immediate shortcut would be to use the sudo pallet which is already part of sgx-runtime. at a later stage, this could be replaced by the democracy pallet (PoS voting, see above)
We would need a special pallet just to register allowed MRENCLAVEs as an ordered update list:

fn update_mrenclave([32; u8], block)
  // only one mrenclave may be allowed at any time, so plan ahead and schedule by block nr

mu-ra would then query that registry when another worker requests provisioning

[brenzi]

decision:

• implement EnclaveUpdate pallet for sgx-runtime that allows sudo to update MRENCLAVE scheduled for a future block. mu-ra shall respect this list when authorizing/provisioning other workers (ahead of the update block)

migration process:

1. start old worker
2. TrustedCall sudo to update MRENCLAVE by block XYZ
3. run substratee-worker request-keys pointing to the old one
4. old worker will provision secrets to new worker (shielding-key and state_encryption_key)
5. new worker substratee-worker run listening on a new port
6. new worker registers enclave onchain (new signing-key, same URL but new port)
7. new worker starts scanning chain with chainrelay (without executing calls because the enclave logic may have changed)
8. upon block XYZ, the old worker stops processing blocks and writes the last state to disk (encrypted with state encryption key)
9. new worker starts processing blocks starting with XYZ

If new workers join, they will need access to all former enclaves to recreate state from genesis (or use snapshotting?)
questions

implications:

• the shielding key stays the same across updates. We may need another process to update that key in case of SGX vulnerabilites. So that we can use and share a new key with patched enclaves only (enclaves that registered RA with status OK after a specific date.

questions:

• it should actually be possible to leave the worker service running but just swap the enclave. That would prevent hiccups on the worker-api and would ease the handover of the snapshot. Not sure if we can hand over chain-relay db because that's actually sealed storage right now (does it need to be?)

[brenzi]

We should test onchain runtime upgrades as well, as trouble with encointer#42 showed

[brenzi]

foundations are laid: integritee-network/pallets#201