Asylo

RenVM is currently at the beginning of phase sub-zero.

0. Too Long; Didn't Read
1. Design
   1. Driver
   2. Networking
   3. Consensus and MPC
   4. Multichain
2. Attestation
   1. Safety
   2. Liveliness
3. Support
4. References

Design

A brief overview of the requirements:

• Nodes would be required to run within a secure hardware enclave. Just as nodes currently require other nodes to have their identities bonded by 100K REN, so too would they require a success remote attestation.
• Nodes would be required to communicate through Asylo's gRPC security stack. This provides enclave-to-enclave protection between remote enclaves.
• Nodes would be required to run their underlying blockchain node infrastructure within a secure hardware enclave.

Driver

TODO

Networking

TODO

Consensus and MPC

TODO

Multichain

TODO

Attestation

Attestation makes it possible for third-parties to cryptographically verify that a node in RenVM is running a signed release of RenVM node software, and is running that software in a secure hardware enclave. This requires trust in:

• Intel SGX (or AMD SEV)
• Ren developers
• Asylo developers

The former can be mitigated by using multiple secure hardware enclaves as support becomes available. The latter two are mitigated by nature of being open-source.

Safety

TODO

Liveliness

TODO

Support

Asylo supports all of the features required on Intel SGX. The Ren core developer team could provide resources to help with adding support for other secure hardware enclave implementations as they become available. This should be prioritised, because it reduces reliance on one hardware provider. Google and Azure both offer confidential computing platforms that give users access to secure hardware enclaves.

References

Further reading material:

• Asylo
• Trusted execution environments
• AMD SEV
• Intel SGX
• Intel SGX Explained
• Intel SGX hardware release enclaves
• Secure gRPC Example