Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modular protostar - architecture #1623

Merged
merged 3 commits into from
Mar 21, 2023
Merged

Modular protostar - architecture #1623

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5f340ef
Added first draft
MaksymilianDemitraszek Mar 17, 2023
cb2c191
updates
MaksymilianDemitraszek Mar 20, 2023
bd3518f
Update design_docs/protostar-architecture.md
MaksymilianDemitraszek Mar 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions design_docs/protostar-architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,23 +4,23 @@ This document proposes the idea how to modularize Protostar. Goals of the modula
- Allow to introduce better ownerships of the codebase parts
- Make workflow asynchronous between smaller sub-teams operating on contracts between modules
- Allow incremental rewrite to Rust
- Remove compilation responsibility from Protostar codebase
- Long term, remove compilation responsibility from Protostar codebase



## General overview
First decomposition of Protostar will introduce 3 modules
MaksymilianDemitraszek marked this conversation as resolved.
Show resolved Hide resolved

- Protostar Gateway
- Protostar Shell
- Protostar Starknet
- Protostar Testing backend

Each of the modules would be a separate poetry package (open question?), to simplify scenarios of updating different dependencies. Example of such scenario, Protostar-starknet relies on starknet.py and devnet but testing backend does not. As a final goal everything would be under one cargo workspace.
MaksymilianDemitraszek marked this conversation as resolved.
Show resolved Hide resolved
![Diagram](img/diagram.png)

## Modules
### Protostar Gateway
This module will be a communication layer of Protostar with outer world, namely Scarb. Its responsibility will be to provide Scarb with a correct cairo compiler (or dependencies in the future) and to fetch configuration from Scarb config. This module will be routing commands as requests to other services. Output formatting will be responsibility of the Gateway
### Protostar Shell
This module will be a communication layer of Protostar with the outer world, namely Scarb. Its responsibility will be to provide Scarb with a correct cairo compiler (or dependencies in the future) and to fetch configuration from Scarb config. This module will be routing commands as requests to other services. Important note, Protostar shell should by dynamically built from provided (during build) commands list. This will allow as to easily split protostar into two separate binaries which may simplify the integrations process.
MaksymilianDemitraszek marked this conversation as resolved.
Show resolved Hide resolved


### Testing backend
Expand All @@ -33,12 +33,12 @@ Output: Stream of test results + summary as a final element
Anything outside of this transaction will be encapsulated in the backend.


### Starknet CLI
### Protostar Starknet
This is a facade over starknet.py SDK, we can migrate it to Rust very soon and use Starknet.rs instead if its capabilities are sufficient.


## Communication
Communication layer between modules will be JSON, simillar to the current Protostar `--json` to make it language-independent. We can do communication either through FFI or calling as sub-processes, this is an open question.
Each of the modules will be a separate binary (protostar shell will be two binaries each built with a different backend set of commands and target backend). Protostar shell will call the backend passing the arguments resolved from config.

## Benefits
- Modularity of backends based on contracts allows us to provide interchangeable backends for different purposes. For example we can support both sierra and casm backends simultaneously. Or we can support different Protostar-starknets, in python and rust depending on which sdk will update faster to new changes or at least maintain the python solution while rust version is being developed.
Expand Down