Skip to content

Decide whether to refactor verify_signatures and standard faucets #2135

@PhilippGackstatter

Description

@PhilippGackstatter

After #2025, we should decide how to proceed with these two APIs.

verify_signatures

The miden::auth::rpo_falcon512::verify_signatures API has the following signature:

#! Inputs:  [pub_key_slot_prefix, pub_key_slot_suffix, num_of_approvers, MSG]
#! Outputs: [num_verified_signatures, MSG]

This is used only by the RPO Falcon512 multisig component. The question here is whether the procedure should assume that public keys are stored in a certain slot name (i.e. miden::standards::auth::rpo_falcon512_multisig::approver_public_keys) or if it should stay parameterized.

For this case, my opinion is that hardcoding the slot name would make it too specific to the multisig component and in that case, it would make more sense to move verify_signatures to the multisig component directly.

This applies analogously to the ecdsa_k256_keccak multisig component.

Faucet metadata

This concerns the BasicFungibleFaucet and NetworkFungibleFaucet components. The miden::contracts::faucets::distribute procedure, which is used by both components, currently hardcodes the METADATA_SLOT to miden::basic_fungible_faucet::metadata.

The distribute procedure is generic over the exact kind of faucet. So, my opinion is that this should become a standardized slot name for use by faucets in general, in which case a name like miden::standards::faucets::metadata would make sense. The exact name is debatable, e.g. if we think we only want a "basic metadata" standard for now, then the slot name can reflect that.

Consequently, the {BasicFungibleFaucet, NetworkFungibleFaucet}::metadata_slot would be defined as that slot name.

Summary

To summarize:

  • For relatively generic procedures like verify_signatures I think it makes sense to take the slot name as a parameter. So, no action required after feat: implement API changes for named storage slots #2025.
  • Standard slot names are fine to be read and written in different components. Basic fungible and network fungible faucet already share the same name, but I think it should be more generic than it is now (i.e. miden::standards::faucets::metadata).

Some context that spawned this:

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueGood for newcomersrustIssues that affect or pull requests that update Rust codestandardsRelated to standard note scripts or account components

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions