How it works

WAVS is a decentralized execution framework for AVSs (Autonomous Verifiable Services), enabling the results of off-chain computation to be brought verifiably on-chain. It provides a runtime for executing WASI-based service components, allowing developers to define event-driven off-chain workflows while inheriting Ethereum's security via EigenLayer restaking.

When an on-chain contract emits an event, WAVS operators listen, execute the corresponding service component off-chain, and sign the result. Results can then be submitted on-chain or passed to other services. This allows AVSs to process complex computations off-chain at near-native speed while maintaining on-chain verifiability.

The WAVS platform comprises service components, operator networks, and on-chain contracts, forming a decentralized execution layer that extends the capabilities of smart contracts to off-chain executions.

The flow

Before diving into each part of a WAVS service individually, it's important to understand the basic execution flow of WAVS.

In this example, on-chain events can trigger service components, which are run off-chain by operators in the WASI AVS runtime. Results are then brought back on-chain, enabling the decentralized execution of off-chain services that are verifiable on-chain.

1. An AVS builder defines their service with a trigger, a service component, and submission logic.
2. Operators listen for on-chain events specified in the trigger contract.
3. An on-chain event triggers a task, and operators run the corresponding service component off-chain.
4. Operators sign the result of the task, and the signatures are sent to the aggregator (optional).
5. Results are aggregated and submitted on-chain according to the submission logic.

WAVS parts

The WAVS platform consists of several different parts that work together to form a decentralized off-chain execution layer for AVSs.

• Triggers: defined events that trigger a component to be run.
• Service components: WASI components written in Rust (with support for other languages coming soon) that contain the core logic of a service.
• Submission: contracts for the on-chain submission of results.
• The WAVS runtime: an off-chain execution environment for service components powered by WASM.
• Operators: node participants that opt into running services.

Triggers

A trigger is any on-chain event that activates a WAVS service. Rather than requiring a specific contract interface, WAVS allows AVS builders to designate any event from any smart contract as a trigger. In the near future, other triggers will also be enabled, such as cron or off-chain triggers.

AVS builders can specify the exact events that operators should listen for, defining:

• The contract address emitting the event.
• The event signature (topic 0 in Ethereum, event.ty in Cosmos).

When a specified event is emitted on-chain, WAVS operators detect it and execute the corresponding service component off-chain. The results are then verified and submitted back on-chain, completing the execution cycle.

Service components

Service components are the heart of the WAVS platform, encapsulating the core logic that powers a service. They are written in Rust (with support for other languages coming soon), which contains all the necessary computational logic to run a service. These service components are compiled to WASM and are uploaded to the WAVS platform where they can be run by operators. In the WAVS runtime, service components are sandboxed from each other and from the node's operating system. This way, operators and AVS services maintain a clean separation, with AVS builders defining service components and operators having to opt in to each service.

Service components are lightweight and built for adaptability. Building a service used to take thousands of lines of code and the configuration of dozens of files to execute even the simplest logic. With WAVS, service components can consist of a few lines of code that can be dynamically deployed to the WAVS platform.

Service components are also designed for composability: an AVS can chain multiple components together, creating decentralized flows of off-chain and on-chain executions. These intelligent protocols merge the performance of off-chain computation with on-chain verifiability, creating a complex mesh of decentralized transaction flows.

Submission

WAVS services save their off-chain computations to an on-chain submission contract. This contract validates input data and confirms the submission address is an AVS operator.

AVS builders can specify a Service Handler as their submission contract. After the execution of a service component in the WAVS runtime, the results can be passed to this contract, which contains validation and submission logic for the service. A Service Handler can be any contract that provides the necessary interface for handling service execution. Developers can use this contract to define their own logic for results and implement different rules depending on the specific needs of their service.

A Service Handler can validate results by calling the Service Manager contract. The Service Manager acts as the intermediary between EigenLayer and WAVS, validating data and operator signatures and enforcing EigenLayer security policies.

WAVS Runtime

The WAVS (WASI-AVS) runtime serves as the off-chain execution environment for all services running on the WAVS platform. Powered by operators running the WAVS node software, it provides a structured framework for deploying and managing service components that run within a WASI (WebAssembly System Interface) environment. You can think of WASI as a lightweight OS-like interface, offering a standard set of APIs that allow service components to perform system-level operations such as file handling and environment interactions. WAVS enables service components to execute securely within this WASI-powered sandbox, ensuring isolation from both the host system and other components.

WASM and WASI

WASM (Web Assembly) is a high-performance, low-level binary format that can be compiled from multiple programming languages. WASM can even run in web browsers at near-native speed. By leveraging WASM, AVSs built with WAVS are lightning-fast, lightweight, and easy to develop.

WASI (WebAssembly System Interface) is a standardized API that enables WASM (WebAssembly) modules to interact with a host system in a secure and platform-independent way. It provides WASM modules with a standardized set of APIs to access system resources. For more information, visit the WASI documentation.

There are significant advantages in leveraging a WASM/WASI-based platform for AVSs:

• Lightweight execution: Service components are lightweight WASM binaries ideal for high-frequency, low-latency AVS tasks.
• Speed: components can run in the WASI environment at near-native speeds, providing a significant advantage over Dockerized AVSs.
• Low overhead: Instead of each service needing its own dedicated Docker container, the WAVS runtime provides a computational layer that can be used by many components, saving storage and startup time.
• Dynamic deployment: to upgrade a service, simply upload a new component and update your service metadata to point to the new component. No more downtime or coordination of new binaries among operators.
• Security and separation: The WAVS WASI runtime enforces security by sandboxing service components, allowing them to interact with the host (WAVS) only through explicitly permitted WASI APIs.

Operators

Operators are network participants that run the WAVS runtime and "operate" different services. Similar to validators in a proof-of-stake network, users can stake (or restake) to operators and provide crypto-economic security to services.

Operators can opt in to running different services by registering with them. Once registered, operators listen for on-chain triggers and run the associated service component off-chain. Then, the operator takes the results of the computation, verifies them, and submits them on-chain.

Signing and aggregation

When a service is triggered, each operator registered to the service will run the service component on their machine and generate the result. These results are signed by the operator before being submitted.

For services that submit results on Ethereum, an off-chain aggregator can be used to conserve gas fees. Instead of each individual operator submitting results of a service directly on-chain (which would be costly), operators sign the results and submit them off-chain to an aggregator, which aggregates the results and submits a result to be posted to the chain in a single transaction. Results are signed using an operator's individual private key to produce an ECDSA signature, which is used to prove that the result is associated with an operator's specific private and public key pair. The aggregator accepts the result submissions from operators, verifies their validity, and compares the responses. If there is a consensus among operators on a single result, it is submitted on-chain as a single transaction. This method ensures that results are verifiably accurate while saving on transaction costs. Aggregation is an optional feature that can be defined in a service. Support for BLS signatures and a decentralized aggregator are currently on the WAVS roadmap.

Updating a service

Because of the lightweight and portable nature of WebAssembly, WAVS operators only need to run a single Docker image. WAVS provides a runtime for all registered services to run, each sandboxed from the other and from the node's operating system due to the nature of WASI. Operators will need to opt in to running different services by registering to an AVS.

Updates to service logic do not require node upgrades. Instead, developers can dynamically deploy a new service component and update their service. Instead of needing to run a new Docker image every time a service is updated, operators only need to upgrade if there is a breaking change to the WAVS node software itself.

Edit on GitHub