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

Support more dynamic fields per table #1463

Open
holic opened this issue Sep 13, 2023 · 1 comment
Open

Support more dynamic fields per table #1463

holic opened this issue Sep 13, 2023 · 1 comment

Comments

@holic
Copy link
Member

holic commented Sep 13, 2023

Right now our PackedCounter design only supports 5 dynamic fields per table. We could maybe up this to 6 dynamic fields if we got rid of the total byte length (#1420).

An alternative approach could be RLP inspired, where the first byte in PackedCounter is the length of the PackedCounter itself (in bytes or in 32-byte words).

This would mean for the first 4 dynamic fields, we'll have the ~same gas. And for one extra storage read (for retrieving single field) and n-1 storage reads (for retrieving the whole record, where n is the word length of the PackedCounter), we could support an arbitrary number of dynamic fields.

@alvrs
Copy link
Member

alvrs commented Sep 13, 2023

a couple thoughts:

  • in terms of storage reads this should be pretty similar to separating into different tables (since we still need to read one word per 5 or 6 dynamic fields)
  • for the StoreSpliceRecord event we'd need to emit a dynamic bytes field for the packed counter (probably shouldn't because it would mean we have to read all slots of the packed counter even if we only needed one of the slots to update a single dynamic field) or have some additional context on the event for "which part of the packed counter was updated"
  • with this design a "total length" field might be more important to avoid having to read all the slots and summing lots of individual lengths to get the total length
  • if we store the total length in bytes eg. at the start, we'd need to write two slots when modifying the length of a field whose length is not stored in the first slot. We probably should avoid this because sstore is pretty expensive.
  • alternatively we store a "total length per word of packed counter" in each word to avoid having to write two separate slots, but that doesn't solve the issue of having to read multiple slots and summing to get the total length, so we might as well just get rid of storing the length accumulator
  • agree it would be a better dev experience if devs don't have to think about splitting tables to support more than 5 dynamic fields

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