-
Notifications
You must be signed in to change notification settings - Fork 311
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
feat: meaningful outgoing #6560
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
27d18ce
to
213e586
Compare
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Proof generationEach column represents the number of threads used in proof generation. | Metric | | L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.
Stats on running time collected for app circuits
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method | Metric | | |
dfd0779
to
d55bb94
Compare
b7f0e6d
to
f446654
Compare
// Not emitting outgoing for msg_sender here to not have to register keys for the contract through which we | ||
// deploy this (typically MultiCallEntrypoint). I think it's ok here as I feel the outgoing here is not that | ||
// important. | ||
let this_ovpk_m = header.get_ovpk_m(&mut context, this); |
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.
@LHerskind in your original review you wanted me to use msg_sender here as outgoing viewer. After all I decided against it because of the comment above.
I feel like given that it's a constructor it's commonly deployed from non contract address (I think it was throwing address 0 in the tests when I tried to change it) so makes sense to not have them set properly here.
This contract is commonly deployed as the first contract with keys so there is a chicken and egg problem here if we wanted to have an outgoing_viewer arg here.
WDYT?
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.
Likely fine otherwise would pass it as input 🤷. I'm still curious around the chicken and egg problem for fees as well 🐔 🥚
// Not emitting outgoing for msg_sender here to not have to register keys for the contract through which we | ||
// deploy this (typically MultiCallEntrypoint). I think it's ok here as I feel the outgoing here is not that | ||
// important. | ||
let this_ovpk_m = header.get_ovpk_m(&mut context, this); |
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.
Same as for the ecdsa account:
"I feel like given that it's a constructor it's commonly deployed from non contract address (I think it was throwing address 0 in the tests when I tried to change it) so makes sense to not have them set properly here."
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.
Same answer.
@@ -30,6 +30,16 @@ contract StaticParent { | |||
context.call_private_function(target_contract, target_selector, args).unpack_into() | |||
} | |||
|
|||
// Just like function above but with 3 args. | |||
#[aztec(private)] | |||
fn private_call_3_args( |
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.
Needed to add this because now the private_call func was used with nested functions with different arg lengths.
// Not emitting outgoing for msg_sender here to not have to register keys for the contract through which we | ||
// deploy this (typically MultiCallEntrypoint). I think it's ok here as I feel the outgoing here is not that | ||
// important. | ||
let this_ovpk_m = header.get_ovpk_m(&mut context, this); |
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.
Likely fine otherwise would pass it as input 🤷. I'm still curious around the chicken and egg problem for fees as well 🐔 🥚
ovpk_m_x_registry.schedule_value_change(ovpk_m.x); | ||
ovpk_m_y_registry.schedule_value_change(ovpk_m.y); | ||
tpk_m_x_registry.schedule_value_change(tpk_m.x); | ||
tpk_m_y_registry.schedule_value_change(tpk_m.y); |
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.
With this added down here, we could also expose the function at the getter higher up? The reason was that it would never be set but it can be now 🤔
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.
Good idea, will do in a follow up cleanup PR.
// Not emitting outgoing for msg_sender here to not have to register keys for the contract through which we | ||
// deploy this (typically MultiCallEntrypoint). I think it's ok here as I feel the outgoing here is not that | ||
// important. | ||
let this_ovpk_m = header.get_ovpk_m(&mut context, this); |
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.
Same answer.
pub fn add<T_SERIALIZED_LEN, T_SERIALIZED_BYTES_LEN>( | ||
self: Self, | ||
outgoing_viewer: 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.
The ordering is going to fuck me up, I guarantee it 😆
async kind => { | ||
const testWallet = kind === 'as entrypoint' ? new SignerlessWallet(pxe) : wallet; | ||
const owner = await t.registerRandomAccount(); | ||
const initArgs: StatefulContractCtorArgs = [owner, 42]; | ||
const outgoingViewer = owner; | ||
const initArgs: StatefulContractCtorArgs = [owner, outgoingViewer, 42]; |
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.
Damn on the test are just using the same values hehe.
oracle.getKeyValidationRequest.mockImplementation((npkMHash: Fr, contractAddress: AztecAddress) => { | ||
if (npkMHash.equals(ownerCompleteAddress.publicKeys.masterNullifierPublicKey.hash())) { | ||
oracle.getKeyValidationRequest.mockImplementation((pkMHash: Fr, contractAddress: AztecAddress) => { | ||
if (pkMHash.equals(ownerCompleteAddress.publicKeys.masterNullifierPublicKey.hash())) { |
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.
The way all of this looks make me want to refactor so there is a small map or something to lookup 😆 but I think it can do for the test.
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.
Good point, I will clean this up in my following PR to finally get this one in.
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.
it's actually a pain to do because different functions are called for different branches so
Fixes #6410