Protocol v0.9 - released May 20, 2025 Full changelog available is here. Key highlights: Network accounts: introduced the concept of network accounts (#1275 and #1349). These are public accounts which are explicitly monitored by the network to enable network transactions (see discussion here). Note execution checker: implemented ability to check which notes out of a set of notes can be executed against a given account (#1269). This functionality was required for the network transaction builder. Error reporting: upgraded to the latest version of miden-vm which significantly improved error reporting and debugging experience (#1353). Other notable changes:

Releases Over the last 6 weeks we've made the following releases: miden-protocol v0.9 on May 20, 2025. miden-compiler v0.1 on May 26, 2025 miden-node v0.9 on May 30, 2025. miden-client v0.9 on May 31, 2025. miden-vm v0.15 on June 6, 2025. air-script v0.4 on June 20, 2025.

Currently, our Sparse Merkle tree implementation (i.e., the Smt struct) has a purely in-memory representation. This will work fine when the amount of data stored in the tree is dozens of GB, but will break down when we'll need to store hundreds of GB in an Smt (as we may need for the nullifier and account tree in the Miden rollup). The purpose of these improvements would be to develop an approach which implements a variant of our Smt struct (ideally, with very similar interface) which can efficiently accommodate up to several terabytes of data inserted into it. Performance goals Main metric we'd like to optimize for: RAM footprint: ideally, the in-memory part of the tree should not require more than 16 GB of RAM regardless of the underlying tree size. Opening speed: time to build a Merkle path for a given leaf should be under 100 µs (currently, under 1 µs). Update/insert speed: time to update/insert a batch of 10,000 leaves should be under 1 second on a 16-core CPU (currently should be under 300 ms). Tree initialization: time to load the in-memory part of the tree should be under 1 minute on a 16-core CPU regardless of the underling tree size. Disk footprint: this is difficult to for me to estimate as I don't have any intuition here. A potential target to throw out is that an SMT with 1 billion key-value pairs should require something between 100GB and 1TB of disk space.

Below is a description of the format for describing the constraint evaluation logic (i.e., the constraint evaluator). The format is JSON-based. All field elements are represented in their canonical values encoded as strings. At the root level, the evaluator is defined by the five components described below: { metadata: "<field, trace, and variable definitions>", zerofiers: "<an array denominators for constraint expressions>", periodic: "<an array of periodic column definitions>", expressions: "<an array of expressions defined by numerators/denominators>", nodes: "<an array of all nodes in the expressions>",

Final format Below is a description of the format for describing the constraint evaluation AST. The format is JSON-based. All field elements are represented in their canonical values encoded as strings. At the root level, the AST is defined by the five components described below: { metadata: "<field, trace, and variable definitions>", zerofiers: "<an array denominators for constraint expressions>", periodic: "<an array of periodic column definitions>", expressions: "<an array of expressions defined by numerators/denominators>",

Frontend and IR Improve AirScript compilation process as described in here. Introduce the new bus construct as described here and here. Combine constraints generated by selector expressions as described here. IR improvements described in #333 and #334. Frontend improvements described in #142, #146, #245, and #266. Backends Finishing MASM backed. Some issues related to this are #335 and #339, but there are probably a few other things which are not yet captures in the issues. Update and better test Winterfell back-end.

This note describes potential improvements for the miden-crypto crate. The improvements can be broken down into 3 groups: API improvements and minor optimizations The purposes of these improvements is to make the APIs of the crate more intuitive and also to implement "low-hanging-fruit" performance optimizations. The changes include: Improvements to the MMR data structure APIs, including #196, #262, #299. Normalizing APIs across various Merkle data structures (e.g., using open() consistently for generating Merkle proofs). Implementing compact Mekrle path data structure (i.e., #215). Improvements to the SMT APIs (e.g., #271, #272).

In order to take advantage of Fabric's VPU once it becomes available, we would like to explore the capabilities of the FC100 chip. To this end, we've outlined below several potential areas for collaboration between Fabric and Polygon. Hash functions Miden is currently using the RPO hash function (paper, impl) and we are investigating migration to the RPX hash function (paper, impl). Both are defined over the Goldilocks field, with the main benefit of RPX being about 40% faster than RPO on CPUs. We are interested in understanding how these hash functions would perform on Fabric's FC100 chip. Specifically, we are interested in: Understanding how RPO/RPX could perform relative to each other on FC100 (i.e., do we get the same 40% delta as on CPUs?). Understanding how RPO/RPX could perform relative to other popular arithmetization-friendly hashes (e.g., Poseidon 1/2) on FC100.

As of March 2024: A few immediate things that we need to finish in AirScript are described in the v0.4 milestone. To cover them in a bit more details: Support for variable-length public inputs is super important as without this we cannot describe all Miden VM constraints (these are used for boundary constraints against initial/final stack state and kernel ROM). This change would affect all parts of AirScript: front-end, IR, and back end. Support for functions (front-end changes only): while it is possible to live without this, it would make describing constraints way simpler. There is also a half-finished PR for this - though, it's been stale for some time. Combine constraints generated by selector expressions is needed as without it, verification of constraint evaluation in the recursive context will likely be prohibitively expensive. This is a front-end change only. Beyond these, there are some smaller front-end improvements (e.g., #331, #333, #334) which are not super-critical, but also could be very nice to have. There is also a more fundamental improvement of the front-end and IR described here which would be really nice to implement.

As of March 2024: Miden VM is still work-in-progress. I would consider it to be at alpha stage of software development. While the core of the VM is working fine and is well-optimized, some pieces haven't been implemented and/or will be refactored. Missing pieces While the entire constraint system for Miden VM is described in the docs, some constraints have not been implemented yet. The biggest representative of this are the decoder constraints (but there are some others as well). Implementing these constraints is just a matter of effort, but we haven't put in this effort as the constraints are very likely to change quite a bit with some of the refactorings mentioned below. Once implemented, the constraints will have very minor impact on the prover performance (e.g., this may slow down the VM by less than 5%). Some sections of docs may be missing or outdated. This is especially relevant to the sections mentioned in these issues: #389, #483, #758, #813. There is a soundness bug in one of memory operation constraints (specifically, in constraints for MSTORE operation). We haven't addressed this as we are planning to refactor the memory subsystem to enable element-addressable memory (see here). There is a bug in the implementation of the kernel procedure table (see here). Recursive verifier is incomplete (and is actually currently broken). To complete this, we need to finish AirScript and optimize MASM backend.

The goal of the project is to enable acceleration of Miden VM proof generation on GPUs - specifically for Metal and CUDA. We already have support for Metal acceleration on Apple silcon. This is done via ministark-gpu crate by implementing a GPU accelerated prover here. Currently, we accelerate two steps of STARK proof generation: Computing trace commitment (see here). Computing constraint commitment (see here). These two steps are by far the most expensive, and for this project, we are not looking to accelerate anything else. This project is broken down into two phases described below.

Input sources Array of polynomials (size $n$) Array of variables Outputs Array of polynomials Program

Version: v0.2 Miden assembly is a simple, low-level language for writing programs for Miden VM. It stands just above raw Miden VM instruction set, and in fact, many instructions of Miden assembly map directly to raw instructions of Miden VM. Before Miden assembly can be executed on Miden VM, it needs to be compiled into a Program MAST (Merkelized Abstract Syntax Tree) which is a binary tree of code blocks each containing raw Miden VM instructions. As compared to raw Miden VM instructions, Miden assembly has several advantages: Miden assembly is intended to be a more stable external interface for the VM. That is, while we plan to make signficant changes to the underlying VM to optimize it for stability, performance etc., we intend to make very few breaking changes to Miden assembly. Miden assembly natively supports control flow expressions which the assembler automatically transforms into a program MAST. This greatly simplifies writing programs with complex execution logic.