IOSG Ventures: A look at the latest progress and use cases of EigenLayer in the field of "re-pledging"

Original author: Jiawei, IOSG Ventures

![IOSG Ventures: A look at the latest progress and use cases of EigenLayer in the field of "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-2be3745338-dd1a6f-6d2ef1)

Source: EigenLayer

In November last year, we introduced EigenLayer in this article "EigenLayer: Introducing Ethereum-level trust into middleware". In the past year, EigenLayer has released their white paper, completed a $50 million Series A round of financing, and launched the first phase of its mainnet. During this period, the Ethereum community also held extensive discussions around EigenLayer and its use cases. This article will track and sort out these discussions.

background

In the Ethereum ecosystem, some middleware services (such as oracle machines) do not fully rely on the logic on the chain, so they cannot directly rely on the consensus and security of Ethereum, and need to redirect the trust network. The usual approach is to first operate the project, then introduce token incentives to attract system participants and gradually achieve decentralization.

There are at least two difficulties in doing so. One is that the introduction of an incentive mechanism requires additional costs: the opportunity cost for participants to purchase tokens to participate in the pledge, and the operating cost for the project party to maintain the value of the tokens. Second, even if the above-mentioned costs are paid and a decentralized network is built, its security and sustainability are still unknown. For start-up projects, these two points are particularly tricky.

EigenLayer's idea is to provide economic security for these middleware (Actively Validated Services, AVS) by restaking by existing Ethereum stakers. If these re-pledgers work honestly, they can be rewarded, but if they do evil, their original Ethereum pledge exposure will be forfeited.

The advantages of this are: first, the project party does not need to guide the new trust network by itself, but outsources it to Ethereum validators, reducing capital costs as much as possible; second, the economic security of the Ethereum validator set is very solid , so that security is also guaranteed to a certain extent. From the perspective of Ethereum pledgers, re-pledging provides them with additional income. As long as there is no subjective malicious intention, the overall risk is controllable.

Sreeram, the founder of EigenLayer, once mentioned EigenLayer's three use cases and trust models on Twitter and podcasts:

• Economic trust. That is, the reuse of Ethereum staking exposure, staking of higher value tokens means more robust economic security, as discussed above.
• Decentralized trust. Malicious behavior of some services (such as secret sharing) may not be attributable and slashing mechanisms cannot be relied upon. There needs to be a sufficiently decentralized, independent group of people doing something to guard against the risk of collusion and collusion.
• Ethereum validator commitment. Block producers make certain credible commitments using pledged exposure as collateral. Below we will list some examples to further illustrate.

System Participants

Source: IOSG Ventures

EigenLayer serves as an open market that connects the three major players.

*Re-pledger. If you have Ethereum staking exposure, you can participate in re-staking by transferring withdrawal credentials to EigenLayer, or simply deposit LST such as stETH to participate. If a re-stakeholder is unable to run an AVS node themselves, they can also delegate their exposure to an operator.

• operator. The operator accepts the delegation from the re-stakeholders and runs the AVS node. They are free to choose which AVSs to serve. Once you provide services to AVS, you need to accept the slashing rules defined by it. *AVS. As a demander/consumer, AVS needs to pay rehypothecaters and obtain the economic security they provide.

With these basic concepts in mind, let's look at the specific use cases of EigenLayer.

EigenDA

EigenDA is the flagship product launched by EigenLayer. The solution is derived from Danksharding, the Ethereum expansion solution. Among them, Data Availability Sampling (DAS) is also widely used in DA projects such as Celestia and Avail. In this chapter we will give a quick introduction to DAS, and then look at how EigenDA is implemented and its innovations.

• THE

![IOSG Ventures: A look at the latest progress and use cases of EigenLayer in the field of "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-7417ebaed1-dd1a6f-6d2ef1)

Source: Dankrad Feist

As a front-end solution for Danksharding, EIP-4844 introduces "Blob-carrying Transaction". Each transaction will carry an additional data size of about 125 kb. In the context of the data sharding expansion route, new data will undoubtedly increase the burden on nodes. So, is there a way to make the node download only a small part of the data and also verify that all the data is available?

What DAS does is to let nodes randomly sample a small part of the data multiple times. Each successful sampling increases the node's confidence that the data is available, and once a certain preset level is reached, the data is considered available. However, it is still possible for an attacker to hide a small portion of the data - we also need some kind of fault tolerance.

DAS uses erasure coding (Erasure Coding). The main idea of erasure coding is to split the data into chunks and then encode these chunks to generate additional redundant chunks. These redundant blocks contain part of the information of the original data blocks, so that when some data blocks are lost or damaged, the lost data blocks can be recovered through the redundant blocks. In this way, erasure coding provides redundancy and reliability to DAS.

In addition, we also need to verify whether the resulting redundant blocks are correctly encoded, because the original data cannot be reconstructed with a wrong redundant block. Danksharding uses KZG (Kate-Zaverucha-Goldberg) commitments. KZG Commitment is a method for verifying a polynomial, which can prove that the value of the polynomial at a specific position is consistent with the specified value.

The prover chooses a polynomial p(x) and uses p(x) to compute the commitments for each block of data, called C 1 , C 2 , ..., Cm. The prover will publish the commitment along with the data block. To verify the encoding, the verifier can randomly sample t points x 1, x 2, ..., xt and ask the prover to open commitments at these points: p(x 1), p(x 2), ... , p(xt). Using Lagrangian interpolation, the verifier can reconstruct the polynomial p(x) from these t points. The verifier can now use the reconstructed polynomial p(x) and data blocks to recompute the commitments C 1', C 2', ..., Cm' and verify that they are consistent with the published commitments C 1, C 2, ... , Cm matches.

In short, using KZG commitments, the verifier only needs a small set of points to verify the correctness of the entire encoding. In this way, we get the complete DAS.

• How

Source: EigenLayer

EigenLayer borrows ideas from DAS and applies it to EigenDA.

1. First, EigenDA’s nodes are re-pledged and registered in the EigenLayer contract.

2. Secondly, after getting the data, the Sequencer divides the data into multiple blocks, uses erasure coding to generate redundant blocks, and calculates the KZG commitment corresponding to each data block. Sequencer releases KZG commitments to the EigenDA contract one by one as a witness.

3. Subsequently, the Sequencer distributes the data blocks together with their KZG commitments to each EigenDA node one by one. After the node obtains the KZG commitment, it compares it with the KZG commitment on the EigenDA contract. After confirming that it is correct, the data block is stored and signed.

4. Afterwards, the Sequencer collects these signatures, generates aggregated signatures and publishes them to the EigenDA contract, and the EigenDA contract verifies the signatures. After the signature verification is correct, the whole process is completed.

In the above process, because the EigenDA node only claims to store the data block through the signature. We also need a way to ensure that EigenDA nodes are not lying. EigenDA uses Proof of Custody.

The idea of escrow proof is to put a "bomb" in the data. Once the node signs it, it will be slashed. In order to implement the escrow proof, it is necessary to design: a secret value to distinguish different DA nodes to prevent cheating; a function specific to the DA node, taking the DA data and secret value as input, and the presence or absence of bombs as the output. If the node does not store the complete data it is supposed to store, this function cannot be calculated. Dankrad has shared more details about Proof of Escrow on his blog.

![IOSG Ventures: A look at EigenLayer's latest progress and use cases in the field of "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-5e2b72172c-dd1a6f-6d2ef1)

Source: EigenLayer

If there is a lazy node, anyone can submit a proof to the EigenDA contract, and the contract will verify the proof, and if the verification is passed, the lazy node will be fined.

In terms of hardware requirements, KZG's commitment to calculate 32 MB of data in 1 second requires approximately 32-64 core CPUs, but this requirement is only for the Sequencer side and will not impose a burden on the EigenDA node. In EigenDA's test network, 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 Ethereum validators).

To sum up, we can see that EigenDA realizes the decoupling of data availability and consensus, and the propagation of data blocks is no longer limited by the bottleneck of consensus protocol and low throughput of P2P network. Because EigenDA is equivalent to taking a free ride on the Ethereum consensus: the process of Sequencer issuing KZG commitments and aggregated signatures, verifying signatures by smart contracts, and slashing malicious nodes all occurs on Ethereum, and Ethereum provides consensus guarantees, so there is no need to Reboot the trust network.

• Problems of DAS

Currently, DAS as a technology itself has some limitations. We need to assume that malicious counterparties will use all means possible to fool light nodes into accepting false data. Sreeram had elaborated as follows in his tweet.

In order for a single node to have a high enough probability that the data is available, the following requirements need to be met:

• Random sampling: Each node is required to independently and randomly select a bunch of samples for sampling, and the counterparty does not know who requested which samples. In this way, the counterparty cannot change its strategy accordingly to deceive the nodes.
• Concurrent sampling: DAS is required to be performed by multiple nodes at the same time, so that the attacker cannot distinguish the sampling of one node from the sampling of other nodes.
• Private IP sampling: means using an anonymous IP for each queried data block. Otherwise, the adversary can identify different nodes that perform sampling and selectively provide the nodes with the parts that they have queried without providing other parts of the data.

We can allow multiple light nodes to perform random sampling to satisfy concurrency and randomness, but there is currently no good way to satisfy private IP sampling. So there are still attack vectors against DAS, making DAS currently only provide weak guarantees. These issues are still being actively addressed.

EigenLayer & MEV

Source: EigenLayer

Sreeram talked about the use of EigenLayer in the MEV stack at the MEVconomics Summit. Focusing on the cryptoeconomic primitives of staking and slashing, proposers can implement the following four characteristics, which are the third point mentioned above - the validator commitment use case.

Event-driven Activation

Protocols such as Gelato enable reacting to specific on-chain events. That is, to continuously monitor events on the chain. Once an event occurs, some predefined operations are triggered. These tasks are usually completed by third-party listeners/executors.

It is called a "third party" because there is no connection between the listener/executor and the proposer who actually handles the block space. Suppose a listener/executor triggers a transaction but (for some reason) is not included in the block by the proposer. This cannot be attributed and therefore cannot bring deterministic economic guarantees.

If this service is provided by proposers who participate in restaking, they can make credible commitments to the triggering of operations, and if these transactions are not included in the block, the proposer is slashed. This provides stronger guarantees compared to third-party listeners/executors.

In practical applications (such as lending agreements), one of the purposes of setting the overcollateralization rate is to cover price fluctuations within a certain time range. This is related to the time window before liquidation, where a higher overcollateralization ratio means a longer buffer period. If a large proportion of transactions adopt an event-driven reactive strategy and have strong guarantees provided by proposers, then (for highly liquid assets) the volatility of the over-collateralization rate may be limited to a few block intervals. , thereby reducing the overcollateralization rate and improving capital efficiency.

Partial Block Auction

In the current MEV-Boost design, the proposer completely outsources the block space to the builder, and can only passively receive and propose the entire block submitted by the builder. There are only a handful of builders compared to the more widely distributed proposers, and they may collude to censor and extort specific transactions—because proposers cannot include the transactions they want in MEV-Boost.

Source: EigenLayer

EigenLayer proposes MEV-Boost++ to upgrade MEV-Boost, introduces the proposer-part in the block, and the proposer can include any transaction in the proposer-part. The proposer can also construct an alternative block B-alt at the same time, and propose this alternative block B-alt when the relay does not release the Builder_part. This flexibility not only ensures censorship resistance, but also solves the problem of relay liveness.

Source: Dankrad Feist

This is consistent with the protocol layer design - the purpose of crList proposed by ePBS, that is, we need to ensure that a wide range of proposers can participate in deciding the composition of the block to achieve censorship resistance.

Threshold Encryption

In the MEV solution based on threshold encryption, a group of distributed nodes manage encryption and decryption keys. Users encrypt transactions, which are decrypted and executed only after the transaction is included in a block.

However, threshold encryption relies on the majority honesty assumption. If most nodes act evil, it may result in decrypted transactions not being included in the block. Re-staking proposers can make a credible commitment to the encrypted transaction to ensure its inclusion in the block. If the proposer does not include the decrypted transaction, it will be slashed. Of course, if a malicious majority of nodes does 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 reserve future block space for a certain validator in advance. Validators participating in re-staking can make credible commitments and will be slashed if there is no transaction involving buyers at expiration. This guarantee of block space has some practical use cases. For example, the oracle machine needs to feed prices in a certain period of time; Arbitrum publishes L2 data to Ethereum L1 every 1-3 minutes, Optimism every 30 seconds-1 minute, and so on.

##PEPC

![IOSG Ventures: A look at the latest progress and use cases of EigenLayer in the field of "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-a2677d5154-dd1a6f-6d2ef1)

Source: Barnabe Monnot

Let’s go back to PEPC (Protocol-enforced Proposer Commitment), which has been widely discussed by the Ethereum community recently. PEPC is actually the promotion or generalization of ePBS.

Let's break down this logical chain one by one.

• First, take the out-of-protocol PBS MEV-Boost as an example. Currently, MEV-Boost relies on the Ethereum protocol-level slashing mechanism, that is, if the proposer signs two different block headers at the same block height, they will be slashed. . Because the proposer needs to sign the block header submitted by the relay, it is equivalent to forming a binding between the block header and the proposer, so the relay has reason to believe that the builder's block will be proposed. Otherwise the proposer will only be forced to give up the slot, or propose a different block (which will result in slashing). At this time, the proposer's commitment is guaranteed by the economic security of staking/slashing. *Approximately, an important principle in designing ePBS is "honest builder publication safety", which ensures that blocks published by honest builders will be proposed. As an in-protocol PBS, ePBS will be incorporated into the consensus layer of Ethereum and guaranteed by the protocol.
• PEPC is a further extension of ePBS. ePBS promises that "the builder's block will be proposed." If this is extended to partial block auctions, parallel block auctions, future block auctions, etc., we can allow the proposer to do more things - and the protocol layer ensures that these things are executed correctly.

There is a delicate relationship between PEPC and EigenLayer. It is not difficult to find that there are some similarities between the above PEPC use case and EigenLayer's block producer use case. However, an important difference between EigenLayer and PEPC is that proposers participating in re-pledge can still theoretically break their commitments, although they will be financially punished; while the focus of PEPC is on "Protocol-enforced", that is, at the protocol layer Mandatory is implemented on the above, if the promise cannot be executed, the block is invalid.

(PS: From a rough look, it is easy to find that EigenDA is similar to Danksharding and MEV-Boost++ is similar to ePBS. These two services are like the opt-in version of the protocol layer design. Compared with the protocol layer, it is a faster solution to the market. , keep pace with what Ethereum is going to do in the future, and maintain 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 to be a criticism of Restaking. The author believes that this is just a reminder or warning to maintain social consensus. The focus is on social consensus rather than the denial of re-pledge.

In the infancy of Ethereum, The DAO attack caused huge controversy, and the community had a heated discussion on whether to hard fork. Today, the Ethereum ecosystem, including Rollup, already hosts a huge number of applications. Therefore, it is very important to avoid causing great divisions within the community and maintain the consistency of 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 to the original is a good example. Today, the total TVL of L2 exceeds tens of billions of dollars. If there is a problem, it will involve a lot. At this time, if the community proposes to implement a hard fork and roll back the state, it will inevitably cause huge controversy. Assuming you and I have a large sum of money on it, how will we choose - get the money back or fear the immutability of the blockchain? Vitalik's point is: projects that rely on Ethereum should properly manage risks, and should not try to win over Ethereum's social consensus, and strongly bind the life and death of the project to Ethereum.

Returning to the discussion of EigenLayer, the focus of risk management is that AVS needs to define objective, on-chain, and attributable slashing rules to avoid disagreements. For example, double-signing blocks on Ethereum; signing another chain’s invalid block in a light node-based cross-chain bridge; the EigenDA Escrow Proof discussed above, and more. These and the like are clear rules of forfeiture.

Conclusion

Source: EigenLayer

EigenLayer is expected to complete the mainnet launch early next year and launch its flagship product EigenDA. Many infrastructure projects have announced their cooperation with EigenLayer. We discussed EigenDA, MEV, and PEPC above, and there are many interesting discussions going on around different use cases. Re-pledging is becoming one of the mainstream narratives in the market. We will continue to follow the progress of EigenLayer and share any views!