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 them inside the trusted path, then use the same TransactionInputs deserialization and re-execution path it uses today.

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.

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

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:

• validator encryption or mTLS 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?