feat!: re-do partial notes #12391
feat!: re-do partial notes #12391
Conversation
| @@ -1,25 +1,320 @@ | |||
| use aztec::{macros::notes::partial_note, oracle::random::random, prelude::AztecAddress}; | |||
| use dep::aztec::{ | |||
There was a problem hiding this comment.
This file is a copy-paste of uint_note.nr except using field instead of u128. Read that one instead.
| let encrypted_log = default_aes128::note::compute_log( | ||
| *context, | ||
| private_log_content, | ||
| storage_slot, | ||
| recipient, | ||
| sender, | ||
| ); | ||
| context.emit_private_log(encrypted_log); |
There was a problem hiding this comment.
is there a way of not-choosing to use default_aes128 encryption strategy here?
can the fn partial have as input an encryption method?
There was a problem hiding this comment.
As of today, encryption is hardcoded in PXE to be AES. We'll soon move it into aztec-nr, at which point it'd be possible to somehow configure which encryption algorithm the contracts wishes to use. But this is just a first step, so it'll take a while to get there. Keep in mind this is the very first attempt to do this this alternative way. We'd similarly want to allow for unconstrained encryption etc.
There was a problem hiding this comment.
this file imports encrypted_logs::log_assembly_strategies::default_aes128::note::encode_and_encrypt_note but could be using other encryption strategy, are both partial notes and full notes processed independently? (could they work with different setups?)
| quote { | ||
| impl aztec::event::event_interface::EventInterface<$content_len> for $name { | ||
| fn get_event_type_id() -> aztec::protocol_types::abis::event_selector::EventSelector { | ||
| aztec::protocol_types::abis::event_selector::EventSelector::from_field($event_type_id) | ||
| $from_field($event_type_id) |
There was a problem hiding this comment.
This was creating warnings and bothering me, so I fixed it in true @benesjan style
| typ.get_trait_impl(trait_constraint).unwrap().methods().filter(|m| m.name() == target_method)[0] | ||
| typ.get_trait_impl(trait_constraint).expect(f"Type does not implement trait").methods().filter( | ||
| |m| m.name() == target_method, | ||
| )[0] |
There was a problem hiding this comment.
There is another copy of get_trait_impl_method in protocol-circuits-types. Makes sense to copy this change over there as well.
| impl NoteHash for UintNote { | ||
| fn compute_note_hash(self, storage_slot: Field) -> Field { | ||
| // Partial notes can be implemented by having the note hash be either the result of multiscalar multiplication | ||
| // (MSM), or two rounds of poseidon. MSM results in more constraints and is only required when multiple variants |
There was a problem hiding this comment.
Interesting. Do you know the resulting constraint difference here?
It's cool that this is so much simpler than fiddling with generators and MSM.
There was a problem hiding this comment.
iirc msm is ~3k, and poseidon should be ~500.
|
|
||
| NFT::at(context.this_address())._store_nft_set_partial_note(partial_note).enqueue(context); | ||
|
|
||
| partial_note | ||
| } |
There was a problem hiding this comment.
Fanstastic how concise ^ this has become.
| ) { | ||
| context.storage_write(slot, point); | ||
| context.storage_write(slot + aztec::protocol_types::point::POINT_LENGTH as Field, setup_log); | ||
| fn _store_nft_set_partial_note(partial_note: PartialNFTNote) { |
There was a problem hiding this comment.
Do we still have some plan down the pipeline to somehow get rid of this public call?
There was a problem hiding this comment.
No, best thing we could do is have the library automatically inject it.
c6fc6cb to
106ce57
Compare
fedae6d to
2a9675f
Compare
2a9675f to
35e25d2
Compare
Closes #9375.
This re-implements partial notes leveraging the work from #12122. We now emit a private log with all of the fields plus a 'public log completion tag', which is the tag of the public log that will contain the public fields. These two logs are merged when doing discovery, resulting in the note's packed representation.
All in all this means we need to store much less information in public storage (just one field), and we don't need to deal with publishing public logs with encrypted public content. It also removes a lot of PXE code that dealt with the destructuring of these logs, slicing off the public fields, etc. Once this is merged, moving decryption to NR should be trivial.
I iterated a bit on how the note structs are laid out and thing the current version is a reasonably good starting point. Eventually we'll autogenerate it via macros, but given we may want to introduce further changes I chose to not worry about that for now.
We're currently sort of hackily relying on the fact that note type ids are 7 bits long, and set the 8th bit to indicate the log is that of a partial note. Fixing this requires properly supporting events during log discovery (which would become message discovery), but that's out of scope for this PR.