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