---
# System prepended metadata

title: Portal network and Beacon chain light clients

---

# Portal network and Beacon chain light clients

There are different ways to standardize the portal network as a networking layer for light clients. This is a short summary of how we may leverage the concensus layer data in Portal network following the Merge.

### Portal history network

Based on my few days of research on light clients, I think for the chain history network we can leverage two pieces of beacon chain data:

- header accumulator for verification of historical headers (after the Merge). This accumulator is included in the [BeaconState](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/sync-protocol.md#containers) data object.
- light client data to follow the tip of the chain ( Altair sync). This requires a portal node to have access to `LigthClientBootstrap`, `LightClientUpdate`, `LightClientFinalityUpdate` and `LightClientOptimisticUpdate` data objects. Those structures are defined in light client [concensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/sync-protocol.md#containers).

### Portal network as networking layer for light clients

I guess the question is how we can incorporate the data above into the current portal network architecture. One possible way is to encapsulate the light client data in a portal gossip subnetwork and include the header accumulator in the portal history network. 

This way, we allow a portal node to run only the light client subnetwork and provide a networking layer for Altair light clients, an alternative to [REST and libp2p](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md).

### Portal header network sync

A portal node in history subnetwork tracks the latest block header by following the light client Altair [sync process](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/light-client.md#light-client-sync-process) and [specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/sync-protocol.md), requesting the data from the light client gossip subnetwork.

### Full node bridge

To push light client data into portal network, a simple initial solution may be a middleware bridge service which will request via REST `LigthClientBootstrap`, `LightClientUpdate`, `LightClientFinalityUpdate` and `LightClientOptimisticUpdate` from a [full Altair node](https://) and push the data into protal network light client subnetwork.
