feat: add ContractAddress type #159
Conversation
tdelabro
requested review from
pefontana,
dan-starkware and
gabrielbosio
as code owners
tdelabro
force-pushed
the
add-contract-address-type
branch
from
c57d3e6 to
bea90b3
Compare
tdelabro
force-pushed
the
add-contract-address-type
branch
from
bea90b3 to
02d6946
Compare
| /// * 0x1 functions as a storage space for block mapping [link](https://docs.starknet.io/architecture-and-concepts/network-architecture/starknet-state/#special_addresses) | ||
| /// - They must be less than 2^251 (0x800000000000000000000000000000000000000000000000000000000000000) | ||
| /// | ||
| /// Making the valid addressabe range be [2, 2^251) |
There was a problem hiding this comment.
| /// Making the valid addressabe range be [2, 2^251) | |
| /// Making the valid addressable range be [2, 2^251) |
| ) | ||
| } | ||
| ContactAddressFromFeltError::TooBig => { | ||
| write!(f, "the highest possible address is 2^251 - 1") |
There was a problem hiding this comment.
I would also add the contract address value in the error message and replace 2^251 - 1 with the value of ADDRESS_UPPER_BOUND so we can more easily compare the failing contract address with the upper bound
| /// which would result in permanent loss. | ||
| impl Felt { | ||
| pub fn is_valid_contract_address(&self) -> bool { | ||
| self >= &Felt::from(2u64) && self < &ADDRESS_UPPER_BOUND |
There was a problem hiding this comment.
| self >= &Felt::from(2u64) && self < &ADDRESS_UPPER_BOUND | |
| self >= &Felt::TWO && self < &ADDRESS_UPPER_BOUND |
|
@gabrielbosio do you have an opinion about the points I highlighted in the issue description? |
It depends if we want to migrate the |
|
@dorimedini-starkware you are maintaining the sequencer repo? |
no reason I can think of, but this suggested implementation differs from ours in several ways, like:
|
Add a
ContractAddresswrapper type that guarantee the felt it contains is a valid starknet contract address.Contain some quality of like function for string conversion
Not a breaking change
Discussion:
@xJonathanLEI suggested we add ClassHash too
I chose to exclude addresses 0x0 and 0x1 from the normal ContractAddress flow. You can still build them with the unchecked one. Should we add constant ContractAddress::ZERO and ContractAddress::ONE to make those special case more explicit?
Do we want to allow them at all? Is there a risk to make some API unusable downstream if those value are entierly excluded?