Telepathy
  • Introduction
  • Why Telepathy?
  • Getting Started
  • Build with Telepathy
    • Cross-Chain Messaging
      • Example: Cross-Chain Counter
      • Example: Cross-Chain Messaging Demo
      • Unit Testing
    • Ethereum Data Oracle
      • Example: Cross-Chain Airdrop
      • Example: Cross-Chain ENS Resolution
    • Ethereum Consensus Oracle
      • Example: Validator Balance Data
  • Telepathy Protocol
    • Overview
    • Sync Committee Protocol
    • Proof of Consensus
    • Smart Contracts
    • Off-chain Actors
    • Circuits
    • Guardrails
  • Resources
    • Telepathy Explorer
    • Contract Addresses
    • Brand Assets
  • Demo
  • Explorer
  • Github
  • Website
  • Discord
Powered by GitBook
On this page
  • Technical Walkthrough
  • Sending Messages
  • Proof of Consensus
  • Receiving Messages
  • Security Properties
  1. Telepathy Protocol

Overview

The steps involved in arbitrary message passing with Telepathy.

PreviousExample: Validator Balance DataNextSync Committee Protocol

Last updated 2 years ago

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

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

Receiving Messages

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

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 .

Once Alice's contract has called , Alice must wait ~12 minutes for her transaction to (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 . 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 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 .

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 . 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 . The 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.

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 and 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 .

send
finalize
Light Client
elliptic curves
here
Guardrails
Telepathy Light Client
Merkle proof
Relayer
Operator
Relayer
Router