# CDAP Development Update 2

This is my second development update for the [Ethereum Core Developer Apprenticeship](https://github.com/ethereum-cdap/cohort-one) and marks the end of my third week in the program. Future updates will follow every two weeks.

These past two weeks I've spent my time defining what project I will be working on for the rest of the program. Since I am well aligned with the goals of the [Portal Network](https://github.com/ethereum/portal-network-specs), I've decided to focus my efforts on a Portal Network client.

Initially I planned on working with the [go-ethereum](http://github.com/ethereum/go-ethereum) team, but it seems they have yet to start planning development. Since that idea was out of the picture, I started down the path of something new.

I started planning how I could build something of value with tools that I am familiar with, and thus the idea of a [libp2p](https://github.com/libp2p) Portal Network was born.

## Low Ethereum Orbit

I started by finding out which parts of the Portal Network could easily be mapped into a libp2p network. I discovered that by utilizing [IPLD](https://ipld.io) codecs, Ethereum state can be stored and accessed over a peer-to-peer network powered by [IPFS](https://ipfs.io) clients.

There are several trade-offs to this approach but there are some interesting ideas worth exploring. The [Ethereum IPLD codec](https://github.com/vulcanize/go-codec-dageth) stores state in the same format as an Ethereum node.

This opens up the posibility of not only using this for a Portal Network client, but also as a replacement for the existing Ethereum state database.

I've started collecting my ideas and some code in the [LEO repository](https://github.com/valist-io/leo).

## What's next?

Over the next two weeks my plan is to:

- Finalize the Ethereum to IPLD state storage code.
- Figure out an approach for getting state into the network.
- Start planning the state gossip network components.