tomtau
commented
4 years ago one other thing is that there's no "trusted time" in enclaves -- one can only use the previous committed block's block time or genesis time (can be one of compile-time parameters)
needs some details: https://github.com/crypto-com/chain-docs/issues/196 (it needs to connect to at least 2 replicas/RPC hosts -- first the remote one, and when it catches up and successfully joins, it can use a local one) In particular, as the code runs inside enclaves, 1) it's trusted (-> needs to be simple and small without too many dependencies), 2) there's no "trusted" persistent storage (in particular, the host may replay the old state.
With regards to "light client state" / trusted anchor, it implies two parts:
1) (no state) the full genesis.json isn't known before TDBE is compiled: https://github.com/crypto-com/chain-docs/blob/master/docs/modules/tdbe.md#genesisjson-creation -- but some parts of it should be known and should be compile-time parameters https://github.com/crypto-com/chain/issues/1996 that are cross-checked 2) once a node "successfully" joins (either valid genesis.json with related mls/keypackage payload OR valid committed nodejointx) OR updates (successful committed SelfUpdateProposal after NACK timeout), it can "seal" its identity+HPKE keys altogether with the "light client state" at that point
Upon a restart, the runner should provide TDBE its "sealed" state from which it can recover -- as it will run the light client, it can also detect if it was provided an invalid/outdated state (e.g. if it restart, runs the light client from the recovered provided sealed state and then finds out a block with valid committed "SelfUpdateProposal" signed by its identity key... it can fail at that point, since the runner didn't provide the latest state and it won't have the correct HPKE key)