An Incomplete Guide to AVS

Jiawei

Published in

IOSG Ventures

7 min readMar 26, 2024

Author: Jiawei, IOSG Ventures

Recently, it’s become popular among developers to build infrastructure projects with EigenLayer. These projects are called Actively Validated Services (AVS), which refers to any system necessitating its own distributed validation semantics for verification. These systems could include DA layers, new VMs, oracles, bridges, among others.

But how exactly can we build an AVS?

To set the ground rules for your design, you need to address four primary questions.

Q1: What defines a Task in your AVS?

A task in EigenLayer is the smallest unit of work that operators commit to perform when serving an AVS. These tasks may be associated with one or more slashing conditions applicable to the AVS.

Here’re two example tasks:

Hosting and serving a “DataStore” in the context of EigenDA
Posting a state root of another blockchain for a bridge service

EigenLayer provides a more detailed example in the following workflow. The task that this AVS is designed to complete is calculating the square of a specific number.

A task generator regularly publishes tasks at fixed intervals. Each task indicates a number that needs to be squared. It also includes the quorum numbers and the threshold percentage of the quorum, stipulating that each listed quorum requires at least a threshold percentage of operator signatures.
Operators currently opted into the AVS need to read the task number from the Task contract, calculate its square, sign the computed result, and send both the computed result and signature to the aggregator.
The aggregator collects the signatures from the operators and aggregates them. If any response passes the threshold percentage of the quorum set by the task generator when posting the task, the aggregator posts the aggregated response to the Task contract.
In the dispute resolution period, anyone can raise a dispute. The DisputeResolution contract resolves that a particular operator’s response is not the correct response or the operator didn’t respond during the response window.
If the dispute is resolved, the operator will be frozen in the Registration contract and the veto committee will decide whether to veto the freezing request or not.

Q2: What kind of trust does your AVS want to inherit?

EigenLayer provides three pillars of programmable trust.

Economic Trust

Economic trust relies on people’s confidence in staked assets. If the profit from corruption is less than the cost of corruption, an economically rational actor would not initiate an attack. For instance, if launching an attack on a bridge costs $1 billion, but yields a profit of only $500 million, then economically, it’s clearly irrational to proceed.

As a widely adopted cryptoeconomics primitive, slashing can substantially raise the cost of corruption.

Decentralized Trust

The essence of decentralized trust is to have a large and widely distributed set of validators, either virtually or geographically. To prevent collusion and liveness attacks among various nodes in AVS, it’s advisable not to have a single institutional service provider operate all the nodes.

On EigenLayer, different AVSs can customize the level of decentralization. For example, they could establish geographical location requirements for validators, or permit only individual stakers to offer node services, and provide more incentives to lure this type of stakers.

Here’s an example.

Shutter proposed a solution to defend against MEV by encrypting transactions using threshold encryption. This process involves a group of nodes, known as Keypers, who participate in the calculation of a shared set of public and private keys through distributed key generation (DKG). These nodes are elected by the governance of Shutter DAO.

Obviously, DKG relies on the assumption of an honest majority.

Through EigenLayer, Shutter can facilitate a wider distribution of restakers who can act as Keypers. This approach not only reduces the risk of collusion among Keypers but also strengthens the security and resilience of the network.

Likewise, the Lagrange State Committee (LSC) consists of restakers. For each state proof, a minimum of 2/3 of the committee members must sign a specific block header to generate a state proof through SNARK.

Ethereum Inclusion Trust

In addition to committing to Ethereum via staking, Ethereum validators who restake on EigenLayer can also make credible commitments to AVS through restaking. This allows these proposers to offer fantastic services (e.g partial block auction by MEV-Boost++) on Ethereum without requiring changes at the protocol level.

For example, long-term block space auctions allow buyers to secure future blockspace ahead of time. Validators engaged in restaking can make credible commitments to the blockspace and will get slashed if they do not include buyers’ transactions.

Let’s say you’re building an oracle, you may need to feed prices in a certain time period. Or suppose you’re running an L2, you may publish L2 data to Ethereum every few minutes.

Q3: Is the work to be done by the operator lightweight or heavyweight?

If you want to maintain the decentralization of Ethereum validators, the tasks of AVS should be designed as lightweight as possible.

If the tasks consume substantial computational resources, solo operators may not be able to handle them.

Q4: What are the slashing conditions?

By opting to restake with a particular service, stakers accept the risk of being subjected to slashing according to the rules in the slashing contract deployed by each service.

AVS should design on-chain-checkable, provable, objectively attributable slashing conditions. Examples include double-signing a block in Ethereum and a node in a light-node-bridge AVS signing an invalid block from another chain.

Inappropriately designed slashing conditions can lead to divergence, which in turn can trigger systemic risk.

AVS should also be designed with observability in mind, allowing for monitoring, tracing, and logging of requests and responses across services.

How to quantify?

How much trust (capital staked, number of distinct distributed validators, and number of Ethereum validators needed to make an Ethereum inclusion commitment) does your AVS need and how would you incentivize it?

For example, if a bridge has a weekly volume of 100M$ and rents security worth 100M$, users can trust that they are safe. Even if validators attempt to disrupt the system, users are protected because they can be compensated through the slashing redistribution, as Sreeram pointed out here.

Given that the TVL of the bridge, the restaked ETH, the number of opted-in operators and many of the other parameters will be constantly changing and could fluctuate significantly, the AVS needs a practical method to adjust their security budget and reserve buffer.

AVS can pay for the economic security with a percentage of its total token supply.

But, do I compromise my token utility by using EigenLayer?

Definitely not!

EigenLayer supports dual staking. This allows you to use both ETH and your native token to secure the network, adjusting the proportion of each as needed. During the network’s bootstrapping phase, ETH may occupy a larger proportion. As the network matures, you may want the native token to play a more significant role. In this case, AVS can increase the proportion of the native token through protocol governance.

Furthermore, when AVS’s security needs grow rapidly in the short term, for example, when the TVL of the DeFi protocol served by an AVS oracle increases quickly, AVS can still use EigenLayer to consolidate its security.

EigenLayer is a programmable trust market which offers elastic security.

What external tools can I use?

Here are some projects worth noting.

In EigenLayer’s tripartite market, the operator depends on AVS developers to code the AVS software correctly and set reasonable slashing conditions. However, given the diversity of AVS, the interaction logic between each AVS and the operator may vary, creating an untapped territory. To prevent accidental slashing events, AVS can audit the code library before launch. Moreover, EigenLayer has a veto committee, capable of vetoing incorrect slashing decisions through multi-sig.

Meanwhile, Cubist is working with EigenLabs on developing an open anti-slashing framework, leveraging secure hardware to restrict the signing of transactions and validation messages with custom policies within the key manager. For example, signing two different block headers at the same height will never pass the policy engine inside the key manager.

Risk-preferring restakers/operators may want to participate in early AVS for higher returns. In this case, Cubist’s anti-slasher can be useful.

Many understand that EigenLayer helps AVS establish a trust network, but how much does AVS need to pay for economic security and to ward off economic attacks?

Anzen Protocol developed the Safety Factor (SF), a universal standard metric for gauging the economic security of AVS. The SF is based on the concepts of corruption cost and corruption profit.

Anzen helps AVS maintain a consistent minimum level of economic security without overpaying the operators.

EigenLabs is developing EigenSDK to assist AVSs in writing their off-chain node software code. The SDK includes modules for signature aggregation, interaction with EigenLayer contracts, networking, cryptography, and event monitoring clients.

Meanwhile, Othentic is building a development tool to help AVS ship the product faster.