[1/2] Authentication component rollup target

[greenhat]

Close #660
Close #667

Corresponding template repo PR - 0xMiden/rust-templates#21

I suggest reviewing this PR on a per-commit basis.

This PR:

• Adds new project template for the authentication component (cargo miden new --auth-component [NAME]);
• Adds example/auth-component-no-auth example project for no-auth version;
• Adds a local network test using the example/auth-component-no-auth as an authentication component using miden-client in the counter contract scenario;
• Fixes a few issues discovered along the way.

[Copilot]

Pull Request Overview

This PR adds support for authentication components to the Miden rollup system by introducing a new project template and compilation target for authentication components.

• Adds --auth-component template for creating authentication components that validate account state changes
• Implements a "no-auth" authentication component example that increments nonce when account state changes
• Adds local network test demonstrating authentication component usage in counter contract scenario

Reviewed Changes

Copilot reviewed 189 out of 190 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tools/cargo-miden/src/commands/new_project.rs	Adds auth-component template option and updates template tag version
tools/cargo-miden/src/target.rs	Adds AuthComponent rollup target detection and library type mapping
tools/cargo-miden/src/lib.rs	Adds authentication component midenc compilation flags and RUSTFLAGS management
tools/cargo-miden/tests/build.rs	Adds test for auth-component template validation
midenc-session/src/lib.rs	Adds AuthComponent rollup target enum variant
sdk/base/wit/miden.wit	Adds authentication-component interface definition
examples/auth-component-no-auth/	New example authentication component with no-auth implementation
tests/integration-node/src/node_tests/counter_contract_no_auth.rs	Test demonstrating auth component usage

Comments suppressed due to low confidence (1)

tools/cargo-miden/src/target.rs:54

• The error message is outdated and doesn't include the new 'authentication-component' option. It should be updated to include all valid project kinds.

        _ => bail!(
            "Invalid value '{}' for 'project-kind' in [package.metadata.miden]. Must be one of: \
             'account', 'note-script', or 'transaction-script'",
            kind_str

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[greenhat]

@bitwalker Rebased and ready for review.

[bitwalker]

Looks good! There is one change that should be reverted here though (see my comment for details)

[bitwalker]

The init procedure needs to be public, so that it can be called from any callable procedure in the component that needs to initialize a fresh context in its prologue.

[greenhat]

I'm not sure that I understand why init needs to be public. We only invoke the init in our lifted exports functions (see an example at

compiler/tests/integration/expected/examples/basic_wallet.masm

Lines 13 to 21 in 4efe063

	export.move-asset-to-note
	exec.::miden:basic-wallet/[email protected]::init
	trace.240
	nop
	exec.::miden:basic-wallet/[email protected]::basic_wallet::miden:basic-wallet/[email protected]#move-asset-to-note
	trace.252
	nop
	exec.::std::sys::truncate_stack
	end

) which we place in the same module. The lifted export function is then called without any prologue and epilogue at the call site. So the lifted export functions are the only public procedures in the component.

See also the discussion that led to making init private at 0xMiden/miden-base#1877

[bitwalker]

It should be noted that the fact we're emitting a single module for a given Wasm binary is incidental here, it isn't an inherent structural thing, just an artifact of how Rust compiles to Wasm.

In any case, if we can guarantee that all exports from a component (including a program entrypoint, if present), are emitted to the same underlying MASM module, sure, the init procedure can be private in that case. I didn't think that was something we guaranteed, so much as it was a happy accident of how things get compiled from Rust.

I'm fine with making this private until there is an actual issue in practice, but wanted to raise the chance of it being an issue during review to make sure the change is actually well-motivated.

[bitwalker]

Marking this approved, per my latest comment