# Block header relay network

We present the formal protocol of block header relay network in the following protocol:

<figure><img src="/files/2qUWK9QNJtZz9vpskEqZ" alt=""><figcaption></figcaption></figure>

Nodes in the block header relay network run RelayNextHeader with the current state of the updater contract (LCS𝑟−1,blkH𝑟−1) as input. The exact definition of LCS𝑟−1 is specific to light client protocols. The relay node then connects to full nodes in 𝒞1 and gets the block header blkH𝑟 following blkH𝑟−1. The relay node generates a ZKP 𝜋 showing the correctness of blkH𝑟 , by essentially proving that blkH𝑟 is accepted by a light client of 𝒞1 after block blkH𝑟−1. It then sends (𝜋,blkH𝑟 ) to the updater contract on 𝒞 . To avoid the wasted proof time due to collision (note that 2 when multiple relay nodes send at the same time, only one proof can be accepted), relay nodes can coordinate using standard techniques (e.g., to send in a round robin fashion).

To incentivize block header relay nodes, provers may be re-warded with fees after validating their proofs. We leave incentive design for future work. A prerequisite of any incentive scheme is installability, i.e., the guarantee that malicious nodes cannot steal others’ proofs. To this end, provers will embed their identifiers(public keys) in proofs, e.g., as input to the hash function in the Fiat-Shamir heuristic. We note that this design relies on the security of the light client verifier of the sender chain. For example, the light client verifier must reject a valid block header that may eventually become or- orphaned and not part of the sender chain.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.zkbridge.com/zkbridge-trustless-cross-chain-bridges-made-practical/block-header-relay-network.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.