EigenLayer Overview

Transcript

Beautiful. Thank you guys so much for having me. Uh my name's Wes. I'm a Devro person from IGEN layer. Um really excited to chat with you and also kind of get your feedback about these ideas. Been with Ian layer for about a year and a half. Prior to iigen layer I was at protocol labs and you know 2010 and 2020 I spent a lot of time in web 2 in centralized largecale systems distributed databases and public cloud systems like Google cloud but in the evening I was a uh ethereum uh proofof work miner and I was you know involved in bitcoin for some time so I've always been really passionate about expanding web3 capabilities beyond just the EVM to offchain compute capabilities ities um

and ZK is one of the most powerful areas I think for enabling that. So I can lay there is sort of a a parallel technology that I think can complement a lot of the work that the smart folks in the ZK community are doing. So we'll get into it. Um we're going to talk about you know why people typically build an iggon layer in the first place. Um the benefits that I community can get from ZK apps and then sort of the opposite side the benefit that I can provide to ZK builders. We'll talk about some examples of ZK apps that are live on layer mainet today and also our roadmap and how it would complement a lot of the great work that's going on with noir and the Aztec community. So I wanted to start with a fun quote. Uh I asked GPT to give me a

quote about uh ZK and how it relates to um uh scaling Ethereum. And I think this is a this probably I don't know if this is like 2018 2019 when Vitalic made this comment but wow it's definitely became true and I think what's fun is you know ZK traditionally is used very much so for privacycentric use cases but I think with IE layer combining ZK it's going to expand to even more use cases even sometimes public data sets that require proof of computation. So a little bit of background on why build an IGEN layer.

Um you know this I think is probably even maybe a little bit redundant for this community but for web 3 broadly it's it's worth saying that you know decentralization is really the value driver. It's the reason that why we're here. You know a lot of the stuff that we're doing today has been done in web 2 but doing it in web 3 in a decentralized way is tremendously impactful. I mean if you look at the market cap of crypto over a period of time you know all of the crypto community what we're building these decentralized ledgers and similar technologies what's special about it is the trustlessness the privacy aspects of it and the truly decentralized nature of it but when you look at a lot of web 3 projects today they may want to be fully decentralized they may want to be zk

provable they may want to be more private but it's very difficult and it's very expensive to build things that are decentralized if If you look at popular systems today like social media systems or finance systems or YouTube or anything that we use as consumers, it's very difficult to rebuild those as fully decentralized systems. Some of the challenges you might come across if you try to do this is first raising capital. If you're going to rebuild one of these systems uh in a web 3D decentralized way, if you use proof ofstake systems, you're going to need a lot of capital and stake behind it. And that takes time, that takes investment, that takes resources. Then you're going to want to look for people to run your network, preferably like a a network of trustless

operators and some some service you can build that they will run. But you'll need to recruit those people as well. You need to build maybe a point system or some other mechanism to get your community excited to run your validator or your operator components. This all takes away from the special uniqueness of what you're trying to build. Whether it's your decentralized social media app, your ZK email service, whatever that special sauce is, that is very different from the first two components. Previously, there were a lot of really smart folks that were providing solutions for this like um the Cosmos ecosystem, but those systems required you to build them um in a way that also required consensus

among the nodes. It was app chains effectively, which is fine, but it's a lot of additional work when you may not necessarily need to maintain a consensus. And so, the way that we're phrasing layer is decentralization as a service. So the goal is is to bring the staked assets and the operators automatically as as part of the the the offering so that you can focus time on your offering for web 3. Um and then also you know there's a variety of staking mechanisms beyond just core Ethereum. You could be staking your token as well. And so if you have a token that's relevant for your community, your DAO, uh whomever, that can be a part of the cryptoeconomic security and hopefully bring your solution to market faster. So that's

that's the general IGEN layer value prop. Uh the way we go about it is we use the term cryptoeconomic security. Uh which is very similar to Ethereum's approach. It's staked assets. It's validation. It's lashing and its rewards. But it is programmatic. It's not purely uh validating Ethereum blocks. It's validating any type of off-chain service that you can imagine. And the term that we use for those services are autonomous verifiable services. So when you build an IGEN layer, you're effectively building an AVS. It's a standalone service that is validated uh it runs offchain, but it's validated onchain. And so there's really three entities in the IGEN layer

ecosystem. There are reststakers, people that bring capital into the ecosystem. Could be retail folks, could be institutional folks. There's a lot of capital out there that wants to participate in these new web3 services and they want to earn a yield or maybe they have a philosophical or emotional alignment with a project. Lots of reasons they want to participate. There's operators could be anyone. It could be a professional shop. It could be a solo operator. Could be someone in your community who wants to run the service. And the third piece is effectively you. It's the person who is building this service. It's a it's a person who's built a novel way to try to decentralize some back-end component to help uh realize the use case that they care about. The fourth is ultimately the

consumer uh the person who's actually going to use this service. And the value flows look like this. You've got staking that flows to the operator. They are delegating their flows as operators. So as a staker, I bring in some ETH and I choose one operator to delegate it to. And now that operator when they run a service that uh that stake is effectively at risk. If the operator runs the service correctly, they'll receive rewards. If they run it incorrectly, they they could have that stake slashed, which means the staker effectively would lose a portion of that capital. So, it's very similar to the Ethereum core staking mechanism just generalized beyond uh block building.

So, let's talk a little bit about how ZK app builders could benefit from this ecosystem. There's a lot of really smart folks that are building uh smart ZK apps in the ecosystem. This is a a a list from the uh awesome Noir repo as an example. Um and when you think about these these uh these components here uh what we would like to do from air perspective is take all the goodness of what they're building this off-chain verifiable compute and use that as a building block for an AVS because as require validation in some component and these are really intelligent creative new ways to do offchain validation. So IGEN layer for the ZK app builder will bring all of the assets

it'll this is a screenshot from our app here if you go to app.igen layer to XYZ. It'll bring the assets that folks might want to operationalize their service. Um, it'll allow them to stake, you know, any token, maybe native ETH if they prefer or maybe a token that they might launch if that ZK developer says, I also want to launch a token, they can have multiple tokens stly qualified operators that want to run that service in exchange for rewards. So in some sense, IGEN layer can be a way to um to operationalize um and add financial incentives behind uh the ZK app that would run on its own otherwise. And so I layer at its own is

really sort of a blank canvas. You know, I layer is the capital, the operators and a protocol to use those for some onchain validation of services. I layer isn't a service on its own. It's not a it's not providing a service, but there's all these really interesting folks that have built these validation services in these apps, right? So, if we can combine the two, we can come up with some very fun and interesting new services for the broader web 3 community. And hopefully I layer can be an accelerant for that. Now, if you go to app.igenlayer.xyz, you can check out our AVS tab. You can see some of the AVS that have launched uh live on mainet.

We've got folks like Brevis and Lrange which are doing uh ZK proving as a service effectively. The uh the proving mechanism happens with the operators in the service. Um you can bring your own circuit. You can run it on uh on these services. We've also got some fun use cases of ZKTLS integration. If you guys have been following Eliza OS, which is a a popular agentic framework for crypto and uh and AI, um we have a fun plug-in that we've built there where uh when the AI performs its inference, it actually uses opacity to validate that inference went through chat GPT as opposed to some unauthorized some some random person's

GPT. Um there was a um there was an example of I think it's AI XPTt might be missing the name but basically it was a Twitter profile that was allegedly an agent but there was some question there was a person involved and so it can kind of be a mechanism to prove authenticity of of offchain inference. And so lastly we very recently uh released our road map our public road map for where we're going with IEG layer. If you go to docs.igen layer.xyz XYZ you can get a a full copy of this road map and some commentary around there but one thing in particular is this uh this interest we've had for a while which is launching AVS's crosschain um building an AVS on ien layer today is

really rooted in Ethereum L1 primarily for assets but many customers want to run on base or opainet or in this case Aztec because there's a lot of benefits to running on these L2s so we are investing heavily in extending our capability ility to L2s take advantage of assets there. We also have some great partners like Authentic which are sort of as a service quick start platforms built on top of IGEN layer which will let you do that today and if you guys are interested I'm happy to connect you with those folks. So in summary, IGN layer is an open uh protocol. You guys are building really the secret sauce. Um you know, whoever builds these new ZK validation

techniques, whether they choose to launch an AVS or if someone else comes along and says, "Hey, like I I found out there's a new ZK validation technique and they use that as launching part of their AVS, it's all positive sum." Um it's really a big unlock for what you guys are doing in the ZK space to enable more trustless uh off-chain services. So if you guys are interested in learning more about Igenair, we do have a a a quick start guide, a simple to use Hello World AS which is a great starting point. Um we have our docs here which will get you right into building your own AS. You can also reach out to us if you want to have a conversation about an idea you have uh for for building a service and you can join our community on Telegram. So that is all that I had

but thank you guys so much for having me. I appreciate it. Thank you so much Wes. I I just took over as MC so I didn't get to hype you up as enough. Um Wes was previously at Protocol Labs, Google Cloud. Uh he did Ethereum proof work mining and uh you're driving as builder adoption at layer. Now I wanted to ask you a quick question before I open it up to everyone else. Um what's a killer app that you would want to see with Noir and with AS? That's a great question. Um let's see. You know, I would actually love to see the Git claim app. I love I someone had written that on awesome a uh awesome noir just to validate what's going on

with a GitHub profile because a lot of folks like that becomes a big issue for like community building who actually contributed code and we don't have really great solutions for that yet. But if there was a way to launch something like git claim amongst a group of trusted operators and then they could go and log into GitHub and they could pull the data run a zk proof to somehow validate that the contributions to a GitHub repo were legitimate. I just think there could be a lot of usage in the crypto community like verifying contributions. Yeah. If not, I can ask another one. That's

okay. Yeah. Either way, maybe you could go a little bit into implementation on the ABS side with gate claim specifically just high level. Yes, absolutely. Um, let me just see if I can pull up a visual here. Great. Um this is a a view of what an as looks like more mechanically which I think would be a good example for git claim. You know I en layer at at its basic is its most basic is a contract on ethereum uh that person implements it's implements some interfaces and it connects to the core ien layer contracts. Those core layer contracts have all the staking assets all the operators registered there. And so if I

was going to implement something like get claim, I'd implement a new AS contract and I would have these operators run some code. I mean the goal of these operators, it's very flexible, but very often they're all running the same code. They don't have to be experts in in what's going on. They just want to get a Docker compose uh component Docker uh Docker package or Kubernetes or something they can just run effectively and as long as they're running it, they're happy. They're they're participating. So, I'd probably wrap claim in some sort of a binary that these operators could run offchain and then when I had a new request come in for um for validating some contribution to to the GitHub repo, maybe that would

come in on chain. Someone would submit a transaction, say, "Hey, I have a new um series of contributions that I want to confirm." The operators would listen to that. They would they would hear that new task come on chain to the AS contract and then they would go and perform that operation using get claim. They would have the ZK proof as a result. Then they would write that proof back on chain. That would be some evidence that they did their work. They would get rewarded accordingly. Uh and the end user would then get the results back as well from uh from that GitHub contribution. So they would have some information about it and it would be a more trustless way to get that information versus what we have today.

H how would you um retain privacy if you uh implemented in that way and how do you see uh IGEN layer um working alongside so I I see like there's many different ways you could use client side stuff you can use private blockchains open blockchains IE layer um where do you see IEG layer in this ecosystem for solutions like this especially where you know you're caring about privacy trying to retain like this this information and get claims case yes no that is the million-dollar question because you know these operators here are really operating in a trust trustless context.

They're operating, you know, on the own on their own on the internet. And so I think in order to maintain privacy, we have to get a little more sophisticated about the data sets that they're operating on. We may need to use some encryption techniques like threshold encryption techniques. A lot of folks will use that or timebased uh time lock encryption techniques so that only the given operator can view the data to operate on it. There's also folks that use uh technologies like fully homorphic encryption or um like trusted execution environments, different ways to make the data more difficult to get access to. I think because this is operating in the public, we have a little bit more work to do to ensure privacy in these use cases. Yeah, question. Thank you. Uh does anyone else

have any uh other questions? Sure. Let me not fall over. Thank you. Um just a quick question regarding the cryptoeconomic security. As far as I know, currently on layer like the protocol doesn't impose a certain limitation as to how many different AVS the same digital asset can be rest to as economic security. Are there any plans uh I don't know to implement that or are there any measures? I mean it may not be you may not be the best suited person

regarding that but I I'm really curious about that because I I mean I've recently been uh uh on your dashboard and I did notice that the total TVs on on um layer and the total TVs when I sum up the t sorry the total TVL on layer and the total TVL of the individual as summed up is actually significantly different. So you see that there is an overcommitment to different uh AVS of the same USD value. So how does how does that look like or from a security perspective or like future uh directions? Yes, something like that.

That's an excellent topic. No, no, thank you for bringing that up. We're in a bit of a of a funny transition where currently on mainet of IGEN layer slashing is not yet live. It's the last final piece of our protocol to be complete. Slashing is actually live on test net currently and it's our biggest focus to launch probably April Mayish approximately you know without any any com any commitments form commitments but it's our number one focus for the engineering team and so prior to slashing you're exactly right I could take $1,000 worth of ETH and I could commit it to as many ABS's as I wanted and for reward's sake that has some functionality because you certain services they may simply want operators that have a certain amount of stake aail

available to them to show that they're legitimate or that they're helpful or useful and they can pay rewards. But getting into the more interesting use cases that require slashing as well. Going forward with the slashing release, the dynamics are going to change a little bit so that those operators in order to opt in to slashable as they have what we refer to as unique stake. They can only allocate a certain amount of unique stake into each individual ABS. So there will no longer be that sharing nuance uh that you described uh as it is today. So so effectively the the the AS operators will have a limited amount of stake.

They can only give it to certain services. Now at the same time some services may say I want you to allocate $1,000 worth of ETH to me as so that I may slash that that thousand ETH. But also in order to ensure legitimacy of you as an operator, I want to make sure that in general you have over a 100,000 stake total. So there's this unique stake and there's this total alloc allocated stake as well and as service developers can choose how they want to balance those to to ensure the right amount of trustlessness that they need for their service. So there'll be a little bit of both going forward. Yeah, great question. Great question. Any any more questions?

Cool. All right, we'll wrap up. Thank you for a great talk, guys. Thank you. Cheers.