## General Information:

### Current Status:

- tztraffic is more or less working,
- we recently switched from custom internal encodings to using tezos_messages that is extracted from tezedge deprecated code
- some RPC related encodings not used in P2P messages are still defined in tztraffic
- tztraffic-experiment contains the docker-compose and configuration to launch a local tztraffic experiment (see below how to improve it)

The main goal of the project is for us to be able to run a network of yes-nodes using a patched protocol in which operations are copied and injected from mainnet.
The proposed experiment is to use O-protocol patched with a 10s-block-time.

I'm not sure how Jeremie will be able to help but don't hesitate to ask questions to him or more generally on the production unit channel if needed (in particular for devops related questions).

The project partly overlaps/relates to the `block-time reduction` project from the Shell Unit. It is lead by Andrea (from TT).
It is important to keep our goal in mind and not be too polluted by their own progresses, however if we can help each other, let's be friendly. In particular, for tztraffic to be used in their experiments we must take their feedback into account.
From my last meeting with them, they mostly ask for a tool that can extract operations from existing blocks and for another tool that can inject operations from a previous extraction. This two actions are currently done in parallel tasks in tztraffic.
[!22](https://gitlab.com/nomadic-labs/tztraffic/-/merge_requests/22) contains an attempt at reading missing blocks between (starting block of tztraffic and actual head of bootstrapped vanilla node) and inject its operation in as few large blocks as possible.

For the coming weeks, our main goals are:
- to improve our code quality
- to progress on the infra needed for deployment
- maybe to improve our Rust skills :smile_cat:
They are not to:
- provide Andrea his tool (this will be done quickly in August/september if the code base is cleaned-up)

Naturally, Boubacar is here to help if needed but remember to focus on our project and not theirs. If any question arise, go to him, in case of emergency, don't hesitate to text me on Signal (my phone number should be on Slack).

## Proposed roadmap for summer (not too ambitious, many people in vacation):

- Infra:
- automatic generation of splitted yes-wallet
- deploy on more machines
- parametrized block time
- Tztraffic:
- extract encodings from tezedge and build a rust crate from it
- finish implementing operation packing
- Observation:
- basic health-checks of the yes-network from tztraffic -> generation of an experiment report

## Detailed potential deliverables (in no particular order):

- Number of :star:s corresponds to estimated difficulty/time to achieve.
- :timer_clock: means that once this is achieved, it should be mentionned to Andrea to make sure `block time reduction` project can benefit from it

### List
- :star: :timer_clock: Create a tezos/tztraffic repository or add missing parts to the NL one:
- :star: Add a tztraffic-experiment subdir inside
- Cleanup and add tezos_messages too

- :star: :star: Cleanup tztraffic-experiment:
- Cleanup unused/badly configured services:
- Caddy uses lambsonacid config :-1:
- Postgres, Teztale archivers and servers are not configured correclty

- :star: :star: Migrate tztraffic-experiment to kubernetes
- Ideally split in several pods:
- Monitoring:
- teztale server
- grafana
- Bootstrap:
- yes-bootstrap node
- teztale archiver
- Child:
- yes-child node
- teztale archiver
- yes-client
- yes wallet
- yes-baker
- Try instantiating multiple child pods (maybe splitting wallet manually)

- :star: :star: Improve tztraffic CI:
- tztraffic CI is quite slow (it does a lot of things but this is probably overkill)

- :star: :star: Yes-Wallet:
- Split the yes wallet automatically
- Handle any network
- Handle all public_keys

- :star: :star: :star: Rust-training:
- :star: :star: :star: :timer_clock: In tztraffic: split data extraction from injection:
- add a parameter `--extract-to "file_path"` to only extract operations from block range and save them in a binary file
- maybe provide two behaviors:
- save each block separately
- or try to order operations in a single list keeping the order based on source*destination dependency
- add a parameter `--inject_from "file_path"` to read such file and inject operations
- :star: :star: :star: Check tztraffic dependencies `Cargo.toml/Cargo.lock` and `cargo tree` are your friends. Try to reduce the dependency tree as much as possible by switching to more lightweight libraries (or doing things internally), tztraffic does not do much, it should compile fast ;)
- :star: :star: :star: In tezos_messages:
- move crypto to a more recent/not deprecated library
- more generally cleanup `cargo audit` warnings ;)

- Deployment/experiment:
- :star: Allow manual generation of yes-docker-images from a tezos/tezos branch
- :star: :star: Prepare a protocol O with 10s block-time
- :star: :star: :star: Prepare an experiment with an UAU migration from N to O-10s
- Start from mainnet snapshot
- Wait for new cycle
- UAU to O
- Profit