Understanding ACCOUNT_ID const

[bal7hazar]

Hello, I hope this is the right place to discuss about account stuff.

I understand quite well why we need an ID for accounts to help contracts differentiate between the Contracts and the Accounts, especially with StarkNet specities. With the new version of Cairo (0.10.x) and the according modification in OZ cairo contracts, the ACCOUNT_ID const has also been updated.

My interogation is about why this ID is changing with cairo versions?
The likely reason I see could be to help/force contracts to interact with accounts with a similar version of OZ contracts (aka compiled with the same version of OZ contracts dependency). In that case, it is quite unconfortable to solve "differentiation" and "compatibility" with a single ID since we could want to keep differentiation feature and leave compatibility aside

Note: The documentation explains well the first understanding "differentiation" point, but I didn't see any information about "compatibility" concern.

[ericnordelo]

Hi @bal7hazar, answering your question, the ID is changing with Cairo (actually Starknet) versions because updates to the base protocol require updates to the account interface. With Cairo 0.10 _validate_, and _validate_declare_ entry points were added to this interface for protocol level requirements, and this interface is yet likely to change with future protocol upgrades.

Accounts need to be upgraded to continue being compatible with the chain (old accounts won't work eventually), and this ID must be updated from the new interface after the upgrade to comply with ERC-165. Then this ID solves both differentiation and compatibility.

[mstrong-tech]

@bal7hazar @ericnordelo Hey guys! if account interface ID is changed, what's the latest value?
To detect the contract is account, should I call supportInterface with all IDs (old, new)? or just ok for using the latest one?

[martriay]

hm good question. it is an evolving standard but it should settle at some point and then you should only use the latest. and although as Eric said some accounts might not work as the network evolves, old accounts could also be valid. i lean towards probing with all previous IDs and consider it an account if any of them work.

some middle ground would be to keep track of the IDs that work/stop working with each network upgrade

[juniset]

I kind of agree and I think for now it's safer to support multiple IDs. Also in some cases the ID was updated because methods where added so both ID (old and new) are valid in that case.

[mstrong-tech]

Hey guys, thanks for your reply. so the latest is 0x01ffc9a7. right?

[martriay]

no, that's the ID of erc165 compliant interfaces (supportsInterface()). the latest is 0xa66bd575

[glihm]

Hello guys, to compute the interfaces ID like in the ERC-165 spec, can you confirm that the algorithm you are using is:

1. get the selector of each function in the interface. In Starknet is a felt252 generated by only the method name -> convert to u256 (as XOR is not available on felt).
2. XORing all the selectors.
3. Taking the first 4 bytes.

Is that correct?

And it's only on methods (and not also events like the ERC721 proposes) as only methods are supported in interface.

Am I correct?

EDIT
I think I just read somewhere in the doc that's the EVM select of interface that is used. Can you confirm that? So it means, we stick to the identifiers determined by EVM?

So one must convert types from interfaces into solidity type to have the interface ID? It could be great if we can compute an interface ID from pure Starknet point of view.

Thanks a lot for the clarification.

(Just seen the SNIP and the post on the forum)

[ericnordelo]

We've using evm like selectors, but we will update our interfaces ids to match the SRC-5 standard soon (starknet version of introspection).

You can check the current version of the standard here (is not finalized yet, but pretty stable):

https://github.com/ericnordelo/SNIPs/blob/feat/standard-interface-detection/SNIPS/snip-5.md