SNIP-19: get_class_hash_at syscall

[Eikix]

Hi all!

Creating a PR for my first SNIP, advised by @LucasLvy from Starkware. I think the community stands to benefit from a get_class_hash_at syscall to be able to query onchain the class hash of a contract.

This is akin to EVM EXTCODEHASH and EXTCODESIZE opcodes, that enable to check the deployed code of a contract against a known code hash.

[Eikix]

As maintainer, I hereby name this SNIP, SNIP-19

[Eikix]

Could we discuss including this SNIP in a later upgrade @ArielElp

[dor-starkware]

Hi @Eikix,

Thanks for the submission! I’ve reviewed the SNIP, and here are some changes needed:

1. Preamble:

Please add the following missing fields: description, discussions-to (please link to your community forum post), type, and category. You can refer to the SNIP-1 guidelines for details on these fields.

2. Rationale Section:

The Rationale section is mandatory. This section should explain the reasoning behind the design choices and describe any alternatives considered. Since people often confuse this with the Motivation section, remember that Motivation explains the problem you're solving, while Rationale explains the choices behind the solution. While I understand there might not be extensive design considerations for this SNIP, the Rationale section is still required. If there aren’t many considerations, you can keep it brief or even state that no major design alternatives were necessary.

3. Implementation Section:

Please rename the "Implementation" section to "Reference Implementation" as per the SNIP format.

4. Security Considerations:

Every SNIP needs a Security Considerations section, even if there are no security implications (in which case, you can simply state that).

Thanks!

[Eikix]

Hi @Eikix,

Thanks for the submission! I’ve reviewed the SNIP, and here are some changes needed:

1. Preamble:

Please add the following missing fields: description, discussions-to (please link to your community forum post), type, and category. You can refer to the SNIP-1 guidelines for details on these fields.

2. Rationale Section:

The Rationale section is mandatory. This section should explain the reasoning behind the design choices and describe any alternatives considered. Since people often confuse this with the Motivation section, remember that Motivation explains the problem you're solving, while Rationale explains the choices behind the solution. While I understand there might not be extensive design considerations for this SNIP, the Rationale section is still required. If there aren’t many considerations, you can keep it brief or even state that no major design alternatives were necessary.

3. Implementation Section:

Please rename the "Implementation" section to "Reference Implementation" as per the SNIP format.

4. Security Considerations:

Every SNIP needs a Security Considerations section, even if there are no security implications (in which case, you can simply state that).

Thanks!

Thanks for your help!