Transition to package-based MASM assembly

[bobbinth]

With v0.22 and v0.23 releases of the VM, we are moving towards package-based infrastructure, and in v0.24 VM structs like Library (and maybe Program) will be removed. This means we should start transitioning to using the Package struct (from miden-mast-package) as a compilation target for scripts/components/executables etc.

Transitioning to MAST packages has a couple of goals:

• This should simplify our build.rs files quite a bit as in most cases we should be able to point the assembler to a miden-project.toml file, and it should be able to assemble all required artifacts from there.
• It should unify the approach that the compiler is going to use to generate packages for note scripts, account components etc.
• It should allow us to be more declarative in describing some standard components.

---

To migrate to packages we first will need introduce miden-project files in the protocol and standards crates. This could look roughly as follows:

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.

---

Once the above is done (and everything compiles as expected), we can start removing Library structs from our Rust code and replacing it, where relevant, either with Package or MastForest structs.

[giwaov]

This looks like it may be better split into a few smaller pieces before implementation starts, especially with the package work already moving in #2859.

Would it be useful to break this down by target, for example protocol project file first, then standards library, then account components? I’d be happy to take one of the scoped pieces once the preferred split is clear.

[bobbinth]

Yes, I think would be helpful to break this down into smaller, more-targeted pieces. I think there is probably 3 - 4 PRs that would be required to address this issue.

[lima-limon-inc]

Since I've opened #2859 I could tackle migrating Protocol over to miden-project.toml since that would unlock things over on midenup

[bobbinth]

Sounds good! As I mentioned in the above comment, I think this would take a few PRs, and it would be good to plan them out before we dive into the work.