# Transactions in Miden
## Overview
Polygon Miden utilizes a STARK-based ZK rollup mechanism on the Ethereum network to enhance both scalability and privacy. This document provides a technical examination of how transactions are processed within the Miden framework, focusing on client-side proving, parallel execution, the utilization of zk, the UTXO-like structure of notes, and their operational significance.
## Transaction Processing in Miden
### Miden Virtual Machine (VM) and Transaction Execution
Transactions in Miden are processed through a sequence of detailed steps within the Miden VM, leveraging Miden Assembly (MASM) to facilitate execution:
1. **Data Retrieval**: Necessary transaction data is fetched from a persistent data store, including account details, block headers, and the input notes relevant to the transaction.
2. **Compilation**: The transaction data is compiled into an executable MASM program. This step translates transaction instructions into a low-level format that the Miden VM can execute efficiently.
3. **Execution**: The Miden VM executes the compiled MASM program. Execution within the VM is context-sensitive, with each transaction or script operating in isolated execution contexts to maintain security and data integrity.
4. **Proof Generation**: Post-execution, a STARK-based zk proof is generated for the transaction. This proof substantiates the transaction's validity and integrity without revealing any underlying data, thus ensuring privacy.
### Execution Contexts and Security
The Miden VM employs multiple isolated execution contexts, each with its own segregated memory space. This architecture prevents direct memory access across contexts, thus enhancing security:
- **Kernel Context**: The root execution context where the transaction kernel operates. It has comprehensive access to all transaction-related memory but restricts external access to prevent unauthorized data manipulation.
- **Note and Account Contexts**: Scripts and transactions involving notes or account modifications run in their respective contexts. Context switching is controlled through system calls (`syscall`), allowing operations to request kernel-level execution for specific tasks without compromising the encapsulation of execution contexts.
## Key Components and Structures
### ZKP
Miden utilizes ZK proofs to validate transactions without revealing any sensitive data:
- **STARK Proofs**: These proofs are computationally efficient and do not require a trusted setup. They are crucial for ensuring that transactions are valid and adhere to the network's consensus rules, all while maintaining the privacy of the transaction's contents.
- **Proof Scalability**: The size and complexity of the proofs do not scale linearly with the complexity of the transactions, allowing Miden to handle more computationally intensive operations without a significant increase in proof size.
### UTXO-like Structure: Notes
Miden adopts a UTXO-like structure through its use of notes, which are analogous to UTXOs in traditional blockchain architectures:
- **Notes as Transaction Outputs**: Each transaction generates new notes as outputs, which encapsulate specific assets or data. These notes can then be used as inputs in future transactions.
- **Note Privacy and Integrity**: Each note contains a script that dictates its usage rules, enhancing privacy by allowing conditions for their consumption. This script is executed as part of the transaction, with the results included in the transaction proof, ensuring both the integrity and the conditional logic of the note are upheld.
### Client-Side Proving
In Miden, clients can optionally perform the computation and proof generation locally:
- **Local Execution and Proofing**: Clients execute transactions locally and generate corresponding ZKPs. This not only reduces the load on the network but also minimizes transaction costs as proof generation is resource-intensive.
- **Privacy Benefits**: By handling transaction execution and proof generation locally, clients maintain greater control over their data privacy.