Confidential computing

01 research

The question

A decentralized cloud marketplace inverts the usual trust model: instead of one audited hyperscaler, compute comes from many independent providers with heterogeneous hardware and unknown intentions. The research question is what combination of trusted execution environments, remote attestation, encryption, and protocol-level verification lets a tenant treat that fleet as trustworthy-by-verification rather than trustworthy-by-brand.

02 research

Approach in the protocol

The open VirtEngine repository carries dedicated on-chain modules for this stream: x/enclave (trusted-execution and attestation integration), x/encryption (protocol encryption and key fingerprinting), x/cert (certificates), and x/audit (provider auditing). Device and hardware attestation likewise anchors the VEID identity pipeline — the same verify-the-hardware discipline applied to a different asset.

Around the modules sit operational research questions documented in the repository's HPC and provider-operations guides: how attestation evidence enters provider auditing, how encrypted payloads traverse the deployment pipeline, and how benchmark and fraud modules (x/benchmark, x/fraud) detect providers that misrepresent capacity.

03 research

Shared substrate with DSEMA

DSEMA's containment research and VirtEngine's confidential-computing research address complementary threats. Sandboxes and egress policies restrict what a workload can do; confidential execution and attestation address a different question about protecting workloads on provider-owned hardware. A gVisor-style sandbox does not by itself establish confidentiality against its host. Verified model loading, containment, and hardware evidence each need their own enforcement and testing. The proposed relationship is for DSEMA collectives to acquire resources through VirtEngine, with these controls composing across the boundary rather than substituting for one another.