The Three Pillars of Programmable Trust: The EigenLayer End Game

Thanks to Alex Obadia, Austin Griffith, Dan Elitzer, David Phelps, Jon Charbonneau, Soham Zemse, and Waylon Jepsen from the community for reviewing and giving feedback. 

Today, if any developer wants to build a smart contract protocol such as a DEX, a lending protocol, etc., on Ethereum, they can inherit security from Ethereum’s trust network by simply deploying their contracts on top of Ethereum. This has ushered in a Cambrian explosion of innovative smart contract protocols on a secure platform, such as DeFi, NFTs, and more. 

However, until now, Ethereum’s security has only extended to smart contract protocols, and it's been very difficult to offer that security to distributed systems like bridges, sequencers, and Data Availability layers. The developer has to go through the cumbersome process of bootstrapping their own trust network to get any security. 

The requirement to bootstrap is arguably the most significant obstacle for every new idea to be the most significant obstacle preventing innovation in distributed systems from reaching a similar degree of speed, variety, and scale comparable to that of innovations in smart contract protocols. 

This has been one of the biggest limitations of building blockchains and decentralized networks in the past. Until now. Because this is the promise of EigenLayer. 

Imagine a world where instead of starting your network from scratch, you could tap into a network with $45B of value at stake and 850k validators at the time of writing, by leveraging the security and trust properties of Ethereum programmatically based on the needs of their systems. 

In such a world, developers would not have to worry about bootstrapping a trust network anymore. Instead, they could design systems that pay fees to the programmable network to get the amount of security they want, in order to build innovative distributed systems that can contribute to the creation of a new and better version of the Internet.

In this article, we will briefly review the EigenLayer protocol, then dig into three forms of fundamental trust that developers can use to program their protocols via EigenLayer:

• Economic Trust
  • Trust from individuals making commitments and backing their promises with financial stakes
• Decentralized Trust
  • Trust from having a decentralized network operating by independent and geographically isolated operators 
• Ethereum Inclusion Trust
  • Trust that Ethereum validators will construct and include your blocks the way it has made promises to you alongside the consensus software they are running

Figure: illustrates the three types of trust you can program via EigenLayer.

Intro to EigenLayer

EigenLayer is the first generalizable network providing programmable trust from Ethereum. Technically, it is a set of smart contracts on Ethereum as well as a set of off-chain node software that allows solo stakers, staking service providers and LST stakers to opt into running new offchain distributed systems. 

Today, Ethereum validators stake ETH in order to make capital-based commitments that they will not deviate from the Ethereum protocol. EigenLayer expands the scope of commitments these stakers can make to include opting in to actively participate and respond to tasks for new use cases and distributed systems. Stakers opt into these systems by running additional node software, and by granting the EigenLayer smart contracts the ability to impose additional slashing conditions (in a programmable manner) on their staked ETH or LSTs as specified by the distributed systems.

We call these new use cases and distributed systems “Actively Validated Services” - AVSs. Examples of AVSs are fast finality layers, data availability layers, virtual machines, keeper networks, oracle networks, bridges, threshold cryptography schemes, AI inference/training systems, and trusted execution environment committees. We will soon post a blog to uncover these ideas.

A very powerful benefit in EigenLayer is that block proposers can make commitments in addition to Ethereum core consensus software such that new ideas around block construction and ordering and onchain activation can be experimented without in-protocol upgrades. 

Understanding Programmable Trust 

There are three distinct models of trust that you can programmatically acquire from Ethereum via EigenLayer: 1) economic trust, 2) decentralized trust, and 3) Ethereum inclusion trust. In this section, we will go through each of them separately. In many cases, your AVS might require a combination of different types of trust. EigenLayer is a platform that allows AVS developers to mix and match these elements to create appropriate trust models.

1. Economic Trust

Economic trust is trust based in capital. These types of assurances are accepted when certain commitments are backed by financial stake at-risk that makes it irrational for a rational economic actor to behave badly. The core feature of economic trust is that the AVS’s validation semantics is objective in nature. 

What objectivity means is that if an operator maliciously deviates from the specified validation semantics while responding to the AVS’s task, then an observer can create an objective onchain proof to slash the malicious validator. 

For example, a chain can adopt reorg-resistance from EigenLayer nodes if the nodes have placed assets behind the sequence it is committing to and be slashed if reorg happened. 

Other applications of economic trust include the following:

Optimistic Claims. If there is enough value staked on EigenLayer to make a set of objectively verifiable claims, then those claims can be instantly treated as correct, acted upon, and later slashed if violated. Consider Light Client Bridges as an example: Run light clients of many other chains off-chain and make claims about the canonical fork of the other chain on Ethereum. The input is acted upon immediately without any latency, and later slashed if wrong.

Arbitrary Slashing Conditions. Rollups are usually thought to be limited to fraud proofs for state execution. On EigenLayer, any slashable violation (such as double signing) can be penalized, and thus EigenLayer can be used to extend functionality beyond state execution. As an example, one can build an ETH-staked oracle that is slashed based on a more expensive trusted input (for example, soliciting inputs from highly trusted sources or individuals). Although the second committee is not cryptoeconomic, the power of EigenLayer is to let different stakers only opt-in to trust assumptions that they are comfortable with.

Latency Transformation. If we consider Ethereum to be the one computing processor, its clock speed is limited by its finality period of at least 2 epochs (~12mins). If there is enough ETH or LST restaked on EigenLayer, it is possible to increase the clock speed so as to get a significantly larger amount of full economic finality at native network latency. As an example, a primitive where overclocking is needed is superfast finality. With EigenLayer, one can run a superfast finality chain on top of Ethereum which gives fast economic finality, and which settles optimistically on Ethereum. This superfast finality chain verifies ZK proofs and arrives at consensus within seconds.

2. Decentralized Trust

Decentralized trust is trust based in decentralization. These assurances derive from having a large and distributed enough validator set that you can be comfortable that they are not all colluding.

Some AVSs have failure modes that are not objectively provable onchain easily identified and penalized on chain, so they cannot be built solely on a system of economic trust. These AVSs can be built on a system of decentralized trust, where the property of the AVS continues to hold as long as enough validating nodes act independently without collusion. One way to prevent collusion is to utilize a large decentralized validator set so that collusion becomes difficult or observable. 

Each AVS can set specific entry conditions using subjective oracles to allow only a certain configuration of nodes (say home stakers) to ensure maximum decentralization of the nodes. By identifying and incentivizing decentralized nodes through additional fees, the overall rewards accrued to decentralized nodes can potentially increase compared to centralized validators. This approach of using subjective oracles to admit only decentralized nodes has the potential to create for the first time a “market value” of decentralization.

So, what AVSs can you build with decentralized trust? Here are some applications:

Secure Multiparty Computation. A simple example is Shamir secret sharing, where the user requires a secret to be split into shards and stored in as many non-colluding and decentralized nodes as possible. Any collusion here is a non-attributable fault and thus, the AVS can instead rely on decentralized trust.

EigenDA. It is possible to combine economic trust and decentralized trust to create new services. EigenDA, built on EigenLayer, relies on decentralization to prevent collusion (the data remains available) and economic trust to punish deviations from the equilibrium (if a node is not storing data, it will get slashed through a proof of custody system). This model combines economic trust (losing ETH) with decentralized trust (difficulty of collusion).

If your AVS requires decentralized trust, then as an AVS developer you should ensure that the node software that is required for executing on the AVS’s validation semantics is lightweight in nature. Being lightweight means imposing a smaller resource cost on the stakers who are in your AVS’s decentralized quorum, enabling more stakers to participate, thus giving you more decentralized trust.

3. Ethereum Inclusion Trust

While the first and second trust models absorb the economics and decentralization of the Ethereum trust network, the fact that it is the Ethereum validators who restake enables a whole suite of powerful new features where you can experiment with new opt-in features to the Ethereum protocol without modifying the core Ethereum protocol. These opt-in features open up new proposer commitments on top of the existing proposer commitments from the consensus protocol. 

Figure: illustrates the difference between with and without Ethereum inclusion trust. Not all services need Ethereum inclusion trust if they don’t need Ethereum inclusion in block construction and ordering. AVSs can also mix and match multiple trusts. 

Below are some applications of Ethereum inclusion trust:

MEV Management. Ethereum block proposers can make credible commitments to order blocks according to different rules, creating a powerful MEV toolkit: (i) proposers committing to sell portions of blocks that they will propose in the future in the MEV market, (ii) proposers agreeing to do event-driven actions, for example, proposers agreeing to include certain transactions (collateral refueling for example) in their block and execute on it in case a certain event happened. This video gives a high-level vision of what MEV management tools are unlocked by EigenLayer. 

Single-slot-finality. The interaction with Ethereum’s consensus protocol “Gasper” needs careful consideration, however it is possible that when enough block proposers opt-in to a new EigenLayer task where they agree to not fork a block, we can get single-slot economic finality purely via opt-in. 

Building with Programmable Trust 

As an AVS developer, in order to inherit trust from EigenLayer in a programmable manner, you must first ask yourself the following two questions:

1. What kind of trust is best suitable for your AVS and how would you penalize wrongdoers if that trust is broken?
2. 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?

There is no one-solution-fits-all to answer these questions and your answer will depend on your specific AVS design and security requirements. In this blog post, we have introduced a mental model for you to be able to answer the first question - what type or types of trust may benefit your system design. To answer the second question, we’re here to dive in with you today. Please submit your proposal via this form and we can give you feedback on your design and start the conversation: https://bit.ly/avsquestions 

And if you’re excited about these primitives, join our private research discussion group here: https://bit.ly/programmabletrust