Block header relay network

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

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.