You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 21, 2024. It is now read-only.
Types that are publics are part of the protocol.
Using usize in such types means that the protocol accepts different max values depending on the machine on which it is executed.
On a 32 bit machine, the max_n_emitted_events maximum value will be u32::MAX, on a 64 bit machine the max_n_emitted_events maximum value will be u64::MAX. Meaning that a block produced on a 64 bits machine, could in theory be invalid for all the u32 machines. They will overflow and end up with a different value.
The values exposed by the protocol should always be defined unequivocally, otherwise, we expose a decentralized network of machines to the possibility of a hard fork and loss of consensus.
same issue on the cairo-vm: lambdaclass/cairo-vm#1498
It should be enforced across the starknet rust ecosystem.
Ideally, in a perfect world, some SNIP should decide for each value, if we want it to be a u8, u16, u32, u64, u128, u256, felt252, or something else. But letting the hardware decide for us is never ok.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Types that are publics are part of the protocol.
Using
usize
in such types means that the protocol accepts different max values depending on the machine on which it is executed.Example:
On a 32 bit machine, the
max_n_emitted_events
maximum value will beu32::MAX
, on a 64 bit machine themax_n_emitted_events
maximum value will beu64::MAX
. Meaning that a block produced on a 64 bits machine, could in theory be invalid for all the u32 machines. They will overflow and end up with a different value.The values exposed by the protocol should always be defined unequivocally, otherwise, we expose a decentralized network of machines to the possibility of a hard fork and loss of consensus.
same issue on the cairo-vm: lambdaclass/cairo-vm#1498
It should be enforced across the starknet rust ecosystem.
Ideally, in a perfect world, some SNIP should decide for each value, if we want it to be a u8, u16, u32, u64, u128, u256, felt252, or something else. But letting the hardware decide for us is never ok.
The text was updated successfully, but these errors were encountered: