Migrate faucet to using a network account

[igamigo]

Originally discussed here.
The idea is that, to avoid modifying the standard account components, on genesis we can prefund a set of accounts to allow for the different services to work well.

The faucet could be modified to be deployed as a network account which gets operated by a wallet which the UI controls. Basically, in terms of specific changes:

• The faucet backend now cares about 2 accounts: the network faucet, and the faucet operator (which is a local account)
• We should make it so that both the network account ID and operator accounts are provided at instantiation time. The main faucet client really only cares about the latter of these, since it will be the one that drives the network account
• The UI now collects requests with solved PoW challenges, and basically uses the wallet to emit one network note per each request and sends it to the network faucet (the request/network note). It's unclear to me whether a single network note can carry information for minting multiple asset notes (we'd have to look into the faucet standard) but it'd be ideal if it could, to avoid bloating the network with mint requests.

Some points:

• Since the minting process now really takes 2 transactions, there's more end-to-end latency
• It's not super clear whether we can easily provide the same flows after having minted the notes. For example, the network faucet will not be able to use the NTL to send private notes. I think we should be able to know all the details from the asset notes beforehand, so after minting we can decide to instantly provide a NoteFile that users/wallets can import. We could also poll the node from the frontend to see when the end asset note gets created
• Should we provide other operator transactions?

cc @bobbinth

[bobbinth]

It's not super clear whether we can easily provide the same flows after having minted the notes. For example, the network faucet will not be able to use the NTL to send private notes. I think we should be able to know all the details from the asset notes beforehand, so after minting we can decide to instantly provide a NoteFile that users/wallets can import. We could also poll the node from the frontend to see when the end asset note gets created

Could another option be that we still follow the network account so that we can detect once the MINT note has been consumed and the P2ID note is issued? From that point on, everything should work as it does now. Basically, the latency would increase (hopefully by no more than 3 - 5 seconds), but the overall functionality would remain largely the same.

[igamigo]

Could another option be that we still follow the network account so that we can detect once the MINT note has been consumed and the P2ID note is issued? From that point on, everything should work as it does now. Basically, the latency would increase (hopefully by no more than 3 - 5 seconds), but the overall functionality would remain largely the same.

Yeah, this should work.

I think we can split this work into 3 changes:

• First, replace backend account with a network faucet operator account:
  • On startup, we can check if the client account exists and error out if it does not
  • We should also check that the network faucet exists
  • init would have to create the operator account and create and deploy the network faucet
  • Question here: do we want the faucet operator account to be public? I think so in order to make it easily recoverable from the network, but we could also decide to make it private (we'd have to look into doing backups of some sort)
  • The PoW challenges batching mechanisms should stay the same, except they result in the creation of one note per request
• Secondly, implement importing the network faucet as a watched account and see if we can provide the same exact flows as before
  • One caveat here is that we would have to speak directly (either from the backend or the frontend) with the NTL. When we see that the network faucet has committed a new transaction, we can send the output notes directly
• Lastly, we can look into trying to minimize the number of operator-output notes. I think we would have to create a note script that loads as many targets as possible from storage/attachments.
  • As we talked offline with @TomasArrachea , we'd have to whitelist this new script root on the network auth component, which might be a dealbreaker. The point of using standards here is probably not to mess too much with audited code and this would break that. As an upside, we'd greatly reduce the number of notes the network creates (the faucet already outputs millions of notes in the lifetime of a testnet version, so if we don't do such an optimization we'd be duplicating that number).

[bobbinth]

Question here: do we want the faucet operator account to be public? I think so in order to make it easily recoverable from the network, but we could also decide to make it private (we'd have to look into doing backups of some sort)

I'd keep it public - at least initially - to simplify the implementation.

Lastly, we can look into trying to minimize the number of operator-output notes. I think we would have to create a note script that loads as many targets as possible from storage/attachments.

If we do decide to do this, I'd probably modify the MINT note so that we could mint multiple P2ID notes from it. Let's create an issue for this in the protocol repo.