Relevant Repository: https://github.com/ethereum/portal-network-specs

Proposal Website: https://www.ethportal.net/

Ethereum Cat Herders’ (video): https://www.youtube.com/watch?v=YzL2GmxA6Wk

Overview

There is a proposed upgrade to the post-merge Ethereum Protocol Client called “Portal Network”.  The goal of the Portal Network is to provide lightweight protocol access by resource constrained devices.

Today, the ethereum network consists of full, or “archival” nodes – which hold a complete copy of the ethereum state.  The complete size of the ethereum blockchain is rapidly approaching 10TBs, which is prohibitively large for most machines to store in co-location with their compute.

Maintaining consensus around the entire chainstate history, in a way that is decentralized across statistically uncorrelated or diverse endpoints (meaning different hardware types, operating systems, geographic locations, owners, and critically – ethereum client implementations) – is what gives the ethereum blockchain its extreme resilience.

According to Ethernodes data, there are 5,399 ethereum nodes that are online and functioning today.

Putting aside whether this achieves minimal sufficient decentralization (see nakamoto coefficient) – this is a surprisingly small number when compared against the total number internet-connected devices (which may be the total addressable market for validators software).

The aim of the Portal Network is to onboard more client validators onto the ethereum network, through a new kind of light-client which enables distributed RPC request routing while also lowering the hardware barrier for participation.

This is sometimes referred to as “fractal sharding” and is made possible through the magic of erasure-coding and p2p networking.

Portal Clients vs Traditional Light Clients

Importantly, these “portal” clients would still hold some amount of the ethereum state.

The Portal Network is composed of multiple peer-to-peer networks which together provide the data and functionality necessary to expose the standard JSON-RPC API. These networks are specially designed to ensure that clients participating in these networks can do so with minimal expenditure of networking bandwidth, CPU, RAM, and HDD resources.

The term 'Portal Client' describes the specific software library which participates in these networks. Portal Clients can be accessed through the browser and mobile wallets, and typically expose the standard JSON-RPC API.

Securing the Chainstate – Replication vs Erasure Coding

Portal client architecture secures chainstate better than full replication.  Rather than storing a complete copy of the blockchain, nodes can all store smaller shards of it, depending on device capacity.

Erasure coding is a method of data protection in which data is broken into fragments, expanded and encoded with redundant data pieces and stored across a set of different locations.

As a technology, erasure coding has been around for decades (Reed–Solomon codes were developed in 1960).  The technology has been used in satellite communication to transmit messages in the face of interference, and is what enables CDs to play music even when they have been scratched.

Just like any two points on a straight line can constitute its slope, any three points can constitute a plane, digital objects can be mathematically encoded in the same way, so that a client only needs K/N pieces to reconstruct the file.

Decentralized storage networks like Storj employ erasure codes heavily to enable parallel and decentralized streaming, in the face of nodes going offline.  A useful visual representation of erasure code can be found below:

In this Client Portal model, all wallets and devices become encoded state validators.  This means more independent devices holding and securing blockchain data.

Ethereum Portal:  Sub-Protocols for Request Relays

As stated in the markdown for the protocol’s repository, The Portal Network is divided into the following sub-protocols.

• Execution State Network
• Execution History Network
• Transaction Gossip Network
• Execution Header Gossip Network
• Execution Canonical Indices Network

Each of these sub-protocols is designed to deliver a specific unit of functionality. Most portal clients will participate in all of these sub-protocols in order to deliver the full JSON-RPC API. Each sub-protocol however is designed to be independent of the others, allowing clients the option of only participating in a subset of them if they wish.

All of the sub-protocols in the Portal Network establish their own overlay DHT that is managed independent of the base Discovery V5 DHT.

Conclusion

As a proposed validator method for a post-merge ethereum architecture, portal clients can enable a more resilient and secure blockchain network by enabling more validating participants to the network, and spreading state more broadly across uncorrelated devices.