Season 5 | Episode 3
In this episode of Bell Curve, we are joined by a duo of special guests: Izzy, Lido Head of Validators, and Oisín, Co-founder of Obol Labs. Today's show dives into the current state of solo staking, distributed validator technology, the impacts of a staking router, and the future of Lido protocol.
- -
Timestamps:
(00:00) Intro: Pre-Interview
(01:27) Interview Start: Izzy & Oisín
(02:22) The State of Solo Staking
(07:37) The Importance of Decentralization
(11:33) What is DVT? 
(20:02) Reducing Hardware & Capital Requirements
(34:34) “Permissionless Ad”
(35:29) Impacts of a Staking Router
(46:08) The Diversity of Modules
(59:12) Lido Fee Markets & Governance Responsibility
(1:07:41) How Permissionless Can Validators Get?
(1:11:16) The Intersection of Liquid Staking & Restaking
(1:26:04) Recap: Post-Interview
- -
Follow Izzy: https://twitter.com/IsdrsP
Follow Oisín: https://twitter.com/OisinKyne
Follow Myles: https://twitter.com/MylesOneil
Follow Mike: https://twitter.com/MikeIppolito_

Subscribe on YouTube: https://bit.ly/3R1D1D9
Subscribe on Apple: https://apple.co/3pQTfmD
Subscribe on Spotify: https://spoti.fi/3cpKZXH
- -
Use code BELLCURVE30 to get 30% off Permissionless 2023 in Austin: https://blockworks.co/event/permissionless-2023
- -
Resources:
Obol Network
https://obol.tech/
https://twitter.com/ObolNetwork
- -
Disclaimer: Nothing said on Bell Curve is a recommendation to buy or sell securities or tokens. This podcast is for informational purposes only, and any views expressed by anyone on the show are solely our opinions, not financial advice. Mike, Jason, Michael, Vance and our guests may hold positions in the companies, funds, or projects discussed.

All right, everyone, welcome back to another episode of Bell Curve.

Before we jump in, quick disclaimer, the views expressed by my co-host today are their personal views and they do not represent the views of any organization with which the co-hosts are associated with.

Nothing in the episode is construed or relied upon as financial, technical, tax, legal, or other advice.

Hey everyone, welcome back to another episode of Bell Curve.

We have a very special episode lined up for you today.

So we're going to be talking to Izzy, who is a contributor to Lido, DAO, and master of validators.

We're also going to be talking to Ashin, who is 1 of the co-founders at Obel Network.

They, along with other folks like SSV, are pushing forth this idea of DVT, which stands for Distributed Validator Technology.

Similarly to the Hasu episode, what we're going to start with is kind of from a high level about why self and solo stakers are so critical to Ethereum, the credible neutrality and decentralization of the network.

And then we're going to be talking about how DVT actually works in practice, how it enables more solo and self staking, and what that could potentially look like in the future.

We got a very interesting timeline from him, so stay tuned for that.

I thought the staking router, I'm going to shout out Izzy here.

I thought he gave 1 of the most intricate detailed descriptions of how the staking router is going to work in practice that I've heard anywhere else.

And we really got into the nitty gritty of what some of these modules might look like and the idea of an internal fee market within that staking router, which I found fascinating.

All that to say, I'm going to do a super quick beta thing and tell you, you got to stick around to the end of this episode.

We talked about the potential of a restaking module within the staking router, and that was I'm still sort of thinking about the consequences of that part of the discussion.

So definitely make sure you stick around for that.

All right, guys, that's enough for me talking into your ears here.

All right, everyone, welcome back to another episode of Bellcurve.

I'm joined as always by my fearless co-host, Myles O'Neill.

Today, we are lucky to be joined by Oisin, who is the co-founder at Obel.

And today I'm also joined by Izzy, who is a contributor to the DAO and master of validators at the Lido DAO.

