Dstack: speedrunning a p2p Confidential VM

[h4x3rotab]

Amazing prototype. We have talked with a lot of developers and I believe this is exactly the direction they want to see – an SDK that is:

• Easy to use: allow to convert any Docker image to run inside a TEE CVM with minimal efforts
• Secure by default: follow the best practices for TEE security
• Not vendor lock-in: abstract the hardware / cloud provider details away from the developers

At the same time, after @socrates1024 shared his idea of dstack, we (the Phala team) have also played around the idea and built our own version of “dstack”: GitHub - Phala-Network/dstack.

The intention was to prototype it and eventually merge to “Tstack” as well. I’m still putting our ideas together as a forum post to share later.

Inline comments below:

@socrates1024

For the first node, we simply check the quote generated at “bootstrap” time into the source code repository. It becomes part of the security auditor’s scope of attention, just like smart contract constructor parameters.

Brilliant idea. So after the security audit, the auditor essentially establishes the trust from the code repo to the binary by its hash in the measurement.

@socrates1024

all of the DCAP quote handling is kept off-chain, keeping gas costs very low.

Is the first quote still verified onchain? If not, do you mean to delegate the verification to the social consensus, i.e. let a DAO to check and vote for the inclusion?

@socrates1024

The replicatoor key is also used to provide EVM-friendly remote attestations, simply by ecdsa-signing a message.

Yeah, I’m for this approach. It fits into the framework of Early Thoughts on Decentralized Root-of-Trust.

@socrates1024

Since we can’t make ordinary browsers do this proactive check, we can instead do our best with Certificate Transparency

Great point! I’ve put a lot of thoughts on the “Unstoppable TLS” idea. We call it “RA-HTTPS” internally, focusing on the browser compatibility and easier verification. The basic idea is by combining content addressing (e.g. 0xOrchAddr.pod.dstack.dev) and the access control of TLS certificate issuance. Passive defense by monitoring Certificate Transparency is a good way. We also explored some other proactive defense mechanism. I think we can share more ideas on this soon.

@socrates1024

encourage moving complexity out of the TEE and into the untrusted host where it’s more manageable

Agree. Another problem around it is about the boundary of trusted code and untrusted (user) code in the guest CVM. We also had a lot of thoughts on it. Hope we can publish some discussion soon.

@socrates1024

We did not cover key rotation yet

It’s going to be hard. Especially the key rotation will put a computation burden to apps with a large database.

Re. KubernEthes (k9s😂): How does local test look like? I think we can have some kind of mock mode to run a standalone stack without accessing blockchain.