What Is Relay?
Relays enables blockchain interoperability by allowing chains to verify events and block headers on another chains. Essentially, this simply means a contract on one chain (Chain A) is able to notice and verify event changes on Chain B. The notice part is handled by nodes known as ‘Relayers’, where they are the actual workhorses responsible for relaying cross-chain messages to keep MAP chain and all relevant contracts updated. The verify part is feasible thanks to cryptographic proof as well as the concept of light client.
One of the distinctive features in MAP chain is that the network is maintained by thousands of relayers and secured by 100+ validators in order to achieve distribution of trust and moving towards increasing decentralization. Due to the vital position of the relayers, all relayers in MAP protocol are incentivised by measuring the work completed.
Relayers will submit the update of interested chains to MAP chain, MAP chain then verify and update corresponding light client. Besides, relayers will also listen to cross-chain tx in target chain and submit tx info via some tx types to notify the chain. The chain will then verify the cross-chain tx message according to the state info of corresponding light client. Besides, relayers can also participate in the on-chain random number generation process by submitting a random number of their own. All random numbers submitted will be merged to forge true on-chain randomness to support various DeFi applications.
What Is Light Client?
Unlike full node, a light client node does not need to query and store tons of information about the blockchain. Light clients normally store only a small set of information that is just enough to verify the status change of the target chain so that they can be updated in a self-verifiable way. Besides, to verify cross-chain messages submitted by relayers, light clients will also store a handful blockchain headers of the target chain.
With the existence of light client, the cross-chain message verification can be done in a pure mathematical way instead of having a federation to verify event on another chain. That is with the trusted Merkel root that usually exists in the blockchain header stored in the light client, the Merkle proof backing up the cross-chain message can be tested. The security of the light client’s state is designed in such a way that it will only be updated by incentive relayers where there is sufficient cryptographic proof following the proof and consensus mechanism of the targeted blockchain, e.g. signatures form enough validators if the target blockchain is PoS and BFT based consensus. Therefore, it formed a strong foundation of cross-chain verification where light clients will be updated by 1000+ relayers through cryptographic proof.
The diagram below illustrates the flow on how a MAP light client and relayers works in cross-chain asset transfer of 100 USDC on Ethereum from Alice to Bob on MAP chain:
