package transaction

Get desktop application:
View/edit binary Protocol Buffers messages

IES scheme used for transaction input encryption. Non-zero values match the discriminants of [miden_protocol::crypto::ies::IesScheme]. New schemes are added here as the node starts supporting them.

Used in: NextTransactionEncryptionKey, TransactionEncryptionKey

• IES_SCHEME_UNSPECIFIED = 0

• IES_SCHEME_X25519_XCHACHA20_POLY1305 = 1

Represents a commitment to an input note of a transaction. For authenticated notes, only the nullifier is present. For unauthenticated notes, the note header is also included.

Used in: TransactionHeader

• optional primitives.Digest nullifier = 1

  The nullifier of the input note.

• optional note.NoteHeader header = 2

  The note header, present only for unauthenticated input notes.

The next transaction encryption key, announced ahead of a scheduled key rotation.

Used in: TransactionEncryptionKey

• IesScheme scheme = 1

  IES scheme the next encryption key belongs to.

• bytes key_id = 2

  Opaque identifier of the next encryption key.

• bytes public_key = 3

  Raw public key bytes of the next encryption key, in the same encoding as `TransactionEncryptionKey.public_key`.

• fixed32 rotation_block_num = 4

  Block number at which the next key replaces the current one.

A proven transaction. Note that we currently require full transaction transparency for the validator set. This is a temporary measure while Miden stabilizes its protocol and proof systems. To this end, a transaction submission includes its **private** inputs, which a validator uses to verify that the transaction execution and proofs are correct. Those inputs are sealed against the validator set's shared transaction encryption key, so the nodes that relay a submission cannot read them: only a validator can. Submissions carrying unsealed inputs are rejected. This requirement will be lifted as Miden matures.

Used as request type in: rpc.Api.SubmitProvenTx, validator.Api.SubmitProvenTransaction

• bytes transaction = 1

  The transaction proof. Encoded using [miden_protocol::transaction::ProvenTransaction::to_bytes].

• optional SealedTransactionInputs sealed_transaction_inputs = 2

  The sealed private inputs used for the transaction proof. Transactions missing this field will be rejected as per the message description.

Transaction inputs sealed against the validator set's shared transaction encryption key. Obtain the key with `GetTransactionEncryptionKey` before submitting.

Used in: ProvenTransaction, TransactionBatch

• bytes key_id = 1

  Opaque identifier of the encryption key the inputs were sealed against, copied from [TransactionEncryptionKey.key_id].

• bytes ciphertext = 2

  The transaction inputs sealed with [miden_protocol::crypto::ies::SealingKey], encoded using the [miden_protocol::crypto::utils::Serializable] implementation for [miden_protocol::crypto::ies::SealedMessage].

A proven batch of transactions. Note that we currently require full transaction transparency for the validator set. This is a temporary measure while Miden stabilizes its protocol and proof systems. To this end, each transaction includes its **private** inputs, which a validator uses to verify that the transaction execution and proofs are correct. Those inputs are sealed against the validator set's shared transaction encryption key, so the nodes that relay a submission cannot read them: only a validator can. Batches carrying unsealed inputs are rejected. This requirement will be lifted as Miden matures. In addition, in order to verify the batch itself, we also require the proposed batch.

Used as request type in: rpc.Api.SubmitProvenTxBatch

• bytes batch_proof = 1

  The batch proof. Encoded using [miden_protocol::batch::ProvenBatch::to_bytes].

• optional bytes proposed_batch = 2

  The batch contents of the given proof. Encoded using [miden_protocol::batch::ProposedBatch::to_bytes]. Batches missing this field will be rejected as per the message description.

• repeated SealedTransactionInputs sealed_transaction_inputs = 3

  The sealed transaction inputs for each transaction in the batch. Must match the transaction ordering in the batch. Each entry is sealed independently against its own transaction's id, because the batch is fanned out into one validator submission per transaction. Batch will be rejected if any transaction's input is missing as per the method description.

The shared transaction encryption key, attested by validators. The public key is shared across the whole validator set, while each attesting signature is specific to one validator. Verifying an attestation against a chain-recognized validator signing key proves the encryption key was vouched for by a legitimate validator.

Used as response type in: rpc.Api.GetTransactionEncryptionKey, validator.Api.GetTransactionEncryptionKey

• IesScheme scheme = 1

  IES scheme the encryption key belongs to. Currently always `IES_SCHEME_X25519_XCHACHA20_POLY1305`.

• bytes key_id = 2

  Opaque identifier of the current encryption key. Changes when the key rotates.

• bytes public_key = 3

  Raw public key bytes of the shared encryption key. For the X25519 scheme these are the 32 bytes produced by [miden_protocol::crypto::dsa::eddsa_25519_sha512::PublicKey::to_bytes] (an Ed25519 public key that miden-crypto converts internally for X25519 key agreement).

• repeated ValidatorKeyAttestation attestations = 4

  Validator attestations of this key (and of `next_key` when set). Currently contains a single attestation from the validator that served the request. Collecting attestations from the whole validator set requires validator intercommunication and is planned as a follow-up; the wire format already accommodates it.

• optional NextTransactionEncryptionKey next_key = 5

  Set when a key rotation is scheduled: the key that replaces the current one, and the block number at which it takes effect. Covered by the attestation commitment, so it cannot be stripped or altered without invalidating the signatures. Never set currently; key rotation is not implemented yet.

Represents a transaction header.

Used in: rpc.TransactionRecord

• optional TransactionId transaction_id = 1

  The unique identifier of the transaction.

• optional account.AccountId account_id = 2

  ID of the account against which the transaction was executed.

• optional primitives.Digest initial_state_commitment = 3

  State commitment of the account before the transaction was executed.

• optional primitives.Digest final_state_commitment = 4

  State commitment of the account after the transaction was executed.

• repeated InputNoteCommitment input_notes = 5

  Input notes of the transaction.

• repeated note.NoteHeader output_notes = 6

  Output notes of the transaction.

Represents a transaction ID.

Used in: TransactionHeader, TransactionSummary

• optional primitives.Digest id = 1

  The transaction ID.

Represents a transaction summary.

• optional TransactionId transaction_id = 1

  A unique 32-byte identifier of a transaction.

• fixed32 block_num = 2

  The block number in which the transaction was executed.

• optional account.AccountId account_id = 3

  The ID of the account affected by the transaction.

A single validator's attestation of the transaction encryption key.

Used in: TransactionEncryptionKey

• bytes validator_public_key = 1

  Public key of the attesting validator, encoded using the [miden_serde_utils::Serializable] implementation for [miden_protocol::crypto::dsa::ecdsa_k256_keccak::PublicKey]. Must match a validator signing key committed in block headers to be trusted.

• bytes signature = 2

  The validator's signature over the attestation commitment: the Poseidon2 byte-mode hash of `domain_tag || scheme || len(key_id) || key_id || genesis_commitment || len(public_key) || public_key || next_key_transcript`, where `domain_tag` is the ASCII string `MIDEN_TX_ENCRYPTION_KEY_ATTESTATION_V1`, the scheme, the rotation block number, and the length prefixes are encoded as 4 bytes little-endian, and the genesis block commitment ties the attestation to one network. `next_key_transcript` is empty when no rotation is scheduled, or the next key's `scheme || len(key_id) || key_id || len(public_key) || public_key || rotation_block_num` otherwise, binding any scheduled rotation to the signature. The canonical construction is `miden_node_proto::domain::encryption`.