You Could've Invented EigenLayer | Kydo 0x - Eigen Labs

[Music] awesome all right hi everyone I'm kaido today I'm going to talk about you could have invented igon layer and hello to the friends you know on YouTube watching this in the future all right so first I want to give a quick acronym for this talk because we're going to going back in the future mention this along you could have invented Aon layer the acon is yci YC YC and the last part it's going to we we're going to reference this talk as a YC talk and the reason is I hope that after you understand what this you know igon layer thing actually is it's going to show you the analyst possibility you can build on it and this is a YC moment for you all right let's get started first what is second layer so I have two options here a is fre and B is some diagram to show of hand who thinks a is I layer right now all right we see a few hands awesome thank you all right who who who knows what B is or have seen b oh we have we have a few hands too awesome so at the end of the talk hopefully you will understand you know I layer is both right we sh is our great founder and B is our architectural design so go up to today's talk we're going to cover four different points first we're going to Start From First principle and think about what problem does Egon ler even want to address second we're going to think about okay to address these problems what are the requirements to solve individual problem the third thing is going to be okay let's build this protocol out to address these requirements and lastly let's make it into a product what's the problem statement the problem statement is the following boost traing any decentralized infastructure is difficult crypto aims to remove move intermediaries and when you know not possible we try to increase the security and resiliency so how do we increase the network security and resiliency normally we use a a decentralized network but building a decentralized network is hard but why is that most decentralized Network requires consensus and consensus mechanism are difficult we have a few different flavors of consensus mechanism proof of authority some people may call it multii meaning just a few authorized people can make changes onto the network another one is pro State Pioneer by Satoshi with Bitcoin and lastly that's g a lot more popularity recently is proof of stake or POS systems to boost trp any proof of stake system the stake in proof of stake is really really hard and there's a few reasons for that so first what is a stake in a proof stake Network the goal for stake inside Pro Estate Network is to do simple resistance so we know who are the individual nodes to the network and they generally represent some economic value the first reason why it's difficult I'm going to run through this really quick and I'm going to go back to it to explain in depth one each one of these are difficult the first one is the stakers and the developers it's very hard to find one another the second reason is in order for you to contribute to any pro State networks today you must be exposed so the extreme volatility of these individual Network tokens the third thing is if I contribute my economic stake to your specific proof EST Estate Network there's no way I can expose to other yields with other uh from other proof estate networks and the the fact of that is if you're are a new proof State Network you must compensate this opportunity cost coming from the stier side and lastly is under this design of each individual Network having having different Pro Stakes they are going to have a fragmentation of security problem all right what does each of these mean the first one is it's difficult to identify where stakers are from a developer point of view and the reason then the the sort of symptom of this is most PR State networks their Economic Security is closely tied to its fundraising meaning most Economic Security for most new protocol will be provided by its investors is there any way for us to connect the stakers with the developers other than you know through this fundraising mechanism the second and third are very much directly tied together for me to contribute to a new proof ofate network security I might you know acquire the token for that specific proof of State Network and then I have to stake it and the network will give me rewards in return because I'm buying this token I'm exposed to a lot of price volatility of the token the network needs to compensate me a lot generally you know in in the double digit aprs and the LA and this sort of goes into this potential scenario imagining a proe Estate Network your token price drops a little bit you have weakened security your tvl decrease as as a result or activity decrease as a result because people don't trust you as much and because your tvl decrease your token price drops even more and then you have a very vicious feedback loop where more less economic security means less economic activity less economic security and vice versa the last part is in the current previous stake uh boost trapping model security are fragmented you may have seen this graph from shiron before this is this is one of the problems imagine you are building a decentralized application and you're using three different you rely on three different other proof EST State networks one of them is a bridge one of them is an oracle and one of them is a co-processor each one of them have about a billion dollar in Economic Security but your application is build on ethereum I should probably add a zero here because now yesterday ethereum surpassed 100 billion Economic Security in this model to compromise this decentralized application even though it's built on ethereum with 100 billion Economic Security it is actually the weakest link of the two of of the the four which is you know $1 billion imagine another world where we instead of fragmenting the security we pull the security into the base layer of ethereum so ethereum has 13 billion Economic Security it go through igon layer and igon layer boostrap these individual Pro of State networks now from the decentralized application developer standpoint to use each one of these Bridges Oracle coprocessors I am under the same security assumption as building on top of ethereum so those are the problems how do we find Solutions or what are the requirements to solve them just go over one more time it's hard to connect stakers with developers it is hard to acquire the token and we don't want to always you know tie a specific network with specific token we want to compensate users on their opportunity cost or lower the opportunity cost and lastly we don't want to fragment security instead we want to pull security so given those individual pain points what do we need to do first we need a platform to connect stakers and developers what does that platform mean I'm going to talk about it you a bit the second part is stakers should be able to provide Economic Security using any token not just like the specific Network token stakers should have the ability to restake and contribute to the security of other infrastructures while earning native Etho therefore for a new when you're boot shopping a new proof State Network your stakers opportunity costs are much lower and lastly through this mechanism of reaking I can l pool security instead of fragmenting it all right those are lot words let's try to build our MVP and we have 10 more minutes to finish building from an MVP to the end stage of wagon areas so first what is the platform between stakers and infrastructure Builders here I illustrate a very high level idea of a waterproof Stak network is so you have a few participants you have the Staker you have the protocol itself and you have the end user who are consuming services from the pr Estate Network and then lastly you have the developers who are writing the code that runs the protocol example would be an oracle the Oracle developers would ride the Oracle protocol the stakers would contribute stake to the Oracle for its Economic Security and lastly the Oracle protocol promises its end user that you know its price feed will be accurate and will not be maliciously manipulated easily normally these users are just smart contracts the other side of the promise is if such promise the Oracle promise made to the end user is broken then the Staker who contributed to the economic security of the underlying network will be slashed developers design these commitments stakers make these commitments by staking and lastly the protocol enforces the slashing of these individual tokens so actually if you abstract far enough all we need to do to build this platform you we just need to make satisfy two requirement the first requirement is the ability to make commitment and guess what ethereum is the best commitment making device the second part is enforcing some commitment sort of similar to running some function and the best way to do it is ethereum you can make a commitment through smart contracts and enforcing a commitment through a function call this is the simplest MVP we will start with a Staker deposits some of to its token into a token pool and inside the token pool there are some commitment Logics what would it look like in practice it will look like something like this if you don't understand cility don't worry about it it's very very easy to follow the first mapping basically tracks how many people have how many tokens you have the stake function to get into the pool you have the withdrawal function to exit the pool and last you have a slash function meaning if you misbehave as a Staker you should be slashed and as you can see there's some question mark here meaning whenever you will be slashed somebody needs to submit a fraud proof or evidence that you've committed things that deviate from the underlying commitment in the Oracle example that means you've reported a price fee that significantly deviates from the actual price feed so we cross out the first requirement we need which is creating a platform to connect stakers with infrastructure Builders the next part is contributing Economic Security using any token that one is easy since we're building on ethereum and we have infinite amount of rc20 tokens the third part is a little bit tricky but here we're going to take a shortcut we're going to say hey there's a lot of liquid staking tokens out there if we can take them in as economic security of the underlying underlying PR stake Network then the user the stakers of those new PR stake Network do not need to forgo their e rewards so that part is crossed out we have another mechanism that go through the uh bypass the liquid staking tokens and that's called native reaking it's on our docs page if you want to learn more about it take a read last part is through reaking ion layer pull security and start fragmenting it so what does it mean here so in the previous example we just describe is some Staker deposit some token into the token pool but if I want to make another commitment then I need to deposit my like another token into another token pool right so each one of these token pool are sort of each one of the commitment or commitment to a single specific proof State Network so how do we do that we achieve that by compartmentalizing the slashing function what does it mean so now as a Staker I can deposit my token into the token pool the token pool doesn't have any slashing logic ties to it however what the user could do is enroll into let different slashers to slash its stake so slasher one could hold the logic for an oracle slasher two could hold the slashing Logic for a bridge slasher three could hold the logic to for slashing for a code processor and the possibility are basically endless here for you to design your specific slashing condition I'm not going to go through the entire cont track sort of a high level idea but feel free to take a pause here or take a picture and you know with that design we actually cross out all the requirements we need to satisfy the initial problems where we came to solve we we establish a platform stakers can contribute Economic Security using any token Staker have the ability to restake and not forgo their eth rewards lastly through reaking ioner pool security and start fragmenting it and this is the MVP of ion layer it achieves most of the things we came here to achieve and the rest of the talk will be very very fast since I only have 20 minutes I'm going to run through a lot of slides so if you're online feel free to take a pause and read through the smart contracts but in the rest of the talk what I'm going to focus on is we're going to try to bring this MVP minimum viable protocol into a product where end users and developers and also A New Concept we're going to call operators will be able to participate the first thing we identify is Staker doesn't always want to operate its own thing right that's why a lot of staking companies exist why coinbase exist so we're going to add an operator role into the a layer contract but it's a little bit messy so we're going to compartmentalize and modularize the sorry if you're taking picture that might be a little bit too fast so we basically are tracking a lot of different variables to understand what is the relationship between the stakers and The Operators and The Operators are basically the people who are running the underlying infrastructure to secure these different Pro State networks so instead of having that big wall of you know code the design will simplify to something like this where we have the delegation manager which is at the bottom of the screen and what the delegation manager basically does is it tracks the relationship between a Staker and an operator for example kaido used to stake to secure an oracle Pro protocol but now kaido is like no I don't want to secure it myself I'm going to delegate that responsibility to coinbase and coinbase will be able to run that delegation on behalf of me this is very similar to delegated Pro of stake mechanisms the second thing we're going to do is this is not only supports one token at a time but that's is very simple to solve because before we only have one mapping to track one specific token so what we going to do is have something very similar to the unisoft design where you have a token manager and the token manager handles tracking of how much user owns inside different token pool and you can think of each token pool are different to holding different token so this one could be stti e this one could be CB e Etc going to pass through the contract code here going to take a quick 3 second pause for pictures awesome and this I'm going to spend a little bit more time on which is expanding the ABS design I think some sharp audience would already identifi some of the problem that exists in the current design which is the following scenario imagine I'm a Staker and I'm also running my own operator I commit some malicious behavior on the first Tim stamp highlighted here and then in the next time instant I'm going to instantly withdraw from Meg layer so now my funds are completely off Aon layer I cannot be slash anymore by the time somebody relays a fra proof for example submitting the evidence to agonal layer protocol to state that somebody you know I have done something malicious it's too late I am already outside the protocol so what we need here is when we commit a malicious activity we cannot withdraw until someone submits a profit proof and this is very similar to the 7-Day optimistic fra proof window with the on bonding period for some proof stake networks we're not going to change anything here on the design this is the current design we land on instead we're just going to add a simple variable called unbonding period and what unbonding period will do is if if I want to withdraw from any single if I want to withdraw from Egan layer then I need to wait for a specific time frame to give people to submit the specific FR proof I'm not going to talk about this here but this slide gives the idea that now withdrawal is no longer you know I call one function I get a money back instead I need to queue on withdrawal and I'll will complete my withdrawal after the unbounding period finishes the last part is a gas optimization issue so in the current design what we sort of run into is there's a lot of different slashers and we need to check with check with the slashers on the status of different individual operators and these cross contract calls really add a lot of gas burden on the end Staker especially when small stakers when they try to stake and withdrawal if the G gas cost is really high it may never be economically viable for them to participate in the system and the way we achieve it is by having a sasher manager similar to the previous idea sasher manager TR the relationship between each single operator and the individual slashing condition the operator is enrolled in and that's it this is the design of igon layer on a very very high level there's some parts of naming convention is different for Simplicity and understanding but this is sort of what on a high level what ion layer is and what reaking is feel free to take a picture because this one I think is going to be one of the most important slide here in the deck all right lastly this talk is titled why you could invented igon layer if you want to reference this talk call it the YC paper or the YC talk and that's the end of my talk thank you guys so much for your time