feat: Starknet storage proof verifier

[maciejka]

Starknet storage proof verifier.

Pull Request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this introduce a breaking change?

• Yes
• No

Other information

[0xLucqs]

can't this live here ? https://github.com/keep-starknet-strange/alexandria/blob/main/src/data_structures/src/merkle_tree.cairo

[maciejka]

can't this live here ? https://github.com/keep-starknet-strange/alexandria/blob/main/src/data_structures/src/merkle_tree.cairo

It is not the same thing. merkle_tree.cairo is an implementation of generic Merkle Tree while proof.cairo verifies Starknet storage which use binary Merkle-Patricia Trie.

[0xLucqs]

It's not the same thing indeed but they are both related to merkle trees, don't you think they should live in the same crate ?

[maciejka]

It's not the same thing indeed but they are both related to merkle trees, don't you think they should live in the same crate ?

Are you suggesting to put storage_proof into data_structures crate?

[0xLucqs]

Hmm I’d rather move the merkle tree out of the data structure crate and create a ˋmerkle_treeˋ crate that would hold the merkle tree and merkle proof

[maciejka]

Hmm I’d rather move the merkle tree out of the data structure crate and create a ˋmerkle_treeˋ crate that would hold the merkle tree and merkle proof

Why a separate crate? Because they are more complex data structes than queue, stack, vec?

[0xLucqs]

Because storage proof doesn’t really make sense in data structure and I think that grouping merkle tree and storage proof verification makes sense

[maciejka]

Because storage proof doesn’t really make sense in data structure and I think that grouping merkle tree and storage proof verification makes sense

Reorganized code under merkle_tree crate as you suggested. I am not convinced but it is better to try and fix later instead of spending time to discuss it.