# EPF Dev Update #4

**tl;dr:**

- Presented my project proposal.
- Wrote about [Trin's architecture](https://hackmd.io/@danielrachi/r1mn3fx3n).

## Project proposal presentation

I started this week by finishing up my slides and getting ready to present my project proposal. Then, I presented it during the office hours call.

You can see my project proposal [here](https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/trin-canon-tx-network.md), my slides [here](https://github.com/eth-protocol-fellows/cohort-four/blob/master/notes/danielrachi/daniel-project-proposal-slides.pdf), and the recording of my presentation [here](https://drive.google.com/file/d/11w169ZK3DDnjgsgZyXDR7uwLPaOGCVpZ/edit) (I start at minute 2:05).

## Trin's architecture

I spent the rest of the week learning about how trin, especially the History Network, works.

My first attempt was to analyze the [trin-history](https://github.com/ethereum/trin/tree/master/trin-history) crate. I quickly realized that it was better to understand the whole system and then see how that crate fits. So, I looked into how trin starts up, including the functions it calls and the "objects" it creates.

I spent a pretty good amount of time there and wrote [this draft document](https://hackmd.io/@danielrachi/r1mn3fx3n). It definitely helped me understand how Trin works, but maybe that wasn't the most productive approach.

I felt that the whole process was hard and slow. There was a lot of info to unpack and many places to start. And when I unraveled something, a new chunk of code I didn't understand came up.

Maybe it's just my learning style, or my lack of experience documenting the architecture of a program, but I think it would be way better for me to understand the project while I write code for it. And then, when I get to "load" the program in my head, I could try finishing the architecture document.