Super excited about this guys and really want to get into, I think the meat of this podcast we're going to be focused on, you know, we've been very focused this, this so far this season on this idea of decentralization as offense and want to specifically dig into this concept of dbt and how that's going to integrate with the staking router.

But before I think we even get into that nitty gritty, it would make sense to start a little bit at a higher level.

And I'd like to just ask the open question to the both of you.

You know, solo staking is something that's seen, I think, as being very critically important to Ethereum and the decentralization of the network.

And just kind of a high level question, I'd love to get a state of the union as it as it is on the state of solo staking.

What are some of the design decisions that Ethereum is making?

So I just want to communicate to listeners, like, what is the state of solo staking today and how are we encouraging that moving forward?

I think the status solo staking at the moment is in a pretty good place, or at least in my perspective, it's starting to like turn up the words and start to like kind of seeing a lot of growth.

I think over the 2 plus years that the Beacon Chain has been running at the very beginning, it was, you know, very solo stake dominated.

There was lots of, you know, true believers that were in early from Genesis.

And then over the kind of the course of a year or 2, a lot of the growth in staking has been more in the like big protocolized staking, the liquid staking protocols, particularly when there was no withdrawals and stuff, it was kind of more like safe to lean towards a liquid representation of stake.

But now that we have the merge behind us and distributed validators is starting to grow, we're starting to see lots of liquid staking protocols in particular really double down on getting more and more solo stakers involved.

And that's probably where I see things at the moment is there's a renewed interest in getting more solo stakers involved and getting a lot more client diversity in there than we currently are at so I maybe want to like toss it over to Izzy and see how he sees it from Louder's perspective but I'm relatively optimistic at the moment I think it's the busiest has been a number of years.

Yeah I think Ashin makes a good point that we kind of started off with all of the protocol diehards or the people that really believed in this effort, who also had the technical acumen.

And that's kind of like the Genesis validator set, which consisted majorly of solo stakers.

And then we kind of saw a transition, you know, like as proof of work theorem and proof of stake theorem were running in parallel, where let's say larger organizations or at least more professional staking organizations started to get their presence on the network, largely because of like the technical acumen.

And So it's much easier to start, for example, validating on a new network if you already know more or less how to validate.

Whereas for solo stakers, it's kind of like a natural ceiling of how many people are technically able and willing to take a certain amount of technical risk involved with regards to running validators and also putting that much Ethereum at stake.

And I think there's like a couple of events that have happened since the genesis of the beacon chain back in December of 2020 that have really made it a lot easier for solo stakers to participate.

So 2 of those are obviously 2 of the large Ethereum upgrades that have happened.

So the merge itself and also the introduction of withdrawals that have meaningfully reduced the technical barriers and risk surface area that solo stakers would need to be wary of.

There are also more minor upgrades throughout this.

So for example, we started with 0x00 withdrawal credentials, so the so-called BLS withdrawal keys.

And now validators are spun up with 0x01 smart contract withdrawal credentials that are a lot easier to reason about and a lot easier to secure and things like that.

So I think that has also made solo staking easier.

And then of course, we've seen a lot of maturity in terms of like the tooling and client software that exists around running validators.

Arguably, in the beginning, the client diversity wasn't so great because there was obviously a few clients that were more mature than others.

But since then, we've seen not only new clients enter the space, but also the really, really amazing evolution and growth of a lot of the other clients.

So there's at least 4 or 5 clients that are almost at parity, I would say, both in terms of feature set and in terms of how easy they are to use.

But we also have tooling that rests on top of, or to the side of these clients.

You know, it might be like Docker installations that you can use or front ends that allow you to kind of like set up your validator however you want to set it up with things like Avado or Dappnode.

So all of these kinds of things coming together are culminating in what I would say is kind of like a reintroduction of a new set of solo stakers to the protocol.

So people that have been learning about Ethereum and proof of stake over the last 2 and a half years, but also now that have much more tooling and knowledge at their disposal to be able to feel safe enough and competent enough to dip their toes in.

