Private validator mode (via TEE)

[bobbinth]

With our current guardrails, the users send private transaction data to the operator (the RPC component), this private data then gets sent to the validator that uses it to re-run the transactions and stores this data for future potential use. In this scenario, the private data is fully visible to:

• The entity that is running the RPC component.
• The entity that is running the validator.

It may be desirable to make sure that neither the validator nor the RPC component can see this private data directly. Ideally, viewing this data would require a viewing key that is shared across multiple parties. One way to accomplish this is as follows:

• The validator runs in a TEE.
• The validator also has a public encryption key.
• The user encrypts the private data they include with the transaction using the validator's encryption key.
• The RPC component forwards the encrypted data to the validator (similar to how it does now).
• The validator decrypts the data, re-executes the transaction, and does everything else that it does now - but all of this is happening in a TEE, and so, not directly visible to the operator of the validator.
• The validator then re-encrypts the data using a key that has a corresponding viewing key which is threshold-shared among $n$ parties.

The end result is:

• Neither the RPC operator nor the validator see the data directly, but we still get the same guardrails we have now.
• Some subset of the $n$ parties can come together to decrypt the data if/when required.

Conceptually, the work here can be split into two parts:

1. User encrypts the private data that they send to the node, and the validator has the decryption key. This ensures that the RPC operator does not see the private data, but the validator does still see it directly.
2. Run the validator in a TEE and re-encrypt the data so that it can be decrypted only with a viewing key that is shared amongst $n$ parties.

[huitseeker]

This is exciting! Here's a straw man proposal:

Proposed MVP

I propose that the MVP protect only TransactionInputs.

This is enough for the first privacy cut. RPC does not need to read TransactionInputs to route the request, and the Block-producer does not need them at all. The Validator can receive encrypted inputs and pass them into the TEE validation path for decryption, re-execution, and comparison against the submitted proof.

The TEE stage protects more than the input wire path. Encrypted storage keeps persistent validator data private from the operator under the TEE security model, so execution data written during validation is also covered by the trusted boundary.

The MVP should do this:

1. Keep protobuf and tonic/gRPC.
2. Add a private-input submission path for TransactionInputs.
3. Put private-mode gRPC communication under mTLS, authenticating at least the validator.
4. Start with an authenticated node key.
5. Move the decrypting endpoint and key into a DStack TEE in the next stage.
6. Route TransactionInputs only to the trusted validator path, not to the block producer.
7. Store any private recovery/viewing material under verifiable threshold decryption.

Edit 2026-05-22: revised MVP framing:

1. Keep protobuf and tonic/gRPC.
2. Add a private-input payload path for TransactionInputs.
3. Use partial payload encryption: the client encrypts only TransactionInputs to a TEE-bound public key.
4. Keep ProvenTransaction metadata visible to the normal RPC, Validator, mempool, and Block-producer flow.
5. Route encrypted TransactionInputs through RPC to Validator as opaque payload.
6. Have the Validator hand encrypted inputs to the TEE validation path; only the TEE decrypts and re-executes.
7. Store private input material only after the TEE re-encrypts it under threshold viewing/recovery.

This MVP does not hide every field in ProvenTransaction. Account ids, nullifiers, commitments, fees, proofs, and reference-block data stay visible. That is acceptable for the first cut.

Private Input Transport

Use mTLS plus protobuf for the MVP.

For the first patch, clients authenticate the validator or node endpoint with mTLS. This gives a small working path and proves the data-flow change. In the TEE stage, the same role moves to a TEE-bound key. The client must then verify fresh TEE attestation before trusting that key.

This works if the RPC decryptor is inside the trusted boundary. The trusted endpoint receives TransactionInputs, then forwards them to validator logic without exposing them to the host operator.

The MVP does not need a nested HPKE envelope if mTLS terminates inside the trusted boundary. A payload envelope can be added later if the trusted decryptor and validator are split, or if we need ciphertext to pass through an untrusted RPC process.

Sources:

• mTLS overview
• tonic transport docs
• tonic client TLS config
• tonic server TLS config
• Rustls gRPC mTLS example

Edit 2026-05-22: replace the transport-encryption boundary with partial payload encryption.

Use the existing protobuf/gRPC flow, but encrypt TransactionInputs in the payload. The user submits ProvenTransaction + Enc_TEE(TransactionInputs). RPC can still perform checks over visible transaction data. Validator is the component that needs plaintext inputs, because it re-executes and checks that they match the submitted proof, so it should pass encrypted inputs to the TEE validation path.

Vocabulary note: RPC, Store, Validator, mempool, and Block-producer are logical components here. The docs are useful vocabulary, but not exact deployment boundaries; Store + RPC + Block-producer may be merged in a deployment.

Internal transport encryption can still be added later as defense in depth, but it is not the MVP privacy boundary.

TEE Stack

Use DStack for the TEE stage.

DStack is the best current fit because it is an app stack, not only an attestation experiment. It supports TEE app identity, KMS/key release, gateway identity, encrypted network and disk defaults, reproducible image work, and measured app updates. Its Rust SDK was added in DStack PR 161, which makes it usable from validator code.

