Enforce encrypted transaction inputs on submission

[huitseeker]

Summary

Clients must now encrypt private transaction inputs before submission. RPC nodes pass the ciphertext to the validator unchanged. The validator decrypts it before the current checks and rejects missing, plain, or invalid inputs.

Each submitter in this repository verifies the validator's encryption key against a trusted signing key. The NTX builder fetches a new key and retries once when the validator rejects an old key. The public RPC does not cache encryption keys.

This supersedes (but builds on) #2381. It completes encrypted submission for Phase 1, modulo key rotation (part of #2373, which should come later). Validation of the encryption key is against a fixed attestation for now.

Existing NTX builder data directories must be bootstrapped again. The database now stores the trusted validator keys from genesis.

Changelog

[[entry]]
scope = "protocol"
impact = "breaking"
description = "Transaction submissions now carry sealed private inputs instead of plaintext inputs."

[[entry]]
scope = "rpc"
impact = "breaking"
description = "Transaction submission rejects missing or unsealed private inputs."

[[entry]]
scope = "rpc"
impact = "fixed"
description = "Transaction submission no longer records private request bodies in logs or traces."

[[entry]]
scope = "rpc"
impact = "changed"
description = "GetTransactionEncryptionKey responses are forwarded without a relay cache."

[[entry]]
scope = "general"
impact = "changed"
description = "Node submitters verify encryption keys against trusted validator signing keys."

[[entry]]
scope = "validator"
impact = "changed"
description = "The validator decrypts sealed inputs before validation and rejects plaintext inputs."

[[entry]]
scope = "ntx-builder"
impact = "migration"
description = "NTX builder data must be bootstrapped again to store trusted validator keys from genesis."

[[entry]]
scope = "network-monitor"
impact = "changed"
description = "Network transaction checks require a trusted validator signing public key."

[juan518munoz]

We are acquirying a lock here, then going through an rpc call before releasing it. Can we assume it will never block?

[huitseeker]

Good catch. The RPC call now runs without the lock. The cache is checked again before insertion.

[bobbinth]

Question (relevant for some other places too): is this a temporary simplification? The monitor should be able to get validator's signing keys from the blockchains (i.e., the block headers) - right?

[huitseeker]

Yes. MIDEN_MONITOR_VALIDATOR_SIGNING_PUBLIC_KEY is temporary. #2389 uses it to trust encryption-key attestations. The monitor should instead read validator signing keys from authenticated block headers.

#2390 and #2393 keep the fixed setting. After they land, #2373, including #2382, will be rebased on top. That integration should pass chain-derived validator keys to #2373’s schedule verifier and remove the environment variable. The same change should remove fixed validator keys from the other node submitters. Each submitter will then follow validator changes through trusted chain state instead of local config.

/cc @juan518munoz

[Mirko-von-Leipzig]

I have some nits but I don't think they're worth it since a lot of this will change over the stacks