Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions .github/workflows/workspace-publish.yml
Original file line number Diff line number Diff line change
Expand Up @@ -34,3 +34,46 @@ jobs:
release-branch: ${{ github.event.release.target_commitish }}
env:
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}

# Upload the pre-compiled artifacts (miden-protocol.masp) on the
# GitHub release page.
# Used by midenup to speed up installs.
upload-artifacts:
name: upload pre-built miden-protocol library artifacts
if: ${{ github.repository_owner == '0xMiden' }}
permissions:
contents: write
id-token: write
attestations: write
steps:
- name: Checkout repository
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
fetch-depth: 0
ref: ${{ github.event.release.tag_name }}
persist-credentials: false
- uses: ./.github/actions/cleanup-runner
- name: Install Rust
run: |
rustup update --no-self-update
rustc --version
- name: Build packages
run: |
make packages
- name: Prepare artifacts
run: |
mv target/packages/miden-protocol.masp miden-protocol.masp
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the last commit regressed the naming and we have the miden- prefix again

mv target/packages/standards.masp standards.masp
- name: Attest packages
uses: actions/attest-build-provenance@96278af6caaf10aea03fd8d33a09a777ca52d62f # v3.2.0
with:
subject-path: |
protocol.masp
standards.masp
- name: Upload packages
env:
RELEASE_TAG: ${{ github.event.release.tag_name }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
set -e
gh release upload ${RELEASE_TAG} protocol.masp standards.masp
4 changes: 4 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,13 +28,17 @@
- Added `tx::get_tx_script_root` kernel procedure returning the root of the executed transaction script (empty word if no script was executed) ([#2816](https://github.com/0xMiden/protocol/pull/2816)).
- Added `TransactionScript::from_package()` method to create `TransactionScript` from `miden-mast-package::Package` ([#2779](https://github.com/0xMiden/protocol/pull/2779)).
- Re-exported `MIN_STACK_DEPTH` from `miden-processor` ([#2856](https://github.com/0xMiden/protocol/pull/2856)).
- Added `into_package()` method for `ProtocolLib` & `StandardsLib` ([#2859](https://github.com/0xMiden/protocol/pull/2859)).

### Fixes

- Made deserialization of `AccountCode` more robust ([#2788](https://github.com/0xMiden/protocol/pull/2788)).
- Fixed `output_note::add_asset` and `output_note::set_attachment` to no longer accept invalid note indices ([#2824](https://github.com/0xMiden/protocol/pull/2824)).
- Fixed auth components to use initial storage state for authentication ([#2677](https://github.com/0xMiden/protocol/issues/2677)).

### Enhancements
- Added binary artifact compilation to the CI to aid `midenup`'s installation speed ([#2859](https://github.com/0xMiden/protocol/pull/2859)).

## 0.14.5 (2026-04-23)

- Fixed note script compilation: all note scripts are now compiled as libraries ([#2822](https://github.com/0xMiden/protocol/pull/2822)).
Expand Down
1 change: 1 addition & 0 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 4 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -146,6 +146,10 @@ build-no-std: ## Build without the standard library
build-no-std-testing: ## Build without the standard library. Includes the `testing` feature
$(BUILD_GENERATED_FILES_IN_SRC) cargo build --no-default-features --target wasm32-unknown-unknown --workspace --exclude bench-transaction --features testing

.PHONY: packages
packages: ## Builds .masp packages and store them in target/packages
cargo +nightly -Zscript scripts/generate-package.rs

# --- test vectors --------------------------------------------------------------------------------

.PHONY: generate-solidity-test-vectors
Expand Down
22 changes: 22 additions & 0 deletions crates/miden-protocol/src/protocol.rs
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
use alloc::boxed::Box;
use alloc::sync::Arc;

use miden_mast_package::{Package, TargetType, Version};

use crate::assembly::Library;
use crate::assembly::mast::MastForest;
use crate::utils::serde::Deserializable;
Expand All @@ -10,6 +13,8 @@ use crate::utils::sync::LazyLock;

const PROTOCOL_LIB_BYTES: &[u8] = include_bytes!(concat!(env!("OUT_DIR"), "/assets/protocol.masl"));

const PROTOCOL_PACKAGE_NAME: &str = "protocol";

// PROTOCOL LIBRARY
// ================================================================================================

Expand All @@ -21,6 +26,23 @@ impl ProtocolLib {
pub fn mast_forest(&self) -> &Arc<MastForest> {
self.0.mast_forest()
}

/// Wraps this library into a [`Package`] named `PROTOCOL_PACKAGE_NAME`,
/// versioned with the `miden-protocol` crate's version.
pub fn into_package(self) -> Box<Package> {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there are any meaningful tests we could add for into_package()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think before this gets merged, we should switch to building the protocol and standards packages as Miden projects, i.e. via miden-project.toml. You can still obtain a Library from the resulting package for legacy uses, but it produces a proper package rather than trying to create one from a Library, which IMO we should not do.

That way this function goes away, and packaging uses the standard workflow and tooling provided by the assembler, and we're guaranteed that all of the package metadata is correct.

Copy link
Copy Markdown
Collaborator

@mmagician mmagician May 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should switch to building the protocol and standards packages as Miden projects, i.e. via miden-project.toml

Would this need to happen here in the protocol repo? I haven't followed up on the packages/projects work recently

Copy link
Copy Markdown
Contributor Author

@lima-limon-inc lima-limon-inc May 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this need to happen here in the protocol repo? I haven't followed up on the packages/projects work recently

I believe so. I believe that would imply switching to a masm miden-project here on the protocol repo.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mmagician Yes, the miden-project.toml would be defined for each logical workspace/project in this repo for which we want to produce a Miden package (we modeled the transaction kernel in the examples under miden-project in the VM repo, but the actual definition would look slightly different here). If you have specific questions about that, I'd be glad to hop on a call to discuss how to approach the project structure , or whatever is most convenient. I can take a stab at defining it too, but you guys know best how you intend to structure packages for things like standards.

Copy link
Copy Markdown
Collaborator

@mmagician mmagician May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bitwalker regarding your suggestion to switch to using miden-project.toml to build packages, IIUC we have two options:

Option A - each dependency package with its own manifest:

  • crates/miden-protocol/asm/miden-project.toml would be a workspace with four members:
    • shared_utils,
    • kernels/transaction
    • protocol
    • asm/shared_modules/ is either pre-linked as currently, or maybe refactored to promote to a 4th workspace member.
  • crates/miden-standards/asm/miden-project.toml would be a workspace with a single standards member that depends on protocol above
  • build.rs in both crates would be rewritten to call Assembler::link_package
    instead of assembling kernel/library imperatively. I think this is a positive change and will result in less boilerplate code for building.

Option B - only the userspace libraries (protocol & standards) get a manifest:

  • crates/miden-protocol/asm/protocol/miden-project.toml and
    crates/miden-standards/asm/standards/miden-project.toml, both single-
    package manifests
  • Kernel, shared_utils, etc. stay assembled via build.rs as today and only the final protocol/standards libraries are produced via link_package.

LMK if this understanding is correct. AFAIU, for option B - if feasible - is simpler and would be a good start already.
But maybe long-term, we could still implement A.
Am I making sense? (as I said I'm only catching up on the package/project concepts)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I was imagining this was roughly like this:

Protocol

We'd have a single crates/miden-protocol/asm/miden-project.toml which would result in the following packages:

  • Transaction kernel library - i.e., result of assembling asm/kernel/transaction/api.masm.
  • Transaction kernel executable - i.e., result of assembling asm/kernel/transaction/main.masm.
  • Transaction script executable - i.e., result of assembling asm/kernel/transaction/tx_script_main.masm.
  • The user-facing protocol library - i.e., the result of assembling asm/protocol directory.

If we can't cover all of these with a single miden-project.toml file, we can split these up into separate projects.

Standards

  • We'd have a project file crates/miden-standards/asm/miden-project.toml to assembler the standards library.
  • We'll also have a project file for each of the components in asm/account_components directory (which we probably should rename to just asm/components.

I'll create an issue for this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #2896.

// The ProtocolLib's version is the same as the crate's as per the miden-protocol's
// Cargo.toml.
let version = Version::parse(env!("CARGO_PKG_VERSION"))
.expect("CARGO_PKG_VERSION must be valid semver");

Package::from_library(
PROTOCOL_PACKAGE_NAME.into(),
version,
TargetType::Library,
Arc::new(self.0),
[],
)
}
}

impl AsRef<Library> for ProtocolLib {
Expand Down
5 changes: 3 additions & 2 deletions crates/miden-standards/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -21,8 +21,9 @@ testing = ["dep:rand", "miden-assembly/testing", "miden-protocol/testing"]

[dependencies]
# Miden dependencies
miden-processor = { workspace = true }
miden-protocol = { workspace = true }
miden-mast-package = { workspace = true }
miden-processor = { workspace = true }
miden-protocol = { workspace = true }

# External dependencies
bon = { workspace = true }
Expand Down
21 changes: 21 additions & 0 deletions crates/miden-standards/src/standards_lib.rs
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
use alloc::boxed::Box;
use alloc::sync::Arc;

use miden_mast_package::{Package, TargetType, Version};
use miden_protocol::assembly::Library;
use miden_protocol::assembly::mast::MastForest;
use miden_protocol::utils::serde::Deserializable;
Expand All @@ -11,6 +13,8 @@ use miden_protocol::utils::sync::LazyLock;
const STANDARDS_LIB_BYTES: &[u8] =
include_bytes!(concat!(env!("OUT_DIR"), "/assets/standards.masl"));

const STANDARDS_PACKAGE_NAME: &str = "standards";

// MIDEN STANDARDS LIBRARY
// ================================================================================================

Expand All @@ -22,6 +26,23 @@ impl StandardsLib {
pub fn mast_forest(&self) -> &Arc<MastForest> {
self.0.mast_forest()
}

/// Wraps this library into a [`Package`] named `STANDARDS_PACKAGE_NAME`,
/// versioned with the `miden-protocol` crate's version.
pub fn into_package(self) -> Box<Package> {
// The ProtocolLib's version is the same as the crate's as per the miden-standards's
// Cargo.toml.
let version = Version::parse(env!("CARGO_PKG_VERSION"))
.expect("CARGO_PKG_VERSION must be valid semver");

Package::from_library(
STANDARDS_PACKAGE_NAME.into(),
version,
TargetType::Library,
Arc::new(self.0),
[],
)
}
}

impl AsRef<Library> for StandardsLib {
Expand Down
30 changes: 30 additions & 0 deletions scripts/generate-package.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
#!/usr/bin/env cargo

---
[dependencies]
miden-protocol = { path = "../crates/miden-protocol" }
miden-standards = { path = "../crates/miden-standards" }
semver = "1"
---

use std::env;

use miden_protocol::ProtocolLib;
use miden_standards::StandardsLib;

fn main() -> std::io::Result<()> {
// Must be run from the workspace root (CARGO_TARGET_DIR is not set for cargo scripts).
let workspace_root = env::current_dir().expect("could not read PWD");
let packages_dir = workspace_root.join("target").join("packages");
std::fs::create_dir_all(&packages_dir)?;

let protocol_pkg = ProtocolLib::default().into_package();
protocol_pkg.write_masp_file(&packages_dir)?;
println!("wrote {}.masp to {}", protocol_pkg.name, packages_dir.display());

let standards_pkg = StandardsLib::default().into_package();
standards_pkg.write_masp_file(&packages_dir)?;
println!("wrote {}.masp to {}", standards_pkg.name, packages_dir.display());

Ok(())
}
Comment thread
mmagician marked this conversation as resolved.
Loading