Ethereum and other EVM chains lack the native ability to run functions autonomously as the result of onchain events – for example:
- position management in response to market activity
- execution of protocol upgrades in response to governance
- distribution of tokens over time with no third party intervention
Without event-driven activation (EDA) layers, all of these tasks require offchain or UI-based interaction from a server or human. Current EDA layers have a reaction time based on the speed of the RPC being used to poll for onchain events.
In this proposed setup, where the EDA layer itself is embedded in the client and execution is handled by an Actively Validated Service (AVS), time-sensitive tasks save valuable seconds by bypassing the RPC entirely. This enables efficient and competitive EDA.
This document outlines a new paradigm designed by the WeaveVM R&D team during our research into EigenLayer. The paradigm proposes a new protocol providing low latency data pipelines for EDA, utilising Reth’s Execution Extensions (ExExes) and EigenLayer AVS. We outline how AVS operators can be used as complex computation extensions alongside Ethereum/EVM Reth nodes through ExEx interfaces to the EDA operators.
Definitions
EigenLayer & Actively Validated Services (AVSs)
What is EigenLayer?
EigenLayer is a protocol built on Ethereum that introduces restaking - a new onchain primitive similar to rehypothecation. It allows either natively staked ETH or Liquid Staking Tokens (LSTs) to be restaked for additional yield.
At a high level, EigenLayer creates a marketplace between restakers (users with staked assets seeking additional yield) and AVS (services looking for cryptoeconomic security). EigenLayer’s potential lies in enhancing cryptoeconomic security by enabling staked Ethereum assets to validate applications not built directly on Ethereum.
What are Actively Validated Services (AVSs)?
Actively Validated Services (AVSs) are decentralized services that leverage EigenLayer restaked ETH to achieve high levels of integrity and trust. These services span a wide range of applications, including middleware, services, chains, networks, and Proof-of-Stake (PoS) systems.
Each AVS operates under a set of smart contracts with specific slashing rules that penalise malicious operator behaviour. By reusing ETH to secure multiple services, this system reduces capital costs for stakers while significantly enhancing trust guarantees for individual services.
Reth Execution Extensions
Execution Extensions (ExExes) allow developers to build their own infrastructure that uses Reth as a base for driving the chain (whether Ethereum or OP Stack) forward.
An Execution Extension is a task that derives its state from changes in Reth’s state. Examples include rollups, bridges, and indexers. They’re called Execution Extensions because they’re triggered by the execution of new blocks (or reorgs of old blocks) initiated by Reth.
Unlike separate processes connecting to the main Reth node, ExExes are compiled into the same binary as Reth and run alongside it, using shared memory for communication.
Introducing Operator-as-ExEx, A New Paradigm For Low Latency EDAs on EigenLayer AVS
Introduction
Operator-as-ExEx is a paradigm that integrates partially or completely the operator of an Actively Validated Services as Execution Extensions in Reth. This approach aligns perfectly with events-driven activated predefined-actions such as Keeper Networks.
Lower Latency Activations
In this paradigm, the AVS operators (exex-operators) achieve lower latency compared to EDA-operators using JSON-RPC-based event triggers. This improved latency comes from partially (or completely) integrating the AVS operator into the Reth node’s ExEx, which compiles into the same Reth binary and runs alongside it. Using shared memory for communication eliminates the need to wait for AVS service manager task emissions or onchain events that typically trigger an EDA workflow through JSON-RPC registered events.
Unrestricted & Flexible Operator Implementation as ExEx
AVS Operator code is an off-chain component that performs computations based on tasks emitted by the AVS service manager smart contract. Reth’s ExEx enables a complete implementation of operator code logic as an Execution Extension, supporting secrets (env variables) needed to submit results of completed AVS tasks.
AVS Operator code is an off-chain code component that performs offchain computation based on tasks emitted by the AVS’s service manager smart contract. Reth’s ExEx is an off chain component that allows a complete implementation of an operator code logic as an ExEx, with support to secrets (env variables) needed to submit results of a completed AVS task by the operator.
Homogeneous EDA Events & Reth Node Network
For this paradigm to achieve low latency and work efficiently, EDA events must occur on the same network as the Reth node (e.g., Ethereum, WeaveVM). Otherwise, the operator (AVS operator implemented in the ExEx) cannot natively access the trigger event from ExEx notifications.
EDTC: Event-Driven Task Creation
Deriving from this paradigm’s logic, the ExEx of a Reth node can serve as an entrypoint for the AVS. The ExEx can maintain a predefined list of events that may occur on the Reth node network (such as reaching a specific blockheight or detecting transactions with certain predefined conditions). When these events occur, the ExEx creates the task on the AVS Service Manager smart contract. Therefore, the EDTC can be actually event-driven, or time-driven.
Task Lifecycle in an Operator-As-ExEx
The lifecycle of an Operator-as-ExEx task begins when a client registers a task on the AVS network’s service management contract (the AVS entrypoint in our simple model). The task should include the EDA’s event that should drive this task in the future, similar to keepers in a keeper network.
After task registration, the exex-operator detects the task’s emitted event from the AVS Service Manager smart contract though ExEx events. Based on the AVS internal logic and protocol design, the exex-operator determines the appropriate action and derives the onchain event to monitor from the emitted task. The exex-operator then scans each SealedBlock in the ExEx thread, searching for potential onchain activities that might trigger an event the operator is assigned to monitor.
When the monitored task is triggered by an onchain event, the exex-operator submits the task’s result to the AVS Service Manager.
ExEx-Operator Code Implementation
This paradigm demonstrates how to implement an EigenLayer AVS operator as a Reth ExEx, leveraging shared memory between the ExEx and Reth node to reduce latency in event-driven activations triggered by onchain events.
To demonstrate this paradigm in practice, we have reimplemented the hello-world-avs operator as a Reth ExEx. The exex-operator includes placeholder control structures to loop through the parent network’s sealed blocks, allowing developers to define their code logic for event scanning. You can explore the exex-avs-skeleton code here on GitHub.