So we see that liquid staking protocols or staking protocols in general are also meeting this kind of like renewed demand for solo participation, which I think is vital to a network like Ethereum, by adding new ways for people to participate.

And Izzy, I think you touched on a critical component, which is just reducing the complexity overall for solo stakers.

And maybe we can get into almost a setup of what a solo staker requires today.

But I would love to also get a sense of, you know, Sriram, who Miles and I are going to talk to on the next episode, who's obviously the founder at Eigenlayer, talks about market forces.

Actually, you might have dApps in the future that want and will actually pay a premium for a block space that's more decentralized and perhaps run by solo stakers.

I think the idea here being that, you know, what I'm trying to get at a little bit is sort of the core reason why Ethereum wants solo stakers, which I'd always thought of as you want this to be a robust network, both and robust in some senses mean it's geographically distributed and it's not easily shut down, you know, against some sort of government intervention.

I mean, how do you guys think about the sort of need overall for Ethereum to be decentralized and the key role of solo stakers?

Is that about right or are there other components that I'm missing there?

So maybe I can take a first stab at this and Ashin can follow up.

There was actually a recent podcast that Justin Drake was on where he had a take on this that was perhaps a little bit spicy.

So he basically said like the 2 most important things for or I mean, paraphrasing or at least the way that I understood it, just to make sure that he doesn't get mad at me.

Like the 2 most important things for like a truly decentralized and robust like blockchain are censorship resistance and credible neutrality.

And decentralization is basically the most surefire way to get those things.

But it's not absolutely necessary if you somehow find a way to get those in another way.

To a certain extent, I think that's true.

But I think the fact that decentralization is so important and baked into the ethos of a lot of these initiatives and projects that we're doing to revitalize financial infrastructure means that decentralization always needs to exist, at least in the form of the common person being able to participate in the network as a buffer against credible neutrality or censorship resistance at some point being capturable or attackable.

You kind of always need this security mechanism, if you want to call it that or perhaps in the parlance of like American constitutionalism, like a second amendment right for a militia of people that are always going to be there to uphold the values of this kind of like digital sovereign.

And I think it also really ties into this idea of what we're trying to do with crypto, right?

The idea that everybody can participate by helping disintermediate power.

And the best way to do that is by having as many people involved as possible.

I know that that might sound a little bit contradictory coming from somebody that, you know, participates in the Lido DAO.

But What we're trying to do, so like, actually, Mike, I think this might've been a conversation that we're having a couple of weeks ago, but there's this kind of like this idea, like there is in Jurassic Park, you know, where there's this quote that life finds a way, like money finds a way.

So what all of these systems are trying to do is ensure that there's like risk management and principled ways to, let's say curb the most pernicious effects of the financialization of things while empowering people to participate in these ecosystems, to secure these ecosystems, and to have like a voice and power in everybody's collective future.

And so I think to that extent, that's why solo staking is vitally important and why networks like Ethereum that have to a large extent, bar some hiccups, let's say, or technical design decisions that have been built around the idea that anybody should be able to run a node and that many, many people should run a node is why they're so successful and have so much cultural mindshare within blockchain ecosystems.

Izzy, you just reminded me that I even secured your permission.

I love that quote, so much money finds a way that that was going to be the title of this season.

So I'm glad we at least worked it into this episode, because I like that idea so much of money finding away.

And I wanted to start this conversation by just, you did a great job, just highlighting why solo staking is so important.

And I think 1 of the big, the big hiccups to that or roadblocks, if you will, is just many, there's a limited number of people who are competent out there to run the sort of hardware requirements.

And that's where I want to segue into dbt, which is short for distributed validator technology.

If you hadn't heard about that before, my guess is that you're going to continue to hear about that quite a bit in the coming months and years.

And Oisin, you and Colin at OBL and other platforms like SSV have been pioneering this idea.

