Skip to content

TEE Implementation #1173

Open @tcharchian opened 2026-05-16 06:45 UTC 4 comments Updated 2026-09-25 10:36 UTC
up-for-grabs protocol

Discussed in https://github.com/gonka-ai/gonka/discussions/951

Originally posted by **mtvnastya** March 25, 2026 # TEE This proposal outlines the integration of Trusted Execution Environments (TEE) into the Gonka network architecture. By leveraging hardware-level isolation (Intel TDX, AMD SEV-SNP, NVIDIA Confidential Compute), we can protect user payloads and inference data from the physical hosts/miners, enabling true "Confidential MLNodes." This document proposes changes to the node registry, validation pipeline, and economic incentives. ## Problem Currently, user requests data sent to the Gonka network is hidden from the public but transparent to the specific host (miner) executing and validating the workload. Even with off-chain payloads, a malicious operator with physical access to the machine can access the data by using custom binaries or modifying the execution environment. For enterprise and privacy-sensitive adoption, trust in the protocol must supersede trust in the hardware operator. ## Proposal We propose a new node class: the Confidential MLNode. This node operates within a TEE, isolating the full Virtual Machine (VM) from the hypervisor. Supported CPUs: - Intel TDX: https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html - AMD SEV-SNP: https://www.amd.com/en/developer/sev.html Both technologies support attaching NVIDIA GPUs with Confidential Compute: - https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf A VM with an attached GPU can encrypt all in-memory data, data transferred to the GPU, and data in GPU memory from the hypervisor. By carefully modifying how MLNode works with data: - Inferences are decrypted only in-memory - No sensitive data is written to disk - No open TCP ports are used for unencrypted data transfer - No sensitive data appears in logs The full inference pipeline can be protected from both the host/miner and the hypervisor (server owner in the case of rented servers). Using a temporary public key generated by the TEE-protected MLNode enables end-to-end data encryption without any decrypted data existing in unprotected memory. ## Architecture Upgrade ### MLNode - VM with MLNode is launched from an image with metadata saved on-chain (model embedded). Full MLNode behavior is defined by its REST API - VM generates a key pair for data encryption/decryption - VM provides an attestation certificate signed by the CPU's hardware module. The signed data includes: - Hardware information - GPU information, including Confidential Compute enabled, exclusive access to GPU, and GPU attestation - Exact VM metadata - Public key from generated key pair - Proof that VM launched from correct entrypoint (target application) Note: If the VM is restarted or the image is replaced, the private key will be lost. - Host publishes this certificate on-chain **Open Question 1:** Should the certificate be validated on-chain? All requests to the Confidential MLNode are encrypted using the public key from the certificate. --- Relevant materials: Framework to simplify TEE deployment: - https://github.com/Dstack-TEE/dstack Insightful paper about NVIDIA Confidential Compute: - https://arxiv.org/pdf/2507.02770 ### Network Node #### 1. New MLNode Type Confidential MLNode with a separate pipeline for scheduling inferences. These nodes do not require inference validation. Confidential MLNodes have an associated attestation certificate and public key. #### 2. Certificate Validation Requirements for certificate validation: - Publishing certificates to the blockchain - Maintaining Intel and AMD root certificates (Root of Trust keys) for verification - Maintaining a list of secure software versions and excluded (untrusted) certificates **Open Question 2:** Should full certificate validation be performed on-chain? Probably yes, on recording. #### 3. Inference Pipeline Current `/chat/completions` request flow: 
Dev -> Transfer Agent (Network Node) -> Executor (Network Node) -> Executor (MLNode)
image (64) https://what-is-gonka.hashnode.dev/decentralized-ai-inference-balancing-security-and-performance In the current system, any request is scheduled to any executor. For Confidential MLNodes, the workflow changes: - User obtains the Confidential MLNode's public key for encryption - User encrypts the payload using the public key - Encrypted request is sent to and decrypted on the specific Confidential MLNode This design enables users to send `/chat/completions` requests directly to the Confidential MLNode without proxying through multiple Network Nodes. ##### Possible Pipeline & Payment Proposed workflow: 1. User sends a request to any Network Node to reserve a Confidential MLNode with quota (possibly for a long-living session) 2. Chain randomly assigns a Confidential MLNode, moves quota from user's account to escrow, returns the Confidential MLNode's public key and certificate to the user 3. User encrypts payload and sends to MLNode: - Option 1: Directly to MLNode - Option 2: Through any Network Node in the network 4. Confidential MLNode performs computation and encrypts response with the user's public key 5. User decrypts response with their private key 6. Confidential MLNode signs response metadata (used tokens) and sends to its Network Node 7. Network Node submits signed metadata to claim coins from escrow. Confidential MLNode signature is verified on-chain before claim Note: Metadata can be sent in batches periodically to optimize on-chain transactions. Unclaimed quota is automatically refunded at the next epoch boundary. Signed metadata from a TEE key is inherently trusted - the execution environment is pre-defined and verified via attestation. The MLNode cannot produce valid signatures without running in the attested TEE, which guarantees the correct binary ran. options (1) --- **Open Question 3:** How to provide redundancy when a Confidential MLNode becomes unavailable? ### Economic Incentive - Confidential MLNode inferences do not need validation => eliminating the need to share work rewards with validators => eliminating need to generate and store artifacts for validation - Confidential MLNodes do not need to participate in all PoC rounds if they maintain the same key pair, since this proves consistent hardware - Confidential Inferences are priced in a separate dynamic pricing group per model, making these inferences more profitable when demand is high **Open Question 4:** Since Confidential MLNodes have less validation overhead, should they receive higher bitcoin-style rewards to incentivize enabling TEE?

