# Development Update 6

## Goal

Previous Goals:

* Continue to work on the chain history spec
* Implement a proxy bridge node that subscribes to Infura for new blocks and distributes them to the network
* Enable custom distance functions for the k-buckets table
* Join other CDAP members to complete secondary storage layer and protocol messages to transmit/distribute data

Current Goals:

* Implement table management for the overlay networks (history and state).
* Clarify the goals of the test network and take up items as we establish milestones.
* Assist in development and review of network storage and content transmission messages.
* Assist in development of header and transaction gossip specs.

## Progress

The chain history spec is essentially complete. The only recent update is that, following the state network, we will not have a `Store` message to transmit content. The rationale for removing `Store` is that block headers are the only content items that are small enough to be fit within the message. Also, removing this message means that the state and history subnetworks use the same set of messages, which allows us to define a more general "overlay" protocol.

The bridge node implementation took longer than expected, mostly due to several false starts along with my own progression in Rust proficiency. Additionally, I had to spend some time thinking about the Bridge API. There is a [preliminary bridge spec](https://github.com/ethereum/portal-network-specs/blob/master/portal-bridge-nodes.md), but it is custom and requires a plugin to expose that API from an existing Ethereum client. This spec is not final, and a plugin that supports the existing spec is not complete. After some discussion, we moved toward a solution that could collect the necessary data from the standard JSON-RPC API along with some non-standard and client-specific JSON-RPC APIs. More specifically, the Go-Ethereum (Geth) client supports a JSON-RPC API to retrieve proofs for accounts and account storage slots, which are necessary for the state network.

The [initial PR](https://github.com/ethereum/trin/pull/104) was one such false start. It did not take advantage of the Rust Ethereum ecosystem, and instead I ended up reinventing some lower-level components that we don't need to optimize at this stage of development. It also baked in an assumption that we would communicate with Infura, when that does not need to be the case.

The [subsequent PR](https://github.com/ethereum/trin/pull/119) leverages an existing Rust Ethereum library that abstracts most, if not all, of the lower-level network details. It is also a much more general and extensible design that conforms to common Rust idioms. This implementation also supports both WebSocket and IPC client connections.

The state network distance function was [implemented by another contributor](https://github.com/ethereum/trin/pull/100). Given that the bridge took more effort than expected, someone else took this up. I think there are still changes necessary on the Discovery v5 crate, but it's something I need to look at with fresh eyes.

The other CDAP members continue to make adjustments to the [secondary storage layer](https://github.com/ethereum/trin/pull/69) and [content transmission messages](https://github.com/ethereum/trin/pull/84). Other than these efforts, there has been a lot of refactoring going on in the codebase. A fair amount of time has gone into review as there are a lot of moving pieces.

A new issue that I have taken up is the [management of the overlay routing table](https://github.com/ethereum/trin/issues/109). Currently, there is no process that actively manages existing connections in the routing table or adds new connections to the routing table in response to network messages. This is the task at hand, and it will introduce a non-trivial amount of complexity into the codebase. The overlay network will transition into a "living" structure that we spawn and is responsible for autonomously managing its routing table according to its configuration and in response to network messages. I have begun the implementation, taking inspiration from the [Discovery v5 crate](https://github.com/sigp/discv5/blob/master/src/service.rs).

I suspect that this issue will occupy some time, both in implementation and review. We want to be careful here to introduce the necessary complexity in a way that is easy to build around and on top of.

The other big item is the [test network](https://github.com/ethereum/trin/issues/118). This is still taking shape. I hope to help shape this effort and take up items as we determine a set of milestones.

Other than that, there are the ongoing efforts around network storage and content transmission that will require additional feedback and development. These items are prerequisites for the test network, so they take priority. There are also preliminary specs for [header](https://github.com/ethereum/portal-network-specs/pull/79) and [transaction](https://github.com/ethereum/portal-network-specs/pull/81) gossip. I plan to spend some time thinking about these subnetworks as well.