So can you kind of just give us the broad strokes of what distributed validator technology is and how it actually accomplishes that problem of, or that solution of encouraging more solo staking.

So distributed validators are the idea of running an Ethereum or any other type of blockchain validator on more than 1 machine instead of them just being like 1 single server.

What's nice about this is you can then introduce fault tolerance where if 1 of your machine goes down, you'll still be online.

This is something we don't have in the web 3 and proof of stake space as of yet, to my knowledge, the vast majority of proof of stake chains, your validator is 1 private key that signs messages and different chains punishes downtime more or less severely.

But Ethereum is 1 that will punish you if you're down for even kind of 6 minutes.

So what distributed validators do, most validators and most servers, machines die all of the time.

You know, don't expect your server to stay on and not need an update and you know never need touching for years at a time.

And if you're a solo staker, you're basically on call

And, you know, if you want to have uptime like the professionals, you need to have redundant hardware, usually ready to go if a drive dies, or you want to be on call being able to be, you know, woken up in the middle of the night if you go offline.

None of these are, you know, super scalable for a one-man solo operator or something like it.

So when you have distributed validators and you're now working in groups, If your node goes offline, no big deal.

The other 3 will keep it up and keep it on.

This is useful, you know, just generally for having better uptime.

The example I can give is I've been running as a solo staker and as partly as an enterprise validator since Genesis.

uptime for the last 2 plus years, whereas the solo node is at about 97% because machines die and I'm not always around.

But with DVs, the goal is that you can get up towards 3 nines and more of uptime.

And, you know, a group of home stakers should be as effective as, you know, your professional operators.

And that's kind of what DVs aim to achieve.

And it's the goal is that, you know, solo staking, you know, you more or less never go down so long as you have a group of people working with you or squad staking is often being kind of picked up as the naming for it.

Yeah, I think that's kind of a short description of distributed validators.

I want to actually get a little bit more in the weeds with you here.

And 1 of the questions that I think Miles and I want to drive towards here is just exactly, not even in the current state, but the future state of how low could we get the hardware requirements implementing something like dbt?

I mean, is there a future here where solo stakers could be running some of this stuff basically on their cell phone?

But before we get there, I actually want to just make this a little bit more concrete for what OBL the protocol looks like.

And I know there are sort of 4 main components here.

So, you've kind of got the dbt launchpad and user interface.

You've got a new custom middleware client called Karan, I believe I'm pronouncing that correctly, Obel managers and then Obel Testnet.

So could you kind of just walk us through the core components of the protocol and if I missed anything.

Yeah, I just wanna give listeners a little bit more of a concrete sense of what this is gonna look like in practice.

So I'll start up at the high level with the user interface or what we call the distributed validator launchpad.

So, this came out of a problem where you want to work with other counterparties, but you need to trust them, or at least you need to figure out what you're going to do together.

Is this going to point at a certain particular withdrawal address?

So we originally did all of this on the command line.

You'd kind of prepare this, look at like long bytes of strings and stuff, but it's really difficult to kind of be confident that you're setting up what you expect to set up with, you know, other counterparties if you're just looking at kind of output on a terminal.

So, we developed the distributed validator launchpad, which is a spiritual successor to the Ethereum launchpad that was put in place by the Ethereum Foundation and Consensus and others at Genesis.

And The idea behind it is it's meant to be user interface to walk you through the process of setting up a distributed validator.

To use it, you log on, 1 person makes the proposal.

So they might say that, hey, Mike, Miles, Izzy, and myself, we're all going to run a distributed validator together.

I say we're gonna make 10 validators and it's gonna be on mainnet and we're gonna send them all to this nocisafe address.

Make sure I'm not trying to send this to my ledger or trying to kind of bait and switch you guys with what we're supposed to be setting up.

And once everyone is kind of approved and signed off that they like are happy with the terms and conditions, you then move over to the command line and to Karon, which is the like software client.

It sits in between your consensus client and your validator.

