▪️Relay contract

At the core of TeleportDAO lies the Relay contract. This contract, residing on the target chain, is responsible for verifying the source chain data. Maintained by Relayers who submit the source chain data to it, the Relay contract verifies the data against the consensus rules of the source chain. The Relay contract is essentially the smart contract implementation of the source chain's light-client protocol, a protocol run by light nodes of blockchains.

Why is it called a light client?

In the blockchain system, there exist two types of nodes: full nodes and light nodes. Full nodes receive the entire blockchain block and verify that it follows the consensus rules, is compatible with previous blocks, and only includes valid transactions. They require significant storage and computational resources to verify the entire blockchain data.

On the other hand, light nodes only receive a portion of the blockchain data, usually the block headers, and verify them against the consensus rules and previous block headers. They don't verify the validity of transactions inside the block. They can use the block header to check the inclusion of some data on the blockchain, eliminating the need to trust others for data inclusion verification. This allows them to check data inclusion with minimal computational and storage resources. Although they cannot contribute to blockchain mining as they don’t access all transactions and cannot verify the validity of new transactions coming, they can efficiently verify data about the blockchain's past.

What are the verification steps?

Relayers submit source chain block headers to the Relay contract. This block header is verified by Relay and marked as valid if it follows the source chain's consensus rules. However, the block header is still not finalized at this point, meaning there is still a chance that this block header might be excluded from the source blockchain in the future. After a few more valid headers are submitted on top of a valid header, it is marked as a finalized block header. This indicates that this block will not be removed from the source chain in the future. The Relay contract rewards Relayers once their submitted block header becomes finalized.

While it's generally safer for applications to verify data inclusion against finalized block headers, this approach may not be suitable for all applications. It takes time for a valid header to become finalized, which might not be acceptable for certain applications with strict time constraints. In such cases, these applications might opt to accept data included in non-finalized block headers to process requests more rapidly, relying on the likelihood that a valid header will eventually become finalized. This trade-off between speed and security becomes important when speed takes priority over absolute security, and the application can tolerate a certain margin of error.