Background

Why is Portal Network important?

After the Merge, Ethereum is a Proof of Stake protocol. To execute and record transactions and balances, it uses two clients to verify and keep the network secure.

• The consensus clients use a peer-to-peer network called LibP2P
• The execution clients use a peer-to-peer network called DevP2P

Execution clients in Ethereum are software components that process new blocks as they are added to the blockchain. This process involves executing the Ethereum Virtual Machine (EVM), which transitions the state from the previous block's state root to the newly computed state root that results after executing all the transactions from that block. DevP2P is primarily designed to facilitate data transfer between Nodes on this network must be full nodes.

Existing Ethereum execution clients (e.g. Geth, Besu, Nethermind) are built on the DevP2P protocol and requires clients to interact with Ethereum within its design structure, mainly:

• Execution clients must fully sync the state and history.
• Clients must build their indices for looking up transactions by hash or blocks by number.

Syncing nodes burdens the existing full nodes within the network, downloading hundreds of gigabytes of history and state data to become a full node.

The main functionality that DevP2P exposes to allow syncing is:

• Requesting batches of block headers by block number or hash
• Requesting batches of block bodies by block number or hash
• Requesting state data via the SNAP protocol to build a full recent snapshot of the state.

Once a node in this network has fully synced, they become a full node. As a full node, the primary network functionality from DevP2P is:

• Gossip of latest block headers and bodies
• Gossip of transactions that are part of the global mempool.

The design of DevP2P impacts users running a full node in many ways:

• High CPU usage
• High hardrive requirements
• Bandwidth usage
• Sync times can be long
• Ability to sync full history
• Ability to sync full state
• Ability to remain online to keep history and state synced.
• Full chain history (headers, bodies, receipts)
• Full latest state
• Block execution is required to keep the state up-to-date
• Required by the transaction pool for validation of pending transactions.

These requirements dictate hardware and network minimums which are currently (and growing)

• 1 TB of bandwidth per month
• 8GB+ of RAM
• 1 TB of fast disk (SSD)
• Be online 24/7

Running Ethereum nodes is prohibitively difficult, resulting in a high barrier to entry that affects both geographic and economic participation.

Trying to build solutions to tackle these issues are not feasible in the DevP2P framework.

They require fundamental changes to the network design in DevP2P, many of which would likely reduce the overall security guarantees that the network provides, which the client teams have chosen to prioritize.

Devp2P network constraints held back previous attempts at building a light client.

• Light Ethereum Subprotocol (LES) developed a light client which relies upon full nodes serving light node data. Only some full nodes opt to serve light node data, meaning light nodes often fail to find peers. Therefore they do not become part of the Ethereum network.
• Trinity, built by the team behind Portal Network, aimed at being lightweight but didn’t end up being viable due to the constraints of the DevP2P network and Python being slow.

‘When we created Trinity, we aimed to build a lightweight client. After spending almost three years deep in the protocol, exploring lots of different avenues for making the type of client we wanted to exist, we eventually concluded that it couldn’t be done on the existing network. Piper M.

One "solution" that might be posed here is for all Ethereum nodes to be light servers by default.

At present, serving light client data is an opt-in process.

If it were instead shifted to be an opt-out process, there would likely be a significant spike in capacity in this network. However, this capacity would still be limited by the number of full nodes in the network. It seems reasonable to expect the same outcome to eventually occur, with the demand for data exceeding the serving capacity offered by the network.

Currently, Ethereum is served by two main infrastructure pieces.

Centralized RPC

Most applications and wallets use a service like Infura because of its speed and economic value over running a node. These services are preferred because the data requirements become heavier and heavier as the chain grows. While Infura offers an excellent service, however developing alternatives is prudent: Potential issues include:

• Centralised (A risk if it goes down).
• Wallets like Metamask allow RPCs/infura to link all your addresses (privacy issues).
• Infura could start following incorrect chain data (previously happened), which all users end up following.

Full nodes

Full nodes require users to have hardware and internet bandwidth to serve the network requests. Full Nodes run by users increase the decentralization of Ethereum. The hardware and bandwidth costs do restrict how many people As the chain data grows, the demand for resources on the hardware and bandwidth also grows, which excludes many users from contributing. Key Differences between a light node and a full node:

• A full node stores all the blockchain data to the latest 128 blocks, validate blocks and verifies their states.
• A light node (Downloads all block headers, block data, and verifies but does not hold any history) Light clients/nodes seek to address these resource intensive so that more users can join the network, which leads to a considerable increase in decentralization. Now you see that the best option to design a decentralised light client needed a new approach from the current infrastructure that addressed the issues that previous attempts faced. Building an independent protocol was the best solution to removing the constraints of DevP2P.