So it more or less is just an extra piece of software that you put on your node, kind of like how MEV boost, you kind of add in.

And 1 of the jobs it does is it will facilitate the key creation for your validator, meaning what's special about a distributed validator is there is in the happy path or the way we encourage people to use it is there's no 1 human with access to the private key.

Instead the 4 of us would all come together, we'd run a bit of software and it would spit out, I call it 4 one-thirds of a private key.

It's not quite exactly how it works, but everyone, like each of us have a piece of the private key and we need 3 of us to put together the full private key.

That Even day 1 has you in a much safer place when it comes to getting compromised or if someone like stealing your private key and getting you slashed.

And at this point, yeah, you're now looking at like you have a deposit data, you want to activate that validator.

Maybe this validator is working as part of a liquid staking protocol.

Maybe it's not, maybe it's just a custom 1.

The Obel manager smart contracts I alluded to, these are splitter contracts for the most part.

We have a few different varieties in the works that we're hoping to kind of show more of the world soon enough.

But this is the idea of, you know, do we guys want to split this 25% each way?

Are we all contributing different amounts?

Maybe we're doing this on behalf of somebody else.

So that somebody else gets 90% and we're splitting

That's kind of where the manager contracts come into play.

And then the test nets is tooling related to letting people run this and, you know, ensure that this is going to work for them, get them to kind of learn how to mine DVs and work with 1 another so that they can do this in production.

So that's kind of a, well, I will say that this is a tour of kind of where we're at currently with our, you know, OBOL as a protocol.

1 of the things that we didn't mention here more broadly is in the kind of earlier versions of distributed validators, You need to trust your counterparties.

If Miles goes offline, you have to kind of hit him up and telegram and be like, hey man, your node's offline.

yeah, if you leave it offline, there's nothing, a whole lot we can do to kind of force anything to change.

But in the future, we're working on succinct proofs of who is online and who is offline.

And that eventually it's like, okay, if Miles is off for a week, he gets penalized and we get all the rewards.

But to do that in an ungamable manner that you can't kind of cheat is quite difficult.

So that's why we kind of refer to that as our distributive validator protocol or kind of our future version where we get this, you know, it's all in cryptography.

There's no human kind of social layer consensus going on.

I think that's a great overview of kind of where we're at today.

And, you know, and I think about the barriers to, I guess, making self-staking more prevalent.

I think about 1, the hardware requirements to the actual capital requirements.

And you've already made great progress in bringing that down from 32E.

And then 3, just maybe the natural incentives for folks that are not, you know, naturally passionate about this technology and decentralization of the network.

But just starting with those first 2, you know, if I could ask you to look forward into the future a few years, I'm very curious to get like a sense of how low we could get the hardware requirements and as well as the capital requirements.

You know, it's just something that 1 day we could run on our phone, like the Solana phone, or some version of that, or, you know, if I have 1 ETH at some point, will I be able to, you know, maybe mint an LST from the staking router?

So, love to ask you, project for it a few years, and how you feel

I don't even think it's a few years more likely.

So the first 1 of running on a phone, I think you make a great point there.

This is something that distributed validators, I think, is very beneficial for.

There's been lots of people that have worked on building clients to run on very low resource hardware, but you don't want to cut it too fine, you might say, or at the very extremes, particularly with mobile, your internet is connecting, disconnecting, you're not going to be on

So we think running low powered validator nodes is much more suited to run in a distributed validator than to run something like full and solo.

Particularly if you're a solo staker trying to run this all yourself, you're like, I want full tolerance, but I, you know, don't really want to run some, give it to someone else.

I run them on, you know, my house, my friend's house, my phone, and, you know, some other thing.

That's kind of how you can have lots of fault tolerance.

