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

TODO: Storage Gas optimization #10

Open
GalloDaSballo opened this issue Jun 29, 2022 · 2 comments
Open

TODO: Storage Gas optimization #10

GalloDaSballo opened this issue Jun 29, 2022 · 2 comments

Comments

@GalloDaSballo
Copy link
Owner

Is there even a way to partially claim tokens?

If not then we can save gas in the pointsWithdrawn through a different data structure that allows better packing, at least for bulk claims

@GalloDaSballo
Copy link
Owner Author

Notes about Packed Optimizations

Struct based packing of epoch | token | amount for rewards and claims.

Reliant on a separate dictionary for Token Identifier. With assumption that amount has got to be uint128 or similar.

Uint sizes for reference:
https://twitter.com/BlockFiZac/status/1542934055892705282

Dictionary is more expensive for one-off (weekly) claims

But should make reward reads significantly cheaper, and should especially make the flag for reward claimed massively cheaper

@GalloDaSballo
Copy link
Owner Author

Smaller Amounts

If we use token.decimals() as the basis, and use that to magnify amounts, we could pack the amounts in a way smaller variable (trillion tokens is high for basically all tokens in existence)

Timestamp can fit into uint32
uint32 has max value 4.2e9, which corresponds to max timestamp of year 2106

Epochs can also be fit into really small uint, if 52000 epochs is 1k years already

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

1 participant