Overview

The steps involved in arbitrary message passing with Telepathy.

Telepathy, at its core, is an interoperability protocol for Ethereum that is secured by verifying the signatures of Ethereum validators on-chain. In this section, we will walk through at a high-level how Telepathy enables secure arbitrary messaging between Ethereum and any other chain.

Technical Walkthrough

Alice wants to send a transaction from Ethereum that increments a counter variabe in a smart contract on Gnosis Chain. To enable Alice to accomplish her goal, the first thing Alice must do is integrate her Ethereum contract with the Telepathy Router.

Sending Messages

The Telepathy Router is a contract on Ethereum that allows you to send an arbitrary message to another chain using the Telepathy Protocol. This contract exposes the following function:

function send(
    uint32 destinationChainId, bytes32 destinationAddress, bytes calldata data
)

The destinationChainId and destinationAddress parameters are used to determine what the destination contract is. The data parameter is used to specify the message that the destination contract receives.

Proof of Consensus

Once Alice's contract has called send, Alice must wait ~12 minutes for her transaction to finalize (this is a fundamental limitation with Ethereum itself--relaying the message any earlier leads to a chance that the transaction does not end up getting included in the canonical chain due to reorgs). A finalized block header can only be produced if a large percentage of Ethereum validators have signed a message that attests to this block header. To know that a block has been finalized, it suffices to check (among other details) that a block header has signatures from a large percentage of the Ethereum validators (details are being omitted here that will be explained in the next section). Thus, one way we can trustlessly verify Ethereum state (via the block header) on another chain is by verifying this large percentage of signatures inside a smart contract--also known as a Light Client. Note that light clients only verify the consensus of a protocol, but do not verify the execution state transition like a full-node. Unfortunately, because verifying validator signatures is quite computationally expensive (as the EVM does not support the elliptic curves used for the BLS12-381 curve used in validator signatures), running an on-chain light client in this manner would be prehibitively expensive. To solve this problem, Telepathy utilizes a zero-knowledge succinct proof that provides a validity proof that a block header has enough signatures from the Ethereum validators. This zkSNARK can be cheaply verified on-chain, accomplishing the same goal that wasn't originally possible due to high transaction costs.

A zkSNARK allows you to generate a proof that some computation has some particular output, in such a way that the proof can be verified extremely quickly even if the underlying computation takes a very long time to run. Read more about them here.

Receiving Messages

By verifying these zkSNARKs that contain validity proofs of Ethereum's light client protocol, we now have secure access to Ethereum's block headers on destination chains, inside a contract known as the Telepathy Light Client. Because these block headers are commitments for the entire state of Ethereum, it allows us to prove that Alice made a call to the Router with a Merkle proof. The Relayer is an off-chain actor that provides these Merkle proofs for them to be verified inside the Telepathy Router contract. Once Alice's request has been verified, the Telepathy Router will pass the arbitrary message on Alice's behalf to increment the counter.

In particular, the Telepathy Router assumes that the contract that Alice specified as destinationAddress in her call to send implements this function:

handleTelepathy(uint32 sourceChainId, address sourceAddress, bytes memory data)

This enables Alice to implement custom logic based on the received message.

Security Properties

Because the block headers are only approved if they have enough validator signatures, the security of the protocol borrows directly from the honesty of the Ethereum validator set. Furthermore, it is important to note that both the Operator and Relayer are not permissioned. Anyone can generate the zkSNARKs and anyone can provide the Merkle proofs that prove that a specific message was requested to be passed to another chain on Ethereum.

Everything is secured by checks made on-chain, and the core contract functions are also permissionless. The few permissioned access controls that do exist are outlined in our Guardrails.