Migrate to the VM v0.20.0

[Fumuran]

This PR updates the code to work with miden-vm v0.20.0 and miden-crypto v0.19.2.

Specifically these changes were applied:

• Account components now created using the name if their files: user will be able to call specific component procedure using its name (e.g. call.::rpo_falcon_512_multisig::update_signers_and_threshold)
  • As a consequence file names in the miden-lib/asm/account_components were updated.
• Any mentions of the stdlib were changed to core lib.
• in_debug_mode parameter was removed from the CodeBuilder and build_send_notes_script method of the AccountInterface.

---

Open questions and follow ups:

• Should the AccountComponent::get_procedure_root_by_name method be renamed to get_procedure_root_by_path, following Library refactoring?
• Remove SMT_PEEK_EVENT from asset_valut: Remove the SMT_PEEK_EVENT event #2115.

---

Migration guide

• MASM syntax

  const.A -> const A
  export.foo -> pub proc foo
  proc.bar -> proc bar
  use.miden::<*> -> use miden::<*>
  export.miden::foo::bar -> pub use miden::foo::bar (re-export case)
  

• Stdlib

  Standard library was renamed, so instead of StdLibrary now the CoreLibrary should be used. It has the same API, so just simple renaming should work. Its MASM usage also changes, so now instead of std:: the miden::core:: should be used.

• Debug mode

  in_debug_mode parameter was removed from CodeBuilder and related methods. Simple removing the parameter or method call will work.

• LibraryPath

  LibraryPath was removed, now you can use Path instead (notice that now there are two paths: from std and from miden_assembly). compile_and_statically_link_from_dir assembler method was updated to work with paths, so to get the same final library you can provide relevant Path or even just a the static string. For example:

  // Old version. Parameters are "$kernel" and "asm/shared_utils"
  assembler.compile_and_statically_link_from_dir(kernel_namespace.clone(), &shared_utils_path)?;
  
  // New version. Parameters are "asm/shared_utils" and "::$kernel"
  assembler.compile_and_statically_link_from_dir(
      &shared_utils_path,
      miden_assembly::Path::kernel_path(),
  )?;

• Account Components

  get_procedure_root_by_name() method was renamed to get_procedure_root_by_path() to match the Library API. In most cases no further changes are required, but notice that the procedure path should include the module name, i.e. "basic_fungible_faucet::distribute".

[bobbinth]

Looks great! Thank you! I left some questions/comments inline - but most of these can be addressed in follow-up PRs.

Overall, in terms of follow-ups, I think we have:

• Remove the SMT_PEEK_EVENT from asset vault (we have an issue for this).
• Change hperm and hmerge to rpo256::permute and rpo256::merge everywhere.
• Rename RpoFalcon512 to Falcon512Rpo everywhere.
• Figure out if we can still search for procedures by name in account components.
• Export/import constants directly (instead of having wrapper functions) - I think we might have an issue for this as well.

[bobbinth]

Probably not for this PR, but we should rename RpoFalcon512 to Falcon512rpo to be consistent with naming everywhere.

[bobbinth]

I think we should probably rename this to keep things consistent.

Ideally, we'd actually be able to find procedures by name, but for this we'd need to make sure all procedures in a component are uniquely named - and this will probably require some re-work. Let's create an issue for this.

[bobbinth]

Question: could we assemble things differently so that these remain just as names rather than pats (or maybe a path with a single component)?

[Fumuran]

This is potentially possible, but will make creating procedure digests with procedure_digest! macro a bit less convenient (because AFAICS this is the only place where we use there constants).

To load a proc digest from some library we need to have a full path of this procedure. So we can change the names back to have just a procedure name, but we will have to additionally supply the library name to the macro to build an absolute path of this procedure.

This problem is actually the same to being able to search for the procedure in the account component using just the proc name.

[PhilippGackstatter]

Looks good to me!

[PhilippGackstatter]

Nit: I would import Path directly. Applies to more occurrences in this file.

[mmagician]

Note: as discussed in the client sync: not to be merged until @igamigo's follow-up to storage slots refactoring is in; the reason is that we'd like to migrate miden-client repo to use named storage slots first, so as to minimize the migration surface. A second migration to miden-client would follow after this PR is in.

[bobbinth]

Note: as discussed in the client sync: not to be merged until @igamigo's follow-up to storage slots refactoring is in; the reason is that we'd like to migrate miden-client repo to use named storage slots first, so as to minimize the migration surface. A second migration to miden-client would follow after this PR is in.

This also means that PRs which are likely to contain significant changes should be built on top of this PR.

[PhilippGackstatter]

@huitseeker Do you have a suggestion for resolving this cargo deny error?

error[duplicate]: found 2 duplicate entries for crate 'syn'
    ┌─ /home/runner/work/miden-base/miden-base/Cargo.lock:259:1
    │  
259 │ ╭ syn 1.0.109 registry+https://github.com/rust-lang/crates.io-index
260 │ │ syn 2.0.111 registry+https://github.com/rust-lang/crates.io-index
    │ ╰─────────────────────────────────────────────────────────────────┘ lock entries
    │  

https://github.com/0xMiden/miden-base/actions/runs/20288516906/job/58267639301#step:4:21

It seems like most things in the dependency tree use syn = 2 but Miden VM uses syn = 1. Maybe that can be updated to 2?

But also, since this is a build dependency, I think we can just allow duplicate versions.

Edit: Even when allowing syn duplicates, there are more cargo deny errors after that.

[huitseeker]

This LGTM. @PhilippGackstatter I pushed the setting that allows syn duplicates as the last commit of this PR. It seems to have fixed CI.