And then on the capital requirement side, I think that is also something that can be mitigated by distributed validators because you don't have to have the same amount of bond If somebody isn't like, you know, God mode over this validator and have total control, if they're just kind of, you know, 1 piece and you assume that even if they were offline malicious, you know, worst case scenario, they're, you know, not harming the validator too broadly so long as there's not a few of them that are offline, it really reduces the risk profile of actually bringing them in and delegating some other stake.

And I maybe want to throw it over to Izzy on that regard because collateral requirements for staking is a kind of a big testy subject when it comes to like delegated staking and should validators be collateralized, you know, Lido famously is not, but they have, you know, plans both for collateralization and also for how solo stakers can get involved with and without collateralization.

So maybe we want to see how he thinks about DVs and its impact on hardware and collateral.

So maybe even going back to like 1 of the original questions, which is what is the presence of, you know, solo stakers on the network right now?

What are the barriers for solo staking existing?

Because that ties into like the whole question around bonding requirements.

So apart from the technical complexity and the operational complexity, which is much reduced and also the technical service risk, which is also much reduced due to the recent Ethereum upgrades, we contend with the issue of financial approachability of the enterprise of running a validator.

So obviously if you were solo staking, you needed to not only have 32 ETH in order to be able to run the validator, but you needed to have it in the beginning.

So it's really hard to borrow it and then run a validator.

And so what a lot of liquid staking protocols basically did was allowed people to participate in the grander, let's say, collective enterprise, not in the sense of a business sense, but like a community effort of securing the Ethereum network without necessarily having that minimum

Obviously distributed validators like Obel is working on, or even like SSV is working on, allows users to do this by putting their money together.

So like you split the 32 ETH into multiple smaller pieces of a deposit, depending on how many people participate in the cluster.

And then therefore you can have like collective participation of 1 full node via more participants as opposed to 1 person needing all of that capital.

And then you also have like permissionless liquid staking models like Rocket Pool, which also has been very, very successful in terms of adding that new node operators to the network.

And I think there should be lauded for that, where basically you had a capital collateral or bond requirement where a node operator or at least a capital allocator associated with this node operator puts up a certain amount of money.

And then the remainder, let's say, of the balance on that validator can be can come in from injections from stakers.

So normal people who would participate in LSTs.

In general, when we started with, and by we I mean like in Ethereum staking as a whole, with permissionless bonded validators, this bonding requirement had to be very, very high, right?

And Now we've seen that liquid staking protocols have started to reduce this bonding requirement based on a number of different factors.

So 1 is obviously the maturation of protocols themselves, but also the underlying network layer.

A second thing is that there are upgrades in the works that will potentially make it so that if a node operator like disappears or is unrespondent or like loses access to their validator keys for some reason, the network will be able to issue a command to this validator via the execution layer, which means that liquid staking protocols can do this via smart contracts to eject these validators.

And so we call this like triggerable exits.

And this is an EIP that will hopefully come sometime next year, a couple of hard forks perhaps after Dan Kun or maybe even the meter hard fork after Dan Kun.

And there are so that in concert with a lot of other things, for example, that historically we actually haven't seen that many slashings and slashings.

It's very, very difficult for them to ramp up to the amount of like slashing a full 16, not a full 16, but up to 16 ETH on a validator has basically led protocols to do like a risk adjusted implementation of what is the sizing that bonds should be.

So obviously like the main thing that reducing bonds means is that you lower the barriers to entry for interested participants, right?

It also means that there's a corollary that the people that have already put up the bonds can basically just multiply the amount of validators that they have using the existing capital by rolling it forward.

But that's also not necessarily negative, providing that these people are actually independent node operators and smaller organizations.

And distributed validators adds an even more interesting aspect to this.

If we get to a point where risk analysis, for example, after we have EIP 7002, which is the triggerable exits functionality that we were discussing, allows you to exit validators and this happens, let's say within a year, and everybody collectively believes that this will happen within a year.

See all Bell Curve transcripts on Applepodcasts

The Staking Router + DVT: A Seismic Change for LSTs | Izzy (Lido) & Oisín (Obol)