The Portal Network: Optimizing Ethereum data storage

The Portal network is a content-specific distributed storage network designed explicitly for storing Ethereum data. Unlike generic distributed storage networks like Codex, IPFS, or Swarm, the Portal network can be optimized for the specific types of data it handles, improving data access and verification processes. This specificity allows nodes in the network to have a vested interest in the content they store, enabling non-monetary incentives similar to the tit-for-tat system in BitTorrent.

Why do we need the Portal Network?

The Ethereum community has long recognized the challenges of maintaining a decentralized and permissionless network while scaling and optimizing performance. As Vitalik Buterin highlights in his blog post “The near and mid-term future of improving the Ethereum network’s permissionlessness and decentralization,” recent advancements like EIP-4444, Verkle trees, and decentralized storage are crucial for the network’s evolution.

Running a full Ethereum node today requires significant storage and technical expertise. For example, a typical node can take up over 2 TB of disk space, and maintaining an archive node may take over 10 TB of disk space, making it impractical for many users. This storage requirement for full nodes continues to grow as the blockchain progresses.

EIP-4444 proposes to reduce this storage burden on Ethereum nodes by no longer requiring them to store and serve historical chain data older than one year. However, this poses another challenge. One major concern with proposal EIP-4444, which removes the requirement for nodes to store old history, is ensuring availability of the history when required. The Portal network addresses this by distributing storage across a peer-to-peer network, ensuring robust data redundancy and accessibility. This approach mitigates the risk of centralization that comes from relying on a few large actors to store historical data.

Portal Network and its Sub-Networks

The Portal network comprises several sub-networks, each optimized for specific types of Ethereum data:

• History Network: Provides access to chain data such as block headers, block bodies, and receipts.
• Beacon Network: Supplies Beacon Light Client data, including bootstraps, updates, and finality updates, facilitating Consensus Light client sync.
• State Network: Offers access to current and historical state data, functioning as a distributed archival node.

Future sub-networks in development include the verkle-state network, canonical indices network, and transaction gossip network, among others. The modular design of the Portal network makes it relatively easy to define new content types and keys, verify data, and bridge new content into the network.

Nimbus Portal Network Client - (Project: Fluffy)

Fluffy is a client implementation for the Portal network written in Nim. It functions as an Ethereum light client, implementing the Execution JSON-RPC API using the Portal network as its data backend. Fluffy can operate as a standalone client with access to both the Portal network and the Execution JSON-RPC API, or it can be integrated into another client as a library.

First Use Case: EIP-4444

The first major use case for the Portal network is to support implementation of EIP-4444 and address concerns about managing chain history. By integrating a "Portal client", nodes can inject this archive data to the Portal Network nodes, maintaining access to historical data without the burden of storing it locally.
For EIP-4444, an initial dual-layer approach may be taken: using torrents for bulk data download and the Portal network for individual access. This ensures both efficient data distribution and easy access to specific historical data.

Diagram 1 illustrates how the Consensus Client (CL), Execution Client (EL) and the Portal Network Client might work together to achieve this goal of keeping resource requirements low for Ethereum Nodes.

Key Highlights:

• When the Execution Client receives a request to fetch a certain block, and its unavailable in its local storage, the Execution Client can request that block from the Portal Node, which will fetch it from the Portal Network.
• The Execution Client (EL) may work with an existing separate Portal Client through the Portal JSON-RPC API or the Execution Client may have an integrated Portal Node (i.e. one binary) to improve the performance and interactions between the two.
• The Execution Client (EL) may also inject the historical data (for example, on pruning) to be maintained in the Portal Network in order to lower or remove the current need of Portal data bridges.
• In the future, there may not be a need for the Execution Client to receive and process all current EL network queries, if most nodes in the network are able to query the Portal Network directly for historical blocks.

Where can I learn more about this Nimbus Portal Network Client?

The Nimbus Portal Network client was one of the first implementations of the client for this network.

Dive into the Github Repo, start with the Docs or join the Nimbus Discord to discuss more about our Portal Network client efforts.