Concepts
Protocols
Portal Sub-protocols
Beacon

Beacon Network

Note that this network is not production-ready

The Beacon Network serves data from the Beacon Chain (Ethereum's consensus protocol) designed to support light clients. Lightweight nodes and Portal clients will be able to use the data retrieved from this network to determine which blocks have made it on-chain, according to validators. This only applies to post-merge blocks.

The Beacon Network is a Kademlia DHT that forms an overlay network on top of the Discovery v5 (opens in a new tab) network.

Data

The Beacon Network serves the following data types:

  • LightClientBootstrap
  • LightClientUpdate
  • LightClientFinalityUpdate
  • LightClientOptimisticUpdate
  • HistoricalSummaries

Light client data types are defined in the light client sync protocol (opens in a new tab).

Data Retrieval

The network supports the following mechanisms for data retrieval:

  • LightClientBootstrap structure by a post-Altair beacon block root.
  • LightClientUpdatesByRange - requests the LightClientUpdate instances in the sync committee period range [start_period, start_period + count), leading up to the current head sync committee period as selected by fork choice.
  • The latest LightClientFinalityUpdate known by a peer.
  • The latest LightClientOptimisticUpdate known by a peer.
  • The latest HistoricalSummaries known by a peer.

Supporting light clients

A light client could keep track of the chain of beacon block headers by performing Light client state updates following the light client sync protocol (opens in a new tab). The LightClientBootstrap (opens in a new tab) structure allows for setting up a LightClientStore (opens in a new tab) with the initial sync committee and block header from a user-configured trusted block root.

Once the client establishes a recent header, it could sync to other headers by processing objects of type LightClientUpdate (opens in a new tab), LightClientFinalityUpdate (opens in a new tab) and LightClientOptimisticUpdate (opens in a new tab). These data types allow a client to stay up-to-date with the beacon chain.

To verify canonicalness of an execution block header older than ~27 hours, we need the ongoing BeaconState accumulator (state.historical_summaries) which stores Merkle roots of recent history logs.

Specification

Read the full specification for the Beacon network on the Portal Network Github (opens in a new tab)

HistoryState