You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#4200 added automatic storage slot allocation, #4500 introduced note type ids (soon to be autogenerated). These values are not currently available outside of the contract, but there's multiple applications that might require them. This is not unique to Aztec: as an example, Solidity exposes the storage layout to ease smart contract upgrades.
In our case, both of these values are required when manually adding notes to PXE, since these values are neede to call compute_note_hash_and_nullifier. Our guides (and tests) are currently forced to include these magic values, and this is only going to get worse once note type ids are autogenerated and become more obscure.
Since we typically care about note type ids in the context of the underlying note that corresponds to each state variable, a reasonable way to do it might be to expose the different state variable along with their storage slot and note type id. I don't think we'll care very much about which id corresponds to which note type, only the state variables.
The text was updated successfully, but these errors were encountered:
#4200 added automatic storage slot allocation, #4500 introduced note type ids (soon to be autogenerated). These values are not currently available outside of the contract, but there's multiple applications that might require them. This is not unique to Aztec: as an example, Solidity exposes the storage layout to ease smart contract upgrades.
In our case, both of these values are required when manually adding notes to PXE, since these values are neede to call
compute_note_hash_and_nullifier
. Our guides (and tests) are currently forced to include these magic values, and this is only going to get worse once note type ids are autogenerated and become more obscure.Since we typically care about note type ids in the context of the underlying note that corresponds to each state variable, a reasonable way to do it might be to expose the different state variable along with their storage slot and note type id. I don't think we'll care very much about which id corresponds to which note type, only the state variables.
The text was updated successfully, but these errors were encountered: