Introduction

EigenLayer is a protocol that supplies decentralized trust to validate new crypto services. EigenCloud is the comprehensive, verifiable cloud platform built on EigenLayer that makes this shared security accessible to developers building on any blockchain. Autonomous Verifiable Services (AVSs) are the services built on EigenCloud that consume the decentralized trust from EigenLayer; they have an onchain component (a set of smart contracts enabling Operator registration, rewards, slashing, etc.) and an offchain component, which is the custom execution environment. This environment can be anything, such as another blockchain. This post will explore how AVSs on EigenCloud can be built and used on many blockchains. Here we will detail the need for EigenCloud in a multi-chain world, the design components, and potential design examples.

The Future Is Multi-chain

Blockchain innovation is rapidly increasing and shows no signs of slowing. As a result, there is an abundance of blockchains, each targeting different goals, such as performance (Solana), trading (Hyperliquid), security (Ethereum), and much more, each fostering the development of new applications. In the context of AVSs, other chains can allow for faster and cheaper verification as opposed to Ethereum (especially if designing batching of verification is difficult).While this innovation is a net positive for the space, it comes with a trade-off: fragmentation, particularly in security. Each network must bootstrap a new validator set (the set that secures the network), resulting in cold start problems and weaker security guarantees. EigenCloud addresses this by supplying decentralized trust, allowing new protocols, apps, and rollups (AVSs) to tap into the cryptoeconomic security of Ethereum. EigenCloud also solves this, which will be expanded on below.

Designing AVSs for Any Chain

The best mental model for thinking about AVS designs in a multi-chain context is a rollup built on Ethereum, where the Layer-2 rollup (can be seen as the offchain component of the AVS) performs some computation and settles it back to Ethereum for finality (e.g., through a validity or optimistic proof). Similarly, for AVSs, arbitrary computations are performed offchain and subsequently verified on Ethereum through means such as stake-weighted signatures over the computation done. This paradigm is the common thread among all multi-chain AVSs.From this pattern, there are three critical components for building AVSs in a multi-chain environment:

1. Generation of EigenLayer State: The state of the AVS on EigenLayer represents the available cryptoeconomic security, specifically, the amount of stake allocated by Operators to an AVS. This AVS state is a stake table that contains all information about the current Operators and their relative stake. Stake tables provide features like Operator identification (e.g., for work distribution) and stake-weighted consensus (e.g., by performing BLS signature aggregation over a hash), which can be used to trigger downstream actions.
2. Stake Transportation: For other chains to use the cryptoeconomic security of an AVS, it must be transported; methods of transportation include using a general message passing bridge (GMP), a validity proof, or RPC. Eigen Labs is developing a solution for mutli-chain verification that can be used to transfer EigenLayer state that leverages RPC. This will support EVM-based chains initially and eventually non-EVM chains, for further details refer to ELIP-008 and documentation.
3. Verification: Evidence of the computation done by Operators must be expressible back on Ethereum for verification, which enforces cryptoeconomic security. This evidence can be used to punish Operators for deviating from the services they committed to. This verification mechanism enables other chains to leverage the cryptoeconomic security of EigenLayer. An example of such evidence for verification could be a signed message from the Operator.

Case Study: Shared Sequencing AVS

A “Shared Sequencing AVS” is an AVS where rollups delegate their sequencing rights to a shared sequencer. For further information on rollup sequencers, refer to this post. EigenLayer Operators, when opted into a shared sequencing AVS, provide a service where they order transactions and build blocks. Layer 2s benefit from this design through faster finality (by relying on the cryptoeconomic security of the AVS) and interoperability through verified state roots.Below are the core components that comprise the Shared Sequencing AVS:

• Onchain: A smart contract on Ethereum where the Operators/Sequencers post cryptographically signed state roots. This contract performs signature verification (e.g., ECDSA or BLS) over the signed state roots. Other chains can read from this state optimistically for interoperability. The L2s will need to deploy a smart contract to perform signature verification against the transported AVS stake table, as a predicate for downstream actions (e.g., interoperability).
• Offchain: Operators run the L2 node binary that sequences transactions, builds blocks, signs them, and posts the signed root to Ethereum. This binary could also support a consensus P2P layer, such as the one provided by Commonware’s simplex P2P, implementing a leader-based BFT algorithm.
• Availability of EigenLayer State: Any transport method (GMP, ZK, AVS) can be used to transport the EigenLayer state, each with different trade-offs. For example, ZK proof generation is more expensive and takes longer, but provides the strongest security guarantees. The transporter would be responsible for transporting both the state roots and the AVS state.
• Verification: Evidence of faults by Operators must be provable on Ethereum. In the case of a double signing at the same block height or signing over an incorrect stake root, the stake roots could be made available on EigenDA for verification against Operator signatures.

Case Study: SVM Oracle AVS

This AVS design details how to build an Oracle AVS on a Solana Virtual Machine (SVM) environment. Oracles naturally align with the AVS design due to their task-based and verifiable nature, with examples like UMA and Redstone (for further information on task-based AVS designs, refer to the AVS Archetype blog post). Oracles enable the settlement of offchain data onchain, being used for things like prediction markets and DeFi protocols.The high-level task-based interaction with an Oracle AVS is the following:

1. User submits a request to the Oracle AVS.
2. The AVS Operators consume the request, run computation to retrieve the offchain data (e.g., consuming price feed data), and sign over the results cryptographically.
3. The AVS Operators reach intersubjective consensus, and the Oracle result is submitted onchain. This result is a cryptoeconomic certificate of offchain data. The Aggregator Pattern can be used here to mediate the consensus between Operators. Refer to the Aggregator Pattern in the AVS Archetypes post for further detail.
4. Trigger downstream actions (e.g., resolve prediction market).

Below are the core components of the SVM Oracle AVS:

• Onchain: A smart contract on SVM supporting signature verification, the SVM natively supports verification against the secp256k1 curve, which is used for key generation and signature verification on Ethereum. This signature verification will be done against the stake table of the Oracle AVS.
• Offchain: Operators run the custom Oracle binary, which would need to support retrieval of offchain data (e.g., API set) and signing over data. A separate Aggregator Service, which would aggregate ECDSA signatures of Operators and submit results to the SVM Oracle contract.
• Availability of EigenLayer State: Any transport method (GMP, ZKP, AVS) can be used to transport the EigenLayer state, each with different trade-offs. The same as the Shared Sequencing AVS mode of transport.
• Verification: Verification of faults by Operators would be done on Ethereum through an Optimistic Challenge Period. This is due to the fact that the fault of an Operator equivocating about an Oracle result is a retrospective intersubjective fault (the fault can only be observed after it is settled onchain and is based on the consensus of honest observers). The evidence supplied in the challenge would be the request and the Operator’s signed result. This optimistic challenge protocol incurs the trade-off of slower finality (the challenge period must expire before downstream actions can be done).

Case Study: Cosmos Appchain AVS

This AVS design leverages the security of EigenLayer Operators to bootstrap a validator network on a Cosmos-based appchain. Operators on EigenLayer would delegate their stake to validators on the appchain.Below are the core components of the Cosmos Appchain AVS:

• Onchain: A smart contract that allows Operators to delegate their stake to appchain validators. A registry contract would need to maintain the identities of the appchain validators via their public keys. The AVS would include a vetoable process for adding and removing validator public keys
• Offchain: Operators run a node binary that implements the Cosmos SDK.
• Availability of EigenLayer State: Cosmos’ Oracle Vote Extension module, which enables enshrining oracle data into the protocol through the block-building process, could be used to transport EigenLayer state to the appchain. This oracle data could be ingested through an Ethereum RPC provider.
• Verification: Evidence of faults by validators would need to be provable on Ethereum - for example, in the case of double signing at the same block height. This would require using a library that implements the Ed25519 curve for signature verification, as this is the signature scheme used on Cosmos chains.

Conclusion

The future of blockchain is multi-chain, and the need for unified security and verifiability across these environments is critical. EigenCloud meets this need by enabling AVSs to extend Ethereum’s cryptoeconomic security to any environment. This unified security model unlocks a new design space where the burden of bootstrapping a new validation network is greatly reduced, allowing developers to build differentiated services across any chain.

Coming Soon

As mentioned above, Eigen Labs is developing a solution that will enable developers to easily go multi-chain, initially supporting EVM environments, another key improvement to our DevEx. DevEx remains the main focus for Eigen Labs, with the DevKit framework and revamped documentation being released soon after another set of major unlocks for developers on EigenCloud. Stay tuned!