Add script constructors from `Package`

[igamigo]

Recently, a constructor for account components based on the compiler's Package was added. In the same vein, should there be constructors for transaction and note scripts that construct scripts from the package's MAST artifacts?
This would integrate the compiler better and make it easier on the client and for users in general to use it as part of their workflows (see 0xMiden/miden-client#1545 for more context).

[bobbinth]

Yes, I think there should be.

@greenhat - how can we figure out if a given package was compiled for an account component, note script, or transaction script? (I believe there is a field in the metadata that allows us to do this)

[greenhat]

Yes, I think there should be.

@greenhat - how can we figure out if a given package was compiled for an account component, note script, or transaction script? (I believe there is a field in the metadata that allows us to do this)

The general package metadata does not contain the package kind (account, note, tx script, etc.), only the name, version and description. The only custom section in the package holds serialized AccountComponentMetadata (optional, only for accounts). The MAST for an account should be a library and for any script it should be a program. But I don't think we can reliably differentiate between a note script and a tx script. @bitwalker any ideas?

[bobbinth]

The general package metadata does not contain the package kind (account, note, tx script, etc.), only the name, version and description. The only custom section in the package holds serialized AccountComponentMetadata (optional, only for accounts). The MAST for an account should be a library and for any script it should be a program

Ah - I see. But there is a way to tell if a package is for a library or an executable, right? If so, the decision tree could be:

• Check if the package is a library or an executable:
• If library, see if it has AccountComponentMetadata, and if so, we know this is for account component.
• If executable, try to build either a note or a tx script out of the contained code.

But I don't think we can reliably differentiate between a note script and a tx script. @bitwalker any ideas?

I think some work that we are doing with note ergonomics now (i.e., defining note as a struct), will probably enable adding something like NoteMetadata section to packages in the future. What exactly goes into this section probably deserves a separate issue, but it could be metadata describing note input schema, maybe note input validation logic, info about what interfaces the note requires on the account (e.g., P2ID note requires a BasicWallet).

[greenhat]

The general package metadata does not contain the package kind (account, note, tx script, etc.), only the name, version and description. The only custom section in the package holds serialized AccountComponentMetadata (optional, only for accounts). The MAST for an account should be a library and for any script it should be a program

Ah - I see. But there is a way to tell if a package is for a library or an executable, right?

Yes, the inner MAST will be either a program or a library.

But I don't think we can reliably differentiate between a note script and a tx script. @bitwalker any ideas?

I think some work that we are doing with note ergonomics now (i.e., defining note as a struct), will probably enable adding something like NoteMetadata section to packages in the future. What exactly goes into this section probably deserves a separate issue, but it could be metadata describing note input schema, maybe note input validation logic, info about what interfaces the note requires on the account (e.g., P2ID note requires a BasicWallet).

Makes sense. This info will most likely end up as a custom section. We already can encode the project kind into the Miden package. I mean we have project-kind in the Cargo.toml (see an example at https://github.com/0xMiden/compiler/blob/3b6c164fcf7e4ea6b08cd28f2db982728ed16f29/examples/basic-wallet/Cargo.toml?plain=1#L22). We should consider putting the project kind in the Miden package header along with the name, version, etc. So far I see the following kinds: account, note script, tx script, auth component, generic program.

[bobbinth]

We should consider putting the project kind in the Miden package header along with the name, version, etc. So far I see the following kinds: account, note script, tx script, auth component, generic program.

I think that's a good idea. Let's create an issue for this in miden-vm.