The Validator should publish:

• TEE-bound encryption public key;
• key id and validity range;
• TEE quote binding that key;
• app measurement;
• upgrade policy or accepted measurement set.

The MVP can start with a narrow allowed-measurement list. It does not need a full production governance flow.

DStack sources:

• DStack repository
• DStack paper
• DStack verification walkthrough

Threshold Viewing and Recovery

Use verifiable threshold decryption for stored private data.

The Validator should not store long-lived plaintext inputs. After re-execution, it should re-encrypt any private material that must be kept for recovery or later viewing. The decryption path should require threshold shares. Bad shares should be rejected or attributable.

The E_htdh1 variant in Context-Dependent Threshold Decryption and its Applications is the best current target. It is simpler than pairing-based threshold IBE designs and does not require pairings. It also lets decryption be tied to context.

The decryption context should include the transaction id, block or epoch, validator identity, and approval id if governance approval is required.

The MVP can mock the threshold layer or use simple envelope encryption while keeping the storage format ready for threshold decryption. The design target should still be verifiable threshold decryption.

Prover RPC

Use mTLS for prover RPC in the PoC. This assumes no remote prover support for the MVP.

Logging and Telemetry

Private mode should use a denylist for sensitive fields and an allowlist for telemetry.

The denylist should include:

• raw TransactionInputs;
• raw protobuf transaction requests;
• account deltas;
• input note details;
• output note details;
• panic payloads or debug logs that include full requests.

Useful telemetry can stay: request counts, validation time, decrypt failures by reason, attestation age, key id, queue depth, storage errors, and block signing results.

Out of Scope for MVP

The MVP should not solve every privacy problem.

Out of scope:

• hiding all visible ProvenTransaction metadata;
• remote prover support
• proof-of-cloud admission;
• full production governance for measurement updates;
• browser or gRPC-web private prover support;
• full account recovery UX.

Proof of cloud is good V2 work. It can strengthen the claim that a valid TEE quote came from an accepted infrastructure environment. It should not block the MVP. See Proof of Cloud and the Flashbots note Mind the Gap: TEE Proof of Cloud.

**Open questions**

Cryptography

• What threshold parameters and membership model should the committee use?
• Should threshold viewing keys be global, per epoch, per validator, or per stored blob?
• Does viewing need context-dependent threshold decryption so decryption is bound to transaction id, block number, epoch, validator identity, or governance approval id?

TEE

• How is attestation freshness handled?
• How are validator upgrades, measurement changes, and key rotation handled?
• Which side-channel, physical, rollback, denial-of-service, and application-bug risks are explicitly out of scope?
• Which DStack key path should private validator mode use: KMS-style key release, app-local key derivation, or a Miden-specific wrapper around those capabilities?
• Should private mode require backup TEEs in addition to threshold recovery, or is threshold recovery enough for mainnet design?

Telemetry

• Is the OpenTelemetry collector inside the trusted boundary, or does private mode require encrypted/export-filtered telemetry?
• Can CI enforce that TransactionInputs, raw protobuf requests, account deltas, and note details are not logged?

Recovery and Scope

• What recovery guarantees belong in the design before mainnet?

V2

• Should private-validator admission require fresh proof-of-cloud evidence in addition to TEE attestation?

[bobbinth]

