feat!: enforce fees

[LeilaWang]

Circuits

• Private kernels ensure that fee payer is not empty.
• Private base rollup and the avm check that the fee payer must have enough balance to pay the fee.

Aztec.js/cli

• Default payment method is FeeJuicePaymentMethod, the fee payer is the wallet owner.
• NoFeePaymentMethod is no longer available.

End-to-end/Sandbox

• Some public data leaves are created for funding the initial test accounts with fee juice. The genesis archive root and block hash are generated with these public data leaves.
  • For the e2e tests, the test accounts are generated randomly.
  • For the sandbox, the test accounts are defined in @aztec/accounts/testing.
• These funded test accounts can deploy their own account contract and pay the fee for the deployment themselves.
• These funded test accounts can be used to deploy another account without pre-funded fee juice.
  • By calling someAccountManager.deploy({ deployWallet: fundedWallet })
• BananaCoin and BananaFPC are deployed in sandbox by default. Users can use the funded accounts to mint banana coin for a new account.
  • The new account can then submit transactions and pay the fees using PrivateFeePaymentMethod.
  • See example in end-to-end/src/composed/e2e_sandbox_example.test.ts

[benesjan]

This seems fine to me but I would do 3 chagnes:

1. Rename the capsules passed via constructor here as ephemeralCapsules to make it clear that it's different data from the ones stored in the DB.
2. Here check that there is no pertinent capsule under the storage slot of the ephemeral one - if it turns out that there is throw an error. I don't like the idea of ephemeral capsules overshadowing the pertinent ones.
3. Please update the docs of the load oracle of capsules.nr.

I will also tag Nico here since I feel like he might disagree with me 😆

@nventuro Leila is passing here an ephemeral capsule to the context that live only during tx simulation and the data is being served via the same loadCapsule oracle. Do you think it's fine? (please ignore this until you come back from vacation)

[LeilaWang]

I'm thinking all capsules are ephemeral. The pertinent data is only available when it's stored by the contract itself. So the previous names, dbStore, dbLoad, etc, make more sense in this case!

[benesjan]

I'm thinking all capsules are ephemeral.

We've decided to update the meaning of what are capsules to not be ephemeral by default. So capsules 2.0 are basically a totally different thing from capsules 1.0. Here is the relevant issue.

[LeilaWang]

Can we still separate the apis so that it's clear to the contract users how the data is being retrieved : it could be the data that's previously stored by the contract itself so the users don't have to do anything, or ephemeral data that needs to be provided by the users for the simulation.

And I assume it's the wallet's responsibility to sync the stored capsules across devices?

[benesjan]

Do you mean by creating a separate oracle handler for the ephemeral capsules and leave the capsules 2.0 intact?

[LeilaWang]

Yes! For the ephemeral capsules there will just be one load api. And when users see this in the contract, it's clear to them that they need to prepare the data themselves for building the tx request.
And for capsules 2.0, nothing needs to be done on users' side, as long as the pxe has all the data previously stored by the contract.

[benesjan]

That indeed seems cleaner.

Then in the contract we could have capsules::load(...) or ephemeral_capsules::load(...) with the function args being the same.