Create a funding service

[Mirko-von-Leipzig]

Now that fees are enabled, things are getting difficult to test without having the faucet available.

Moreover, on mainnet we won't have free access to funds from the faucet at all, so we also need a solution for this. The amount of funds will be negligible since txs are "cheap".

Create a service which has an endpoint to request funds for a specific account. e.g. Request { account_id, amount }. This triggers creating a tx to create a private p2id note for that account. Respond with the note ID, ideally with the inclusion proof aka wait for it to be committed.

Infrastructure accounts will periodically request funds to top themselves up i.e. this is not done frequently. This means there is no real benefit in attempting to coalesce requests into a single transaction. Though perhaps this would occur e.g. at monitor start up. Still this is an optimisation, not a requirement.

Authentication would be restricted at the infrastructure level, i.e. no need to bake in auth methods into the service.

The service should assume it has funds for now; initially we can prefund/create this at genesis.

Consider adding a maximum amount via cli.

[Mirko-von-Leipzig]

cc @SantiagoPittella @igamigo.

The intention is that the client integration tests could also use this. @SantiagoPittella perhaps see if this is simpatico with the monitor conceptually?

[igamigo]

Sounds good. A couple thoughts:

• this sounds very similar to what miden-faucet already does. Not much to do here because it depends on the client even if the dependency is through HTTP (although, on mainnet this would be more reusable since we don't nuke state), but just noting it
• client integration tests are already wired up for tests. You do need to provide an account/private key for an account you own that has some funds on mainnet though which is in principle simple but in practice maybe marginally a bit more cumbersome than hitting an HTTP API.
• monitor and integration tests could be users of this service, but would there be more? If not I wonder if this is overkill in a way. e.g. could we provide a simple UI in the monitor to paste a note ID into it to top up a funder account in the monitor that? I guess it would really be a simple service anyway but trying to think if there are interesting simple alternatives (but this depends a lot on whether this has 2 users or 10 and how different they are from each other)
• for things such as the integration tests we do care about having the fewest amount of transactions because of running time, but we can always top up one funder account and then have some tooling to fan out funds to many accounts which then test accounts use. Still would be nice to be able to top, say, 8 accounts at once. We could also have accounts return remaining funds once they are done

[Mirko-von-Leipzig]

• this sounds very similar to what miden-faucet already does. Not much to do here because it depends on the client even if the dependency is through HTTP (although, on mainnet this would be more reusable since we don't nuke state), but just noting it

Indeed. Though I guess a difference is simply that its not a faucet account itself. The main (long term) thing here is for mainnet.

• client integration tests are already wired up for tests. You do need to provide an account/private key for an account you own that has some funds on mainnet though which is in principle simple but in practice maybe marginally a bit more cumbersome than hitting an HTTP API.

Do all tests go via a single account? I thought there would be multiple accounts involved, including deployment tests? Or do they already have this flow of a single account funding the rest?

• monitor and integration tests could be users of this service, but would there be more? If not I wonder if this is overkill in a way. e.g. could we provide a simple UI in the monitor to paste a note ID into it to top up a funder account in the monitor that? I guess it would really be a simple service anyway but trying to think if there are interesting simple alternatives (but this depends a lot on whether this has 2 users or 10 and how different they are from each other)

Unclear, but centralizing it does let us expand without having to reimplement the same pattern. The monitor also currently is stateless, so every reset would require manual top up again. Other infrastructure providers would also like to have something like this.

All of this can be solved for each service/dApp separately, but I reckon having a central location may make sense.

[Mirko-von-Leipzig]

The design I originally had in mind was purely for the monitor use case. Where it would be a single, persisted account prefunded at genesis. And it would provide p2id notes via channels to the test accounts to transform directly into their fee note. i.e. one p2id per test tx.

This was then generalized as a gRPC p2id note stream to any infra account. The main "benefit" here is that the stream would always be full of p2id notes, ready to consume. So no latency, and users simply pluck the next p2id note into each tx.

But this adds complexity to the funding service, and it is simpler to have infrequent requests for a top up 🤷 I'm still somewhat partial to the channel idea, and it could be implemented regardless e.g. for your integration tests, with a fan out. But probably just having an easy way to get funds is more important.

[igamigo]

Unclear, but centralizing it does let us expand without having to reimplement the same pattern. The monitor also currently is stateless, so every reset would require manual top up again.

The monitor could handle a single funder account and use that to distribute funds to all volatile accounts (IIRC some scenarios don't even require a restart to result in new accounts getting created), and this account could be the only one that it persists. Shouldn't be hard to implement, but also I think I agree with generalizing and factoring this out into its own service.

Other infrastructure providers would also like to have something like this.

Yeah, it sounds very likely that more infra will need more of this.

Do all tests go via a single account? I thought there would be multiple accounts involved, including deployment tests? Or do they already have this flow of a single account funding the rest?

You can have as many funding accounts as you want, and then tests request from these accounts. There are a bunch of optimizations we did (consuming the funds optimistically as unauthenticated notes, merging the deploy tx and the first test tx together) and we are still improving this (we can avoid creating specific faucets within the tests, and also was thinking about having something like your channel idea where we could even merge funding requests for test accounts)

One thing to think about is authentication. This should be simple to solve, but even simpler if we assume only infra providers will be able to access it. Another thing is how we fund the funder, but it also should be fairly straightforward (SyncNotes and detect any P2ID note, discard the rest and consume them on the next tx).

[Mirko-von-Leipzig]

This should be simple to solve, but even simpler if we assume only infra providers will be able to access it.

I think delegate to infrastructure i.e. load-balancer/proxy problem.

Another thing is how we fund the funder, but it also should be fairly straightforward (SyncNotes and detect any P2ID note, discard the rest and consume them on the next tx).

Several options, but could be as simple as:

1. Prefund via genesis.
2. Top up via admin console or note submission endpoint or public note which it can sync.

[SantiagoPittella]

we could prefund in genesis but eventually will require a top up, right?

[Mirko-von-Leipzig]

we could prefund in genesis but eventually will require a top up, right?

Yes, I think my point is more that we should establish a single service which can provide funds. That way we only have to worry about maintaining a single place to fund manually.

The genesis prefund is more an ease of use for bootstrapping/resetting networks. Otherwise we have to manually provision it only after the faucet is online.

[Mirko-von-Leipzig]

Though on devnet and testnet we could prefund enough to last.. decades. And manual top up would be in case of bug etc