I think encrypting just the TransactionInputs part of the ProvenTransaction is the way to go (even beyond the MVP - as the other fields of ProvenTransaction make it to the chain anyways - and so, don't reveal anything that will be publicly known anyways).

I do wonder if the first step for this could avoid TEEs (for now) and only introduce privacy against the RPC operator, but not against the validator. Specifically, the user would encrypt TransactionInputs using validator's key, and then the validator would decrypt them and w/e processing it does now. This should be pretty straight-forward to do now - but there are a couple of open questions:

• How does the user learn about the key they need to use for encryption? One option is to use the validator's key included in the block header, but:
  • We'd be using the same key for encryption and signing - which is usually discouraged.
  • Not super clear how to handle validator rotations (e.g., the user encrypted there data with validator X, but now, 5 blocks later, validator Y is processing transactions).
• We have been discussing expanding the number of validator from one to a few more (e.g., 3 at most). This would not be a mechanism - e.g., all validators need to sing. But it still has a number of benefits (better security, validators could act as a natural source of distributed backups). But in case we have more than 1 validator - how would the encryption works? The naive approach is to use all e.g., 3 keys to encrypt the data and triple the payload - but there are probably better approaches.

[bobbinth]

The way I'm seeing things is that we have two types of keys. There is a submission key (client to validator), used to hide the transaction inputs from the RPC operator until the validator decrypts and opens them. And there is a second key, the viewing key, which is the one the validator re-encrypts the transaction inputs with after decrypting them in order to validate the transaction.

I'm wondering if we can get away with a single key for this (i.e., no separate keys for encryption and viewing). To describe the endstate first (i.e., the state which involves TEEs):

Let's assume we have 3 validators, and each of these is running a TEE. The key setup is as follows:

• Each validator has their own key - the signing key. The public keys of the signing keys are included in the block headers (same as now), and for a block $n$ to be valid, each validator needs to sign it with the public key committed to in block $n - 1$.
• In addition to the signing key, there is a single encryption key. This key is shared by all validators. The encryption key lives inside the TEE, and we'll need to have a setup protocol that allows all 3 validators to end up with the same encryption key in their TEEs w/o anyone outside of TEEs knowing this key.

When the user sends a transaction to the network, the following happens:

• The user gets the encryption key from the node. This key needs to come with proper attestation that proves to the user that this key is managed by the TEEs.
• The user then uses our standard IES encryption (probably X25519XChaCha20Poly1305) to encrypt TransactionInputs for their transaction.
• Once the RPC gets the transaction data, it forwards it to the validators (same as now), and validators' TEEs decrypt the corresponding TransactionInputs, re-execute the transaction etc.
• Once the transaction is confirmed to be valid, the validator stores the originally-encrypted transaction on disk.

This does mean that technically, any of the 3 TEEs can decrypt the transaction at a later point in time - but I think we can get around this. I'm assuming that we could write the code that requires extra checks before decrypting a transaction and returning plaintext to the user. For example, decrypting may require a special signature of 2 out of 3 validators on the transaction ID. Once someone has obtained such a signature, they could use any of the TEEs to decrypt a specific transaction - but not more than that.

Here, I believe, we'd be relying on the security of the TEE to verify that it has necessary signatures before returning plaintext to the user - but I think that's fine, and it allows us to avoid the need for threshold encryption/decryption.

I think this would be a pretty simple setup - but let me know if I'm missing something somewhere.

---

The above approach also makes it pretty easy to build the first step (i.e., no TEEs yet) which, from the user's standpoint, would remain basically the same once we involve the TEEs. Specifically, I think we could do the following:

1. Add something like GetTransactionEncryptionKey endpoint to the RPC. This endpoint would need to return an X25519 public key, together with the current validator's signature over this key. The user would get the validator's signing key from the chain (e.g., the latest block) and verify the signature to make sure the encryption key came from the validator.
2. The user then would use the X25519XChaCha20Poly1305 IES scheme to encrypt the TransactionInputs (we already have all the machinery for this, I believe), and then send the transaction to the network (same as now).
3. The transaction would be forwarded to the validator (same as now), and the validator would decrypt the data using their encryption key, and then re-execute the transaction etc. (same as now).

So, the only changes right now that are needed:

• Node:
  • Validator: add the encryption key as another key that the validator is managing (could be done in the same way as we manage the signing key). This will also require adding the GetTransactionEncryptionKey on the validator.
  • RPC: add the GetTransactionEncryptionKey which basically just forwards the request from the validator to the user.
• Client:
  • Add the logic for periodically getting the encryption key from the network.
  • Encrypt the TransactionInputs using this key before submitting the transaction to the network.

[Al-Kindi-0]

Yes, I think we have all the ingredients, including in the crypto crate to make the above work. The main issue I see with the collapsing of the two keys into one is the following:

The viewing key, or better for this argument we can call it the archiving key, has to persist for long time horizons, probably even for an indefinite amount of time, in order to allow reading any transaction in the archive. By collapsing the submission key with the archiving key, we are making the submission key also "eternal".

This makes any enclave compromise reach both directions in time, i.e., both past archived data (decryptable with the leaked submission key) and future in-flight submissions, until the system becomes aware of the breach and remedying steps are taken to address it.

The separate-key design is an immediate consequence of wanting the archive's confidentiality to live in a different trust domain than the submission path: a leak of the submission key then costs us one rotation epoch of in-flight traffic at most, while the archive's confidentiality depends on a separate trust gate, namely a t-of-n quorum held outside the TEE infrastructure.

So, in other words, yes we can just rely fully on the TEE primitive to do both archiving and viewing/auditing, but that would force a monolithic eternal key, which is a not robust design.

Though I might be missing the threat model here, especially given that a lot of components will be centralized initially.

[Mirko-von-Leipzig]

The viewing key, or better for this argument we can call it the archiving key, has to persist for long time horizons, probably even for an indefinite amount of time, in order to allow reading any transaction in the archive. By collapsing the submission key with the archiving key, we are making the submission key also "eternal".

We could re-encrypt everything whenever we rotate the key? If we rotate under duress (key compromised) then we shut everything down, rotate and re-encrypt. Under normal rotation we could do this live by having a key overlap window.

[Al-Kindi-0]

I'm not sure I follow, but isn't the operator already in possession of the encrypted archive bytes since it is the one running the storage? That's the whole point of encryption at rest. Which means a key compromise at a later point implies that the operator will be able to decrypt those archives, and no re-encryption can help then.

[Mirko-von-Leipzig]

Yes, I think I was missing a few cups of coffee. Ignore my comment :D