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.

[Mirko-von-Leipzig]

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

[bobbinth]

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.

I think we can still rotate the submission keys - it is just the TEE would need to keep track of all submission keys ever generated. This would mean that a compromise of any specific submission key would not allow the attacker to decrypt any past or future ciphertext.

On the other hand, a compromise of a TEE would make the entirety of the data decryptable - i.e., whoever can break the TEE will get all the past submission keys and will be able decrypt all the ciphertext produced up to this point.

So, overall, I do agree that separating submission key from archival key has its benefits - though, in my mind, it does come with non-trivial additional complexity (mostly the need for threshold encryption scheme, we we don't currently have in miden-crypto).

So, I think the overall sequencing could be:

1. Implement the simple scheme I described above (i.e., there is a single submission key singed by the validator). We already have everything needed to implement this, and it would give us largely-stable user interfaces.
2. In the background, add the threshold encryption/decryption mechanism to separate submission keys from archival keys. Here, the validators would still share the same submission key, but the archival encryption would be done using threshold encryption scheme. For this, we'll need to add threshold encryption to miden-crypto (probably as a re-export of something that's already available). Let's create an issue for this.
3. Introduce TEEs so that private data is hidden from the validator.

[huitseeker]

Have you had a look at existing schemes? There's a whole blockchain that worked out a key hierarchy for this. but without going as far, dstack-kms sounds right-sized for a PoC: https://phalanetwork.mintlify.app/docs/security-research/kms/kms-security-arch https://arxiv.org/pdf/2509.11555v1 section 3.1.1

[bobbinth]

@huitseeker - you mean this for the points 2 and 3 I listed above, right?

[huitseeker]

Yes, but I meant the two references slightly differently: the existing blockchain key-hierarchy work is relevant to 2, while dstack-KMS looks like a pragmatic PoC path for 3. I wouldn’t assume dstack-KMS by itself is the final archival mechanism.

Your sequencing still makes sense. Before opening an issue to add generic threshold encryption to miden-crypto, though, I think we should compare that against an existing threshold key-derivation approach that may fit the archival use case more naturally. Let’s take that design discussion offline.