Off-chain Actors
An overview of all the off-chain actors used in Telepathy.
The Telepathy protocol relies on off-chain actors to trigger on-chain contract execution:
- The Operator is responsible for generation zkSNARK proofs and updates for the Light Client contract.
These actors are completely permissionless. Succinct 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.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 (circuit) 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
step 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 (circuit) which attests to the proper selection of the next sync committee. This zkSNARK is then passed into a different function called rotate 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.
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 Router contract's
executeMessageFromLog 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.
Last modified 6mo ago