Portal Network Introduction: Expansion of Ethereum Network from Network Design Level

Original title: The Portal Network

Original article by :  namrapatel

Translation :  MinMin & amp;   O sword & have spent  

Introduction to the

The Portal Network is designed to allow devices with limited resources to access the protocol in a lightweight way. As the name implies, the so-called "portal" means that these networks only provide a view of the protocol, but are not essential for the operation of the core protocol of the platform.

The Portal Network will consist of one or more decentralized point-to-point networks that collectively provide the data and functionality required by the standard JSON-RPC API. These networks are designed to ensure that clients can participate with minimal bandwidth, CPU, RAM, and hard disk resources.

Portal Client refers to software that participates in these networks and exposes a standard JSON-RPC API port.

motivation

The Portal Network aims to achieve two interrelated goals.

Stateless client

The core Ethereum protocol is moving in the direction of a "stateless" block validation model. Under this model, the client can fully verify the execution of blocks using Witness data. In this way, the client will no longer need to save any Ethereum "state" data. This client is of great value to the Ethereum core protocol, helping Eth1 and Eth2 merge better.

To learn more about why stateless for Eth1 / merge for Eth2 is so important, recommended reading: https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html

It's easy to forget that this "stateless" client can do little else without additional infrastructure. Specifically, it does not service most JSON-RPC APIs. The Portal Network fills this gap by allowing stateless clients to expose external APIs that support the Web 3.0 ecosystem.

Extensible lightweight client

"Light client" usually refers to the client of the existing DEVP2P LES network. The network is designed with a client/server architecture. The total capacity of an LES network is determined by the number of "servers" in the network. To facilitate network expansion, "server" capacity must be increased. That is to say, at any time, once the network load exceeds the total capacity of the network, it will lead to the whole network service degradation. As a result, the LES network is not reliable when operating near full capacity.

Portal Network aims to solve this problem from a Network design perspective, allowing each new client to join the Network to increase the capacity of the Network. As more and more nodes join the network, the network becomes more robust and powerful.

Read: https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/  (The Chinese version)

Video tutorial: https://www.youtube.com/watch?v=MZxqRs_tLNs

Network function

Status: Account and contract storage items

The state network helps retrieve Ethereum state data on demand.

Nodes can choose which state they want to store and share, and the network should provide a way to identify which nodes to query for the required state data. In this way, nodes, no matter how small, can contribute to maintaining the robustness of the network.

The operation of the network depends on receiving new states and updating them according to the new block. The fully-functional "bridge" node, which acts as the status provider, is responsible for transporting this data from the main network to the portal network. As a result, the network can remain healthy even with a small number of Bridges.

The speed at which data is queried and read from the network should be sufficient for human wallet operations, such as estimating gas charges for transactions or reading status from contracts.

Chain history: block header, block, and receipt

To validate the data obtained from the Portal Network, the Portal client needs to be able to retrieve the block headers and verify that they exist on the main chain. Clients can use validated block headers to further validate blocks, tertiary blocks, transactions, receipts, and status nodes.

A normal client downloads each block header to build a backbone. This makes no sense for a "stateless" client. The "double-batched Merkle Log Accumulator" mechanism allows portal clients to avoid downloading every block header that belongs to the main chain.

When a portal client requests a block header, two accumulator certificates are returned along with it. Accumulator proof can be used to verify that a block header is included on a valid chain, as long as the client (via Gossip Network) keeps the latest view of the chain header. The client can then use the block header to validate additional data retrieved from the Portal Network.

The design of Portal Network simulates the following Ethereum protocol messages, supported through   block_hash  Retrieve the following data.

Main Chain Lead: Retrieves transactions by hash and blocks by number

To serve & NBSP; eth_getTransactionByHash  And & have spent eth_getBlockByNumber  JSON-RPC API endpoints. Clients typically create local indexes when synchronizing the entire chain. Portal Network needs to emulate these indexes. This is done by generating unique mappings for transactions and blocks, and then publishing them on the Portal Network.

Since it is possible for valid transactions to exist outside of a particular block, we need a mechanism to prove that a transaction is included within a particular block. Similarly, valid blocks may be tertiary blocks, but there is no proof that they are contained in the main chain. Therefore, a mechanism is also needed to verify whether a block is at a block height on the main chain (rather than a tertiary block) and whether a transaction is included in a valid block.

The following mapping is stored on the Portal Network and functions as a legitimate index with the accumulator.

Main chain block index: block_number - >; (block_hash)  . Obtain and block_hash & have spent And using the accumulator to verify the   in the block; block_hash  Whether it corresponds to a block_number.

Main chain transaction index: tx_hash - >; (block_hash tx_index). Gets the block header associated with block_hash and validates the block with an accumulator. Then, the blocks related to the size of the area are obtained and verified. tx_hash  Whether to pass with the transaction tree & NBSP; tx_index  Found a trade match.

Transaction sending: cooperative transaction gossip spread

The purpose of the transaction gossip network is to ensure that miners have access to all new transactions so that they can be packaged into blocks.

Stateless clients should be able to declare, based on the resources they have, the percentage of transactions they want to process among all unbundled valid transactions (i.e. trading pools), and can only obtain these transactions from other nodes.

Stateless transaction verification involves verifying the account balance and the nonce, so the network needs to attach proof of the account with each transaction it propagates.

Network specification

1. UTP&NBSP based on DiscoveryV5;

2. State network

    1) new state data of extensible gossip spread: https://ethresear.ch/t/scalable-gossip-for-state-network/8958/4  (The Chinese version)

3. Chain history network

    1) No specification for the time being

    2) previous studies: https://notes.ethereum.org/oUJE4ZX2Q6eMOgEMiQPkpQ?view 

    3) proof of concept before written in Python: https://github.com/ethereum/ddht/tree/341e84e9163338556cd48dd2fcfda9eedec3eb45 

    4) This proof-of-concept does not represent the final goal. It combines mechanisms that have not yet been implemented in the real world, in particular the "advertising" system (which has proven to be a huge bottleneck) and the SSZ Merkelroot system (which was originally designed to solve the big data transmission problem, but we are now going to use UTP instead).

4. Trade gossip propagation

    1) No specification for the time being

    2) previous studies: https://ethresear.ch/t/scalable-transaction-gossip/8660

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia