Introduction
Background
The significant evolutionary advantage of humans rests in our ability to cooperate in large numbers. Large- scale cooperation requires trust, which is usually provided by intermediating institutions. The modern econ- omy has seen the rise of digital platforms such as Facebook, Uber, Airbnb, Visa, iTunes, Ebay and Amazon marketplace which allow global communication, efficient markets and cooperation at scale. One might say that these digital platforms form a system of digital commons, somewhat akin to the physical commons, such as forests, fisheries, national parks and oceans, that we have in the real world.
While existing digital platforms rival physical commons in access, importance and reach, they do not fully qualify as digital commons as they are controlled without democratic governance, leading to significant frictions, such as: (i) centralized information and control silos, where users or innovative solutions can be de-platformed any time, (ii) platforms enshrine somewhat subjective positions, such as the specific recom- mendation engine, moderation policy, and mechanisms to evaluate driver behavior, credit or renter behavior,
(iii) innovations on top of these platforms require permission of the platform creators, and this significantly constrains the innovation velocity, and (iv) platforms can unilaterally alter policies that affect users without seeking their inputs.
Blockchains offer an alternative paradigm for building the global digital commons where it is possible to have
(i) permissionless user access, (ii) native user governance, (iii) programmatic incentives to share value across the various participants and (iv) permissionless innovation. All of these properties arise because blockchains
have two main properties: (a) openness, which comprises of censorship resistance and permissionlessness and (b) verifiability, which ensures that the nodes participating in the blockchain are performing their duties correctly. Thus we can say that blockchains offer a new paradigm for building the open, verifiable digital commons.
Staking via a work token. This brings us to the question of how one can create a digital commons platform, which is at the heart of blockchain architecture design. Instead of a legal solution of ensuring openness and correctness via laws, blockchains strive to create a neutral digital platform by ensuring that no single party is responsible for creating and maintaining the platform. That is, blockchains decentralize the ability to partici- pate in the upkeep of the platform, by which we can achieve credible neutrality. A popular mechanism that blockchains employ to achieve this decentralization is using proof-of-stake protocols: creating a token that anyone can use to participate in the digital work required for the upkeep of the blockchain [1]. One can think of these staking tokens as work tokens, designed specifically for the particular digital task of participating in the operations of running that particular blockchain. Similar to how a taxi medallion is required to drive a taxi in certain cities, these work tokens are required to participate in the digital work associated with the upkeep of the blockchains.
Slashing. A major advantage of proof-of-stake protocols is that if the participating stakers violate the com- mitments required for the digital work, then they can lose their staking tokens using a mechanism called slashing. Slashing ensures that even if all the validators try to collude to break the commitments inherent in running the blockchain, they will lose their staking tokens. This creates a system of Karma: the law of attri- bution and enforcement. Ethereum, again, pioneered this structure of “cryptoeconomic security” [2]. Crypto
- alludes to attributability of the fault to agents using cryptographic methods like signatures, and economic - alludes to loss of economic value associated to stake for agents who commit faults. Cryptoeconomic security is a significant advance in the ability of individual agents to cooperate to perform digital work, thus creating an emergent digital platform which can make credible commitments of neutrality and correctness.
EigenLayer makes ETH as a Universal Objective Work Token. In prior work, we created EigenLayer restaking, a universal mechanism to share the same stake across a variety of different digital tasks, thus making ETH a “universal work token”. While prior staking mechanisms coupled a given type of stake / token with an enshrined set of digital tasks in the platform, restaking enables the same token to participate in a variety of digital tasks including new consensus mechanisms, optimistic rollups, bridges and MEV management solu- tions, which third parties can permissionlessly create and innovate upon. Thus EigenLayer expands the scope of staking ETH from a single enshrined task of participating in consensus to a variety of digital tasks that can be built permissionlessly on top of the common blockchain. However, restaking provides cryptoeconomic security via slashing only for digital tasks whose faults are objectively attributable, i.e., clearly verifiable on- chain. Examples of such onchain attributable faults include: double spending (the same coin should never be spent twice in a payment chain), double signing (there can be no two blocks with the same block index), invalidity (creating a new state of the system which is not correctly transitioned from the previous state given the intervening transactions). Thus we can say that EigenLayer converts ETH into a Universal Objective Work Token.
Limitations of restaking: non-onchain attributable tasks exist. There are many categories of faults that dig- ital workers can commit that do not have objective attribution on chain. For example, let us take the example of a price oracle required onchain, which brings the market price of a digital asset onchain. Price oracles are famously difficult to build slashing protocols for: if a digital worker performing an oracle task reports that 1BTC = 1USD (which is wrong by several orders of magnitude), the blockchain by itself has no locus to verify the correctness or otherwise of this assertion. This is because blockchains are purely deterministic state machines and to preserve the determinism and objectivity these subjective claims are excluded from intrinsic verification in the blockchain. There are other examples of claims that are not verifiable onchain: bridges (claims about the state of a different blockchain on another blockchain), data availability (i.e, verify- ing whether a data item has been published in public), censorship (not incorporating some transactions into a ledger). Another major problem with enforcing slashing onchain is that immutable code for slashing is difficult to get right - if there is any error in the code, then honest nodes may get slashed.
Current state-of-the-art mechanisms to resolve non-onchain attributable frauds. There are two classes of mechanisms that have been proposed for this purpose of non-onchain attributable tasks:
Penalize (i.e., slash) divergent claims of a node relative to the majority of the nodes. However, such a mechanism is subject to the tyranny-of-majority. If the majority of workers are dishonest, then a minority honest agent can be slashed. This is clearly unacceptable.
Utilize an entrenched committee to verify the veracity of a node’s claims and issue slashing authoriza-
tions. The problem with this model is that if the committee is malicious, they can slash honest workers. The crux of the problem here is the tyranny-of-majority (of token holders, or an entrenched committee) and, even more fundamentally, it boils down to the question of: who watches the watchers/committee?
Both scenarios are vulnerable to tyranny-of-majority.
Categorization of Faults in Digital Tasks
We can categorize faults made while performing digital tasks into three categories based on the ability to attribute them: (i) onchain attributable fault, (ii) intersubjectively attributable faults and (iii) non-observable faults.
The first category is objectively attributable faults - which are attributable purely mathematically and hence cryptographically. A clear example is execution validity: if a node runs a piece of code on a deterministic virtual machine, and certifies the input and output, then it can be verified onchain later. A second example of this is double-signing: in a consensus protocol, if a node is not supposed to sign two conflicting blocks but it does, then it can be proven onchain that the node has committed an onchain attributable fault. We furthermore note that the former fault (validity) is proactively attributable - for example, the chain can run a verifier for a ZK proof and ensure the correctness, whereas the latter (double-signing) is only retroactively attributable: you can prove that a node committed the fault *after* it committed the fault but not as soon as you receive a first signature.
The second category is intersubjectively attributable faults: the set of faults which can be attributed with broad agreement by all observant outside observers. This set is a superset of purely onchain attributable faults, since anything that is attributable on chain can also be attributed offchain. We can further subdivide this category of faults into (i) retroactively attributable, which can be attributed at any point in time, vs, (ii) concurrently attributable faults, which need the observer to be online and observing at the time of the fault in order to be at- tributed. Some examples of retroactively observable intersubjective faults: (a) oracle price inputs - if the price input by a oracle node is clearly different from the actual price by a significant margin, all outside observers can come to a consensus on whether the price is correct or not, and whether the oracle should be slashed. (b) objective faults for which it is hard to write slashing conditions - as an example, running a specific instance of an AI / ML code. Some examples of concurrently observable intersubjective faults are: (c) Data availability
- if a data item is published transparently into a peer-to-peer network or not can be attributed by all those observing the peer to peer network, (d) censorship - if a transaction that has been propagated in the peer to peer network has not been included due to a malicious collusion, then it can be intersubjectively attributed.
The fault observability in concurrently attributable faults can be enhanced by reducing the monitoring cost of the observer so many more nodes can observe the faults. We note that this phenomenon is not unique to digital platforms, and in fact, in the breakthrough work [3] on “Governing the Commons” by Elinor Ostrom, winner of the Nobel Memorial Prize in Economics, it is observed that reducing the monitoring cost of viola- tions is a prerequisite to a well-functioning commons.
For example, light nodes can sample portions of the data claimed available using a method called Data Availability Sampling. Light nodes can randomly sample the transactions in the p2p network (rather than monitoring all the transactions) to attribute censored transactions. Another factor that significantly boosts attributability is circumstantial evidence downstream of the digital task manipulation: for example, was an oracle manipulation then used downstream to attack a lending protocol, or if data might have been purposely withheld to pass an invalid claim through a fraud proof, or a oracle transaction censored in order to manip- ulate liquidations etc. In all of these cases, there will be strong social agreement on whether the system was purposely attacked.
The third category of faults is not attributable outside the victim of the fault. For example, consider a secret- sharing system where anyone who wants to store a secret can split the secret into smaller chunks of infor- mation and different nodes store different subsets of the data; and the secret is revealed only after a certain amount of time. In this case, if the nodes collude together to break the privacy and reveal the secret, it is possible for the secret storer to know that his / her secret is revealed but a third party cannot disambiguate between whether the storer is malicious or the system is majority malicious. Since it is not possible to attribute and punish for these faults, it is only possible to avoid these faults by making the validators decentralized and hence collusion resistant.
Fig. 1 illustrates the above categorization of digital tasks.
Figure 1: Categorization of faults in digital tasks.
Core Idea
The main question that we wish to address is whether we can extend cryptoeconomic security to digital tasks on EigenLayer in the context of intersubjective faults. We answer this question in the affirmative by creating EIGEN: the universal intersubjective work token.
Chain forking in Ethereum
Before we get to the description of the protocol on how to get cryptoeconomic security for intersubjectively attributable tasks, we glean some key insights on how we escape the problem of the tyranny of majority in existing protocols like Ethereum. Ethereum has been a leader in recognizing the importance of the layers of social consensus, which surround and moderate the objective consensus mechanisms of the blockchain. Each layer reveals a form of watching the watcher, which is already implicit in Ethereum.
We can easily distinguish two layers of consensus that are integral to the operation of Ethereum:
Chain Validity
which rule for determining the validity of a given chain of blocks is to be used.
whether a given chain of blocks is valid, according to a given validity rule (see [4] for details).
Chain canonicity
which chain of blocks, valid under a given validity rule, constitutes the canonical chain at a given point in time.
While it might seem that a majority of Ethereum validators would have carte-blanche power to completely determine the content of the canonical chain, this is not true. Suppose that the majority of Ethereum validators were to turn malicious and collude in order to sign off on a block that was invalid under the validity rule held to by the overall user community of Ethereum users. This would set in place the following sequence of events:
any validator not a part of the colluding set would reject these blocks as invalid under the current validity rule.
by running full nodes or by listening to the testimony of trusted full node operators, end users would be able to ascertain the basis for the appearance of two forks of the original singular chain.
as one fork of the chain would be in violation of the validity rule uphold by the overall social consensus, members of this community would choose not to interact with this fork, opting instead to follow the chain being maintained by the minority set of validators.
the digital assets of the majority chain would be excluded from any interface between on-chain and off-chain1, their market value would tend to zero.
1Examples are exchanges, real-world shops where crypto is accepted as medium of exchange for physical goods, etc.
Figure 2: A high-level overview on how intersubjective staking in EigenLayer resolves intersubjective faults without overloading ETH’s social consensus.
Thus, on inspection we find that the influence of Ethereum validators ultimately extends only to determining which of any possible set of valid blocks should be added to the canonical chain at each moment in time. In particular, we see that there exists an easily overlooked but powerful social consensus about which protocol the validators ought to be executing (refer to step 3 above where the social consensus decides on which va- lidity rule to upheld). Even if a majority of Ethereum validators were to collude and accept a block that was invalid according to this social consensus, by simply filtering out this now erroneous fork of the chain and paying attention to the validators faithfully executing the preferred protocol of social consensus, end users can neutralize the attempted majority take-over and slash the offending validators (step 5 in the above sce- nario). See fig. 2(a) for an illustration. This is an illustration of how social consensus is protecting Ethereum ecosystem from tyranny-of-majority of the Ethereum’s validator set. Unlike the set of validators staked on the chain, a key observation is that the coverage of social consensus is the set of all possible observers, and is an unsized and potentially infinite set. Even if all the nodes that are running the software agree on a malicious fork, new nodes that come in might detect this problem and choose only to build on the truthful fork. Thus truth becomes a self-enforcing equilibrium, and becomes nearly impossible to takeover by an adversary.
The Two Phases of Intersubjective Agreement
Systems that utilize intersubjective agreement proceed in two phases usually. There is a setup phase, in which the rules of intersubjective agreement are codified, and then there is a second phase, called the execution phase, in which the pre-agreed rules are executed. As a first example, consider the establishment of a modern nation state. The setup phase comprises of codifying a constitution which all later laws must then follow. The execution phase then requires the creation of laws, which must then comply with the constitution. The clearer the constitution is, the easier it is to agree on whether a given law complies with the constitution.
Lets take as a second example, blockchains. The setup phase for blockchains involve specifying the fork- choice rule of the consensus protocol (for example, the longest chain rule specifies that the current block is the tip of the longest chain of blocks). In the execution phase, any node can now identify, based on its
Figure 3: An illustration of setup and execution phase for for different scenarios in government setting and blockchain setting.
observed chain of blocks, which is the current block. Thus, the setup phase requires consensus, and later, the execution phase requires purely local information. This is an example of a powerful intersubjective sys- tem, as there is little ambiguity left to the execution phase. As a more complex example, in a proof-of-stake blockchain, there are two distinct consensus rules possible: (i) light-node-rule: accept any block header signed by 67% of the nodes, or (ii) full-node-rule: accept only blocks that you can download and that are valid and that are signed by 67% of the nodes. It is pre-agreed in the setup phase of the blockchain that the full-node- rule is the real rule, and the light-node-rule is a proxy, so when there is a disagreement between the two rules, nodes already know that they should go with the full-node rule during the execution phase.
As another complex example, consider two distinct kinds of rollups: (a) standard rollup, where the setup phase defines the current block in the chain as the latest valid block written to the bridge contract, and a
(b) sovereign rollup, where the setup phase defines that the current block in the chain is the latest valid block written to the bridge contract, except if it is reverted by social consensus. In the standard rollup case, the execution phase is totally self-evident: each node can find the current block directly without requiring to talk to each other. In the sovereign rollup case, it is required for the nodes to talk to each other in order to know if social consensus has reverted that block or not. The more an intersubjective system makes the execution phase self-verifiable, the stronger the intersubjective cohesion is, i.e., participants will agree on the right version of the world easier. If there is too much coordination required during the execution phase, it is possible for the system to experience intersubjective collapse, i.e., participants disagree on the right version of the world.
Extending the power of social consensus beyond chain validity
Don’t overload Ethereum’s social consensus. Given the benefit of using social consensus of Ethereum to resolve any take-over of Ethereum’s validator set to attack chain validity, an immediate step would be to extend the usage of social consensus beyond chain validity. One example of services that can benefit from using Ethereum’s social consensus to resolve tyranny-of-majority are any tasks which are potentially verifi- able such as oracles or data availability (see sec. 1.2). In such services, fraud can’t be attributed objectively by submitting any fraudproof or ZK proof as part of execution of chain state. However, the fraud is subjec- tively visible from any outisde observer. As a concrete example, if an oracle reported that 1BTC is equal to 1USD, which is far away from the real truth, this fraud is obvious from the outside. A naive solution would require Ethereum validators participate in such services (for example, the validators vote on price feeds as part of block proposal) and assume (super-)majority of Ethereum validators are honest. In case of adversarial take-over of majority of Ethereum validators to break this oracle, the social consensus of Ethereum would just subjectively step in to resolve the tyranny-of-majority of Ethereum validator set. However, the problem is that this overloads the Ethereum’s social consensus layer as any end user would now have to make decision for forking the chain for lot more digital tasks, some of which are more high-risk than others [6]. See fig. 2(b) for an illustration.
Extending the power of social consensus. Our proposal to extend the benefit of social consensus in resolving tyranny-of-majority without overloading Ethereum is as follows:
Restaking: Tap into Ethereum’s social consensus only for resolving objectively attributable faults. Any digital task where fault can be objectively attributed and malicious operators can be penalised programmatically should accept only native ETH or LST as stake on EigenLayer. In such tasks, the
dispute resolution can be programmed within the chain state as a smart contract2 and, thus, correct execution of the dispute resolution is subsumed into chain validity. Therefore, cryptoeconomic security for digital tasks with objectively attributable fault is directly tapping into Ethereum’s social consensus for resolving tyranny-of-majority of operators without overloading.
Intersubjective staking: Tap into EIGEN’s social consensus for resolving intersubjectively attributable faults. The core idea of EIGEN is to recognize that the principle of intersubjectivity can apply at gran- ularities other than that of the chain itself. In particular, EIGEN expands the idea of subjective choice from choosing a fork of chain to choosing a fork of tokens for any potentially verifiable digital task. EIGEN provides a primitive for unconditional slashing of the EIGEN staked by malicious operators on EigenLayer through tapping into the power of EIGEN’s social consensus to canonize the fork of EIGEN token that penalizes the malicious operators without forking the Ethereum chain itself.
EIGEN features its own social consensus for resolving intersubjective faults of potentially verifiable tasks. This responsibility of resolving intersubjective faults is now no longer being imposed on Ethereum’s social con- sensus, thus, not overloading it. Now, AVSs on EigenLayer tap into the ETH quorum for objective faults but tap into EIGEN quorum for intersubjective faults. See fig. 2(c) for an illustration. Now there could be forking in EIGEN for resolving intersubjective faults without requiring forking the chain state of Ethereum itself.
Prior Work. The intellectual precursor to this work is the pioneering work by Vitalik Buterin documented in the Ethereum blog (circa 2014-2015): [7], [8], [9]. To the best of our knowledge, Augur built on these posts and introduced the idea of designing a token that forks at an application layer of Ethereum in the context of prediction markets [10]. In this paper, we build on this core idea to design EIGEN expanding it in several ways: (i) building a universal intersubjective token rather than a solution for a specific problem, (ii) solving how to utilize a forking token in fork-unaware applications, (iii) ensuring that the cost of social consensus is metered and the value distributed to those who partake in it, and finally (iv) designing mechanisms to utilize the intersubjective fork for compensating users against faults of the stakers, rather than only punishing them.
EIGEN unleashes more open innovation. EigenLayer enabled anyone to create new Actively Validated Ser- vices (AVS) that have objective slashing conditions to incorporate security from ETH rather than restricting the amount of security for their AVS to be capped by its own new token, solving a major bootstrapping problem. However, there is a significant limitation that if the AVS had an intersubjective fault, it cannot resort to the cryptoeconomics of ETH but is forced to use its own token because its own native token at least inherits token toxicity (a downward price pressure if a majority of the token stakers act). In our previous work [11], we showed that token toxicity is insufficient under adversarial circumstances to be protective, and slashing is indeed necessary. In this work, we create the first universally intersubjectively slashable system, so that stakers can make a wide range of commitments about the digital work that they perform. This en- ables a wide range of new AVSs to utilize the cryptoeconomics of EIGEN without being capped to their own economic value. We envision a renaissance in the design of new services structured as AVSs utilizing EIGEN cryptoeconomic security, in addition to ETH security. Any Actively Validated Service (AVS) on EigenLayer which has intersubjectively attributable digital faults can now obtain the cryptoeconomic safety guarantee of EIGEN. In order to make the faults intersubjectively attributable, the AVS may need to focus on developing robust monitoring infrastructure including light clients. This can lower the cost-of-monitoring, ensuring that there will be a wide net of community members from EIGEN’s social consensus who will operating the AVS’s light node software for monitoring the EigenLayer operators who are opted into the AVS.
The importance of comprehensiveness of setup phase reflects the need for any AVS that is using intersubjec- tive staking to be very clear on their constitution that they adopt during setup phase. That means specifying, without any ambiguity, under what conditions/scenarios can a staker be considered to be malicious and subjected to intersubjective slashing. For example, if an AVS developer wants to run a rollup VM using intersubjective staking without deploying any dispute resolution contract3 on Ethereum, then the AVS must specify which version of the VM code should any operators opted into the AVS run. More deterministic this VM is, less likely that there will be confusion if there is challenge against operators giving wrong output to the VM execution.
2Any evidence of objective fault can be submitted as a fraudproof or ZK proof to the chain. Here, the assumption is that there is at least one honest participant who will submit this evidence. This submission of evidence will be subjected to Ethereum’s censorship- resistance.
3ZK verifier contract or optimistic challenge contract
Interaction between intersubjective staking and DeFi
Existing PoS protocols
Any PoS protocol features only a limited amount of their native tokens being staked at any given time, while the remaining tokens are utilized for other purposes such as DeFi, or users holding the staking token without deploying it. A similar scenario is expected to happen with EIGEN. In this section, we will try to under- standing how intersubjective (forking) nature of EIGEN makes the interaction bit complex. To understand this interaction, we will understand the interaction in two existing protocols.
We note that in chains like Ethereum, the native ETH token forks along with the chain, so as long as the ETH is deployed into DeFi protocols deployed in the same chain, the protocols always the right version of the ETH. We coin the term intersubjective frame-of-reference, in order to understand from which frame forking is happening. Protocols and (standard) tokens that share chain fork together when the underlying chain forks, so they can be said to inherit the intersubjective frame of reference from the chain. With EIGEN, the token has its own intersubjective frame of reference, so if the token forks, DeFi protocols may not know that it has forked, and will need to handle it with care. This consideration is shown in Fig. 5a.
Solid representation: Isolation barrier between intersubjective staking and DeFi
Interaction between intersubjective staking of EIGEN and using EIGEN of DeFi is complicated. There can be forking of EIGEN but there is no forking of the chain state of Ethereum and, by extension, the rest of the application layer on Ethereum. This leads to a complicated scenario where EIGEN’s social consensus have agreed upon a new canonical fork but the EIGEN which were locked in non-staking applications such as DeFi would be still representing the stale version of EIGEN token from before the fork. In order to solve this problem, we propose creating an isolation chamber between the DeFi usecases of EIGEN and the staking usecases of EIGEN. We term a representation of EIGEN as a solid representation, if that representation can be redeemed for whichever fork of the underlying EIGEN token that the holder desires. See fig. 5a for an illustration.
In order to achieve solid representation for EIGEN, we proposed an intersubjective forking protocol with two tokens: EIGEN and bEIGEN (i.e., backing EIGEN). bEIGEN will be used solely for intersubjective staking and EIGEN will be used for non-staking applications such as DeFi. The forking protocol is designed such that EIGEN is a wrapper over bEIGEN with special clauses on when and how wrapping and unwrapping can be executed which imparts the behavior corresponding to a solid representation. Even if bEIGEN is subjected to intersubjective forking, any EIGEN holder who is using it for non-staking applications doesn’t have to worry as it can redeem the forks of bEIGEN at any time later. For any developer of a non-staking application, as long as their surface area of interaction with the intersubjective forking is limited to only using EIGEN, the application can be agnostic of any intersubjective forking of bEIGEN.
Compensating for the Cost of Intersubjective Consensus
We observe that intersubjective (social) consensus incurs a cost, and if it is not metered properly gives rise to two kinds of problems: (i) if it is free, then it might lead to grieving attacks, where someone tries to abuse social consensus without incuring a cost, and (ii) if the users who participate in social consensus are not correctly compensated, then it might lead to users not participating in it. These two lead to core principles: (i) anyone who tries to fork the token should incur a cost, and (ii) some portion of the cost should be distributed to users who participate in social consensus.
We formalize this by requiring two types of economic costs in the original token bEIGEN1 and the forked token bEIGEN2:
Deflation-per-fork (DPF). DPF represents the minimum fraction of total bEIGEN1 that should be tagged as malicious and slashed while creating the fork bEIGEN2. If bEIGEN2 ends up being considered as the
canonical fork, then each unit of bEIGEN2 would appreciate by 1
1
−DPF
multiplication factor. If the chal-
lenger intersubjective challenge isn’t slashing at least DPF fraction of total bEIGEN1, then that challenge will not be considered legitimate.
Commitment-per-fork (CPF). CPF represents the ratio between total bEIGEN1 that needs to be committed by the challenger for triggering the intersubjective challenge. Here commitment refers to the fact that the challenger will burn CPF fraction of bEIGEN1 so that they cannot access this portion of tokens if the original token bEIGEN1 is continued to be considered the cnaonical fork. The challenger will in return be able to redeem these tokens if bEIGEN2 is the correct version of the fork. An important to note is
Figure 4: Simple illustration of CPF and DPF. Here bEIGEN2 is a fork of bEIGEN1 as a consequence of an intersubjective challenge.
that the challenger has to be convinced of the intersubjective fault that has happened as it is burning its bEIGEN1 holdings and is betting on the value extracted from the bEIGEN2 that it is getting as part of the challenger reward. So, anyone harmed by the intersubjective fault in the AVS has the highest incentive to raise the challenge.
Both the parameters DPF and CPF are enshrined in the setup phase of EIGEN token. Setting the values of DPF
and CPF properly is critical to ensuring the healthy functioning of the system.
Here, DPF pays off the cost for the social consensus to switch from bEIGEN1 to bEIGEN2. This switching cost comes in the form of the need for the social consensus to validate the claim of intersubjective fault, gas cost of redeeming bEIGEN2, gas cost of against staking bEIGEN2, etc. On the other hand, CPF acts as a deterrence against any adversary raising vacuous intersubjective challenge. Even in the case of vacuous intersubjective challenges, anyone participating in the social consensus has to verify the authenticity of the fault before rejecting the challenge, which incurs a cost. CPF serves as a mechansim to pay off for that social cost. See fig. 4 for an illustration.
Setting values for CPF and DPF
CPF pays off for the social cost of malicious fork, acting as a deterrent against an adversary raising vacuous challenges and requiring everyone in the social consensus to verify the authenticity of the challenge and re- ject it. If CPF is set too large then there is a need for large off-chain coordination to pool enough bEIGEN1 for raising the intersubjective challenge. This sets an upper bound on the value of CPF.
On the other hand, DPF pays off the cost for the social consensus to switch from bEIGEN1 to bEIGEN2. This switching cost comes in the form of the need for the social consensus to validate the claim of intersubjective fault, gas cost of redeeming bEIGEN2, gas cost of against staking bEIGEN2, etc. The deflation is created because there is some amount of stake slashed in the forked token. Therefore, if DPF set too high, then it imposes a requirement on the AVS that at least DPF fraction of stake is attributable and slashable when a fault happens on the AVS. This sets an upper bound for DPF.
Overview of protocol for intersubjective staking on EigenLayer
Next, we will give a very high-level explanation for the intersubjective staking on EigenLayer.
Naive Design
We start with a baseline design for the intersubjective protocol that features a single token model. This is described as follows:
Intersubjective staking with EIGEN. Stakers stake the EIGEN for staking into EigenLayer. By staking EIGEN, the staker is opting to respond to digital tasks and subjecting its stake to intersubjective slashing.
Simple illustration of solid representation.
A simplified illustration of V1. Here, bEIGEN2 is fork of bEIGEN1 after the intersubjective challenge is raised.
An simplified illustration of V2. Here, bEIGEN2 and EIGEN2 are corresponding forks of bEIGEN1 and EIGEN1 after the intersubjective challenge is raised.
Figure 5: Overview of the intersubjective forking protocol that is being enabled by EIGEN.
Here, EIGEN is an ERC20 token. The staking contract ensures that withdrawal from staking is subject to a withdrawal lag - this lag is important as it allows a time period for the token to fork before affecting other holders.
Intersubjective forking and intersubjective slashing. In order to raise a challenge against an intersub- jectively attributable fault, the challenger must burn some amount of EIGEN and intersubjectively fork EIGEN. Intersubjectively forking the EIGEN requires the challenger to deploy: (a) a new ERC20 contract that represents a new fork of EIGEN (recall that the existing EIGEN was also an ERC20 contract) and, (b) a fork distributor (FD) smart contract that specifies how stakers and other holders of existing EIGEN can redeem tokens from this new ERC20 contract. We call this new ERC20 contract as a fork of EIGEN. This FD should allow stakers delegated to honest operators and the challenger to claim token from this new fork of EIGEN whereas stakers delegated to malicious operators should not be able to redeem tokens from the new fork. For simplicity of explanation, we call the tokens from pre-forked EIGEN as EIGEN1 and post-forked EIGEN as EIGEN2.
Redemption mechanism. The FD also specifies how a non-staked holder can redeem the fork. Any holder of EIGEN1 is able to redeem EIGEN2 by locking their EIGEN1 in the FD of EIGEN2 for a period of Tlock slots. This redemption is permitted for a period of Tredeem slots after the attack has happened. Note that here it is necessary to have Tlock > Tredeem in order to avoid the issue of double redemption4.
By including the details on who is not able to redeem EIGEN2 tokens, the challenger is effectively slashing certain existing stakers who had staked EIGEN1. This slashing is intersubjective in nature as others might not agree with the challenger and can ignore the EIGEN2. In such a case, EIGEN1 will continue to be held as the canonical fork of EIGEN by the social consensus. Therefore, we call such a slashing as intersubjective slashing. Ideally, the challenger should deploy the EIGEN2 and its FD after deliberation with rest of social consensus.
Lack of ”Solid representation”. The baseline design lacks ”solid representation”. If an EIGEN1 holder is not active for the period of Tredeem slots after the malicious attack was executed by operators, then the holder will never be able to redeem EIGEN2. Therefor, the baseline design doesn’t offer solid representation. In the next few sections, we will give a high-level outline an intersubjective forking protocol that will progressively achieve this property. We also want the intersubjective protocol to be resilient against malicious behavior of the security council5 of the staking contract.
V1: Two-token model for the intersubjective staking protocol
The protocol has two separate tokens but with different functionalities: bEIGEN and EIGEN. The bEIGEN is used for staking and the EIGEN is used for non-staking applications. The EIGEN contract is a wrapper on top of bEIGEN.
Any challenge against an intersubjective fault requires submission of challenge bond along with the forking of bEIGEN and its associated FD contract (see sec. A.1.2 for details).
The governance of EIGEN contract makes decisions on which fork of bEIGEN should the EIGEN wrapper configure to and then pushes for an upgrade which is subjected to a governance lag (see sec. A.1.3 for details).
Anyone can instantly wrap bEIGEN to get EIGEN and instantly unwrap from EIGEN to bEIGEN. Unwrap- ping will return the current fork of bEIGEN that the EIGEN wrapper is configured to. As for wrapping, the EIGEN wrapper contract will only accept the current fork of bEIGEN that the wrapper is configured to (see sec. A.1.3 for details).
Any withdrawal from staking bEIGEN is subjected to a withdrawal lag. Withdrawal can be done directly from the staking contract or via the UI (see sec. A.1.1 for details).
For any new legitimate fork of bEIGEN, there is a limited redemption period for redeeming tokens belonging to the new fork of bEIGEN. To redeem post-forked bEIGEN, the holder of pre-forked bEIGEN
4By ”double redemption”, we mean that for the same 1 unit of EIGEN1 token, the holder or staker shouldn’t be able to redeem more than 1 unit of EIGEN2 token.
5We partition the governance of the staking contract into two parts: (1) governance for regular contract upgrades for adding new
features and will have lags in place for these upgrades, (2) security council for triggering emergency upgrades or pausing. Clearly, the security council has a lot of power.
has to lock its tokens for a limited period (see sec. A.1.4 for details). The EIGEN holders can be passive if it agrees with the decision of EIGEN governance. However, if it doesn’t, then the holder has time to unwrap to bEIGEN during the governance lag period (see sec. A.1.5 for details).
See fig. 5b for a high-level illustration.
V1 makes the following assumptions:
Governance of EIGEN wrapping contract is honest, or, EIGEN holders are engaged in non-staking activi- ties have not locked their token for more than a certain period.
Security council governing EIGEN staking contract is honest.
If the governance of staking contract is honest, then EIGEN will always point to the right version of bEIGEN. However, if the governance is not honest, and the EIGEN wrapper’s governance decides to reconfigure to a new fork of bEIGEN which EIGEN holder disagrees with, then this EIGEN holder can unwrap to their bEIGEN and then redeem the correct fork. However, if they are locked for more than the redemption period, then they will not have this ability to redeem the right fork, even when governance is dishonest.
If the security council governing the staking contract is malicious, then they can take the staked amounts and convert them without imposing a temporal lag. The core reason for this problem is that the temporal lag is enforced by the staking contract rather than being enforced unconditionally.
See lemma 1 for further details. With some additional upgrade in V2 as described in next section, we achieve solid representation.
V2: Getting solid representation
The wrapper contract EIGEN is now immutable contract. This immutability requires that the wrapper EIGEN contract can now also be forked socially. A legitimate intersubjective challenge now requires forking EIGEN which is in addition of forking bEIGEN and launching FD contract. See sec. A.2.2 for details.
A legitimate intersubjective challenge against an intersubjectively attributable fault must also stop fur- ther wrapping in the canonical pre-forked EIGEN to pre-forked bEIGEN. See sec. A.2.1 for details.
An additional redemption clause is added to get solid representation. Suppose a pre-fork EIGEN holder has unwrapped to pre-forked bEIGEN after the redemption period of post-forked bEIGEN is over. This unwrapping action is recorded in the storage of the pre-forked EIGEN contract. Now, this user can just submit the proof of this unwrapping to be able to redeem post-forked EIGEN. See sec. A.2.3 for details.
See fig. 5c for a high-level illustration.
V3: Making intersubjective staking protocol resilient to corruption of security council
To make the protocol resilient to an attack by the security council governing the staking contracts, we can add a separate lag via an immutable gateway contract.
In addition to the features in V3, following are the additional features:
All staking and withdrawal is done by a governance-free gateway contract. Only the accounting is done in the staking contract. The withdrawal lag is now imposed by the gateway contract and anyone can raise a challenge that stops withdrawal if there is a malicious withdrawal by the security council of staking contract’s governance.
For further details on the full description of V3, please refer to Appendix. A.3.
Summary
Following table summarizes the differences between different protocols:
Solid representation
Resilient against a malicious security council?
V1
No
No
V2
Yes
No
V3
Yes
Yes
Intersubjective Staking for Actively Validated Services
EigenLayer enables services beyond consensus to inherit security from a shared security system, which com- prises of a pool of stake as well as operators, who are equipped to run various software. These services are called as actively validated servies (AVSs) and there is a wide variety of AVSs including new chains, data availability (DA) layers, oracles, verifier-as-a-service, fast-finality-layer, and coprocessors.
In this section, we talk about how EigenLayer can be used to share security across AVSs using intersubjective staking. When an intersubjective token such as bEIGEN is staked, in the event of fork in bEIGEN, the AVS has to decide whether it wants to accept the new fork of bEIGEN or not. This leads to a new complexity that was not present when staking objective tokens like ETH and other ERC20 tokens in EigenLayer.
In the next section, we consider the case when there is only one AVS using bEIGEN for intersubjective staking and describe how this AVS handles forking of bEIGEN. For the purpose of explanation, we represent the canonical bEIGEN before the intersubjective challenge as bEIGEN1 and the new fork of bEIGEN arising out of the challenge as bEIGEN2.
Single AVS with Intersubjective Staking
Figure 6: An illustration of how AVSs would handle intersubjective forking,
Consider a single AVS that is built on top of intersubjective staking of bEIGEN. We note that in the two-token system explained earlier, bEIGEN is the staking token, which needs to be fork-aware and EIGEN is the fork- unaware token which can be used in non-staking applications. Let us consider the initial case where bEIGEN1 is staked into a single AVS and no other AVSs are present.
Suppose that some of the stakers are attributed to have participated in an intersubjective fault in the AVS. This results in bEIGEN1 being subjected to an intersubjective challenge, and a new fork bEIGEN2. The governance of the AVS now needs to make a decision on whether to accept bEIGEN2 for intersubjective staking or not and to enact that policy at the smart-contract-level. At any point in time, it is natural for the AVS governance to accept only one fork of the bEIGEN depending on whether the forked token is correct or the original one is correct.
Assume that the governance of the AVS agrees with the intersubjective challenge and the forking. See fig. 6 for a timing diagram. In order to ensure that the stakers have enough time to redeem bEIGEN2 and opt into the AVS with the new bEIGEN2 quorum, there is a need for governance lag before the AVS starts accepting bEIGEN2. Furthermore, the lag before opting into a fork ensures that AVS users who do not agree with the fork can gracefully move on to a different AVS that actually accepts the correct fork. Therefore, the AVS governance must make an announcement that after Tredeem slots since the attack was executed:
After Tredeem slots from the attack, the AVS will accept only bEIGEN2 stake (instead of bEIGEN1).
The governance will have to queue a governance upgrade for this decision soon after the intersubjective challenge of bEIGEN is finalized on Ethereum and this upgrade will be executed at Tredeem slots from when the attack was executed. During the interval of Tredeem slots since the attack happened, any bEIGEN1 staker who agrees with the intersubjective challenge will be able to redeem bEIGEN2 from its associated FD and then again stake with EigenLayer and opt into the AVS. On the other hand, those bEIGEN1 stakers who don’t agree with the AVS governance’s decision would be able to simply opt out of the AVS.
In the intervening period, bEIGEN1 stakers are still responsible for runnning the AVS. This is important, because, in case the challenge is malicious and the AVS governance is malicious, the AVS users are still protected by bEIGEN1 staking. On the other hand, if the challenge and the AVS governance are correct, then the bEIGEN1 stakers may engage in continued malicious behavior. Therefore, when performing a cryptoeconomic analysis, it is important to ensure that the penalty incurred by the bEIGEN1 stakers is greater than the harm that they can inflict throughout this Tredeem period.
Cryptoeconomic Analysis of Intersubjective Staking
In this section, we will analyze the cryptoeconomic guarantees of the intersubjective staking continuing on the single AVS case.
Pooled security for Single AVS
In the case of when there is only a single AVS using the EIGEN quorum, profit-from-corruption is computed by evaluating the total cost that all the consumers on top of the AVS will incur in a period of length Tredeem slots if the malicious operators attack. We note that this is because, the AVS is allowed to switch to a different quorum only after the Tredeem period, which is important to ensure AVS users are protected in case of a malicious challenge (see sec.3.1 for details). In case that the challenge is correct, though, the malicious operator with bEIGEN1 stake can continue to attack the AVS during this period.
Therefore, for the AVS to be considered to be cryptoeconomically secure, it is essential that:
Cost-of-corrupting the AVS ≥ Profit-from-corrupting the AVS in any interval of length Tredeem slots (1)
3
The cost of corrupting the AVS is measured by the amount of stake that is slashable. For any AVS, it is possible to calculate the fraction of stake that is attributable as malicious if there was any safety violation in the AVS. We call this parameter Fraction-slashable-for-AVS, emphasizing that this parameter depends on the structure of the AVS. For example, for a standard BFT consensus protocol with quorum threshold 2 , the
3
Fraction-slashable-for-AVS is 1 [12].
Cost-of-corrupting the AVS = Stake slashable for AVS safety failure (2)
= Fraction-slashable-for-AVS × Amount-staked (3)
Recall that cost-of-corruption is defined as the cost incurred by any adversary to attack a system. From the definition of DPF, it is evident that the adversarial stake can be slashed in an AVS only if at least DPF fraction of total bEIGEN1 has behaved maliciously in the AVS. Therefore, we must have
Fraction-slashable-for-AVS × Amount-staked ≥ DPF × Value(bEIGEN1), (4)
⇐⇒ Fraction-slashable-for-AVS × Fraction-staked ≥ DPF. (5)
Satisfying this condition will ensure that a ”socially” legitimate intersubjective challenge can be raised to slash adversarial bEIGEN1 stake via intersubjective forking.
Attributable Security for Single AVS
An important caveat for pooled security is that it is not possible for the EigenLayer protocol to know the profit-from-corruption for the AVS. So, there is no in-protocol guarantee whether the security invariant in eq. 1 is being satisfied or not. Moreover, assuming eq. 1 is satisfied, even if the malicious operators’s stake is slashed in the event of attack, there is no redistribution to the harmed parties: AVS and consumers of AVS. An important primitive that we want to achieve is
Strong Cryptoeconomic Security
Any honest users should be appropriately compensated in the event that the AVS stakers behave maliciously.
We call this guarantee as strong cryptoeconomic security and design a mechanism to actually satisfy this prop- erty. This notion was introduced in [13] and analysed for a single proof of stake system. Here we extend it to intersubjective staking for a single AVS and in later sections to multiple AVSs.
Consider that there is a legitimate intersubjective forking from bEIGEN1 to bEIGEN2. See fig. 7 for an il- lustration. In the pooled security model, all of the adversarial stake is slashed and burnt. Instead, in the attributable security mechansism, only a fraction of the adversarial stake is burnt by the FD of bEIGEN2 (that is, remains non-redeemable under bEIGEN2’s redemption mechanism). The remaining adversarial stake is instead redistributed to the harmed AVS. In the general case where there are multiple AVSs, a mechanism is needed to apportion the redistribution across the various AVSs. However, in the case of a single AVS, all of the redistributed funds will obviously go to that AVS.
Even though redistribution is the key property we seek here, the mechanism ensures that there is a portion of adversarial stake that is burnt during the fork. This is necessary for mitigating any grieving attack, where an adversary represents all the malcious stake but also holds redistribution claims for the AVS, thus making sure it does not suffer any loss. This strategy becomes unprofitable with the burning mechansism as a portion of the stake is burnt and not returned to the redistribution. Furthermore, a portion of the stake has to be burnt in order to satisfy the deflation conditoin for the fork, to pay off for the social cost of forking.
DPF × value(bEIGEN1) ≤ γburn × Stake-slashable. (6)
⇐⇒ DPF ≤ γburn × Fraction-slashable-for-AVS × Fraction-staked (7)
When slashing happens, out of the amount slashed, γburn is burnt and γ = 1 − γburn is redistributed to the AVS. Therefore
Attributable-security = γ × Stake slashable for an AVS safety fault (8)
= γ × Fraction-slashable-for-AVS × Amount-staked (9)
For the system to be strongly cryptoeconomically secure, we need the attributable security to be greater than the harm that any user of the AVS can suffer during the entire Tredeem period. This is because, switching from one fork of bEIGEN to the other incurs a delay of Tredeem, and the adversarial stake can cause harm throughput this Tredeem period. We need for strong cryptoeconomic security,
Attributable-security ≥ Harm-from-corruption for AVS in Tredeem period. (10)
Example 1: As a simple example, consider a fast bridge AVS for a rollup, which has a (X, T)-rate-limit, i.e., that it does not allow more than X total transaction value in any T period. Now if the bridge had (X, Tredeem) as the rate-limit, then we know that the total value transacted by the bridge is less than X during any attack
period, and therefore the harm from corruption for the Tredeem period is less than or equal to X. If the attributable security is greater than X then this AVS works correctly. For this example, then we have the following condition for strong cryptoeconommic safety.
γ × Fraction-slashable-for-AVS × Amount-staked ≥ X. (11)
Example 2: Consider an oracle for price feed that requires any operator participating in the oracle to re- spond with the price feed at every fixed time. These operators are required to stake bEIGEN1 in order to participate in the oracle (we assumed that the pre-forked bEIGEN is called as bEIGEN1 and post-forked bEIGEN is called as bEIGEN2). In the event that operators behave maliciously that impacts the price-feed from the oracle, then bEIGEN1 will be intersubjectively forked to bEIGEN2. Under attributable security, the oracle must beforehand evaluate the profit that any malicious operators can extract by corrupting the price feed over the next period of length Tredeem slots (here the oracle is designed to not pause when a challenge is raised but instead continues to use bEIGEN1 as the stake until the redemption period of bEIGEN2 is over). The adversary will extract this profit from the Dapps or co-processors who might utilize this corrupted price feed. The oracle has to purchase attributable security equal to this profit every Tredeem slots (assuming this is less than γ × Value of total number of bEIGEN1 staked). The oracle must utilize some form of circuit breakers to ensure that, over the course of a period of Tredeem slots, the Dapps and co-processors who are sourcing their on-chain price feed from this oracle can be harmed at max the attributable security that it purchased. This ensures all
users of the oracle are compensated for the harm that has been caused to them due to the attack.
Multiple AVS Case: Synchronized Quorum Forking
One of the core features of EigenLayer is to have same stake to be used for multiple AVSs which enables capital efficiency, while ensuring that the cost-of-corruption in EigenLayer remains greater than the profit- from-corruption. We want to have the similar feature for intersubjective staking.
Figure 7: Assume that there are 7 stakers with equal stake of bEIGEN1 who are opted into the AVS and self- delegated to themselves. Consider that stakers 2, 3, 4, 6 participated in an attack that successfully corrupted the AVS. Here, γburn represents the fraction of total stake delegated to an operator that is earmarked for burning if the operator gets slashed. γ represents the fraction of total stake delegated to the operator that is earmarked to be claimable by the AVS in the event of the operator gets slashed in any intersubjective fault of the AVS.
Consider that there are multiple AVSs who are using bEIGEN1 as their quorum for resolving intersubjective faults in their AVS. Suppose that bEIGEN1 is subjected to an intersubjective challenge for a fault in one of the AVS, say AVSk, which results in a new fork bEIGEN2. Consider any other AVS AVSj. If the governance of AVSj agrees with both the intersubjective challenge in the context of a fault in AVSk and with the fork, then the AVSj governance must make an announcement that:
After Tredeem slots from the attack, the AVS will accept only bEIGEN2 stake (instead of bEIGEN1).
This governnace upgrade for this should be queued as soon as the transaction for the intersubjective challenge is finalized. The interesting thing with this policy is that all of the AVS switches to the new quorum at the same time, which is Tredeem time slots after the attack.
There are lots of complex timing games, where an attacker may attack an AVS and then, while that AVS is transitioning to a forked quorum (within the Tredeem period), attack a different AVS. We need to make sure that both in the pooled security and attributable security case, this effect is accounted for.
In the next section, we will analyze the pooled security of intersubjective staking under multiple AVSs. There is a general case of where some stakers are opted into some AVSs. But, for the simplicity of explanation, here we only consider Full Staking: every operator in the bEIGEN1 quorum is opted into every AVS. The set of AVSs who are considered to be part of full staking are assumed to be whitelisted by the EigenDAO. We leave the analysis for the general setting for future research.
Pooled Security for multiple AVSs under Full Staking
We take a very conservative action that if an EigenLayer operator who has in the bEIGEN1 quorum behaves maliciously in an intersubjective fault in one AVS, then the bEIGEN1 stake of that operator is completely slashed and burnt.
Cost-of-corruption-for-AVSi = Fraction-slashable-for-AVSi × Amount-staked (12) To attack the system, the attacker needs to attack at least one AVS. Thus a simple bound says,
i
Cost-of-system-corruption = {min Fraction-slashable-for-AVS } × Amount-staked (13)
i
Hence the system is cryptoeconomically safe as long as the following security invariant is guaranteed:
Cost-of-system-corruption
≥ ∑ Profit-from-corrupting AVSi in an interval of length Tredeem slots. (14)
i∈A
We note that we need to make sure that the amount slashed and burnt satisfies the DPF constraints for forking, i.e., the amount burnt should be greater than a DPF fraction.
Figure 8: Assume that there 5 AVSs in perfect staking and there are 7 stakers with equal stake of bEIGEN1. With perfect staking, all the 7 stakers are opted into all the 5 AVSs who are using the EIGEN quorum for resolving intersubjective faults. Here, γburn represents the fraction of total stake delegated to an operator that is earmarked for burning of the operator gets slashed. γi represents the fraction of total stake delegated to the operator that is earmarked to be claimable by the AVSi in the event of the operator gets slashed in any intersubjective fault across any of the AVSs enlisted in perfect staking.
i
DPF × value(bEIGEN1) ≤ γburn × min Stake-slashable-for-AVS . (15)
i
i
⇐⇒ DPF ≤ γburn × {min Fraction-slashable-for-AVS } × Fraction-staked (16)
i
Attributable Security for Multiple AVSs under Full Restaking
Because there are multiple AVSs, when slashing happens, we need a mechanism to know how to redis- tribute/allocate the slashed fund across the different AVS. One example mechanism to provide attributable security to an AVS is to make it proportional to the security fees paid by a given AVS over a past epoch period. The security fees paid by AVSs to stakers and operators over an epoch period is observable on-chain and so the attribute security held by the AVS is on-chain observable and computable. This is just one ex- ample of implementing attributable security for intersubjective staking but there can be other examples for allocating attributable security.
We will now argue that it is insufficient to only compensate the AVS that got attacked. If the protocol does that, it is possible for an attacker to attack AVS1, and then wait for a fork of the token to be created with redis- tribution only to AVS1, and then switch to attacking AVS2, etc. This leads to complex timing races between the attacker and the challenger. We will now propose a simple mechanism that does not have this timing race.
Redistribution mechanism: As was in single AVS scenario, attributable security under multiple AVS requires that whenever any operator in slashed, γburn fraction of the stake held by the operator will be always burnt. The remaining γ fraction of slashed stake is allocated across all the AVS. The fraction of this redistribution allocated to an AVS can be determined based on different mechanisms, but for concreteness, we consider the simple allocating the funds proporitional to the security fee paid by the AVS.
Now, we can proceed to calculate how to make the system strongly cryptoeconomically secure. First we note that the amount of stake slashed.
i
Amount-slashed ≥ min{Fraction-slashable-for-AVS } × Amount-staked. (17)
i
Out of the amount slashed, γ is redistributed and out of that, AVSi gets a fraction θi of the redistribution (where θi is the proportional fraction of fees paid by the AVS in the particular mechanism).
i
Attributale-security-for-AVSi = γ × θi × min{Fraction-slashable-for-AVSi } × Amount-staked. (18)
Strong Cryptoeconomic Security under Multiple AVS
If AVSi ensures that the total harm from corruption during the Tredeem period is smaller than the attributable security, then AVSi is strongly cryptoeconomically secure.
Attributale-security-for-AVSi = γ × θi × min{Fraction-slashable-for-AVSi } × Amount-staked.
i
(19)
See fig. 8 for an illustration.
Risks & Mitigations
Risk Landscape
As we have seen in sec. 4, intersubjective slashing opens the door toward building cryptoeconomically secured AVSs that deviate from this pattern, enforcing conditions whose verification may depend on information that is external to the blockchain history or temporal in nature. In this section we will consider some of the risks related to ways in which such a system might break down, and the mitigations of these risks.
Intersubjective cohesion. An important requirement for social consensus to be able to resolve intersubjective faults for potentially verifiable digital tasks is: all honest members of social consensus should be in cohe- sion about what is the correct fork of bEIGEN after an intersubjective challenge is triggered. This is called as intersubjective cohesion. See fig. 9a for an illustration. AVSs which rely on intersubjective slashing must focus on making sure that a large body of users in social consensus of EIGEN has direct (first-hand) access to evidence about whether the validators of an AVS have behaved correctly or not. Users not having direct evidence can rely on indirect (second-hand) evidence and their own trust relationships to determine their own evaluation concerning the status of any slashing event. For instance, in a Data Availability AVS, users running light nodes will directly observe the AVS validators to ensure that they are properly serving data; for an oracle AVS, using running the light nodes will make observations of the source and observations of price attestations made in the chain and check whether the two are consistent.
(a) Intersubjective cohesion. (b) Intersubjective collapse.
Figure 9: Cohesion vs. Collapse.
Intersubjective collapse. If an AVS doesn’t carefully design its light node architecture for users to utilize for resolving intersubjective faults, it presents the risk of a collapse in the social consensus. Here, collapse comes in the form of disagreement among the honest users of social consensus on whether the fault has happened or not and whether it can be properly attributed. We term such a scenario as intersubjective collapse. See fig. 9b for an illustration. Such a collapse can happen either by accident or by artifice:
Edge cases: Consider an oracle AVS which specifies that slashing happens when the price feed is
incorrect. Intersubjective collapse can arise if it is difficult to decide if the price feed is slightly incorrect or approximately correct.
Corruption of Information Sources. By making use of security vulnerabilities of world information sources, operators, or intermediate internet infrastructure, an adversary may be able to feed disparate observations to sow confusion in the social consensus.
Light node monitoring attacks. If an AVS relies on light node monitoring to detect concurrently at- tributable faults, it is possible for intersubjective collapse when different nodes have different observa- tions.
Mitigations
There is no one-size fits all approach for mitigating the risk of intersubjective collapse intrinsic to an inter- subjective staking ecosystem. Rather, protocol developers need to be disciplined about considering how to insulate their protocols from common sources of breakdown in intersubjectivity. A key general pattern is that, the Setup phase of the AVS intersubjective staking should be made comprehensive, so that the execution phase can be made as self-serve as possible. A comprehensive setup phase specifies what happens during all imaginable observations accounting for imperfections in the intersubjective process.
We give some examples here.
Edge Cases: As an example, an oracle AVS prespecifies that stakers will only be slashed if the price deviates more than 1% but may or may not be slashed if the price deviates between 1% and 5%, this creates a buffer zone where social consensus can make decisions gracefully.
Information Source Contamination: By pre-agreeing on which information sources are used, and hav- ing routine monitoring of these information sources by light nodes, it is possible to minimize confusion due to equivocation by these sources, as such equivocation is more widely observed.
Circumstantial Evidence: One way to boost detectability of malicious behavior, is it observe down- stream consequences of the said behavior. For example, if an oracle manipulation is used to steal funds from a defi protocol, this may leave additional traces that can help in arriving at a common view of whether this is an attack or not.
No harm done
The core principle in the design of the intersubjective system should be that, no honest participant should lose funds. Thus, similar to the principle in jurisprudence, a staker should be slashed only if their action is malicious beyond reasonable doubt. In cases where the AVS software is misbehaving rather the stakers are misbehaving, the risk is shifted to the AVS (users) and stakers will not be slashed for honestly running bad software.
A World With Intersubjective Staking
Relationship between Intersubjective Staking and Restaking
Intersubjective staking and objective staking can each fill complementary roles within a staking system such as EigenLayer.
Many mature AVS protocols consist of both safety properties that can be secured via objective slashing and liveness or censorship-resistance properties that would previously depend on majority-assumptions which rest on stake decentralization. As discussed above, for such protocols, there are often strong advantages in moving to an intersubjective, cryptoeconomic security model for those types of faults. Intersubjective staking can also be used to support digital tasks which could in principle be secured via objective fraud proofs, but where doing so would involve a large amount of technical complexity and associated risk. For a service that uses objective staking for safety and intersubjective staking for liveness, fees can be split between the two quorums. Furthermore, for core services provided to the Ethereum ecosystem, we envision many services that will use dual staking between ETH and EIGEN, where the native restaking absorbs the decentralization and operator alignment that comes with ETH restaking, and the EIGEN staking can actually support cryptoe- conomic slashing.
We can also understand the relationship between intersubjective and objective staking along the axes of security and rate of innovation, as illustrated in the following fig. 10. In particular, in envisioning the lifecycle
Figure 10: An illsutration of innovation-vs-security tradeoff and how a service can progress towards ”poten- tial enshrinement”.
of a new AVS, we can identify a progression that leverages intersubjective staking for security early in the bootstrapping phase of the protocol and transitions to objective staking or even native protocol adoption as the protocol matures and ossifies.
Intersubjective staking for fast innovation. Early in the lifecycle of an AVS, intersubjective staking can be used in order to launch the AVS protocol and prove product-market fit without assuming the cost/risk associated with developing and deploying fraud proofs on an accelerated schedule. Many existing projects, such as Optimism, have illustrated the need for such a phase. Intersubjective staking could allow projects in such stages to proceed with bonafide cryptoeconomic security.
Objective staking for higher economic security. The economic security affordable by intersubjective staking tops out at the total EIGEN market cap. AVSs which require even greater amounts of cryptoeco- nomic security may find it necessary to provision their protocols with fraud proofs in order to support objective staking and access the higher amounts of cryptoeconomic security available from Ethereum.
Protocol integration for unconditional security. AVSs which support credibly neutral capabilities and whose implementations have matured to a highly ossified and stable state may be eligible for an even higher level of security via adoption by the Ethereum protocol itself. This extends unconditionality, not just to slashing but to the correctness of the operation of the protocol. Obviously, this comes with added complexity to the consensus protocol of Ethereum as Ethereum validators now have to additional tasks.
Fig.11 illustrates the scenario when ETH restaking should be utilized and when EIGEN staking should be utilized. For all objectively attributable faults that want higher economic security from ETH market cap, should use ETH restaking. On the other hand, intersubjective staking via EIGEN should be utilized for resolving intersubjectively attributable faults. In applications serving the Ethreum ecosystem, it is highly beneficial to use ETH restaking (where existing Ethereum operators run additional software) and EIGEN staking in combination. In this model, the former serves as a mechanism to obtain majority trust from the Ethereum participants and the latter serves as a mechanism to obtain economic security, and the system together absorbs the better of the two safety models, even if liveness requires both quorums separately. For example, an oracle built in this model can be thought of as a half-way house between the enshrined oracle model proposed by Justin Drake [14] and the cryptoeconomic oracle model proposed in [10] and [15].
Examples