💬 Comments (4)

@x0152 commented 2026-05-25 21:11 UTC

Some first experiments on this in #1246 - covers the wiring end-to-end (chain, dapi, ml-node, devshard) + a Phala CVM smoke test

Not a final implementation, but should give a head start

@mkostrus-gif commented 2026-07-02 19:00 UTC

Strong +1 for prioritizing this.

My blocker is practical, not theoretical: I run AI agents over private operational context, and I cannot route real prompts/responses through Gonka while the selected host can read them. Privacy sanitization is useful as a temporary guardrail, but it does not solve the core threat model.

The feature I would actually use is an attested private inference path: client-verifiable Confidential MLNode/TEE, encrypted prompts and responses, and no sensitive payloads in host-readable logs or disk.

I'm happy to help test an MVP and provide acceptance criteria from real agent workloads. Is there a current roadmap after #1246 for the next milestone where users can help validate it?

@x0152 commented 2026-07-04 13:32 UTC

Hi, thanks for the message!

1246 is a first experiments PR - it connects the private path across chain, dapi and ml-node, with a Phala TDX smoke test. It's not the MVP yet, still some work before we can really test it

Rough plan (from my mind): - Review and land #1246 as the base - Add dual attestation (intel-tdx + nvidia-cc) so the GPU side is covered too, not just the CPU - Do a full end-to-end run on a localtestnet with real Intel TDX + NVIDIA CC hardware (Phala Cloud is probably the easiest for that)

Just note the MVP is only to show how this can be integrated - not a secure, production-ready version yet. It's just a first direction to build on

Maybe you could start with reviewing #1246 and let me know what you think? From there we can discuss the next steps. And if you have any questions, feel free to ask

@zpoken commented 2026-09-25 10:36 UTC

Hi all,

We'd like to share a proposal that builds on the current status and the work in PR #1246, where only the initial wiring was tested (a TDX smoke test on a cloud CVM). Reviewing the PR, we found several gaps that need to be closed before it can protect anything. The verifier checks only MRTD, so the kernel and the application are not pinned, and there are no DEBUG, TCB or CRL checks. report_data binds only the public key, so evidence can be replayed, and VERIFIED status is carried forward between epochs. There is no GPU attestation, every node gets the same KMS-derived key, and the encrypted route bypasses devshard accounting and validation.

We wrote a draft proposal that addresses these points and covers Intel TDX, AMD SEV-SNP and NVIDIA CC: https://github.com/zpoken/gonka/tree/zpoken/tee-proposal/proposals/confidential-mlnode. Alongside it there is an attestation glossary that explains MRTD, RTMR0–3, HOST_DATA and NVIDIA evidence with vendor spec sources: https://github.com/zpoken/gonka/blob/zpoken/tee-proposal/proposals/confidential-mlnode/attestation-glossary.md.

The proposal describes a self-hosted Confidential MLNode on dstack without a KMS, where keys are generated inside the CVM on every boot. The OS image, compose file, model weights (via dm-verity), GPU policy and VM shapes are pinned through an on-chain governance registry. Attestation is bound to the chain, epoch, participant and node, and NVIDIA GPU evidence is bound into the CPU quote. Only small commitments (about 250 bytes) go on-chain, while the evidence itself is served off-chain, and a challenge flow allows a re-vote on wrong decisions. Requests are encrypted through devshard to several attested nodes of the slot's host, usage is covered by signed receipts, and validation between enclaves is driven by validators.

🔄 Auto-synced from Issue #1173 every hour.