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.
Last updated