IOSG Ventures: A look at EigenLayer's latest progress and use cases in the "re-pledge" field
Original Author: Jiawei, IOSG Ventures
Source: EigenLayer
Last November, we introduced EigenLayer in the article "EigenLayer: Bringing Ethereum-level Trust to Middleware". In the past year, EigenLayer has released their whitepaper, completed a $50 million Series A funding round, and launched the first phase of their mainnet. During this time, the Ethereum community has engaged in extensive discussions around EigenLayer and its use cases. This article will track and summarize these discussions.
Background
In the Ethereum ecosystem, certain middleware services (such as oracles) do not rely solely on on-chain logic and therefore cannot directly leverage Ethereum's consensus and security. Instead, they need to bootstrap a trust network. The typical approach is for the project to be operated by the team initially and then introduce token incentives to attract participants, gradually achieving decentralization.
This approach faces at least two challenges. First, introducing incentive mechanisms adds additional costs: the opportunity cost for participants to purchase tokens for staking, as well as the operational costs for the project to maintain the token's value. Second, even if the above-mentioned costs are incurred and a decentralized network is built, the security and sustainability of the network remain unknown. These two points are particularly challenging for early-stage projects.
EigenLayer's idea is to enable existing Ethereum stakers to restake and provide economic security for these middleware services (Actively Validated Services, AVS). If these restakers work honestly, they will be rewarded, but malicious behavior will result in the forfeiture of the original Ethereum staking.
The benefits of doing this are as follows: Firstly, the project does not need to establish its own trust network, but instead outsources it to Ethereum verifiers, thus minimizing the cost. Secondly, the economic security of the Ethereum verifiers is very strong, ensuring a certain level of security. From the perspective of Ethereum stakers, staking provides them with additional income, as long as there are no malicious intentions, the overall risk is controllable.
Sreeram, the founder of EigenLayer, mentioned three use cases and trust models of EigenLayer on Twitter and podcasts:
Economic trust. The reuse of Ethereum staking exposure means stronger economic security for higher-value tokens, as discussed above.
Decentralized trust. Malicious behavior in some services (such as secret sharing) may not be attributable and cannot rely on forfeiture mechanisms. There is a need for a sufficiently decentralized and independent group to do something, in order to prevent collusion and conspiracy risks.
Ethereum verifier commitment. Block producers pledge their exposure to make certain trustworthy commitments. We will list some examples in the following text to further illustrate.
System Participants
Source: IOSG Ventures
EigenLayer is the main participant that connects the three parties in an open market.
Stakers. If they have Ethereum staking exposure, they can participate in re-staking by transferring their withdrawal vouchers to EigenLayer, or simply by depositing stETH or other LST tokens. If a staker cannot run an AVS node themselves, they can delegate their exposure to an operator.
Operator. Operators accept the delegation of stakers and run AVS nodes. They can freely choose which AVSs to serve. Once providing services to AVSs, they need to accept the forfeiture rules defined by them.
AVS. As the demand side/consumer, AVSs need to pay stakers and obtain the economic security they provide.
After understanding these basic concepts, let's take a look at the specific use cases of EigenLayer.
EigenDA
EigenDA is the flagship product launched by EigenLayer, and the solution is derived from the Ethereum scaling solution Danksharding. The data availability sampling (DAS) used in Celestia, Avail, and other DA projects is also widely applied. In this chapter, we will quickly introduce DAS and then look at the implementation and innovations of EigenDA.
DAS
Source: Dankrad Feist
As a precursor to Danksharding, EIP-4844 introduces "Blob-carrying Transaction," where each transaction carries an additional 125 kb of data. In the context of data sharding and scaling, the added data undoubtedly increases the burden on nodes. So, is there a way for nodes to download only a small portion of the data and still verify that all data is available?
The DAS approach is to have nodes perform multiple random samplings on a small portion of the data. Each successful sampling increases the node's confidence in the data's availability. Once a certain preset level is reached, the data is considered available. However, attackers can still hide a small portion of the data, so we need some fault tolerance mechanism.
DAS uses Erasure Coding. The main idea of erasure coding is to divide the data into multiple chunks, encode these chunks, and generate additional redundancy chunks. These redundancy chunks contain partial information of the original data chunks, allowing the recovery of lost data chunks when some chunks are lost or damaged. In this way, erasure coding provides redundancy and reliability for DAS.
In addition, we need to verify if the obtained redundancy chunks are correctly encoded because using incorrect redundancy chunks will prevent the reconstruction of the original data. Danksharding uses KZG (Kate-Zaverucha-Goldberg) commitments for this purpose. KZG commitments are a method for verifying polynomials, proving that the value of a polynomial at specific positions matches the specified values.
The prover chooses a polynomial p(x) and uses p(x) to compute commitments for each data block, called C 1, C 2, ..., Cm. The prover publishes the commitments together with the data blocks. To verify the encoding, the verifier can randomly sample t points x 1, x 2, ..., xt and ask the prover to open the commitments at these points: p(x 1), p(x 2), ..., p(xt). Using Lagrange interpolation, the verifier can reconstruct the polynomial p(x) from these t points. The verifier can now compute new commitments C 1', C 2', ..., Cm' using the reconstructed polynomial p(x) and the data blocks, and verify if they match the published commitments C 1, C 2, ..., Cm.
In short, with KZG commitments, the verifier only needs a small subset of points to verify the correctness of the entire encoding. This gives us a complete DAS.
How
Source: EigenLayer
EigenLayer borrows the idea from DAS and applies it to EigenDA.
1. First, nodes in EigenDA re-stake and register in the EigenLayer contract.
2. Next, the Sequencer takes the data, splits it into multiple blocks, generates redundant blocks using erasure codes, and computes KZG commitments for each data block. The Sequencer publishes the KZG commitments one by one to the EigenDA contract as witness.
3. Then, the Sequencer distributes the data blocks along with their KZG commitments to the EigenDA nodes. Upon receiving the KZG commitments, the nodes compare them with the KZG commitments on the EigenDA contract, store the data blocks if they match, and then sign them.
4. Afterwards, the Sequencer collects these signatures, generates an aggregate signature, and publishes it to the EigenDA contract for verification. Once the signature is verified, the whole process is completed.
In the above process, the EigenDA node only claims to store data blocks by its signature. We also need a way to ensure that the EigenDA node is not lying. EigenDA adopts Proof of Custody.
The idea of Proof of Custody is to place a "bomb" in the data, which would be confiscated if the node signs it. To implement Proof of Custody, we need to design: a secret value to differentiate different DA nodes and prevent cheating; a function specific to the DA node, taking DA data and secret value as inputs and outputting whether the bomb exists or not. If the node does not store the complete data it should, it cannot compute this function. Dankrad has shared more details about Proof of Custody on his blog.
Source: EigenLayer
If there is a lazy node, anyone can submit evidence to the EigenDA contract, and the contract will verify the evidence. If the verification passes, the lazy node will be confiscated.
In terms of hardware requirements, computing a 32 MB data KZG commitment within 1 second requires approximately 32-64 core CPUs, but this requirement only applies to the Sequencer and does not burden the EigenDA node. In the EigenDA testnet, the throughput of 100 EigenDA nodes reached 15 MB/s, while the demand for node download bandwidth was only 0.3 MB/s (much lower than the requirements for running an Ethereum validator).
In summary, we can see that EigenDA decouples data availability from consensus. The propagation of data blocks is no longer limited by the bottleneck of consensus protocols and P2P network throughput. Because EigenDA is like hitching a ride on Ethereum's consensus: the Sequencer publishes KZG commitments and aggregate signatures, the smart contract verifies the signatures, and the process of confiscating malicious nodes all happen on Ethereum, which provides consensus guarantees, thus eliminating the need to bootstrap a trust network.
Problems of DAS
Currently, DAS itself has some limitations. We need to assume that malicious adversaries will use various means to deceive light nodes and make them accept false data. Sreeram has made the following statement in his tweet.
In order to ensure a single node has a sufficiently high probability to believe that data is available, the following requirements need to be met:
Random Sampling: Each node independently and randomly selects a set of samples for sampling, and the adversary doesn't know which samples are requested by whom. This way, the adversary cannot change its strategy to deceive the node accordingly.
Concurrent Sampling: DAS is performed by multiple nodes simultaneously, so that the attacker cannot distinguish the sampling of one node from the sampling of other nodes.
Private IP Sampling: It means using an anonymous IP for each queried data block. Otherwise, the adversary can identify different nodes performing sampling, selectively provide the parts of data that they have already queried to the node, but not provide other parts of data.
We can use multiple lightweight nodes for random sampling to satisfy concurrency and randomness, but currently there is no good method to achieve private IP sampling. Therefore, there still exist attack vectors against DAS, making DAS currently only provide weak guarantees. These issues are actively being addressed.
EigenLayer & MEV
Source: EigenLayer
Sreeram discussed the application of EigenLayer in the MEV stack at the MEVconomics Summit. Around the cryptographic economic primitives of staking and confiscation, proposers can achieve the following four characteristics, which were mentioned as the third point - Validators' Commitment Use Cases:
Event-driven Activation
Protocols like Gelato can react to specific on-chain events. Continuous monitoring of on-chain events allows for triggering predefined actions once a certain event occurs. These tasks are typically performed by third-party listeners/ executors.
The reason they are called "third-party" is that there is no connection between the listener/executor and the proposer who actually processes the block space. Suppose a listener/executor triggers a transaction, but (for some reason) it is not included in the block by the proposer. This cannot be attributed, thus cannot bring deterministic economic guarantees.
If the proposers who participate in the re-pledging provide this service, they can make credible commitments to the triggering of operations. If these transactions are not ultimately included in the block, the proposers are penalized. This provides stronger guarantees compared to third-party monitors/executioners.
In practical applications (such as lending agreements), one of the purposes of setting an excess collateralization ratio is to cover price fluctuations over a certain time range. This is related to the time window before liquidation, where a higher excess collateralization ratio means a longer buffer period. If a large portion of the transactions adopt event-driven reactive strategies and have strong guarantees provided by proposers, then (for highly liquid assets) the volatility of excess collateralization ratio can be limited to a few block intervals, thereby reducing the excess collateralization ratio and increasing capital efficiency.
Partial Block Auction
In the current design of MEV-Boost, proposers completely outsource block space to builders and can only passively receive and propose the entire block submitted by builders. Compared to a more widely distributed group of proposers, builders constitute only a small group. They may collude to review and extort specific transactions because proposers cannot include the transactions they want in MEV-Boost.
Source: EigenLayer
EigenLayer has proposed MEV-Boost++ to upgrade MEV-Boost, introducing Proposer-part in the block, where the proposer can include any transactions. The proposer can also simultaneously construct an alternative block B-alt and propose this alternative block B-alt without releasing the Builder_part in the relay. This flexibility ensures both censorship resistance and solves the liveness issue of the relay.
Source: Dankrad Feist
This aligns with the goal of the protocol layer design-ePBS's crList, which is to ensure widespread proposers can participate in determining the composition of blocks to achieve censorship resistance.
Threshold Encryption
In the MEV solution based on threshold encryption, a group of distributed nodes manages the encryption and decryption key. Users encrypt their transactions, which are only decrypted and executed after being included in a block.
However, threshold encryption relies on the assumption of majority honesty. If a majority of nodes act maliciously, it may result in decrypted transactions not being included in the block. Proposers who undergo re-staking can make trusted commitments to the encrypted transactions to ensure their inclusion in the block. If the proposer does not include the decrypted transactions, they will be penalized. Of course, if the malicious majority nodes do not release the decryption key, the proposer can propose an empty block.
Long-term Blockspace Auction
Long-term block space auctions allow buyers of block space to pre-book future block space from a validator. Validators participating in re-staking can make credible commitments. If a buyer's transaction is not included by the deadline, the validator will be penalized. This guarantee of obtaining block space has some practical use cases. For example, oracle sources need to provide price feeds at certain time intervals; on Arbitrum, data from Layer 2 is released to Ethereum L1 every 1-3 minutes, and on Optimism, every 30 seconds to 1 minute, etc.
PEPC
Source: Barnabé Monnot
Now let's go back to the recently widely discussed PEPC (Protocol-enforced Proposer Commitment) in the Ethereum community. PEPC is essentially the promotion or generalization of ePBS (embedded Protocol-level Builder Security).
Let's break down this logical chain one by one.
Firstly, taking the off-chain PBS MEV-Boost as an example, the current MEV-Boost relies on a protocol-level penalty mechanism in Ethereum. If a proposer signs two different block headers at the same block height, they will be penalized. Because the proposer needs to sign the block headers submitted by the relay, it creates a binding between the block header and the proposer, giving the relay reason to believe that the builder's block will be proposed. Otherwise, the proposer can only choose to abandon the slot or propose a different block (which results in penalty). In this case, the proposer's commitment is ensured by the economic security of staking/penalty.
Approximately, one important principle of designing ePBS is "honest builder publication safety", which ensures that blocks published by honest builders will be proposed. As an embedded PBS, ePBS will be included in Ethereum's consensus layer, providing guarantees through the protocol.
PEPC is a further promotion of ePBS. While ePBS commits to "builders' blocks will be proposed," if we expand this commitment to partial block auctions, parallel block auctions, future block auctions, etc., we can allow proposers to do more - and the protocol layer will ensure that these actions are executed correctly.
There is a subtle relationship between PEPC and EigenLayer. It is not difficult to see that there are some similarities between the use case of PEPC mentioned above and the block producer use case of EigenLayer. However, an important difference between EigenLayer and PEPC is that proposers who participate in re-staking can theoretically still violate their commitments, although they will be economically penalized for doing so; while the focus of PEPC is "Protocol-enforced", which means that it enforces commitments at the protocol layer, and if the commitments cannot be executed, the block is invalid.
(PS: Roughly speaking, it is easy to see that EigenDA is similar to Danksharding, and MEV-Boost++ is similar to ePBS. These two services are like opt-in versions designed at the protocol layer, compared to the protocol layer, they are solutions that can be brought to the market more quickly, keeping in sync with what Ethereum plans to do in the future, and maintaining Ethereum Alignment through re-staking).
Don't Overload Ethereum Consensus?
A few months ago, Vitalik's article "Don't Overload Ethereum Consensus" was considered by most people as a critique of Restaking. I believe that this is just a reminder or warning about maintaining social consensus, rather than a negation of re-staking.
In the early days of Ethereum, The DAO attack caused a huge controversy, and the community had intense discussions about whether to perform a hard fork or not. Today, the Ethereum ecosystem, including Rollup, has already hosted a large number of applications. Therefore, to avoid causing great divisions within the community, it is important to maintain consistency in social consensus.
Hermione creates a successful layer 2 and argues that because her layer 2 is the largest, it is inherently the most secure, because if there is a bug that causes funds to be stolen, the losses will be so large that the community will have no choice but to fork to recover the users' funds. High-risk.
The above quote from the original text is a good example. Today, the total value locked (TVL) in L2 exceeds billions of dollars. If there are any problems, the implications would be massive. If the community proposes a hard fork to roll back the state, it will undoubtedly cause great controversy. Imagine if you and I have a substantial amount of funds on there, how would we choose - to retrieve the money or to respect the immutability of the blockchain? Vitalik's point is that projects built on Ethereum should properly manage risks and should not attempt to co-opt Ethereum's social consensus by binding the life or death of a project with Ethereum.
Returning to the discussion of EigenLayer, the key to risk management is for AVS to define objective, on-chain verifiable, and attributable penalty rules to avoid disagreements. For example, double signing blocks on Ethereum; signing invalid blocks on another chain in a cross-chain bridge based on light nodes; and the EigenDA custody proof discussed above. Such rules all fall under clear penalty rules.
Conclusion
Source: EigenLayer
EigenLayer expects to complete its mainnet launch early next year and release its flagship product, EigenDA. Many infrastructure projects have already announced their collaboration with EigenLayer. In the preceding content, we discussed EigenDA, MEV, and PEPC, and there are many interesting discussions ongoing around different use cases. Staking is becoming a mainstream narrative in the market. We will continue to follow the progress of EigenLayer and share any insights!
