feat: storage slot as point

[benesjan]

Implementing Mike's storage slot as point scheme https://hackmd.io/ZTSdUpDTTnKVFJFr9xcUBw

Notes for reviewer:

1. There are a lot of small issues which will need to be tackled after this PR is merge and I track them with this issue.. I am not tackling them in this PR to keep the scope as small as possible (particularly the naming is messy),
2. this PR does not yet properly handles nesting and the use of different generators for different steps of slot derivation --> this is to make the PR scope smaller + it is not essential for the code to work (it's needed to avoid potential collisions but I think it's ok to handle in the following PR given that we are still prototyping).
3. There is currently an issue with generating a verification key for base rollup. To workaround this issue I have commented out the contents of compute_fee_payer_gas_token_balance_leaf_slot func. This makes the fees tests not pass.

[benesjan]

• feat: storage slot as point #7437 👈
• refactor: optimizing DA cost with new point compression #7473
• refactor: moving pub_key_to_bytes to aztec-nr #7506
• feat: trimming 1 byte from compressed repr of Point #7505
• master

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

Join @benesjan and the rest of your teammates on Graphite

[github-actions]

Changes to circuit sizes

Generated at commit: f2ef5b2525bde15572faf3f4e532f2f0b20fd71b, compared to commit: 2633aa91a97684f481a861aee0be8756c956135a

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_tail	-42 ✅	-0.00%	-250 ✅	-0.01%
rollup_base	-49 ✅	-0.01%	-404 ✅	-0.01%
public_kernel_teardown	-48 ✅	-0.02%	-256 ✅	-0.02%
public_kernel_setup	-48 ✅	-0.03%	-256 ✅	-0.02%
parity_root	-144 ✅	-2.94%	-944 ✅	-0.02%
rollup_root	-112 ✅	-2.67%	-720 ✅	-0.02%
rollup_merge	-80 ✅	-2.88%	-496 ✅	-0.02%
private_kernel_empty	-48 ✅	-2.58%	-273 ✅	-0.03%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_tail	965,054 (-42)	-0.00%	4,644,848 (-250)	-0.01%
rollup_base	341,345 (-49)	-0.01%	3,835,877 (-404)	-0.01%
public_kernel_teardown	241,730 (-48)	-0.02%	1,618,002 (-256)	-0.02%
public_kernel_setup	183,195 (-48)	-0.03%	1,554,056 (-256)	-0.02%
parity_root	4,749 (-144)	-2.94%	4,171,794 (-944)	-0.02%
rollup_root	4,081 (-112)	-2.67%	3,144,641 (-720)	-0.02%
rollup_merge	2,702 (-80)	-2.88%	2,092,160 (-496)	-0.02%
private_kernel_empty	1,811 (-48)	-2.58%	1,041,821 (-273)	-0.03%

[AztecBot]

Docs Preview

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

[nventuro]

Thanks for taking on this behemoth of a task! I left some initial feedback and questions, but eventually got stuck with the review since there's too many things I don't understand. In particular I'm puzzled about the changes to the rust macros and how we now handle different levels of nesting in Map, since there seem to be no changes to that file.

Given that this is such a large changeset, with multiple new concepts, small renames and the beginnings of future refactors, I strongly suggest investing some time in the PR description so that readers have context re. what is being done here, how, what blockers you encountered and how you're temporarily working around them, etc. As is, it can be quite hard to understand all of the changes here armed with just the hackmd document.

[benesjan]

Given that this is such a large changeset, with multiple new concepts, small renames and the beginnings of future refactors, I strongly suggest investing some time in the PR description

@nventuro sorry, should have done that before asking you for a review. Added the description

[benesjan]

This PR turned out to be unnecessary so I am closing it in favor of https://github.com/AztecProtocol/aztec-packages/pull/7618/files

[nventuro]

We realized that in order to support partial notes for e.g. private refunds (#7226) in such a way that'd avoid the issues listed in #7297, we don't really need for the storage slot to be a Point. What we really want is to change the definition of note_hash so that it is not the hash of the slot plus hash of the content, but rather multi scalar multiplication of the slot and content (e.g. value, randomness, npk). This lets us create partial notes with an embededd slot, while retaining a Field slot.

The only thing a slot Point allows for is for partial slots, e.g. multi-nested maps in which some of the keys are private but some are public. We're not doing this because:

1. we cant think of an actual usecase for this
2. it introduces extra complexity in very large parts of the codebase (note storage, decoding logs, storage setup, etc)
3. it is possible that usecases that needed this could still be supported with slightly different schemes (somehow avoid nested maps)
4. doing msm instead of poseidon for the storage slot results in a larger gate count, which we'd have to pay for even if not using partial notes
5. if we really found a use case that needs this, it would be possible to add the feature later in aztec-nr 2.0, and have pxe support both the current and new scheme. Contracts could e.g. publicly announce they're using the new scheme, and PXE would interpret their logs differently.
6. we are not sure how we'd present an api for this given that it mixes map and notes, so it'd be quite hard to use and easy to misuse