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
By account byte indexing I mean fetching accounts of a program using memcmp filters.
In the helpers.ts I see such logic. The first improvement we can make in the future - is to additionally filter by the first 8 bytes account selector to make filtering more reliable.
Another potential problem is that the same data can be at different byte indexes with our data. That is because of the way Rust enums and options are serialized by Borsh(used by Anchor, specification: https://borsh.io/). None variant is always serialized as 1 byte, but Some variant is 1 byte + variant size. For example, Some variant of Option<u64> would be serialized as 9 bytes. So the next field offset would be 1 or 9 bytes depending on the option variant.
The simplest way to solve it is to move all Option values to the end of the struct so most of the fields would have determined offsets.
Another more complex solution is to write Option wrapper that would serialize None variants to full size.
The text was updated successfully, but these errors were encountered:
Good catch, as discussed. We should keep these at the end of the data structure for now. Should add in serialization so the structure is always the same size.
By account byte indexing I mean fetching accounts of a program using memcmp filters.
In the helpers.ts I see such logic. The first improvement we can make in the future - is to additionally filter by the first 8 bytes account selector to make filtering more reliable.
Another potential problem is that the same data can be at different byte indexes with our data. That is because of the way Rust enums and options are serialized by Borsh(used by Anchor, specification: https://borsh.io/). None variant is always serialized as 1 byte, but Some variant is 1 byte + variant size. For example, Some variant of
Option<u64>
would be serialized as 9 bytes. So the next field offset would be 1 or 9 bytes depending on the option variant.The simplest way to solve it is to move all Option values to the end of the struct so most of the fields would have determined offsets.
Another more complex solution is to write Option wrapper that would serialize None variants to full size.
The text was updated successfully, but these errors were encountered: