RFC: Decouple Protostar from StarkNet

Protostar is heavily coupled with StarkNet which:

• increases maintenance and modification cost
• delays releases relatively to cairo-lang
• makes the boundary between Protostar and StarkNet vague

This proposal suggest:

• introducing an abstract module (protostar.blockchain) between Protostar and StarkNet
  • StarkNet internals are unstable, hence shouldn’t be used as a dependency

    The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is. https://wiki.c2.com/?StableDependenciesPrinciple

    • Fundamental theorem of software engineering
  • Abstraction represents Protostar’s expectations from StarkNet, which could allow us to move some parts of the adapter to the cairo-lang package reducing the maintenance cost
  • better modularity improves work separation / code ownership
  • improved testability removes the need for creating integration tests when it’s not necessary resulting in faster tests
  • recreating Protostar and StarkNet in Rust is going to be easier if both teams know interface ahead
• keeping Protostar state in the TestExecutionState rather than in the adapter module
  • currently, part of the state is kept in the TestExecuteState (e.g. TestContext) and other part in CheatableState for unknown reasons

[mkaput]

We have to discuss this F2F soon.

[kasperski95]

I’d say Commander is an abstraction over Cheaters.

BlockInfoCheater leaks StarkNet implementation details in its name.