Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Account byte indexing can be problematic #37

Open
EquilateralDelta opened this issue Jul 29, 2022 · 1 comment
Open

Account byte indexing can be problematic #37

EquilateralDelta opened this issue Jul 29, 2022 · 1 comment
Assignees

Comments

@EquilateralDelta
Copy link
Collaborator

EquilateralDelta commented Jul 29, 2022

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.

@pindaroso
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants