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 is unofficially called “Yeti Labs”.

My wishlist for YetiNet

• Full EVM compatibility

• Easily runnable on low-power hardware like a Raspberry Pi Zero

• Container based nodes

• Publicly accessible - anyone can technically participate

• Eventual ability to become a Layer 2 atop Ethereum

• Open source code

• Hosted block explorer

• Oracle ecosystem - home automation, Strava integration, etc

• Dedicated versions of common ETH protocols - Uniswap, ENS, 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. Namely the following:

1. geth - they have a readily available Docker image and even instructions on running a private network

2. IPFS - for sharing data peer-to-peer within YetiNet

3. MongoDB - 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 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

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!