feat: `into_package()` for `ProtocolLib` and `StandardLib` + CI Artifact by lima-limon-inc · Pull Request #2859 · 0xMiden/protocol

lima-limon-inc · 2026-04-30T20:33:05Z

Closes 0xMiden/midenup#200
Blocked-by #2896

This PR is part of an ongoing effort to migrate serialization towards the .masp Package format exclusively (see 0xMiden/midenup#191 (comment)).

A new into_package() method for both ProtocolLib and StandardLib was added which directly returns the corresponding Package.
This new method is then used in generate_package.rs script, which publishs the masp artifact onto the Github release page.

Notes:

into_package() was also added for StandardLib for consistency's sake, it wasn't strictly necessary.
This is a follow up of feat: add action to upload pre-compiled artifacts miden-vm#3029

mmagician

Overall looks good, but there are two items I'd still like double checked:

the CI should follow whatever patterns 0xMiden/miden-vm#3029 establishes, it looks like there are a lot of useful comments about the upload-artifcats job there which will be relevant in protocol repo, too
verify whether only ProtocolLib or StandardsLib needs to be uploaded as per my comments

mmagician · 2026-05-05T10:55:27Z

+
+    /// 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> {


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

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.

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

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.

@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.

@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)

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.

Created #2896.

mmagician · 2026-05-06T08:10:35Z

+          make packages
+      - name: Prepare artifacts
+        run: |
+          mv target/packages/miden-protocol.masp miden-protocol.masp


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

My bad, I've updated the name here: 81e2ac4

huitseeker · 2026-05-13T13:11:09Z

+  # Upload the pre-compiled artifacts (miden-protocol.masp) on the
+  # GitHub release page.
+  # Used by midenup to speed up installs.
+  upload-artifacts:


This new job is missing runs-on, so GitHub Actions treats the workflow as invalid. actionlint .github/workflows/workspace-publish.yml reports this at the upload-artifacts job. Could this add e.g. runs-on: ubuntu-latest before steps?

Good catch!

Added it here: dad9a43

Reported-by: François Garillot <francois@garillot.net>

bobbinth · 2026-05-16T06:22:13Z

@lima-limon-inc - could you resolve the merge conflicts?

lima-limon-inc · 2026-05-18T12:54:49Z

@lima-limon-inc - could you resolve the merge conflicts?

However, I'm not sure we want this to be merged as per @bitwalker's comments:

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.

I think tackling this PR as described in #2896 is the way to go.

Regardless, I have resolved the conflicts here, just in case, f727705.

lima-limon-inc force-pushed the fabrizioorsi/libs-as-masps branch from 885c68c to a9148d7 Compare April 30, 2026 20:34

lima-limon-inc mentioned this pull request Apr 30, 2026

feat: add miden-verify to toolchain 0.14.0 0xMiden/midenup#199

Merged

feat: add the ProtocolLib's masp Package as artifact

86f8f70

lima-limon-inc force-pushed the fabrizioorsi/libs-as-masps branch from a9148d7 to 86f8f70 Compare April 30, 2026 21:10

bobbinth requested review from huitseeker and mmagician May 1, 2026 01:26

mmagician reviewed May 5, 2026

View reviewed changes

Comment thread scripts/generate-package.rs

Comment thread .github/workflows/workspace-publish.yml Outdated

mmagician reviewed May 5, 2026

View reviewed changes

lima-limon-inc added 4 commits May 5, 2026 12:36

review: remove miden- prefix from package artifacts

1163ceb

review: rename STANDARDS_LIB_NAME -> STANDARDS_PACKAGE_NAME

3f0e214

feat: add StandardsLib library to generate_package.rs

c06648a

feat: add multiple files to the workspace_publish.yml

0498c29

mmagician reviewed May 6, 2026

View reviewed changes

giwaov mentioned this pull request May 11, 2026

Transition to package-based MASM assembly #2896

Open

lima-limon-inc mentioned this pull request May 11, 2026

feat: add action to upload pre-compiled artifacts 0xMiden/miden-vm#3029

Open

huitseeker requested changes May 13, 2026

View reviewed changes

lima-limon-inc added 2 commits May 15, 2026 14:56

feat: rename miden-protocol.masp to protocol.masp

81e2ac4

fix: add runs-on

dad9a43

Reported-by: François Garillot <francois@garillot.net>

Merge branch 'next' into fabrizioorsi/libs-as-masps

f727705

Conversation

lima-limon-inc commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mmagician left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mmagician May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lima-limon-inc May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mmagician May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Option A - each dependency package with its own manifest:

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

Uh oh!

Choose a reason for hiding this comment

Protocol

Standards

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bobbinth commented May 16, 2026

Uh oh!

lima-limon-inc commented May 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lima-limon-inc commented Apr 30, 2026 •

edited

Loading

mmagician May 5, 2026 •

edited

Loading

lima-limon-inc May 5, 2026 •

edited

Loading

mmagician May 6, 2026 •

edited

Loading

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