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
  • Operator
  • Relayer
  1. Telepathy Protocol

Off-chain Actors

An overview of all the off-chain actors used in Telepathy.

PreviousSmart ContractsNextCircuits

Last updated 2 years ago

The Telepathy protocol relies on off-chain actors to trigger on-chain contract execution:

  • The is responsible for generation zkSNARK proofs and updates for the contract.

  • The executes messages for the contract.

These actors are completely permissionless. operates their own version of these actors so that the user experience of integrating with Telepathy painless, but as all LightClient and TelepathyRouter update functions are permissionless (with no access control), anyone who wishes to can run their own versions of an operator and relayer can do so.

Operator

The Operator is responsible for keeping the Light Clients on each chain up-to-date with Ethereum's latest block headers. To accomplish this, the Operator periodically queries the sync committee for the latest finalized block header, and then generates a zkSNARK () which attests to the fact that enough of the sync committee has provided signatures for this block. The zkSNARK takes around 1-2 minutes to generate on a 32 core machine. This zkSNARK is then passed as an argument into a function called within the Light Client contract for verification. The Operator is also responsible for updating the set of validators included in the sync committee within the Light Clients. The sync committee rotates every 27 hours. The Operator periodically generates a zkSNARK () which attests to the proper selection of the next sync committee. This zkSNARK is then passed into a different function called within the Light Client contract for verification.

All circuits and contracts are open-source and can be used to generate the above proofs in running one's own operator if desired.

Relayer

The Relayer is responsible for relaying the arbitrary messages sent from Ethereum to the other chains. The Relayer waits for the Light Clients on each chain to be updated by the Operator, and then relays all the messages that can be validated via a Merkle proof against the latest block header in the Light Client.

In particular, the Relayer will gather the necessary Merkle proof for each message and then pass them as an argument to the contract's function:

function executeMessageFromLog(
    bytes calldata srcSlotTxSlotPack,
    bytes calldata messageBytes,
    bytes32[] calldata receiptsRootProof,
    bytes32 receiptsRoot,
    bytes[] calldata receiptProof,
    bytes memory txIndexRLPEncoded,
    uint256 logIndex
)

Assuming the Merkle proofs are valid, the message will get relayed to the correct destination contract.

Succinct
circuit
step
circuit
rotate
executeMessageFromLog
Operator
Relayer
Light Client
Router
Router