Templating of auth procedures

[mmagician]

Placeholder issue

[...] There could be other ways to describe actions that need to be authenticated. For example, to check if an someone is trying to modify account settings, we could check if the initial and final storage slots with these settings have changed, and if so, require some special action. I'm not sure yet what's a more general approach here - but we may need to start thinking about "templating" of auth procedures.

Originally posted by @bobbinth in #1806

[PhilippGackstatter]

If we do end up having templating with something like this:

let my_create_component: MyCreateComponent = todo!()
AuthRpoFalcon512::new(pub_key, AccountComponent::from(my_create_component))

Then it'd be nice to still be able to allow users to check if AuthRpoFalcon512 is present in an AccountInterface. Because the create component would change the MAST root, our current approach of iterating the set of exported procedures may not work with this. One idea is that, instead of implementing functions that return components in an interface, the user should rather provide a component and the function checks if it is present / can be reconstructed, e.g:

let has_component: bool = account_interface.contains_component::<AuthRpoFalcon512<()>>(&account_storage);
// and / or
let component: AuthRpoFalcon512<()> = account_interface.try_from_component(&account_storage)?;

Potentially, we can then just have a default template implementation like () that avoids the need to provide the concrete component that was used for templating. The underlying Library should still have the MAST root of the actual auth procedure (which is however not exported) defined by AuthRpoFalcon512 which would be how the functions check if that component is present (and recreate it). That last point I'm not completely sure about, but I think it should work.

[bobbinth]

instead of implementing functions that return components in an interface, the user should rather provide a component and the function checks if it is present / can be reconstructed

I like this idea - though, I'm starting to somewhat question the usefulness of the AccountComponentInterface concept. IIRC, we use this in 3 places:

1. We use this in the note consumption checker to figure out if some well-known notes can be executed against an account. This isn't really relevant to auth procedures because auth procedures can't really function properly during such checks (at least in most cases). And also, for our use case, there is probably a simpler way to check whether a well-known note complies with the account interface (e.g., a note could provide a set of procedures that must be on the account interface for it to work).
2. We use this in the client to be able to figure a set of public keys associated with a specific account. But as discussed some time ago, there are probably better ways to do this (cc @igamigo just in case).
3. This could be useful for general account introspection (e.g., in the explorer) but here there are also probably better approaches.

If we do get rid of the concept AccountComponentInterface (at least in its current form), then templating becomes pretty simple.

[PhilippGackstatter]

I agree with those points. Getting rid of AccountComponentInterface seems possible. We have the try_from_interface for BasicFungibleFaucet, and this pattern could be generalized into a trait that account components can implement.

Currently, account interface is defined as:

pub struct AccountInterface {
    account_id: AccountId,
    auth: Vec<AuthScheme>,
    components: Vec<AccountComponentInterface>,
}

This is what that could look like without AccountComponentInterface, in the interface and assuming named storage slots (from #2025):

/// This is what was previously AccountProcedureInfo.
/// After the named storage slots refactor there is no storage offset or size, so this wraps
/// just a MAST root.
#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]
pub struct AccountProcedureRoot(Word);

pub struct AccountInterface {
    account_id: AccountId,
    /// The MAST roots of the procedures in the account interface.
    /// This would actually be AccountProcedureInfo
    procedures: BTreeSet<AccountProcedureRoot>,
}

impl BasicFungibleFaucet {
    /// Returns the set of MAST roots of this account component.
    pub fn procedures() -> BTreeSet<AccountProcedureRoot> {
        BTreeSet::from_iter([
            AccountProcedureRoot(Self::distribute_digest()),
            AccountProcedureRoot(Self::burn_digest()),
        ])
    }

    fn try_from_interface(
        interface: AccountInterface,
        storage: &AccountStorage,
    ) -> Result<Self, FungibleFaucetError> {
        if !Self::procedures().is_subset(&interface.procedures) {
            return Err(FungibleFaucetError::NoAvailableInterface);
        }

        let faucet_metadata = storage
            .get_item(BasicFungibleFaucet::metadata_slot_name())
            .map_err(|err| FungibleFaucetError::StorageLookupFailed {
                slot_name: BasicFungibleFaucet::metadata_slot_name().clone(),
                source: err,
            })?;
        let [max_supply, decimals, token_symbol, _] = *faucet_metadata;

        // verify metadata values
        let token_symbol = TokenSymbol::try_from(token_symbol)
            .map_err(FungibleFaucetError::InvalidTokenSymbol)?;
        let decimals =
            decimals.as_int().try_into().map_err(|_| FungibleFaucetError::TooManyDecimals {
                actual: decimals.as_int(),
                max: Self::MAX_DECIMALS,
            })?;

        BasicFungibleFaucet::new(token_symbol, decimals, max_supply)
    }
}

I think, ideally, we'd also remove AuthScheme from the interface as done here, and then implement AuthRpoFalcon512::try_from_interface, AuthRpoFalcon512Acl::try_from_interface, etc. to be able to extract auth components in the same way as any other account component. From there, we can determine the auth schemes and public keys, though ideally this happens at the miden standards or a higher level.

To do this, it may be necessary to generalize the try_from_interface into a trait that all account components should implement, for which this conversion is desired. One question to answer next is what this trait should be called and whether we should enforce all account components to implement it, i.e. by encapsulating both the CustomComponent -> AccountComponent conversion and the (AccountInterface, AccountStorage) -> CustomComponent conversion into that trait.