# YetiNet Part 1

By [runninyeti.eth](https://paragraph.com/@runninyeti) · 2022-10-16

---

For a while now I’ve been meaning to run my own EVM-compatible blockchain network. In part for the learnings, but mostly for the hell of it 🤷‍♀️ So this is me kicking off YetiNet with a little brainstorming.

Why “YetiNet”? It’s the first thing that came to mind and works well with my ENS name, runninyeti.eth. Also, the web3 arm of [Bridgetown Collective](https://www.bridgetowncollective.com/) is unofficially called “Yeti Labs”.

![](https://storage.googleapis.com/papyrus_images/50c0b75ecf1de31c9ebbe902737b69d4a3a4358859c637240c0966ada06ca122.gif)

My wishlist for YetiNet
-----------------------

*   Full EVM compatibility
    
*   _Easily_ runnable on low-power hardware like a [Raspberry Pi Zero](https://www.raspberrypi.com/products/raspberry-pi-zero/)
    
*   Container based nodes
    
*   Publicly accessible - anyone can technically participate
    
*   Eventual ability to become a [Layer 2 atop Ethereum](https://ethereum.org/en/developers/docs/scaling/#layer-2-scaling)
    
*   Open source code
    
*   Hosted block explorer
    
*   Oracle ecosystem - home automation, [Strava](https://www.strava.com/) integration, etc
    
*   Dedicated versions of common ETH protocols - [Uniswap](https://uniswap.org/), [ENS](https://app.ens.domains/), etc
    

In short, I’m aiming for YetiNet to give me an unnecessarily robust medium for toying around in the Ethereum ecosystem by simply recreating the whole thing in a controlled environment. And since I’ll control the network, “gas fees” will just be technical details and not something I need to financially consider. Then with that ecosystem in place, I hope to explore some blockchain use cases such as P2P chat, MEV manipulation, logistic networks (e.g. for vertical farming), etc, etc … lots of ideas, no where to shove them.

### Why not use an existing Layer 2?

There’s 2 reasons:

1.  Popular Layer 2’s like Optimism and Arbitrum don’t have open access for others to run their own nodes. I want _full_ control
    
2.  Presumably I’ll be the only one using YetiNet, so the storage and compute requirements can be kept to an absolute minimum
    

Architectural Thoughts
----------------------

With an emphasis on keeping an unnecessarily complex endeavor as simple as possible, I’m planning to create a concept of a “YetiNode”. These nodes will simply be a collection of _at least_ 5 Docker containers all orchestrated through [Docker Compose](https://docs.docker.com/compose/). Namely the following:

1.  [geth](https://geth.ethereum.org/) - they have a readily available Docker image and even [instructions](https://geth.ethereum.org/docs/interface/private-network) on running a private network
    
2.  [IPFS](https://ipfs.io/) - for sharing data peer-to-peer within YetiNet
    
3.  [MongoDB](https://www.mongodb.com/) - as a database solution
    
4.  “code” - a generic container for all the custom, nonsensical Typescript code I end up writing. This will likely be split into an [indexer](https://mirror.xyz/indexingco.eth/c2GOCeUxmteugbJ61tbJgKSTZJdyckdurOo8Bl-vMCc) and a set of APIs very early on
    
5.  explorer - some form of a homegrown network explorer. There are open source block explorers, but I want to create my own with specific logic to YetiNet
    

![](https://storage.googleapis.com/papyrus_images/abb9da1b1e9ca348ce717d22b50405afe8ac7c6c9794370039441925a090f738.png)

In this way, each “node” of the network will be a whole lot more than just a block producer - which opens the doors to many fun projects later 😎

I’ll do another post once I have the above architecture initially built and YetiNet “deployed”. If anyone wants to participate or has any thoughts, please reach out!

---

*Originally published on [runninyeti.eth](https://paragraph.com/@runninyeti/yetinet-part-1)*