search

foundry-rs / starknet-foundry

Blazing fast toolkit for developing Starknet contracts.
https://foundry-rs.github.io/starknet-foundry/
MIT License
293 stars 143 forks source link

L1 interoperability testing #347

Open MaksymilianDemitraszek opened 1 year ago

MaksymilianDemitraszek commented 1 year ago

L1 messaging and related utilities

Arcticae commented 1 year ago

@MaksymilianDemitraszek can you elaborate on what is the scope of this?

MaksymilianDemitraszek commented 1 year ago

This is a big one, without clearly defined scope. Probably will require extensive research and getting some information from teams developing cross chain solutions like bridges.

Generally my vision here is a possibility to spawn anvil instance alongside the cheatnet instance and allow l1 <-> l2 messaging between them.

I believe @glihm was very excited to work on this one 😄

Arcticae commented 1 year ago

@MaksymilianDemitraszek we should have a design doc for that, right?

glihm commented 1 year ago

Very interesting stuff yes!

For now, this is how I do e2e testing for messaging. Spawning up katana (with messaging feature, currently in PR) and anvil, I use bash scripts to coordinate the state verification on both chains and execute messages on each side.

In the case of Starknet Foundry (snforge), we're in a testing environment, which means each time a test runs, we may expect a fresh state on the eth devnode. So how would be the UX for the user to determine which anvil setup he needs for which test, that's interesting part of the design.

Due to the asynchronous nature of messaging, we may also not be able to wait for a specific message in a test. And I am not sure that running snforge, we can expect some tests being triggered by anvil generated logs in a spontaneous manner.

But I'm not sure yet @MaksymilianDemitraszek at which level the forge code will "verify" what's going on on anvil (in the case L2->L1). How to express such expectations?

For L1->L2, we need anvil to fire a TX to generate a log, and then getting the logs, we can fire the L1 handler transaction. But this is what we're doing with the l1_handler_execute at some point.

So, thinking more about it, is it really in the scope of snforge? Or are we talking about integration of starknet devnet / anvil into a two-nodes devnet integrated into Starknet Foundry?

Arcticae commented 1 year ago

BTW: Moving this to general since it needs design & research

MaksymilianDemitraszek commented 11 months ago

@Arcticae I believe you are researching it rn, is it a duplicate of anything?

Arcticae commented 11 months ago

643 was a duplicate

Arcticae commented 11 months ago

FYI: I have some takeaways on this after chats with starkgate team & ex-MakerDAO developer

Arcticae commented 10 months ago

Putting in triage in favour of #644 for now