Trin Development Update #1
tl;dr – The Trin client is alive and talking with other clients. Next steps involve transmitting data.
The portal network is a new cross-team effort to re-imagine the ethereum light client, and develop a practical and functional light client experience. You can dive deeper into the portal network specification here.
Trin is a Rust implementation of a portal network client, still in the early stages of development. Currently, it is a fully functional jsonrpc light client. The caveat being that it just serves as a proxy to Infura for all jsonrpc requests. Of course, relying on Infura hardly realizes the purpose of the portal network, but our intention is to start with a piece of software that is immediately useful for the end user. As the network is developed, we will slowly remove reliance on Infura for jsonrpc endpoints, based upon the kind of data made available by the network, until we've completely removed all reliance on a 3rd party provider.
Trin supports the discv5 protocol, and uses the same discovery network as the Ethereum protocol for peer discovery. The Trin client has successfully completed handshakes with other discv5 clients, including Status's portal client and ddht (a portal client prototype written in python).
- Scripts for launching and connecting a
Trinandddhtclient. - A stun client server has been written to help with NAT traversal and simplify the process of bootstrapping, so that Trin clients are immediately addressable by peers that have their enr.
Now that we have communication established between clients, next we're focusing on building an overlay network to actually transmit data between portal nodes. Initially, we're focusing on serving state data over the portal network. This means that the Trin client will reliably, and securely fetch state db nodes from the portal network, which can be locally verified against state roots. This enables users to perform actions like retrieving account balances and estimating gas for transactions using the portal network.
The state network requires "bridge" nodes that will help pipe state data into the portal network. Development is underway on a Nethermind plugin that serves a custom jsonrpc api to provide this data to any portal node that wants to act as a bridge node. An initial spec for the bridge jsonrpc api can be found here, though the spec is not yet considered finalized.
The portal network spec is still in flux and is subject to change. There are still important design decisions to be finalized (eg. are state, chain history, and tx gossip data served over the same subnetwork, or three separate subnetworks?) If you would like to help out, you can join the conversation on the #portal-network channel on Eth R&D Discord, or join our weekly calls, Tuesdays @ 3PM UTC. Development is also underway on ethportal.net - which will serve as a collaborative FAQ blog, where community members can submit and answer their own questions about the network.