-
Notifications
You must be signed in to change notification settings - Fork 327
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
Library_packed #336
Comments
@ponderingdemocritus have been thinking along similar lines (using |
Here is a rough implementation. Thanks Lancelot...
|
regarding |
good point - it would be better to use that check. I think this pattern could be extended out to 721 and 20 if people request it. The 721 could be crucial if users are bulk transferring as the cost will be halved. |
Looks like a good idea, curious to see if in practice it really halves the cost tho. Is it worth the overhead ? Probably, yes. |
well, it is two memory stores instead of 1. So for example in Realms we have 22 resources and an AMM. So in the current implementation, this is 44 memory slots to write on an AMM trade. Halving this is huge. I am trying to work out exact edge cases to arise from this and would love to know more. In .sol there is an 1155 packed balance contract that stores balances in bitmaps. But you have a max limit on how many tokens you can store if you choose max compression. But this is the developer's choice to make at deploy time according to their use case. |
Hi, the proposal seems interesting but I'm not sure I understand the interest from a storage point of view. If a uint256 is composed of two felts, as long as one felt is not exceeded, the other one remains initialized to zero. I'm not sure about the implementation of fees right now, but in principle we shouldn't have to pay storage fees as long as we don't change the felt value, should we? |
@Th0rgal the way I understand it is:
I might be wrong here, but if I'm right, then you can see that indeed this proposal would optimise the storage for any number that is bigger than 2^128 :) |
Sorry I may not have correctly understood. If I'm not mistaken, we only have to pay for the state changes, not the storage itself. In your example the amount of bits to update doesn't change, does it? |
yes, very valid point. I think you might be correct, the only question is if storage structs costs more to update, or if they count towards two storage updates on every write |
I don't think I follow here:
So to me it looks like 3. is better. Am I missing something? :) |
The question is now - if the 0 element within the uint256 never actually gets updated from 0, then it shouldn't actually cost anything extra than this implementation as the actual state change only happens on 1 memory cell anyway. |
Yes but from what I understand, for any number bigger or equal to |
Yes, correct. So then this whole optimization becomes moot if the use case never gets above 2^129. So it's not worth the low-level change at that point, because the use case was planning on using a number less than 2^129 anyway... |
Oh ok I thought the goal for this optim was to store up to a felt, not necessarily something smaller than |
Using felts instead of Uint256 would also save on transaction execution resources. I was curious about the savings. I forked the repo and created a In a simple Not much in absolute terms, but somewhat significant in relative terms. Given that these contracts are going to be the canonical implementation of tokens used on Starknet, that we're still early and that scaled out to hundreds of millions of TX in the future, the savings are serious. I'd urge OZ to consider a felt-based implementation for ERC tokens as originally suggested. |
🧐 Motivation
The current design pattern for all ERC tokens is to use the uint256 as this interfaces with EVM. This is understandable. However, not all use cases of these tokens need a pure uint256 standard. The most important part is that we keep the interface of the uint256 but in the library.cairo we can make a low-level conversion into a felt if it is appropriate for the use case. It is then the responsibility of the developer to choose what they wish to use.
For the upcoming ERC1155 standard this is particularly helpful as it will effectively half the storage space for the tokens.
📝 Details
Proposes design pattern:
library_packed.cairo
This file would simply have a low-level conversion from uint to felt and vice versa where needed. This would then just be chosen by the developer when they deploy the contract.
Thoughts?
The text was updated successfully, but these errors were encountered: