# 2022Q3 OKR 4.4: Make current protocol architecture visible with folders and libraries and propose a new architecture with more guarantees

## 1. Make current protocol architecture visible (cosmetic side) (5pw)

### 1.1. Make lib_protocol_compiler allow folders
- deliverable: MRs
- 2pw, Mehdi and 2 reviewers (amongst Hugo, Raphaël P., Romain)
- Risk:
- people need to update their node so this feature require a node upgrade, ideally coming with an environment change

### 1.2. Build a dependency graph of the protocol code
- deliverable: a graph, possibly a devtool (MR)
- 1pw, Mehdi and 2 reviewers (amongst Hugo, Raphaël P., Romain)
- Main risk:
- finer granularity is needed, requiring to build a new tool (rather than reusing existing tools) taking more time

### 1.3. Split the protocol code into folders matching the current dependencies
- deliverable: MRs, announce on #proto-proposal
- 2pw, Mehdi and reviewers
- Depends on 1.1 and 1.2
- Main challenge:
- conflicts with everybody's work

## 2. Propose a new architecture with more guarantees (security side) (7pw)

### 2.1. Understand and document the current architecture
- deliverable: doc MRs
- depends on 1.2, 1.3
- 2pw, Mehdi and early protocol architects, reviewers (Nic?)

### 2.2. Understand developers' requirements
- deliverable: interview notes, summary hackmd
- should be done after 2.1 (not hard requirement)
- 2pw, Mehdi, discussion with protocol developers (early and new ones), architects, verification people

### 2.3. Propose guarantees a new architecture need to ensure
- deliverable: hackmd, protocall discussion
- depends on 2.2
- 1pw, Mehdi, reviewers

### 2.4. Propose a new architecture ensuring those guarantees
- deliverable: hackmd, documentation, protocall discussion, #proto-proposal post
- depends on 2.3
- 2pw, Mehdi, reviewers

## Stretch goals (not expected for Q3)

- Come up with a migration plan
- Start implementing/migrating
- Design/implement tools to ensure guarantees
- Reduce size of protocol code
- Use ppxes
- Reduce length of protocol files
- Make a Michelson library
- May be needed for MORU

## Risks

### Time
- engineers and other actors unavailable
- because busy on other projects/duties (reviewing other projects/helping on other projects/onboarding/mentoring/CSE/internship management/academic partnerships/...)
- unexpected time off
- discussions taking more time because of lack of consensus
- work hardly parallelizable

### Conflicts
- MR conflicts because refactoring touches code being modified by other people, as well as people using it (e.g. project _All Python tests are rewritten in OCaml_)
- added constraints conflicting with other projects

### Inherence and measure
- Part 2 is exploratory
- Goal not measurable, no clear destination
- Solution will not be perfect or only for a limited time
- Disentangling the current spaghetti situation may be harder than expected
- Found solution may be hard to reach, especially with OCaml

## Links with other projects
- Feature flags
- Protocol environment
- SCORU (Michelson PVM)
- Tests