Skip to content

Bridging content into the Portal history network#

Seeding from content bridges#

Seeding history content with the portal_bridge#

The portal_bridge requires era1 files as source for the block content from before the merge. It requires access to a full node with EL JSON-RPC API for seeding the latest (head of the chain) block content. Any block content between the merge and the latest is currently not implemented, but will be implemented in the future by usage of era files as source.

Step 1: Run a Portal client#

Run a Portal client with the Portal JSON-RPC API enabled, e.g. Fluffy:

./build/fluffy --rpc --storage-capacity:0

Note: The --storage-capacity:0 option is not required, but it is added here for the use case where the node's only focus is on gossiping content from the portal_bridge.

Step 2: Run an EL client#

The portal_bridge needs access to the EL JSON-RPC API, either through a local Ethereum client or via a web3 provider.

Step 3: Run the Portal bridge in history mode#

Build & run the portal_bridge: 

make portal_bridge

WEB3_URL="http://127.0.0.1:8548" # Replace with your provider.
./build/portal_bridge history --web3-url:${WEB3_URL}

Default the portal_bridge will run in --latest mode, which means that only the latest block content will be gossiped into the network.

The portal_bridge also has a --backfill mode which will gossip pre-merge blocks from era1 files into the network. Default the bridge will audit first whether the content is available on the network and if not it will gossip it into the network.

E.g. run latest + backfill with audit mode: 

WEB3_URL="http://127.0.0.1:8548" # Replace with your provider.
./build/portal_bridge history --latest:true --backfill:true --audit:true --era1-dir:/somedir/era1/ --web3-url:${WEB3_URL}

Seeding post-merge history content with the beacon_lc_bridge#

The beacon_lc_bridge is more of a standalone bridge that does not require access to a full node with its EL JSON-RPC API. However it is also more limited in the functions it provides. It will start with the consensus light client sync and follow beacon block gossip. Once it is synced, the execution payload of new beacon blocks will be extracted and injected in the Portal network as execution headers and blocks.

Note: The execution headers will come without a proof.

The injection into the Portal network is done via the portal_historyGossip JSON-RPC endpoint of the running Fluffy node.

Note: Backfilling of block bodies and headers is not yet supported.

Run a Fluffy node with the JSON-RPC API enabled.

./build/fluffy --rpc

Build & run the beacon_lc_bridge: 

make beacon_lc_bridge

TRUSTED_BLOCK_ROOT=0x1234567890123456789012345678901234567890123456789012345678901234 # Replace with trusted block root.
./build/beacon_lc_bridge --trusted-block-root=${TRUSTED_BLOCK_ROOT}

Seeding directly from the fluffy client#

This method currently only supports seeding block content from before the merge. It uses era1 files as source for the content.

  1. Run Fluffy and enable portal_debug JSON-RPC API: 

    ./build/fluffy --rpc --rpc-api:portal,portal_debug

  2. Trigger the seeding of the content with the portal_debug_historyGossipHeaders and portal_debug_historyGossipBlockContent JSON-RPC methods. The first method will gossip in the block headers, the second method will gossip the block bodies and receipts. It is important to first trigger the gossip of the headers because these are required for the validation of the bodies and the receipts.

curl -s -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"1",
"method":"portal_debug_historyGossipHeaders","params":["/somedir/era1/"]}' http://localhost:8545 | jq

curl -s -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"1","method":"portal_debug_historyGossipBlockContent","params":["/somedir/era1/"]}' http://localhost:8545 | jq