-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: fpc optimization, cleanup + docs #10555
Conversation
35a2868
to
bc6c54b
Compare
Changes to public function bytecode sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
#[public] | ||
#[internal] | ||
fn prepare_fee(from: AztecAddress, amount: Field, asset: AztecAddress, nonce: Field) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nuked this function as it was superfluous --> we could just enqueue the call to the token directly from the private function (which saves 1 kernel iteration).
#[private] | ||
fn fee_entrypoint_public(amount: Field, asset: AztecAddress, nonce: Field) { | ||
FPC::at(context.this_address()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nuked the prepare_fee function as it was superfluous --> we could just enqueue the call to the token directly from the private function (which saves 1 kernel iteration).
&mut context, | ||
); | ||
#[view] | ||
fn get_accepted_asset() -> AztecAddress { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exposed this so that we can load this info directly from contract instead of having to pass that value in our TS API.
@@ -615,9 +615,9 @@ contract Token { | |||
|
|||
/// We need to use different randomness for the user and for the fee payer notes because if the randomness values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unified the naming in this contract with FPC.
@@ -42,8 +41,40 @@ export class PrivateFeePaymentMethod implements FeePaymentMethod { | |||
* The asset used to pay the fee. | |||
* @returns The asset used to pay the fee. | |||
*/ | |||
getAsset() { | |||
return this.asset; | |||
getAsset(): Promise<AztecAddress> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now obtaining the value directly from the contract --> this declutters the API.
7338f52
to
ae343c7
Compare
ae343c7
to
ceabdbb
Compare
// since we're interested in the first set of values AFTER the account entrypoint | ||
// For public functions we retrieve the first values directly from the public output. | ||
const rawReturnValues = | ||
this.functionDao.functionType == FunctionType.PRIVATE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assumed that we always simulate via an account contract and if we did not it would fail with undefined. Since I did exactly that in this PR I've stumbled upon this. Note that there is a new issue that needs to be tackled.
/// 1. `setup_refund` function subtracts the `max_fee` from user's balance of AA, prepares partial notes | ||
/// for the `private_fee_recipient` (to obtain the payment in AA for the fee) and for the msg_sender (for refund | ||
/// note of the AA) and sets a public teardown function (in which the partial notes will be finalized), | ||
/// 2. then the private and public functions of a tx get executed, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does private_fee_recipient
need to receive the payment privately? The amount is public, and the address is public. Can't we just send them public balance? That'd be much cheaper since there are no logs etc., and also less gates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes total sense. Will do the change 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not as part of this PR, but I do think we need an example for how someone can pay a fee privately with the following kept private:
- The user
- The FPC contract address
- The asset used to pay the fee.
If there are to be many FPCs on Aztec, then this information will drastically reduce Aztec's global privacy set.
Ideally we'd have an example of a way to pay fees without leaking any of this info.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created an issue for this.
If there are to be many FPCs on Aztec, then this information will drastically reduce Aztec's global privacy set.
As we discussed in a scrum, this could be alleviated by us integrating the FPC with the token contract and allowing only for a few of those (e.g. 2 stablecoins and ETH).
6949ccf
to
bd10e66
Compare
41c3df4
to
03946d4
Compare
FPC code docs, overall cleanup and refactor, improved naming, ContractFunctionInteraction fix.
Note 1: Based on Nico's feedback the fee is paid in public and not in private (only the refund is paid in private as we need to conceal the identity of the user --> identity of the FPC is public so no need to waste resources on the private note).
Note 2: there is no longer a fee_recipient passed to the
setup_refund
function as it's no longer required --> before it was required because we needed someone to receive the fee note and the FPC could not receive notes. With the change to public we just send the fee directly to FPC.