Share Sierra contracts between nodes

[Juul-Mc-Goa]

Madara needs to have the Sierra intermediate representation to handle the ContractClass::Sierra variant (from starknet_core::types). For now, the conversion from blockifier's contract class to starknet's contract class returns dummy values (see #1316).

The preferred solution, as described here would be to store each sierra class locally, and gossip them to other nodes. This discussion is for finding a good way to implement this.

Be aware that I am very much a newbie, so my suggestions may be completely ill-advised.

Solution 1 (last resort)

described at #775: implement this in the runtime. This means the runtime would have more data than the strict necessary for the chain state, so something better is needed.

Solution 2 (gossip)

Store it in the client, implement gossiping with a rust lib. I guess there should be a way to do peer-discovery, and a way to prevent DoS attacks by malicious peers.

Solution 3 (random)

Having one shared global state that is resistant to malicious actors sounds like a job for a blockchain. However, I'm clueless as to how to do this in practice. (This solution is included for entertainment purposes only).

[tdelabro]

I think solution 2 is the one to go with, but we can probably leverage the substrate p2p mechanism rather than using the lib you suggested.

[antiyro]

For Deoxys we are currently already receiving classes on the client side, verifying them against the sequencer, passing them to the digest logs and directly store them within the runtime in on_initialize.

So we are kind of using Solution 3 relaying on the sequencer.

[tdelabro]

I can't understand for sure what you are describing here.

"classes" Are you talking about sierra or casm classes?
"already receiving" how? Inside the block? Through some additional RPC call you do? From l1?
"directly store them within the runtime" so you are doing solution 1: storing sierra in the runtime?
"kind of using Solution 3" how?

[antiyro]

I think that on your case option 2 by storing it in the digest after some checks and comunicate it to the network via p2p is good and should be safe. But I'm not 100% sure of what it would imply since we do not respect the Starknet p2p specs yet.

[tdelabro]

Do you know if sierra classes are part of the p2p specs?

[antiyro]

they dont seem to be part of the specs but retrieving them trough get class should do the job

[tdelabro]

https://github.com/starknet-io/starknet-p2p-specs/blob/f3e4d4c3c8467e454896e7ad1fad45e6d327c21c/p2p/proto/state.proto#L49

Apparently they are

[tdelabro]

https://github.com/paritytech/substrate/tree/master/client/network-gossip

I think this is the crate we will end up using. I think it's really doable. I can create an issue and try to find a developer with substrate experience

[tdelabro]

Isn't topic supposed to be something like "SierraClasses" instead? And the messages are tuples of (SierraClassHash, SierraClass) ?

[tdelabro]

@Juul-Mc-Goa do you feel like you could work on that one? It's a quite complex one requiring some substrate knowledge.

[Juul-Mc-Goa]

hmm I was thinking "SierraClasses" would rather go into the protocol name. It seems you can have several protocols on a single network. The idea for having each class hash as a topic name is that you can request only one sierra class by calling messages_for on the class hash. Otherwise (with topic = "SierraClasses") I believe you can only request every known sierra classes via messages_for(topic). I don't know the specifics of the network and the gossiping process so maybe requesting every sierra classes is the better solution.

[Juul-Mc-Goa]

@tdelabro I don't have a lot of substrate knowledge, so if there's anyone who knows better, they should rather work on it. If nobody has this knowledge then I can give it a try

[tdelabro]

I will try to find someone who knows the framework well