Skip to content

Network faucet with note-based authentication #1891

@mmagician

Description

@mmagician

Currently, our default faucet contract is a local account with AuthRpoFalcon512Acl authentication (with distribute as the trigger procedure, and allowing anyone to call burn).

Going forward, we should deprecate this account (as it opens the door to DoS attack as described here), and instead have two types of faucets in use:

  1. Local faucet with the standard AuthRpoFalcon512, with only the owner able to call distribute and burn (used for testnet faucet)
  2. Network faucet with note-based authentication (used for all other faucets incl. the AggLayerFungibleFaucet

The first point is straightforward. The second needs some more work:

  1. Instead of calling distribute directly from a transaction script, network accounts operate by consuming notes addressed to them. It's the note script should call distribute / burn (and for the latter, carry the specified asset).
  2. The account's storage contains the AccountId of the owner. When a distribute note is consumed by the faucet, it first checks whether owner == note.sender. A burn note doesn't perform this check, allowing anyone to send BURN notes.

In terms of storage, the main difference with the current faucet is that we'd store owner's AccountId rather than their public key. One nice effect of this is that the faucet no longer cares whether the owner is a single account or a multisig.

Overall, this entails:

  1. create_basic_fungible_faucet to switch back to AuthRpoFalcon512. Should be renamed to create_local_fungible_faucet (and in similar fashion, rename BasicFungibleFaucet -> LocalFungibleFaucet)
  2. Create a standard DISTRIBUTE note
  3. Create a standard BURN note
  4. New create_network_fungible_faucet which builds a network account with a new NetworkFungibleFaucet component

+ we should rename distribute -> mint as it's a more standard term for token contracts.

Relevant discussion: 0xMiden/faucet#77


Open question (general)

  • are authentication procedures useful for network accounts? If not, we should remove the requirement for network accounts to contain an auth procedure (more tricky because calling the auth procedure is hardcoded into the epilogue), or at least automatically insert a NoAuth procedure without explicitly requiring AccountBuilder::new(seed).with_auth_component(auth::NoAuth)

Metadata

Metadata

Assignees

No one assigned

    Labels

    agglayerPRs or issues related to AggLayer bridging integrationstandardsRelated to standard note scripts or account components

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions