# [Panel] The Staking Economy: From Monolith to Modularity | Devcon Bogotá

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-07
- Duration: 51:27
- Watch: https://streameth.org/watch/yt-Ee9a1VV0ygA
- YouTube: https://www.youtube.com/watch?v=Ee9a1VV0ygA

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/panel-the-staking-economy-from-monolith-to-modularity/

The staking industry is on the verge of a new and exciting innovation cycle. The modularization of the staking tech stack, led by advances in middleware solutions such as Obol Network (Distributed Validator Technology), Flashbots (MEV Boost), Liquid Collective (liquid staking), and EigenLayer will create a new playing field for existing operators, product builders and solo stakers.

This panel seeks to discuss these important developments and the new benefits and risks they bring to Ethereum.

Speaker(s): Collin Myers, Sreeram Kannan, Viktor Bunin | Coinbase Cloud, Stephane Gosselin
Track: Staking & Validator Experience
Keywords: Staking,Validators

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] So today we're going to be talking about the sinking economy and how it's moving from monolithic to modularity we're going to introduce our speakers here I'm the host Victor Bunyan [Applause] [Music] ah the big supporters over there um I got a taste for Colombia and anyway so um we have an amazing panel before us um introduce myself on protocol specialist at coinbase cloud coinbase cloud is an infrastructure provider uh we run validators and nodes across and like 30 or 40 different blockchains at this point uh we run a good number of uh eth validators um and so we're extremely invested in the success of ethereum ecosystem paying a lot of attention to this transition from the um you know what is currently a validator which is a you know it's a box somewhere that has some software on it the keys are either there or in some other box and it's pretty vanilla and it goes and it does its work and it you know performs the consensus duties uh but the trend that we're seeing right now is that there's a whole host of essentially middleware solutions that are changing uh and modularizing the validator experience and so they're almost kind of like plugins or extensions you can think of it as it's a very crude uh example um this is a fairly recent phenomenon um you know flashbots and Mev boost was you know the first and primary example of it you know reaching an enormous scale within the ethereum ecosystem but with the advancements coming from you know the teams up up here and also other teams working in the space we expect for this to be an extremely exciting uh and pivotal moment in the development of blockchain infrastructure on ethereum and so with that I'm going to pass it over to the panelists to each introduce themselves and their projects we're going to give them a little bit of time to not go super technical but like it's important to understand what like each project is because it's really going to inform the rest of the conversation and these are nuanced uh meaty topics and so the directive we gave them as a VC pitch but a VC that knows what's going on you know that's how [Music] that's all with that Stefan please go ahead all right hello hello all right this works hey everyone I'm Stefan um until recently was at flashbots um one of the big things I've been working on there over the last year has been developing and shipping my Boost which uh is often talked about these days so I'm happy to get into it get into like discussing what it means to develop this kind of software for validators um you know Mev boost was developed to help solve two very specific problems with regards to um to validator deployments and Mev one was allowing access to solo validators to participate in the Mev market and the other one was to protect client diversity and sort of avoid a future where um you know Valdez would try to Fork their own code and create some some technical debt in integrating new uh new upgrades so the way that it's architected and the way that it works today is anyone running a validator whether it's at home or a massive node operator like coinbase Cloud can can again Mev Booth into their system do some minor configuration and essentially run out of the box and and get uh better rewards um so yeah that's that's the intro there well good evening everybody I'm sriram uh I'm founder of this project called eigenlayer and uh also run the University of Washington blockchain research lab what we're doing at eigenlayer is essentially enabling the sharing of decentralized trust from ethereum is taking to anybody who wants to build a new system on top so the core idea here is staking is the root of trust so when you're you know after the merge you know we are in a proof of stake world where no uh use the uh stakers basically put down a stake and commit to Black Block validation and if they make a error or if they behave maliciously they can lose the stick so this underwrites a certain Economic Security into the blockchain what we are doing is enabling it to be flexibly shared so for example you put down your stake and re-stake so restake is a New Concept we came up with restake is the idea that you're using the same stake putting it at additional risk and committing to doing additional things maybe running a new chain running a new service like data availability running other middlewares on top of this common stake so the exchange here is stakers are taking on additional responsibilities and additional risk and in exchange they are compensated with some fees or other tokens which are paid for those stickers imagine you want to build a new distributed system you have to go around and try to create a whole new validation Network which is decentralized fund Economic Security to it which is actually very very expensive for example just to get a sense of numbers here ethereum has like you know 20 billion dollar worth of economic stake at risk if you wanted to build a platform which has similar Economic Security you're talking about like you have to pay the stickers an annual APR like 10 right that's like two billion dollar worth of fees just for your other system to be as secure as ethereum it's virtually impossible so what you can do is you can borrow this massive Economic Security because you're restaking it you're using it for additional Services anybody can come and build new services on top thus augmenting the feature set of the ethereum ecosystem we think of those as a permissionless way to do feature addition to ethereum so in you're borrowing the ethereum trust and now running new services it is probably opt-in from the Staker side it's not forced on anybody but the stakers that do opt-in are actually able to earn this additional risk reward Dynamic so that's what we do at eigen layer hey everyone uh Colin Myers uh co-founder of opal we are focused on building what's called distributed validators um easiest way to describe what a distributed validator is is today all validators are seen as one key one entity one individual and it's very singular in nature our primary goal with DBT is to enable and change everyone's Minds that validators can become communities so with DBT what you can do you can take a regular validator you can use a dkg divide up its key into different shares and the four of us today can share a validator together and if Victor's house burns down all things are fine because we use threshold signing and applied photography so our node will keep going it'll keep validating the network will not halt um and yeah that's what we're focused on it takes on the form of a middleware and it sits on the eth2 side awesome and uh I know you folks are all starting out on ethereum and you talk a lot about ethereum but obviously it's not the only proof of stake Network that's out there um there's a proliferation of them and most networks these days are proof of mistake um how do you think about the trade-offs of sticking to ethereum versus also starting to work on other layer ones or you know layer twos and other ecosystems I think right now there's a huge Narrative of like the bazaar versus the app chain uh I think they can both live and survive I'm an American that spends half my time in Europe and it's actually almost culturally how the world is divided like Europe is kind of a bizarre uh all their cities are meant to be lived in everything is close to each other Americas like app chains suburbs houses everything's real structured and together um so the way that we look at that is ethereum is the bizarre and then who's the app chain so for us as we look at where to take DVT it needs to fit technically within that Network and what's favorable for us are not too fast the block times because there's rounds of communication that need to go between the individuals that are inside of a cluster um so for us Cosmos is like another chain that where that could work and is kind of the app train model they have five to seven second block times for us to work on other chains DVT works best with BLS signatures um they're homomorphically additive which enables you to split them up and then re-aggregate them and broadcast in a very efficient manner Cosmos does not have that maybe they will adopt it or maybe DVT can be fit into another chain in that sense but today we are most focused on ethereum however DBT is something that all public blockchains should use in my opinion to add like more resiliency and add fault tolerance to the network so it comes down to demand it comes down to like where the economic value is it comes down to like where the smartest minds are and I do believe that outside of the bazaar the app chain model is probably the only other layer one that would compete with ethereum and that's how we currently look at the option set very cool um we are primarily ethereum Centric and the reason is when you want to build a layer like this you are basically looking for where is the maximum pool of decentralized trust because we have basically a decentralized trust marketplace where do you have maximum Economic Security where do you have maximum decentralization how can we leverage this and build a whole bunch of new technologies on top of it so our attention is actually an onboarding newer and newer modules and Technologies and one interesting thing that you know if you look at ethereum versus the other blockchains ethereum has committed itself to the modular blockchain world and I think very few people understand the kind of scope of what a modular blockchain world is uh the way to think about it is one thing we all love you know across all these ecosystems about blockchain is permissionless composibility right you can build an app and I can build something on top of it and somebody else can build something on top of it together they stand much stronger than any one person could have ever built and permissionless composability is at the app layer and that's how all smart contract systems work but we want to bring permissionless composability at the distributed system level you build a new system I build a data availability layer you build a broadcast layer somebody else builds uh some other thing on top you know an authentication layer you just pack all of these together and then create a new service so ethereum having committed to this modular Paradigm where you know there is going to be different things done at different modules rather than all bundled together we're all about unbundling trust right so we are actually taking the trust Network and letting people innovate on the different modules so for us it is a natural fit that ethereum is the right place to build something like this for Mev okay um deciding where to build Mev Solutions sort of comes from the starting point of where is the biggest problem and the biggest problem is where you know the most usage is so it sort of makes sense to start from that perspective with ethereum um and it turns out that building Mev Solutions is kind of hard so you kind of solve it you build something on one layer and then you say well it would be nice to go build it on everywhere else but there's only so much time in uh and resources to be able to do it so the other thing is it's not a one-size-fits-all solution so I think there's some principles there's some abstractions there's some research some ideas that can be reused across multiple different places but you can't just reuse the model that you deploy for a a certain um a certain node architecture for a certain client architecture and copy paste it into other Chains It's been really cool to see other teams emerge in other ecosystems that try to solve similar Med problems at the middleware layer at the node customization layer I know on the Solana side right the GTO team has been working on it for for a little while and it's fascinating to see how different the solution space is right so sort of the solution that they are coming up with to be able to Outsource the um the Mev extraction is actually to slow down block times so because Solana has this main difference of being so much faster at block production than than ethereum to do any meaningful Outsourcing you need to have slower time block time so that you can add the network latency that's required and so it sort of highlights that even though the principle is the same the idea of being able to Outsource Mev extraction from the validator level the implementation ends up looking completely different um you know the other thing that I'll note is like boost is surprisingly simple software you know like running a consensus client uh doing all the peering and the networking is really difficult my Boost is just like a plug-in that is a sidecar through the system and allows it to connect to a bunch of other uh resources for receiving blocks um it's just a multiplexer of like an RPC call um yeah it's so hard to get adopted right like such a finite such a small change which you'd say like okay like anyone could implement this in like a day and ship it is not that trivial when you're like deploying it to a network with four you know 430 000 or so nodes there's so many different stakeholders involved so many different interests and the hardest part of developing this kind of software is not the technology itself it's also being embedded into the ecosystem understanding what are the goals that are being achieved by the development of this software what are both a technical but social goals as well as well as economic interests of all the parties involved and that's where you know 90 of the work of developing these kinds of uh Solutions lies it's not necessarily just the technical side yeah I think I think it's such a good point and um I think that's something that unless you spend time in multiple ecosystems it's very easy to take it for granted that people you know outside of your ecosystem have the same worldview about what's fair and like what should happen and who should benefit or not benefit from certain activities and what we find is that you know you can't copy paste boost because you know other ecosystems don't want necessarily these kind characteristics right and so software just doesn't make sense as it is um but there you know I think sure I'm especially you know talked about some of the some of the use cases kind of like off the cuff but um something that I would like to do is just make this a little bit more real of like what can all of this look like longer term and so what I'd love it is if you could if you guys could like talk about like what are the most ambitious use cases that you're thinking about um that you could potentially solve or or address like what does that look like um so on our side any type of validator can use DVT um you can be big you can be small you know whatever it doesn't matter um what we find most interesting is that using its cryptographic properties to partner professionals with non-professionals so when it comes to like how do you decentralize a liquid staking pool today most of the pools are run by professional validators or they are run by the pool themselves and over time what you must do is uh include other people into that validator set and with DBT um you can get the consistent uptime rewards and performance by pairing someone up with a professional in that capacity so today like let's say there's a four node cluster it can be a figment it can be a coinbase cloud and it could be two at-home validators and if applied cryptography works the way that it should that validator should have just as much performance and it enables the small person to come in with the big person and then maybe become the big person eventually so taking a node and mixing its constituents between professional and at home is kind of the not the tail end of what we're going for but right now it sits at the most Innovative spectrum of how we're testing with people and how we're looking to push it forward um from our end uh the the main thing we are quite uh fascinated about is the ability for the ethereum ecosystem to become much richer we can start listing out like the top five problems in the ethereum ecosystem and then like start ticking off how we can solve all of them just by using Michael layer I'll give some examples number one the data availability bandwidth on ethereum so in the role of centric roadmap computation is offloaded but data availability still happens on ethereum so the data availability bandwidth of ethereum even with upcoming upgrades will be in say 80 90 kilobytes per second so when you have a bandwidth like this the Roll-Ups are of course extremely optimized to actually take advantage of this and still pump in like tens of thousands of transactions per second so that is awesome but in a world where we are imagining a lot of the uh digital intermediation fundamentally happens through things like blockchains we want to make sure that there is abundant bandwidth you know 80 kilobytes per second is not enough ethereum itself has a road map for with some really interesting ideas called dunk sharding where you can increase this up to like 1.3 megabytes per second but even that we feel and that's a few years out and we feel this is not enough there are applications which will need much much more and we are provisioning uh the first service we're building on top is a data availability Solution on top of eigen layer which can actually scale the throughput of data availability quite significantly we are in our internal devnet at 15 megabytes per second already and I think we can scale this another 100x in the coming years this is one example of taking one pain point in ethereum and then figuring out how new distributed systems methods can actually come in and solve these things we build we stand on the shoulder of giants we build on top of dark shadowing some of the best ideas out there just good engineering and open permissionless competition this has done a lot of good to the layer 2 world you know compared to what sharding was where one solution has to be enshrined and there's a lot of internal contesting on which is the right solution whereas a permissionless competition for each of these different features actually leads to a very very powerful world so another example um people think a lot about whether we'll be in a single chain world or a multi-chain world and I think this is not a very relevant discussion for what we are doing why because even in a multi-chain world it's very clear to us that ethereum will be at the center of this multi-chain world and why is that what is the center of a multi-chain world is a no the if you think of each blockchain as like a node and it's like a graph you see that the Hub mode of this network is ethereum it is the most connected it is the most liquid and the most secure these are the three properties you need for a hub node of a multi-chain world and we feel ethereums is the right hub node and so in in this Paradigm there are some lacking things you know they see a lot of bridge hacks for example and can we think about how we can build like very powerful bridges on top of the ethereum landscape so that's another thing you can do is you once you restrake you can opt in and start running uh like client bridges for all other chains and start bringing in very powerful uh inputs into ethereum another example you can think of other things like Mev management right like you you want to do Mev management when you're uh when uh when a block proposal is making a claim that I'm going to follow this ordering rule what makes them hold to that rule if they can rest take on eigen layer and then opt-in to new slashing conditions for what they have particularly agreed into like I'm following this threshold encryption I'm following this auction model whatever the new rules are that you opt into you can hold by it because you can make credible commitments on eigen layer some examples of what I think we can yeah I also think we can just cancel the rest of Defcon he got it I can later resolve everything I have a question about eigenlayer um how should like validators think about the risks so like intuitively to me there's like okay I have my steak are we're gonna get to that I'm saving the spiciest ones for the end you want to know you want to do it now all right I'll do spicy ones now we can do spicy ones now yeah let's do it but but but but here's a here's the condition the spiciness actually applies to each of you not just eigen layer and I want to hear about the risks associated with each project and the failure cases that are possible have you changed your mind where do we start well I think um you know maybe I'll I'll give like a little bit of background in that you know when you think about a middleware solution that does one thing right so today a lot of people run flashbots right they run meth boost um as part of their validators and they're able to participate in the flashbots um software and ecosystem and and all that and the nice thing is that because it's like relatively simple software that doesn't make like tremendous changes from otherwise expected death Behavior it's fairly well understood and we understand the risk parameters we understand how it interacts with relays and the failure cases there uh but you know we don't understand it's like if you're running flashbots and you're running eigen layer and you're staking there and also you're part of opal right and so your validator key split into four for example and so that that actually creates a very powerful situation where you can have these like incredibly robust and performant and like do everything type validators but at the same time it's also a very scary situation because of the risks involved of like okay now you have you know nine client and teams that are doing different things you have three middleware solutions and you have upgrades across all of them happening all the time and so the risk there starts to compound and so that's from the background that we're thinking about and so maybe there's going to be two questions here one I'd love to hear about you know what are the risks and failure cases associated with what you guys are building like what's the you know worst case scenarios that could happen and how are you trying to prevent it and then second thing I'd love for us to talk about as a group is like okay you know we are um you know all marching and all kind of like making upgrades and doing all the things if I'm a validator that is going to be using all of your softwares right and also something else right how do we make sure I don't get slash how do we make sure that the ethereum network remains performed and how do we make sure that your development processes or testing or whatnot are you know in sync between all of you and also the other clients are using such as the execution or consensus clients so it's a big meaty topic who wants to go first um I'll start with uh block times we talked about this earlier so first and foremost like long block times in ethereum are super important for all this entire middleware Renaissance is what we're calling it internally you have these core client teams they've been built up over time um they're funded by the EF it's free software it's the MVP viable way that you access the network and now it's time to like build enhanced functionality on top of that those middlewares must be designed and a credibly neutral manner they must be designed with like simple modes of failure for us on our side of the equation you know the biggest mode of failure well first of all like what is the number one reason why everyone's been slashed to date in the network uh it's because everyone's been running a configuration called active passive redundancy it means to get more Effectiveness or more uptime you run the same key in two places one is online one is offline this can result in like lots of false positives so you can't have a highly available validator without DDT basically so first and foremost DBT addresses the number one slashable event in the network to date by being able to give you more availability so when designing the middleware modes of failure for us today are missing you know just miss your duties and then you take your time and you bring your machine back online and that really only happens if if you leave if you lose more than 33 of the nodes in your cluster right so we're talking seven of ten we're talking three of four uh in different combinations like this um we'll be getting a talk tomorrow ocean and I um around how to design DVT at scale while not increasing correlation so today now where we're at with DVT is like correlated slashing is one of the worst things that can happen in the network we try to like avoid that at all costs we believe that um liquid staking pools in DVT will like rain predominant inside of these so it's our duty and responsibility to make sure that it's designed in a manner that doesn't increase correlation because the worst thing that can happen is a correlated slashing event takes place across 80 of the network who's running the same middleware Obel is a security middleware right it's it's different than Med boost where you use Mev boost to get more with obelo you use it to protect yourself which in theory will probably earn you more as well um so today when it comes to correlation that's our biggest focus on testing we think it's probably the biggest risk of the whole future of staking is making sure that correlated slashing events don't take place um and yeah that's where we're at awesome what's the biggest risk of using eigen layer there are many risks but as many as things it fixes there we've tried um so there are really two kinds of uh major failure modes one is you know you get a whole bunch of stakers collude and they're not only attacking the core protocol but also attacking all these other services so the potential profit from actually your attack has increased because you have a much higher exposure that's number one I think this is uh even though this is somewhat significant I think it can be addressed uh quite uh quite well and the basic Paradigm for why this can be addressed well is we have to compare existing systems to this new upgrade using eigen layer imagine you're running a uh a whole bunch of dabs and all of them depend not only on ethereum for service but also they depend on some Oracle uh bridging service and a few other things that's exactly how the ecosystem is today and even though ethereum is giving you very strong security guarantees in terms of the economic security you have all these other dependencies which do not have uh you know the same same level of Economic Security or decentralization built in and you're only as safe the daps are only as safe as the weakest link and by restaking the yeast takers for example if you know just to give some numbers if there's 20 billion at stake in eat but like there's no there are three middle byes each of them have like one billion at stake you just attack the weakest pool and you can actually potentially completely corrupt all the inputs and the alternative universe is where uh each takers all opt-in to provide these Services especially if these services are lightweight or scaled horizontally then it's possible that a lot of heat sakers will opt in and when you have a lot of each takers opting in you are essentially to corrupt any one service to corrupt any one dab you have to corrupt a majority of the each stickers and they are putting themselves at slashing risk at some point this becomes infeasible there is a hardening of security you want to take 20 billion of a flash loan and go and you know stake and get burnt for 10 billion dollars and going to extract more than that it's very difficult so then you have a lot of restaking happening actually your systems net security increases significantly related to that where we are today okay the counterpart to this is the other kind of risk which is what happens if there are programming errors okay you have a bunch of these services that are running one of these servers has like a bug or even words it's maliciously designed to break the entire network you know somebody's offering a 20 yield things we have seen before and everybody opts in and at the end of the day there is some you know massive slashing event at the end of this thing all lead stakers are slashed and there is Mayhem this is our worst nightmare okay how do we solve this um I think this is uh this is you know to to get a good analogy at least you know in the ethereum ecosystem there has been a lot of thought in how to create systems that are immutable and ossified and the the right approach to this is to start with training wheels like Layer Two Solutions today and you have these training wheels where you have governance mechanisms which can backstop risks and and that's the same thing we'll do so essentially there are two grades of services on eigen layer one grade of service in which there is what we call a slashing veto there is a committee of ethereum community members this is not a token Dao which you can buy out this is reputed ethereum community members including people building on top in this committee they can veto slashing events which happened illegitimately right so slashing happens it doesn't get actuated there's a gap and in this Gap and I'll clarify there because one thing that I can you know when we say slashing it's not necessarily slashing on the ethereum blockchain itself it's slashing via the eigenlayer protocol and so what it does is that your ether you have staked it essentially gets withdrawn to an eigenlayer smart contract and the eigenlayer smart contract confiscates some or all of that each depending on the slashing condition that you triggered as part of eigen layer so it's like slashing conditions on top of flashing editions depending on like which rules of the protocol you break and so that's that's what he's referring to absolutely um so the governance committee can veto slashing on Tower eigen layer and this prevents things like these risk contagions but as these protocols evolve and they have been well tested in the wild they can ossify themselves to another grade which is not subject to any slashing veto so the the only thing that the governance committee can do is to veto slashing they cannot add on new slashing so the stakers are not taking additional risks but people building on this middleware are taking a governance risks because whatever legitimate slashing gets illegitimately vetoed and so as you grow in trust when you build these new Services you've been tested in the wild you can ossify yourself to another grade where you're not subject to the slashing veto and so at that point the stakers have to opt in you have to convince them to opt in because they they are losing one of their core protections either by establishing reputation and you know testing yourself in the wild so that's how we mitigate some of these risks it necessarily requires exerting subjectivity and I think this is one thing that you know the whole blockchain space should take more seriously is how do we combine subjective mechanisms with credibly neutral mechanisms so that we can get the best of both worlds very good all right um back in the house did you go yeah yeah before I started answering actually I want to get a sense of what the room is composed of so um I will ask for show of hands and and uh and please participate um anyone who's running solo validator at home can you put your hand up okay anyone who works for some professional node operator validator company put your hand up all right all right a good chunk of you anyone who's building like validator middleware sort of what we're talking about here you can put your hand up Okay small group this is the oboe Crew That's the whole Mobile TV amazing that's a fan over there um anyone who's validating or staying on other networks uh put your head up okay cool um all right mostly mostly action professional validators which is which is interesting okay so risks um Mev risk boost risks um and facts I mean at some point risks no longer rests and they become actual um so in developing nav moves I think and maybe any software really it's easy to think about the first order risks right like what are the first order you know possible failure modes um and uh and you can sort of create a security model that says okay here are all the different ways in which the software could go wrong or good abuse etc for my Boost this was threefold right so from the validator perspective you are Outsourcing part of your power to these third parties are called relayers um and there's three ways in which these wheelers could start to misbehave one of them is they produce a block that's just simply invalid right so you believe they're proposing a valid block to the network but the block is invalid the second one is that they can lie about the value of the block so they'll say hey this block is worth 10 each but in fact it's only worth one eat second way that they can misbehave and the third way is that they could withhold the the block so they give you a block you sign it you return it and then the relay just never reveals it to the network and so it causes you to miss the slot um so okay you think about okay these are three different things that the counterparty is trusting um is is trusting what are the impact of that and then how do you like start to mitigate them well the validity one right is if um if a relay continues to produce invalid blocks over time that's publicly known and so you can see like this block this this relayer is not behaving as it's expected to I can simply disconnect from this um and so the validator in this case has a power to be able to protect themselves from being uh sort of attacked and they can also critically notice if this happens to other parties so this is sort of a key part of the of the of the security model you don't want a validator who is maybe going to propose like three blocks a year or something right to have to wait until the next block proposal to know that the counterparty that they're interfacing with is is uh is malicious as the subway in some way you need to be able to see it from the state of the entire network for the third one in the block withholding one is the most difficult because there's this problem of attribution like you don't know if the relayer just revealed too slowly if it's because the validator never like submitted their block to the relayer and they only submit it to the you know to the rest of the network there's a lack of attribution as to where the fault lies and these kinds of issues are the most difficult to solve when you're building software for validators if you don't know which actor in the system default originates from you can't mitigate it as effectively and you have to look at these like wider Health metrics for the system the the solution for that specific risk is looking at um is the blockchain continuing to propose blocks um and so you can have this health factor for the blockchain as a whole if there is X percentage of the last you know 100 slots that had a valid block proposal that you can consider it to be good enough if for whatever reason the health Factor Falls below some threshold you have a circuit breaker in which it says it disconnects from all the middleware that could possibly be causing these kinds of faults and you fall back to sort of a tried and trusted uh operation of the system okay these are the first order risks everyone's the following but wait there's more this way this is making what we do look a lot more simple this is great for the most complex thing on a panel but this is this is awesome all right second order risk so this is like the risks that aren't just directly from the behavior of a single node right but more risks are emergent from when you look at what if the entire blockchain is operating the same software right what are the economics incentives what what are like the marketplaces that get developed on top of this and how does that impact the expected behavior of the software I think this is where censorship is sort of comes into play right so you can solve all of the micro sort of risk at the individual layer while still having some bigger broader risks that are more emergent out of the use of the entire system that can't be necessarily solved just through the the initial design they sort of become second order effects um and some of them are easier to predict than others um and it's sort of a question of iterating on on the ecosystem of the solution both at the technical layer but also at the industry level uh to try to make these yeah and and I think that you know censorship is a prime concern for uh you know the whole ecosystem right now um and it's been a prime you know topic of conversation throughout other panels and talks at depcon um so yeah we're all working on fixing it together that's actually one of the things that eigenlayer is often mentioned in uh each research posts about like how it can support uh potentially solving that problem and so you guys talked about the individual risks uh associated with each project but then I want to go to the next question which is that how do we deal with The Amalgamated risk profile that results from using multiple middleware Solutions why why is that funny Amalgamated that's not his word I don't know if it's right but it's good yeah [Music] this is like a I'm like all English words are nice I like them um so where we're at here like fact of the matter is there's really only one for dominantly used middleware and it's a Navy boost um so there will be many more and we made it we made it we like paved the way for all of us to see that it's actually you know doable um so like today there aren't combinations of middle Wars happening we actually recently integrated Caron which is our client into immunity boost uh and now a distributed validator can propose blinded Beacon blocks which is cool um so actually that kind of opens up this new entire landscape where like um a validator looking at the mempool if there's 10 people in a validator all 10 of them have a view on the mempool uh and then that has like and since there's a consensus mechanism built inside of it that opens up like a whole new paradigm of not only what Mev looks like but also like what security looks like so we have validators uh combined with me boost running on testnet today um we don't get to propose very often but going through that process of testing it and figuring it out fortunate for us they came first I like really don't think it would have been smooth if like DVT and Mev boost launched at the same time and it was kind of the natural of getting to the merge let's get any view Boost near mainnet let's change it from like a client into a middleware uh it let's merge and then after that now we take on the next middleware which is like DVT or others so I think doing them in phases as a community is like super important I think the EF kind of um unknowingly designed it that way and that's kind of how we interact with the client teams for example it's kind of like wait in line you know and your turn will come up so now that we're seeing more middlewares come out and they're getting more use yeah what happens when they sit on top of each other we've been looking at it less from the risk perspective and more from the opportunity perspective but through that finding we'll probably find what what the risks are yeah and I'm glad you mentioned the client Team Angle that's actually the next thing I want to talk about because I think it's super important any any other takers on The Amalgamated risk um on The Amalgamated opportunities yes I already mentioned for example that you know uh you can do Mev type things on top of uh eigenlayer you know that's one one set of opportunities another set of opportunities is can you build distributed validation for some of these other services built on top of Icon layer because again the same set of reasons why you would need DVT on top of a code layer also applies to Services built on eigenridge so that's these are some of the touch points and interfaces I think one nice thing is the core eigen layer design is kind of as a sidecar it's not directly uh touching the client so we are basically add-on right so opt-in add-on that's the two two aspects but there are some touch points between these different uh one of the other interesting things to mention about eigenlayer and opal is for like the long-term goal of this cryptography project is to deal with what's called The Lazy validator problem so today it's not like cryptographically possible to like objectively prove who in a threshold signing scheme was not doing their job um so I can layer can't fix that that's more like Moon math they can fix that but then it comes down to how do you solve that once you can identify it and that lazy person in that DBT cluster you can disincentivize you can punish you can do a variety of different things today the only way that the industry has thought about punishing that actor in our sense would be to like create a token make everyone Bond oval token to the node disincentivize slash that token and to your point we would have to create our own trust Network so at the later tale of DVT and it's more mature State the goal is to be able to use cryptography so that a group of people can run a validator together and not know each other they don't have to know each other they don't have to trust each other but to get there you you have to deal with the lazy validator problem and today the best way to do that is to create a new trust Network which is just you know 2017-18 all over again so there's like things that we would need for the later tale of what we're doing that eigenlayer is trying to build I have a question yeah please is it better if we like have a world where all the middleware solutions can sort of innovate right and like throw new ideas at the wall figure out what happens and you know what sticks if it gets adopted then you know it's just all chordev's problem now and they like have to deal with it or should it be that um each of these new middleware Solutions have to figure out sort of their own governance mechanism over how to continue maintaining these and shipping new features and how does it fit with integrating into the principles of ethereum and to all the other uh middleware solutions that get built is there like one path that's better than the other by the way I I really regret showing Stefan the questions ahead of time [Laughter] so um in our case [Applause] [Music] uh so what was the question how do you feel about front earning his question was like you know you guys are all building really cool stuff um but it's you know it's sidecars it's like you know different clients uh and so like as we mentioned earlier there's nine different clients that are you know either execution or consensus that are currently on the ethereum blockchain and now you have this slew of middleware solutions that aren't part of the all-core devs aren't part of the EIP process they're not part of any established rails by which the ethereum community you know releases infrastructure software and upgrades and so the question is like how do you deal with that right and like do you try to you know do you just ship whatever you want and then just like throw it at the at the core devs and be like it's your problem now so um ours was a reverse problem actually um I was part of a group of people who were focused on pre-genesis for eth2 we spent a lot of time on like enablement uh onboarding education uh then we began to focus on like uh post-genesis problems um and one of the first ones was take centralization and DVT started off as a research project at the EF and then we worked with them to like build a reference implementation out of it and then we took it on and now it's basically our responsibility as a project to like take that and push it forward that's more in my opinion how the EF is being designed today is like uh if you want to be a real decentralized Foundation you probably can't ship too much code when you get more mature so like their job are to be like Educators and business people uh and reference Implement like you know do all the research do the legal work do the business work enable a community and push out technology that other people can take can run with it also ties to the economic scheme of how things work right the fact of the matter is is that the client teams are funded by the ethereum foundation and or in some cases Joe and now you know middlewares um are not anymore right we have our own private funding um we're not relying on the EF our software doesn't need to be it has to be open source obviously but it doesn't need to be free so that fact then creates a whole new world of like yeah the economic schemes of how it works because economics incentives and coordination will deem all relationships and at the base layer the like the relationships and the client layer are straightforward it's like virally left um everyone can use it it will be forever free the EF has given them good chunks of money to do so and now we're at a new layer and we get to create it uh economically the way that we want to um yeah from our end I think one of the things that has been lacking I think already Colin alluded to is economic models for people to build these new services and that's something we and the other issue that uh Victor raised is the question of whether these should be governance processes which bring on new things or should we let permissionless open competition I'm very much on the side of like open Innovation we I think if you look at the the rate of innovation on the various layers of the blockchain stack you would see that the rate of innovation we saw in the tap layer is simply amazing you know you can take anybody else's ideas compost things on top and build new things whereas if you are a protocol Dev there were very minimal opportunities for you to express your like engineering and building skills because the only way you could do it is to go and start a whole new network and what we need is mechanisms by which we can actually massively accelerate the rate of innovation at the core protocol is because it's entirely log jamming the rest of the applications that can be built on top so we feel like as long as there is an attendant economic model to each of these middleware being built or for example on top of eigen layer that would be collect a fraction of the fees and only the remaining fraction of the fees goes to the stakers it could be hey you have a new token and you have dual staking you you stake your own token as well as you have each state so there could be a variety of different models in which these middle wires can become self-sustaining um but I but I do understand that there are some some examples for example flashboss has done a great job in stewarding Mev towards uh away from things like multi-block Mev where things and reorgs where things can get quite hairy and I think these should the the pressure on these things should be exerted socially rather than in terms of any kind of governance process what about you yeah I I fall on on that side of the camp I think it's really tricky to design good uh standards body governance bodies over you know anything but open source technology in particular um I think we're very lucky that we have sort of an ethereum core development ecosystem that's so committed to transparency and openness and it has allowed for a lot of these social consensus things to get expressed directly into how the protocol gets designed um you know all these wars and these arguments are having being had in the public can go away if there's this like formal process by which things get approved then the question is like you know what's acting and getting these things approved and like how it's it's a completely different game that isn't necessarily about public dialogue and discourse and um and that's a big part of it um I mean you know Victor you you helped out a lot in the development of um of an Mev solution right like the there was this um eth2 working group that essentially got started um maybe this time last year to develop uh the the Meb boost solution and bring all the the stakeholders in-house like what do you think is the role of all these different stakeholders continuing for it is it like you know you vote with your feet you decide which technology that you operate as a node operator which technology that you use or should there be some more active process for involving you know those views and opinions yeah that's a great question um it's it's hard to know but I think that as infrastructure providers what do we want is by large to be unopinionated and that we want to take open source software if we want to run it in the vanilla way in which it is designed and we don't want to ever express opinions over the state of the network and like what is allowed or not allowed or is on the Strip or any other properties and so when we think about the designs of these various softwares something that we think about is you know as interest providers if we know how to run infrastructure really well and so the things that we focus on are you know performance our security are like all these components that enable us to run great infrastructure but when it comes to the characteristics of the designer the trade-offs um that the that the design makes I think over there it becomes much more of a of a conversation and a vote with your feed kind of thing um and we actually we did have a a different map solution come and come and talk to us and they they came to us and they uh you know explain their their design to me and I was like that is completely uninteresting to me and that's that's something because they were like well I had 100 hit rate before I talked to you and I'm like yeah well here's why your idea is dumb and I'm not gonna do it this is why Victor makes the big bucks brutally honest yeah I'm loving but direct um and so you know I think that we we try to we try to influence as much as we can in a way that still allows us to you know remain incredibly neutral as infrastructure providers but at the end of the day we have to make decisions and I think that the decision that we make as infrastructure providers always have to be aligned with the long-term goals and health of the network and if we're not doing that then our business is dead and nothing matters so okay we're we're very much a Time thank you so much uh and thank you so much for the speakers really appreciate you thank you all right uh we'll be here if anybody wants to talk uh and if not we'll be outside and if not you can find us on Twitter and Telegram and all the things thank you guys thanks everyone