Open rubenhorne opened 2 years ago
@integral-wizard Here is some more information: https://forum.dfinity.org/t/amd-sev-virtual-machine-support/6156
I would say that secure enclaves are mostly about privacy and integrity of the replica binaries. A secure enclave is basically a hardware module that is designed to encrypt and protect computations or storage from prying eyes, even from the direct owner of the secure enclave. Even if you have direct physical access to the enclave, you should not be able to break into it and thus read any encrypted storage in short or long term memory. Unfortunately it seems all enclaves are still subject to side-channel attacks. Thus secure enclaves will most likely never be good enough (maybe with quantum technologies they will be) alone to ensure privacy of data, but they will certainly help.
Secure enclaves can also possibly provide attestations that the replica binary (the Internet Computer node software) has not been tampered with, and is the same exact binary that the NNS has determined is correct. This would allow us to know with a degree of certainty that all nodes on the IC are running the correct replica binary. This could help prevent things like MEV and all sorts of other tricks that dishonest nodes could engage in.
Would it allow quicker onboarding of new nodes? Is this a prerequisite for decentralizing node onboarding?
I imagine this would help us onboard new nodes more quickly, and help us to decentralize the onboarding. If the secure enclaves are robust, and if we can implement mitigations to side-channel attacks (possibly through node shuffling: https://forum.dfinity.org/t/shuffling-node-memberships-of-subnets-an-exploratory-conversation/7478/52), it may become easier to bring on more nodes in a decentralized fashion since we will have less need to trust them.
What's the result of this improvement? Would it allow quicker onboarding of new nodes? Is this a prerequisite for decentralizing node onboarding?