As for pros with Uint256, I don’t see any besides compatibility.
And the cons of using felt well… breaking the compatibility.
Solving it at the language level wouldn’t solve the fact that a felt cannot contain 256 bits of data and we would then always need to use 2 felts: 2*252=504 bits for which 246 would be useless.
If someone (with some insights about Cairo 1.0) could pop in to clarify this situation it would be very helpful and help close a part of the issue.
Solving it at the application would be very cumbersome as every application (and there will be a ton of them (I hope )) would have to deal with it.
And delegating it to a bridge could also create some problems indeed…
So my idea is to create a new “kind of app/token” that would just be a wrapper of token?
It would wrap an ERC20 standard EVM to ERC20 standard StarkNet.
We would have then the same as is already existing on other chains with ETH and wETH. Where some application only allow to deal with some wrapped tokens.
I hope someone can bring up more arguments in favor of Uint256 to broaden my view on the problem. But so far I don’t see any value (besides compatibility) in using Uint256.
Yes it would. The runtime can smartly decide whether to use one or two felts to represent a given uint256. So, unless there’s a value it cannot represent, it will mostly use one felt. But the interface remains.
It seems to me that a good part of the issue described above is not a numerical one (2^251 vs 2^256), it’s an “coding comfort one” (3 simple lines of codes vs 5 complex ones).
This problem can be solved by making uint256 much easier to use when coding in Cairo. Cairo 1.0 should be a big step forward in that regard. More details coming soon(ish)
I personally actually don’t care too much about the inconvenience of using the Uint256 structs in the smart contracts. It’s more the complexity of the interface for web-devs and the increase in computational costs.
Imo a native Uint256 type would be the way to go…I remember that being part of the cairo roadmap.
It fixes the developer experience issues mentioned by milancermak and in most situations one should be able to split the uint256 into felts for optimized calculations.
If there is no native Uint256 type in sight then I would be hard pressed to agree with milancermak.
It seems like Cairo 1.0 will significantly improve the developer experience of operating on uint256, which is great!
I think a remaining question is how much computational overhead does it impose? Handling uint256 increases complexity quite substantially with cairo today and presumably will still do so at the circuit level with cairo 1.0, even if the language abstracts some of it away. This is pretty hard for me to understand theoretically. Milan has provided some empirical benchmarks which shows it is quite substantial.
Would be really great if someone with a deeper understanding of the CairoVM could chime in on these aspects. Can we dismiss this concern as something that can be optimized at the compiler or does it have meaningful implications on the complexity of circuits?
As Cairo 1.0 will come with a new VM I feel like we don’t really have a choice other then wait for StarkWare to release the specs.
Before that we can just speculate.
Since we now have Cairo 1.0 visibility, should we consider it again?
From my point of view, u256 will be less risky and more convenient to be used in Cairo 1.0 for smart-contracts developers, however I don’t think it solves the following points:
web developer will still need to manage it as an array of 2 felts?
u256 storage will still be more expensive than native felt?
Also I’m not sure having 2 standards will be helpful for the ecosystem.
From the perspective of first principles, the more important question is whether Starknet still uses the ERC20 standard, the essence of ERC20 is designed based on EOA account, and starknet defaults to AA.
)) would have to deal with it.