feat: packing note content

[benesjan]

Fixes #11375

[benesjan]

• feat: packing events #11544
• feat: #[derive(Packable)] #11531
• refactor: using UintNote in crowdfunding and claim #11270
• feat: packing note content #11376 👈 (View in Graphite)
• feat: Packable trait + using it for public storage #11136
• refactor: Serialize trait impls for U128 following intrinsic Noir serialization #11142
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[benesjan]

I have a note to enable packing here in a followup PR.

[benesjan]

The changes in this file are just renamings

[AztecBot]

Docs Preview

Hey there! 👋 You can check your preview at https://679a29e4c9e0ae470e066b17--aztec-docs-dev.netlify.app

[github-actions]

Changes to public function bytecode sizes

Generated at commit: e6db48686fd350423570390053cb5d77044faeb3, compared to commit: c4892c640d025b95fdd78cef42dfda2da585efa4

🧾 Summary (100% most significant diffs)

Program	Bytecode size in bytes (+/-)	%
Token::public_dispatch	-293 ✅	-0.94%
Token::complete_refund	-307 ✅	-5.17%
Token::_finalize_transfer_to_private_unsafe	-307 ✅	-5.62%
Token::finalize_transfer_to_private	-307 ✅	-5.67%
Token::_finalize_mint_to_private_unsafe	-307 ✅	-6.01%
Token::finalize_mint_to_private	-307 ✅	-6.06%

---

Full diff report 👇

Program	Bytecode size in bytes (+/-)	%
Token::public_dispatch	31,020 (-293)	-0.94%
Token::complete_refund	5,632 (-307)	-5.17%
Token::_finalize_transfer_to_private_unsafe	5,155 (-307)	-5.62%
Token::finalize_transfer_to_private	5,108 (-307)	-5.67%
Token::_finalize_mint_to_private_unsafe	4,803 (-307)	-6.01%
Token::finalize_mint_to_private	4,756 (-307)	-6.06%

[nventuro]

I'm unsure about this. What if I have struct Foo { a: u32, b: u32 }? Even if u32 implemented packable then this would not do the correct thing (i.e. packing the u32 together). So what's the point of having this if I still need to do it manually?

[benesjan]

So what's the point of having this if I still need to do it manually?
Because it works well for the typical use case which is a note containing a U128.

If devs want to do some complex packing I would expect them to do it manually.

But if you want to do a more advanced packing that is measuring size of the types then I would do that in a follow-up PR. But not sure if it's good time to do it as it feels like something we could leave up to devs to experiment first with (will there ever be a note containing multiple u32s)?

[nventuro]

But if we're not doing any kind of packing, why not do

impl Packable<N> for T where T: Serialize<N> {
  fn pack(self) -> {
     self.serialize()

and remove all of the custom code

[benesjan]

Because if some of the struct members implements "real packing" (like e.g. U128) then we achieve a smaller result because packing of that struct gets used.

E.g. packing UintNote which is defined as:

#[partial_note(quote {value})]
#[derive(Serialize)]
pub struct UintNote {
    // The amount of tokens in the note
    value: U128,
    owner: AztecAddress,
    // Randomness of the note to hide its contents
    randomness: Field,
}

resulted in the note content occupying 3 fiedls instead of 4 (because the value got actually packed).

Does it make sense now?

[nventuro]

Yes, I see. So you'd use the derived version if all members either a) occupy a field or b) are packable. If this is not true (e.g. you have two u128 members) then you'd roll your own.

[benesjan]

Exactly. And given that a more sophisticated packing can be introduced just with an update of Aztec.nr and that we currently don't have any note type which would leverage it I think it makes sense to not deal with that in the foreseeable future.

[sklppy88]

Fantastic work 🙏