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]

Some spitballing..

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).

Depends on rotation frequency, there could be an overlap window where both old and new keys are accepted maybe? At least for the submission portion..

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.

We could form validator chains? If they're not a mechanism, then the extra validators won't appear on chain iiuc? If so, then they're purely "internal" in a way to share the data? Then we could have the user encrypt for the primary, the primary re-encrypts for the next/rest.

[bobbinth]

Depends on rotation frequency, there could be an overlap window where both old and new keys are accepted maybe? At least for the submission portion..

Yeah - now thinking about this, the window could be indefinite (or at least very long). The validators could always keep track of the old keys, and decrypt messages encrypted with any of the past keys.

On the other hand, maybe the encryption key could be a purely node property - i.e., it doesn't need to be a part of the chain. In that case, the client could just request the encryption key from the node, the node would return the key signed by the validator (this way, the client knows the node didn't try to inject its own key), the client checks the signature, and then uses this key for encrypting the transaction inputs.

I think the main question for me now is whether we have one or multiple encryption keys. Let's say we have 3 validators:

If there are no TEEs, technically, we just need one encryption key. The validators could all have the same key as they end up seeing the data anyways.

If there are TEEs, we may also be able to get away with a single encryption key. The setup would be a bit more complicated though, as we'll need to run some protocol between the TEEs so that they can establish some shared secret (cc @huitseeker and @Al-Kindi-0 to double-check if I'm off here).

---

So, my takeaways so far:

• We just need one encryption key.
• This key does not need to be a part of the chain, but rather could be returned by the node (we'll need an endpoint for this).
• The key that the node returns needs to be signed by the validator(s). This means, the config for the RPC would need to include a bit more data. Or maybe the RPC could just query the validator for the key and then cache it locally.

[Al-Kindi-0]

A lot of what I am about to say is really building on @huitseeker's proposal (#discussioncomment-17087125), which already lays out the bones: encrypting only TransactionInputs, DStack as the TEE stack with its KMS/key-release primitive, the validator publishing a TEE-bound encryption key together with a key_id/validity range and a quote binding that key, and verifiable threshold decryption for stored material. What follows is mostly a refinement on top of that, plus a small clarification on the submission-key question.

1- 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. The defining property of this second key is that no single party can use it on its own to decrypt and inspect the inputs, since only a quorum above the threshold can do so. This second layer is exactly the threshold-decryption proposal @huitseeker laid out (he pointed at the E_htdh1 variant from eprint 2025/279 as a pairing-free target; the PoC currently uses vetKeys via golden-rs, a pairing-based scheme serving the same purpose). So for the submission key there are really only two choices: a per-validator/enclave key, or one key shared across all validators/enclaves, and no thresholding is needed in either case.

2- For the submission key, the single-key option (i.e., a shared secret between the TEEs) seems defensible, and DStack as proposed by @huitseeker already gives us the right primitive: a Key Management Service (KMS) that releases the same key to every enclave satisfying a set of conditions, such as presenting a fresh attestation quote with an approved measurement. The main challenge is that this single-key model moves the trust to the KMS. The most promising attack vector is then no longer the TEE itself, but rather the approved set of measurements, together with whoever controls admission to it and its updates (as well as the KMS's own root keys). This is what @huitseeker already flagged regarding the measurement set and upgrade policy.

3- As for how the client obtains the submission key in the first place (the public half it encrypts to), I agree with @bobbinth that this key doesn't need to live on-chain and can instead be served by the node. This is essentially @huitseeker's list of what the validator publishes (TEE-bound encryption key; key_id and validity range; TEE quote binding that key; app measurement; upgrade policy) restated as a discovery flow: the validator/TEE signs a blob containing the submission public key together with a key_id and validity window, rather than the public key alone, since otherwise replay attacks become possible. The client verifies that signature against the validator's on-chain signing key, which is the trust anchor and stays separate from the submission key itself. This is what stops a malicious RPC operator from swapping in its own key in order to read the inputs. Under the TEE model we'd also want the submission public key bound to a fresh attestation quote (huitseeker's "TEE quote binding that key"), so the client can check it was generated inside an approved enclave and not merely signed by the operator.

4- Finally, note that a static submission key necessarily means giving up forward secrecy. The alternative that does give FS is an ephemeral handshake terminating inside the TEE, which is what @huitseeker's original transport-boundary proposal would have provided. The catch is that an interactive transport doesn't sit cleanly with the async submit/mempool model, namely, clients would need a live session to a processor that isn't even assigned at submit time. The pragmatic answer for the static envelope is therefore most likely frequent key rotation with an overlap window where both old and new keys are accepted, the idea @Mirko-von-Leipzig already raised above. This is probably fine because we decrypt inputs synchronously at submission, so the window over which an old key has to stay alive is short (roughly the gap between a client fetching the key and submitting). That lets us rotate often and retire old keys quickly, which keeps the harvest-now-decrypt-later exposure bounded to a small epoch.

5- Lastly, on @bobbinth's suggestion of a simpler first step without TEEs (privacy against the RPC operator only), the discussion above largely translates and actually simplifies. The submission/viewing key separation, the discovery flow, and the forward-secrecy/rotation discussion all still apply. What falls away is the KMS, the attestation binding in discovery, and the measurement-approval governance that came with the TEE story. The trust then collapses onto the validator role being a distinct (and non-colluding) party from the node/RPC operator, which is what makes the no-TEE step meaningful at all. As long as that separation holds, this is a strict subset of the TEE design and a reasonable first target.

[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.