Welcome to epicenter the show which talks about the technology
is project that people are driving decentralization and the
blockchain revolution. I'm Felix.
And I'm here with mayor Roy. Today, we're speaking with
Colleen, Myers and ocean keine, worte cofounders of mobile apps.
Mobile is building software to enable distributed operation of
validator. He's starting on aetherium.
Hi, ocean. And hi.
Colin and welcome to epicenter. Hey guys, thanks for having us
pledge to be here. Yeah.
So both of you actually were in touch for like a long time.
You've both been in the space and in staking, especially for a
while. So, you know, as is customary on
epicenter. We'd love to first, get an
introduction to how you, how you got into crypto, and how you got
to where you are today? Maybe calling you can even start
Yeah, cool. Yeah, thanks, thanks for having
us again. I have been watching and
observing epicenter for from a distance and always wondered
when we get our shot. So, yeah, happy happy.
I finally came. Definitely on the longer end of
the spectrum, based on my expectation set.
But yeah, happy, we finally made it happen.
Yeah. So quick, quick background on me
actually. Non-developer by background used
to work on Wall Street worked in a variety of different banks.
It's mostly in like credit and debt and got involved with
etherium Community 2017. I was living in New York and,
you know, lucky for me, there was consensus, and there was Joe
Lubin and there was meetups and you know, it was different stuff
happening and at this point in my life like 2017, I was trying
to spend a lot of time, you know, trying to work at a hedge
fund or a private Equity Firm or actually, honestly, just totally
lost it still like, what I was supposed to do, and There was
two things going on at that point in time, one of them was
we work and the other one was crypto in New York and those
were like the two main things that everyone was buzzing about
and work worked in trying to get a job there but also spent most
of my time on it period 2017. I met Joe living in a Meetup was
inspired to quit my job. So I did then I joined consensus
in 2018 and I worked there for about three and a half years at
consensus, was able to work on a lot of different.
Technologies even like space and blockchain and some crazy stuff
like that but primarily focused on staking I started a project
called token Foundry which was like an early mover in this
space to helping Network's launch and trying to do
compliant token launches turned that project into a project
called activate which was recently sunset by codify
something. We actually partnered with on
course one in the early days and throughout those time periods I
spend a lot of Didn't time contributing to eat to was
involved in early working groups.
After Devcon for, and I primarily at the beginning
focused on the economics of E2, they were not very well
understood and my job was to help enable the understanding of
the economics. For your at-home.
Validators for your larger scale, validators, your
exchanges. People like quite basic
consensus and these different types of actors.
Those initial work streams led to a lot of different enablement
projects around the Genesis event.
So the majority of my time was spent around the Genesis event
and enabling that to take place while it consensus.
We built the eats you launch pad, which is so individual
place where you're at on validators.
Interact with the deposit contract, spent quite a bit of
time with the client teams and help them with user feedback.
And ultimately all of these research projects culminated and
what today is Is now DBT. 2019, dr.
Fights. And curl be started to research
group focused on trust minimize staking and Marsh meet and
myself, were the first two to come in to help enable that.
After it, got completely sucked down the rabbit hole on DBT,
thought it was world changing technology.
Three years ago, no one had any idea what we were talking about?
It was kind of grossly underfunded as an effort and
ultimately the The only way that we found proper funding to turn
DBT into a project was by ocean and I both quitting our jobs
respectively and going out and, you know, raising capital on our
own and finishing the effort and putting the group of people
together to make the technology a reality.
So, yeah, that's me. Thanks for having me on.
I'm a neat Maxi, loving Cosmos these days though, but yeah,
really excited about it. And then yeah, to give my
background, I'm a software developer by background and in
fact, I'm the fortunate person who's like, second generation
internet entrepreneur. My parents have run web
companies, most of my life. So yeah, would have grown up
around kind of original website, building web design and the like
late 90s early noughties. And so, I kind of sass companies
built in the kind of notice and 2010's and out of college.
I worked as a consultant and kind of discovered.
Crypto in 2017 and got my first kind of full time role in 2018
when consensus opened an office in Ireland, and I did two years,
they're in their tokenization Department, we did some
projects, very tokenized Securities for French real
estate on maenette back in 2019, before that was prohibitively
expensive to do on my net, and I left consensus in March, 20, 20,
and I Incorporated myself as a self-employed kind of
contractor. Picked up by black demon to do e
to research for them back in 2018, when the originally two
specs came out my I wrote an article that was effectively
quite critical of them. At the time, it was 1,500 either
minimum and Sachin was fairly severe.
And I was like really do bees with this was going to be safe
or make sense and then yeah, I kind of kept an eye on it.
Got involved with block demon building it along and end up
building out their teeth to stack for them. by Genesis and I
say shortly after Genesis I was first introduced to the idea of
trust was validators by getting an invite to this trust was
validated Community Hall that common Ameri running and at the
time I was kind of agonizing over having no ability to run a
backup validator or do anything when one failed and I was
introduced to this technology and it's like, oh it's high
availability for validators, is definitely going to be thing
everything in web to does this and I was kind of an immediate
convert but yeah I think Colin realize it's not very many other
Where yeah, we took me maybe a few more months of kind of being
involved. I was trying to make an mft
issuance kind of Stack. I did some work trying to issue
like rugby video and ft's with some kind of like, famous rugby
players that didn't really go to plan.
And then someone once approached me and asked me to make a nearly
20 token for to represent steak, and I kind of counter pitch them
and try to make like NF teeth to represent validators.
And then, yeah, it, I wasn't Really very good at selling any.
This idea had a product but I had no business Acumen and I
realized that I wasn't really very correct for the whole CEO
role. So I reached out to one of the
only business people I knew in the space, who's Colin because a
couple of people have been kind of pushing my me his Direction,
and I was talking to about what I was doing.
Yeah, she'll be what he was working on and what I wanted to
do with oh ball took me a few weeks to get convinced that it
was not too hard to attempt. And yeah, I think we kind of
started around April 20-21 together and here we are met. be
2 years later, but more Awesome. Yeah that's a rich history.
You both have and thanks for going too deep into it, I think.
Yeah, we personally also have worked a little bit on high
availability of a validation. So like we're both very excited
about this episode so yeah I can to get into it right?
So I guess maybe we can start there.
We already mentioned DVT a bit. Maybe.
Can you explain? You know what is distributed
validator technology? Yeah, cool.
I'll give kind of a more macro perspective, is to like the
difference between a normal validator, and then, oh, she can
get a bit more into like technical architecture and
deployment and stuff. So, today, a validator consists
of three pizzas. It is a public-private key pair
is a machine and it is an agent, an agent.
We look at is an individual or an entity.
So it's three things and all of those are super monolithic and
that's just The validator stack of today from an Indian
perspective, what DBT enables is a more modular validator stack
and now what happens post DBT is you have key shares, not just
one public-private key pair. You have a collection of key
shares as many as you'd like to create based on your trust, you
know, properties. Essentially, the next piece is
that those key shares then can go on multiple machines, not
just one machine, but multiple machines, and then third, and
lastly, this salad Can be run by a group of people or a group of
entities. So it takes your modular
validator today, super monolithic and it takes it to
the more modular version where you can have multiple key
shares. It increases your security, you
can have multiple machines and increases your availability and
you can have multiple people or entities.
Therefore increases kind of your game theory or decreases.
The chances of Byzantine behavior for that validator and
I'll give it to a sheet and you can go more Linda kind of
technical talk. Yeah, I think an epicenter
podcast. Maybe one of the only places
where I can talk about their like nerdier details of this
rather than the high-level idea. But yeah, I think one of the
interesting things about it or what, you know, makes these
distributed validators more possible than they might,
otherwise be is the cryptography that etherium to, I should
probably stop saying the word of to use as proof of stake
etherium. And that's the BLS signature
scheme. What's so fancy about the BLS
signature scheme? Is it's one of the first signal
like elliptic curve signature schemes.
Where if you have, you know, independent signatures all for
the same. Hash you can actually like add
them together in a low trust environment.
You don't need the original private key to do so so what
happens as Colin alluded to is you know you want to set up a
distributed validator. The first thing you probably do
is a distributed key generation unless you want to just spit a
normal key locally, but it's better if you kind of do one
with the dkg, then at the end of that process, there's you know,
let's call it. Or machines to keep it easy and
each with the piece of the private key on it and you have a
piece of software in the middle of your validator stack between
your like consensus client and your validator client and it
these four nodes can be like connect to one another over like
TCP and they more or less play a little consensus game to decide
what they're going to sign. Every time that there's a
validator Duty coming up. They play little consensus game
pick. This is the hash we're going to
sign and then every valid are client Even the exact same, you
know, hash to sign. They all, you know, check it for
slashing rules, do all the usual things.
What's nice is everyone gets to keep their own private Key
Management. You know, the oval software is
just kind of read. Only the Middle where it doesn't
actually have the power to sign anything.
So all the independent validators, check that nothing
flashable. Once they're happy, they sign it
with their piece of the private key and they broadcast to what
it looks like their consensus client.
And then in the middle, there are software like intercepts
them. Share them around with the other
machines. And once any of in this
instance, like a four node cluster, 13 of them like this.
Three of the signatures of together, you can combine them
into a full, valid signature, for the validator, and you can
send that on which to the network.
And what's neat about that is, you don't need all four
signatures. He actually can have fault
tolerance and this is kind of one of the super important
things about high availability is if you put, you know, a
validator and for machines, but you need all four of them to be
online, you're more brittle than you would otherwise be, but he
put in for Machines and, you know, only need 3 to be online.
This is where things really start to change and you can have
high uptime. You can do rolling restarts, you
can replace Hardware that fails without downtime, and, you know,
all of those good things and are kind of unlocked with
distributed validators, So from a user perspective, if I
mistake, ER, generally the options I have today is I can, I
can either put it into a liquid sticking protocol.
The line item would be the biggest of them I could go to a
specialized validator shop, like a block demon, of course.
And I could spend about a P2P when I can spin up my evaluators
there, or if I am usually technically competent than Then
I can run my own validator. I've actually curious and of in
these three, three, kinds of segments.
Let's imagine that being liquid sticking as one segment.
The other being the specialized validator, that's, like hosting
validators for you. If you have 32, eat third
segment, being you want to run your validators at home, How
would these three segments, kind of use this technology?
And what difference would it make for them?
Yeah, it's a that's a good question.
So I'll talk a little bit about like our adoption path.
So far the earliest adoption of oble has been at home
validators. They're the first ones to have
put it on maenette, we put our first ones, you know, I'm a net
between core team members all running at home and now kind of
the adoption evolution is now getting into your hosted person
and you know your liquid steak pool.
Like what's taking place or kind of the earliest adopters of the
idea and supporters of it being in their road map?
So the I'll start with the at home validator, which is quite
interesting. So today we got home, validator,
for example, like pushing grunts grunts one out of his house and
like, we travel a lot today for for, for like purposes of oble.
And it's always, it's like kind of chronically offline.
It's kind of this thing that you have to worry about it.
You can't really have peace of mind for being an at-home
validator today, which is something that like DBT can
unlock for you, right? You can have your at home
machine, you can run backups inside of the cloud in an on /
about way so that you can ensure you can kind of live your normal
life. The other side of the at-home
validator is Persona type of I don't have 30 to eat but I trust
myself to run my own machine and there's actually like quite a
lot of those people and they can You zobel to come together to
like create their own shared validator because they may not
be interested in taking on the risk of the pool.
And you know, they may not need a liquid stake token but they
don't have 32 week and that's kind of the squad staking
concept which we've seen honestly take off quite a bit in
the at-home validator category which is you know a whole group
of people who's like you know some of my eat is in a pool.
The rest of it, I just want to run myself but I don't have a
full validators work which has been quite interesting so yeah
it's peace. Mind.
But then that second user group is actually where we think most
of the tail end adoption for DVT will be in like 10 to 15 years
is like enabling just groups of people to get together to run
their own machines and giving each other fault tolerance and
like a human to human manner. So yeah, a lot of early adoption
there but the middle adoption of DBT won't be there in my
opinion. They're like the early
enthusiasts. They're the ones that help set
us up our primary duty is to figure out how to give you at
home. Validator more tools to get more
Them online. And now we're bridging more into
the hosted and like liquids taking full category.
So now I'll get into those two different types of users and you
know why it's beneficial for them for your liquid staking
pool. It is actually the most
Innovative use case of DBT today because most of the pools are
using it for its Byzantine properties which is quite cool.
So the example I like to give is let's just, you know, use a
hypothetical liquid state. Pool today, there's 10
validators inside of this liquid, staking pool, all of
them are supplying their own, you know, keys to the system
keys that they create keys that they manage and keys that they
run on their machines again, in a very monolithic environment.
And the reality is, is that like, in each in this liquid,
like this hypothetical liquid staking pool, each of those,
validators would have like a certain amount of steak that
they're responsible for, and that person can actually self /.
They can be You know, they can sabotage, they can act
malicious, they can't take the phones, right?
But they can shut the machines off, and they can like bring
penalty to the greater pool. If you will, when most of these
pools you social economic, so it does mean that like it could
take, you know, it'll hurt every single participant in the pool.
If one of these validators defects and it doesn't even need
to be malicious, right? It could also be a bad day at
the office where like, you know, all your servers crash and
everything goes down or it could even be catastrophic.
Right? Like you have a rogue employee
who steals the keys and, you know, there's a variety of
different things that can happen inside of that, construct.
So when DBT enables is that, that group of 10 people can, now
just share one validator, which like creates this whole new
defect in Game Theory between the different operators in that
cluster. It gives fault tolerance and it
makes it essentially, I hate to use the word impossible but it
makes it very, very difficult for 81 validator in that group
to do. Do anything malicious or
defective to that pool. So that again like its
availability and slashing protection, reasons and
utilizing it for the fact that there's a consensus mechanism
and it prevents Byzantine Behavior.
So it's one of its true, you know, corporate motives the
other reasons that they're using it as not only for that but
they're using it as well to decentralize their validator
set. So if you're going to build a
liquid, staking pool that wants to be very decentralized, then.
You're going to have to invite, call it middle to lower to sub.
Tear validators to like decentralize the validator set
over time, and you need to do. So, in a way that protects the
pool, especially if it's an existing pool.
And most of the pools today, like my granny DBT, our existing
tools and there's lots of money inside of all the fun, right?
So, if you are going to let new validators in, you need to let
them enter the pool in a manner. That does it hurt the pool and
DBT is a great way to do that because you can just build some
shared values. Alligators, you can partner, you
know, three highly proficient people with one newcomer and
then, you know, you have some fault tolerance.
There's some give there if they make an error Without Really
harming the pool. So yeah, the decentralization of
the validator said is also a very interesting one for pools
and the use of it for its Byzantine properties your
hosted. Service provider is actually
someone that we thought would come later in the adoption
cycle. However, they've come in quite
quickly and it's a factor to do with the centralized staking
product or the hosted product is was the first product in the
industry. It's been competitive for a
number of years now, it's like entering it's fairly normal
maturation, cycle of compressed margins and increase costs.
And now those products like need to mature themselves in a way
where they decrease their costs, but they improve their security
as being a centralized for Vidor like requires saw to Sock one
compliance. These things help to kind of
institutionalize yourself. And most of these people have to
offer some type of off chain Insurance mechanism, which is
quite costly to do, or you just have to be pretty well, you
know, bankrolled. So, for these users, their
maturation and growth is meeting DBT, kind of in the middle and
they're experimenting with it to help scale their operations in a
way, where they can decrease the amount of machines, they Need
for a certain amount of each while also, increasing the
security profile of that setup. We've seen a lot of interesting
things recently in the insurance and reinsurance topic around DBT
offerings, taking insurance has been difficult historically
because, you know, the definition of a bad day at the
office is losing all your Easter potentially, but that was just
at the beginning. And now, we're as a community
DBT, being one of those Technologies building things,
Like alleviate worst case scenario of like you know losing
all your needs. So insurance providers have been
interested in kind of including DDT into their criteria of
providing Insurance because it gives them more assurance that
like, you know, you can't lose all of it.
It's not an absolute loss situation.
So you know. No insurers.
Going to ensure something that's an absolute law situation and
Technologies. Like DVT have now come in and
helps like alleviate that so yeah.
The Three core user groups. I think the fourth one I'll
mention is kind of defy and how defy has thought about using
DDT. So like in most D5 projects
today, you're like taking an asset in your wrapping it or
you're taking a collection of assets and you're pulling them
together and you may produce a stable coin from it, right?
Or you may produce other streams of yield or income off of a
collection of tokens, the collection of tokens that people
are using today. They are LST tokens like would
stake tokens and they're doing a variety of different things with
them. Those products since there's a
product built on top of it, it's better for those products at
those liquid state tokens RSD wrist as possible.
And now, people are looking at what is their risk criteria and
mostly they haven't been looked at the only risk criteria that
an LST token has been looked at to date is liquidity because
that was the biggest risk. Right?
How liquid is this thing? Like, what does that look like?
But but now it's more Or less like okay, what are the
potential penalisation properties of these lsts and
under the hood? Like what types of security
protocols and parameters? Are they using for it?
So now we've seen D5 who has like its own interpretation of
bris. Honestly.
Probably a more mature interpretation of Chris than the
validating community. And now DBT is kind of come into
their Spectrum over the past, call it month or two, which has
been very interesting for them to want to include.
Glued it in their ecosystem and to learn more about it.
One of the downsides of a DVD like setup is that it adds extra
cost. Meaning you know what's the
what's the other case? Let's say you have a hosted
service provider and they're running a validator on some some
Cloud probably Amazon or Google and they have an engineer there
for up time and they're running it on a single machine.
They won't have 100% uptime, but they will get to somewhere
higher than 99% of time just on on on that sector.
Now, when a, when a DVD set up comes into the picture, you're
running like three or four machines and usually spread
across different parties and you're also adding some kind of
key setup and key tear down cost, right?
Like, probably the setup of these systems will need some
extra extra work. It's one of these cases where
you are adding fault tolerance, but you're adding cost.
And sometimes the custard customer cannot perceive the
extra fault tolerance meaning that they will go to some kind
of log explorer that will say, hey what are the returns of the
validators and the evaluator, with 99 up percent of time
running on one machine, they return will be X and then they
will see the DVD set up and it might be marginally better like
X Plus in 0.1 percent or point zero five percent.
How do you have a dress that address that At issue.
And do you see that issue in in practice?
And what does it mean for the different parties and you might
end up DVD? I love this question because it
actually pushed back a little on increasing cost.
You're writing that increases Hardware.
But depending on what people have done before hand, it
doesn't necessarily increase their cost and what I'm kind of
getting at you. Kind of talked about it in the
cloud is originally without distributed validators and the
real problem was that there was more or less.
No safe way to run a backup and the only kind of option.
You had was do some sort of monitoring game and pray that
you're monitoring is you know, a perfectly reliable.
And there's not a scenario where you turn onto machines the same
private key at the same time and and the problem would not be
able to run a backup. Is it can be very hard to
recover from a failure and particularly if you want to use
something like a bare metal machine and like a data center
somewhere, that's usually one of the more low-cost ways to run a
server. And the problem is, if you do
put, you know, particularly large amount of private keys on
a bare metal server, like that, and it just goes, Flying which
is regular occurrence of probably happen at least once or
twice a year and you just kind of have to sit in your hands
there's more or less nothing. Say if he can do at that point
well you can try and bring up a backup and hope to shut down the
back up before the primary comes back.
Or you can bring up the data center and ask them to kind of
go and like pull the plug out of the wall.
And but this not being able to like run a backup and has
changed a lot how people have, you know, build their
architectures in the early years and most of these centralized I
say Moses not quite true. Lot of centralized providers at
least started running in the cloud and particularly because
then, if you do have a failure of machine, you can kind of
detach the disk, you know, it's all in software, you've a lot of
power to kind of actually recover things that you don't
have when it's just a server sitting somewhere.
And but the problem with that and you kind of alluded to the
fact that they might run one machine.
A lot of people, they'll have at least a few servers in the
cloud. Normally they'll have kind of,
at least two, the runs going to Els and ciel's and which is kind
of the Meat of it, then they'll have a machine with their
validator on it and plausibly, they'll have some more with key
manager on it as well. So a lot of people like kind of
Enterprise taking validate. If you talking kind of 327 Cloud
servers and Cloud Server, the much more expensive than a bare
metal server. Rule of thumb, think about 10x
more, including one of the real kickers is bandwidth costs which
I'm sure you guys are familiar with egress but that can often
take up Scent of the kind of operating cost of a cloud
validator. So you start to pile on egress
multiple cloud machines and so on.
And it really starts to end up kind of costly.
And that's kind of where we one way to have, you know, high
uptime without distributed validators is to kind of put it
all in the cloud have a bit of failover and do things that way.
The other option that some roots go down, is they kind of do the
hardware route where they'll buy a particular server that has
Jewel. CBS, Sockets live two CPUs.
They have a raid array of disks. So if you want disk fails or
problem that have dual networking cards, so, you know,
if there's problems there, they'll survive, maybe grps use.
But these PCS cost in the tens of thousands of dollars and
they're not particularly cheap. So either, you know, trying to
get kind of fault tolerance by using cloud services or fault
tolerance by using really expensive Hardware.
Both of these are, you know, not the cheapest expect a lot of,
you know, some of these tax, if you're running. 7 machines in
the cloud, you wouldn't feel spending a couple thousand,
maybe three, four thousand a month, for something like that.
And if you then have distributed validators and and you can have
private Keys like split into groups, it opens up the ability
to more safely put validators on bare metal machines.
Because if one of your four machines dies, no big problem.
It will stay online. You can kind of wait for it to
come back. If it doesn't come back, you can
bring up another, you know, partial on another note.
It's not going to cause a slashing, it doesn't have a
phone. Key on its own.
All of these machines are doing consensus beforehand.
So kind of what we talked, a lot of the centralized providers
that are like, how could you know distributed validate is
possibly not increase my cost and we tell them that, you know,
with software fault tolerance you can move away from like
cloud-based Solutions. You can move away from having
like extremely, you know, fancy Hardware, based Solutions / up
time. And instead, you can move
towards commodity bare, metal, and use just fault tolerance to
Do it. So instead of having, you know,
4274 on the books and month nodes that run in the cloud, you
can have, you know, a hundred dollar month bare, metal
machines, and your full stack and cost 400 a month instead of
4K a month. And yeah the last kicker that
is, can you do it at scale with high load?
We're doing running a lot of good test in that regard.
Seeing if we can do this at like you know, thousands of keys as
well to improve margins but yeah, naively in the scenario.
Yes, you running more than one note but bear the homestake or
Most Enterprises most you know, operators within the ESPYs,
they're not running a single machine.
Unless they're, you know, doing something with very fancy
Hardware. They're probably running at
least a few machines. So distributed validators and
having fault tolerance allows them to kind of.
Yeah, use cheaper servers less, you know, not over pretty
over-provision them as much. And we are reasonably
comfortable, buyer. You know, the people that are
already running on bare metal. Have a very low cost basis to
the very large amount of validator operators at least
speak to that DVT actually will at them.
Reduce the costs. Even if they are running more
Hardware, I think your question mayor's, well kind of present
the this cell of DVT, you know today because look at the end of
the day, it's a security protocol, it's not a yield
protocol which is like, what everyone wants everything to be,
right. Everyone wants to hear, like I'm
not using your thing, unless it makes me more money, right?
And like, for us the fact of the matter is, is that it's a
security protocol today, and maybe there is ways that it can
get a validator Become more profitable, but it's not this
Lottery mechanism that you download onto your node.
And then one day, you see, 200 each sitting in your account.
It's not one of those things. So getting people to adopt it,
yes has taken quite some time but there's a reason for that
because it is a security protocol.
So it's supposed to give you other things that benefit you in
the event, that there's an increased cost for it.
However, we think too. Oceans points.
It's not only a benefit to them on the security front, but it
will actually probably save them money on a relative basis today.
And then in the future time periods up to us to kind of
standardized DBT as a configuration.
And what we like to use internally is that we've been
calling this like the old bull inside strategy like similar to
in tow right? Like what intel was able to do
so I basically Really standardized.
It's the inclusion of their chip into like everything and then
the machines in the software and everyone else you know where the
competitive market we think getting like oval on the inside
of these things is far more where it's it's because it's a
security protocol. So like how do you position a
security protocol in a Time? Wondering a bear Market into an
industry where like, you know, everyone's looking for yield.
Right there amazing I think yeah we talked about a little bit now
the sort of cost from the operator side.
I guess there's also double as this middleware that obviously
you guys are developing. You spending a lot of resources
on developing this and you also raised money.
So there's also like expectation obviously of this having some
sort of business model, maybe if whatever you can share in terms
of like how do you imagine like sort of oble to be adopted?
Is it like The Operators that would pay Pay to run or ball is
there like some other models that you've thought of to
utilize or yes. Yeah, it's a good question.
So I'll tell a little story here and have been fortunate enough
to observe like how they eat 1 and E 2 client teams like were
developed and hardened and staffed and funded.
And that's really kind of like the core of like how middleware
Is and oboe and others. You know, what types of monetary
streams, they'll be able to, like, take on and work with.
So, like the early Foundation of etherium was, you know, there's
five client teams. I think maybe six actually on
the, on the POS side and then I think maybe three or four on one
side. But anyways, these are all kind
of, you know, privately bankrolled.
Now they're well funded. It took years to get to this.
They were funded by the es or other like, you know, large
donors and that software. Is free forever, right?
So it's virally free. It's the primary network access
to the etherium network. It has basic functionality, but
it's going to be free forever. And now like, you know, Danny
Ryan uses the words, like, ossification and crystallization
and really what that means, is that, like, the amount of
innovation that takes place at that core client, level, and
funding is going to lessen and lesson over time and new
innovative. Space needs to be opened
elsewhere. And now the new in effect like
the new Innovative space that's being opened elsewhere, it is
being enabled in this middleware layer.
So now we have this whole new middleware market where they'll
be a variety of different protocols who are coming to add
complimentary software to the core etherium stack and that
middleware layer today. Has private funding but tomorrow
cannot have private funding forever.
Right. There's like there has to be a
way for these middleware protocols to maintain
themselves, but also continued the eat those of giving back and
having regenerative economics. So today we think that optimism
has taken that responsibility. It is a responsibility at the
end of the day. If you're building at this level
is to try to figure out how you can make circular economics,
some sort. So, the way that optimism has
like built their Network and started to ecosystem, having a
fee, which comes And it is then donated retroactively as a
community to other projects that support, the core aetherium
staking stag. So this is, you know, people
like a protocol Guild. These are people like eat steak
or this is get coin. There's a variety of varieties
like projects that require funding to maintain themselves
on a different level of being open source, a noble and DBT.
Sits at this new low enough layer.
That, like, we believe it's our responsibility to utilize
retroactive public. Goods in some sort of way, is
the primary way that we start the economic machine where it
goes after that, you know, is to be determined.
But there's a way for us to kind of use that economic model with
every validator type, which is also the important thing that
economic model works with your at-home validated, the economic
model works with your hosted person.
And it also works with your liquid staking pool and what
other other future, you know, topic or use case that comes
about, so yeah. Hi today.
We're most focused on what is the version of retroactive
public goods? That works for opal?
Right now, we're just like learning and figuring this out
through this maenette adoption time.
Period. You know, all those totally free
today, dvts, completely free, you can go and, you know, play
with it, do whatever you want. But like tomorrow, how do we
Bridge into? Like a circular economic system?
And that's our biggest Focus today.
I'm I'm actually curious if if you think the ideal place to
house this kind of middleware Stack, I mean, the
specifications of it might be actually something like the
etherium foundation itself and then the client teams actually
implement this middleware as part of their, as part of their
code bases. Yeah, so this is, this is ABO be
too. Today, we are on our roadmap to
be one at the moment, we're about 60, 70 % to be one, but
we've been working on a parallel work stream, which is OB to and
all will be to like further protocol lies DVT by turning it
into a specification. So we actually partnered with
never mind for them. To be the second core
development team for the oval Network.
And they will be leading in partnering with the oboe Labs.
Current core development team for the oval Network to work on
the research and specification of the Ogilvy to protocol and we
are pushing towards a spectrum and environment where we hope to
incentivize a variety of different.
Implementations right for different peoples, use cases.
And the reason that we're also doing that is to kind of the
prior story that I told, which is you need to be as Most of the
base layer from a variety of different perspectives as
possible. One of them is roadmap.
You have to keep your road map on.
You can't get in front of the mother ships roadmap.
You got to kind of hang out in this Goldilocks time.
Period. And yeah, those are those are
the most important things that you have to follow and kind of
stay on top of Yeah, the one extra thing I want to add
actually about the middle right side, or as you said, like, why
don't the client teams implemented?
You know, directly, this is something we looked at ourselves
for quite a while, and it's actually why I touched on BLS
signatures being aggregated by being so important.
And I'll talk about it kind of by way of talking about May
boost and before that even might get.
And so for those of you that aren't familiar, have boobs,
just now the product like run by flash spot.
Is that allows, you know, people that want to get, you know,
inclusion into blocks without getting front-run, they kind of
talked to validated through the software, but before it was
called move boost. It was called may have get, and
it was just like a slight modification to the original get
code base. And they were like highly
successful in their roll out more or less all of the etherium
miners back in the day were running may have get to the
point that people are concerned. It was north of 90% of clients.
And the theorem Foundation were kind of concerned about this.
They were like, okay, if there's anything goes wrong with the
software, you know, almost everyone is running it.
So when it came time to move towards eat to and Reinventing
it, to figure out how it works in this new paradigm with
validators, one of the best changes they made was to
re-architect my have get instead of it being like a forked
client. It's an optional middleware or
oracular Leah, side care that all of the clients can add.
And rather than it being your feature that only one specific
client has the others don't, it was something that they could
all opt into and this, you know, massively D.
Risked it and allowed it to be more accessible and didn't, you
know, prevent client diversity in any way.
And we had kind of a similar like issue when we were
developing distributed validators as well.
The easiest kind of way to make an MVP is to make a standalone.
Validator client that has, you know, arbitrary power to sign.
You can build your distributed system to go and run.
The data is this way. Whereas yeah.
Did the kind of problem here is either you have, you know one
client that super successful networks?
Are you expect that everyone has to implement but if you do that,
you kind of really slow your roadmap, you kind of have to get
everyone to March along the same time and you really don't have
much optionality if new better version comes along, people
can't switch to it very easily. So in the interest of, you know,
not, you know causing harm while trying to do good when it comes
to building distributed validators we Realize that we
could also build distributive outages and as a middleware
because of BLS signatures being aggregated level.
So right now all of the existing validator clients they can add
our software into their stack and become a distributed,
validator more or less with no changes.
And this is super beneficial because it does allow, you know,
you're not one client or you know, replacing them all or if
there is, you know, a better spec comes out or, you know,
although you know goes to 0 in the morning and you Can come
along, all the clients can just put in a new middleware and it's
much more modular and it's much more like fault-tolerant in that
regards that, you know, if something goes wrong you know,
no big deal. People can kind of pivot and
this, you know, design idea is why we kind of went towards the
Middle where route and it's, you know, something that's kind of
served as well in that regard. But the last leg of it is, you
know, just one implementation of the Middle where is, you know,
sufficient from a safety perspective but there could
still be alive - risk. If you know the thing has a bug
and it goes Offline that could be a problem.
Mm. So they kind of further leg of
the journey is after you build ones, get some adoption prove,
that it works, then it starts to become more sensible to protocol
eyes. It make a spec have a couple
implementations, but even if there is just one, it is still
modular replaceable and is this, you know, nice thing that if a
better, one comes along, no big deal.
You know, it can be swapped out. So I think that is kind of an
important design decision versus why isn't this, you know, a spec
that all of the clients To because you can iterate, faster,
you can try more things, you can have more optionality and that's
kind of the way we've designed the software so far.
Okay cool. I guess we also wanted to sort
of talk about how mobile interacts with other middlewares
in the etherium stack so you already mentioned like meth
boost here. I guess that that might be a
good place to start. We're like in my imagination,
right? Like I guess now, we run this
opal. Cluster, like all of these nodes
in the cluster also run meth boost.
Do they have to make basically consensus on in terms of like
what sort of block you accept their or can you Talk a little
bit about how how this interaction works.
Yeah. And so it's relatively
straightforward because may have peace talks to the consensus
clients, whereas, we're almost a little layer lower down talking
to kind of validate your clients and you ask a good question
about. Do you have to kind of come to
consensus on what's provided and Maeve?
Boost is a bit different to, you know, a normal block proposal in
that and the fear is that if you have, you know, a block that's
extracting out of V that's, you know.
Yeah. Taking I can emphasize rewards
and the Searcher, doesn't want to show the proposer.
Exactly. The full block because then the
pros will be like, oh thanks for the alpha.
I'm just going to rewrite this to send it to my address and I'm
just going to propose it and this was actually one of the
reasons around the kind of redesign of meth boost.
Now, when I move towards proof of stake was, if we want this to
be available to every proposer, we needed to Helo trust because
you know in the eat one world there was only a handful of
minors so you could kind of trust them whereas in you know
eats do the hope is that there's a huge amount of validators so
you do this does need to be low trust.
So what actually happens is the relay in the situation is
actually the kind of trusted party.
They have the full block, they know, you know what it is and
they promise, you know, not to Rogue or like undermine the
Searchers and you know, school with them.
So they just provide hash like are like the header of a block
To the actual distributed validator.
So at that point yes the nodes and do come to consensus on, you
know what one to pick, but there is, you know, there's not too
much that can go wrong. There's not a full block there,
they cannot reorder transactions.
They can just say, hey, you know, this is a Blog header,
it's going to pay us. This reward, are we cool with
this and everyone says? Yep, cool.
That sign it and send it back to the relay who then brought pens
the real block and sends it on words and say, yeah, that that
would be How the men have Boost kind of integration works and do
you want to talk about some of the other ones?
Maybe? Yeah, I guess the other thing we
want to talk about here is also like, sort of a trend that kind
of coming up any Theory. I like Reese taking and I'm
layer like sort of re utilizing your collateral or it if you're
in validators to offer additional services like let's
say it may be Oracle or whatnot and I guess that's also like
first of all is very The hyped, I guess, but also seems to
interact with with, oh, ball on the front.
That, you know. Yeah.
How how could like Reese taking service will be offered through
a bowl? I guess that that would be
something that I'm personally very interested in, for sure.
Yeah, it's a great question and something we're chatting quite a
lot about at the moment, these days.
So I talked about, so we're talking to them for the most
part, about a project called eigen layer is introduced, this
idea of restoring, Taking. And as far as how old ball fits
into the equation, this kind of two ways that we fit in first as
a Staker, which is, you know, the kind of Crux.
These are the people that are, you know, pointing their
withdrawal. Address of their validator, at
a, you know, an igon layer, smart contract and opting in to
be the reef takers. Like, yes, you know, we will
provide Economic Security for some extra I think additional
validated Services, what they're calling that the other thing and
From mistaking perspective we think distributed validated
snowball is super important because if you are trying to you
know sell your Reese taking solution to these other services
that are you buying Economic Security from you?
You want to be extremely sure that the steak underneath you is
safe and secure, because if something goes wrong and they
all get slashed, your Economic Security kind of disappears.
Technically, you know, they'll be able to, you know, Charge the
person to get slashed and they'll get penalized for it.
But if you're, you know, maybe running an oracle or something
and depending on this, if there's a mass slashing under
you all the validated get exited.
So your Economic Security just kind of disappears on you all of
a sudden and that's you know something that you can't really
are you really don't want to happen if you're trying to you
know, if you're you know additional validating service
looking for you know Economic Security you want to be sure
that the validated need this Rock Solid.
So this is where Distributed validated is really kind of add
benefit for the kind of Reese taking Paradigm.
It's like, yes, you know, this steak is run by groups of
people. The odds of it being slashed or
quite low, the odds of it going offline are quite low and that
kind of gives you a more firm based actually provide
guarantees to extra services. And then, you know, going a
little further or ball itself could reward and penalize people
within a distributed validator by using this kind of reef
taking and Economic Security. T and this is, you know, the
kind of further version of Leo in the near term mobile can be a
Staker for something like I can layer, but in the longer term it
can also be an additional validated service that, you
know, being the one paying for economic security or for Reese,
take to keep it, you know, protocol running and CI weirdo.
Quite bullish on the idea of having distributed validators,
be a safe base to Reese take on Yeah, that's that's really cool.
I like personally was thinking, you know, also since you know I
guess there could be a lot of additional services that are
offered through angle, a right and maybe for a single node,
operator can be hard to run so many additional services.
So I guess. Do you think it's possible that?
Like for example a oboe cluster sort of shares, these
responsibilities like one guy runs their Oracle the other.
That's a hundred percent, right? Yeah.
In the, in the near term, the be bit of trust involved.
If you're a, you know, saying hey we will put our withdrawal
contract, you note or diagonally, I will trust my hair
is going to run that Oracle for us.
He's not going to get a slashed. You can do that.
Absolutely. And you know we could all be
taking the risk of, you know, doing that extra additional
voluntary service each and put going even further.
We're working on the cryptography to make kind of
proofs of kind of, you know, Fair participation more, easily
provable. And here's a scent that they're
like the longer term. Goal.
Is that, you know, one piece of this distributed validator could
opt into this service for everyone?
And if they do screw up there, the one that takes the hit or
eats, you know, most of the blame rather than the whole
group sharing in the, like, slashing, if, you know, one
person who they like trusted to, you know, do some extra service
for them doesn't like match. But yes, you absolutely can
have. You know, one person in your
cluster doing all of these extra validating services for you
Yeah, maybe this eigen little ecosystem would be so large that
specialization of Labor will emerge, meaning some validators,
do some things, and other evaluators, do other things.
And if that kind of specialization of Labor, emerges
then, o ball, is kind of perfectly fit for for
exploiting, that specification, be specialization.
But it's still early days, right?
Like there is not not a single service that's actually running
on this Reese taking model in product 10.
I think they announced their no not in production, they
announced their spec and stuff, I think this week so shout out
to them for that. So yeah, they're working away in
it. We're keeping an eye shadow way
is is the overall concept only applicable to etherium because
of its special staking model or is it also applicable All to
other chains. Could you expand to other chains
and deliver utility? Yeah, it's a good question.
So what we've been thinking about DBT for aetherium,
validators for three and a half years at this point.
So I made it a pretty large effort at the end of last year
to be like, hey guys, it's time. We have to go look at where else
we can go right? Like this technology, most
likely will benefit other ecosystems or other layers of
the theory of, for example. So we went on this effort to
kind of go find problems recently.
So we spent the entire fourth quarter.
Um, and a good portion of the first quarter on a cosmos
effort, which, you know, the team at course, one was very
helpful with and a lot of the other causal is ecosystem as
well. We've also over time when we'd
like our first and second fundraising round kind of had
this emphasis on like what is the second ecosystem that we
think they're smart people. Working in that have the right,
you know Mission and like the right vision and that was caused
most investors. So the ecosystem itself already
has a pretty actually large Cosmos presence in.
It today as a zobel. So we decided to double down on
that fact because we had the best access to information and
we figured we could like learn as quickly as possible succeed.
Quickly fail. Quickly, kind of one of those,
you know, mindsets. So we went into Cosmos and we
started looking for problems. We spoke to the validators, we
spoke to the liquid staking projects.
We spoke to the ICF, the folks at the builders program, we kind
of did this whole Loop of going through the whole Cosmos
ecosystem and speaking to people and looking for problems.
And we were able to identify, you know, a couple structural
problems is to how DVT could be useful for smaller.
Validators, for example, in Cosmos to team up to get more
delegation to enter the active set.
There's kind of like this larger portion of Cosmos validators
that are like chronically unprofitable.
Even like some of the largest, you know, cause most alligators
aren't necessarily that profitable today either.
So the smaller to, you know, middle tier ones, there's really
no game for them unless they could maybe team up together,
right? Right?
And attract delegation through, you know, means using DDT.
So yeah, we found some good problems in Cosmos.
We published a blog post on it recently, you know, there is
coordination difficulties to making it a reality there's
protocol difficulties. There's cryptography,
differences for example, Cosmos does not use BLS signatures, but
we also learned through that effort that if you wanted to get
it done you could and there's kind of like a existing versions
in the cosmos ecosystems that are about, you know, a third of
what DVT. Is but there would be a lot of
builds inside a cosmos. That would be necessary.
One of the most interesting things that we found about
Cosmos was actually the kind of social threshold of the value of
DVT and inside of Cosmos, what we realized is that there wasn't
enough value at risk for people to think that it was something
that shouldn't just be, you know, an open-source primitive.
They couldn't believe that it needed to be a network with all
these, you know, tools and education and funding and
ecosystem around it. But our take from that was that
the cosmos ecosystem is almost mature enough to have enough
value at risk for everyone to say like, hey, we think this is
a good technology to adopt into our community.
So, for us, we believe that it's a little bit early for DBT in
Cosmos, but we are still actively, like working on
implementation based research now, So we like stated the
problems and now what we want to present to everyone is kind of
like here's how it could be implemented.
So yeah that's like one area of alternative layer ones outside
of it. The area where are our
communities aligned and we're experimenting to see if the
compost Community Values, it and then will, you know, collaborate
with it. The other area, which is
actually super exciting segment. Just put out a piece yesterday
around distributed sequencer technology.
A new term that we're trying to coin and this is the Then the
other research area for us at opal, is just going up the stack
and looking at your other actors, right?
So today we've spent all this time on the validator.
Well, let's go up to the block Builder.
Let's see if there's like centralization problems around
block building people talk about MVC block building, right?
All these different constructs. And then we've also been looking
at the sequencer and like the approver, the verifier, all of
these new actors that are becoming more and more important
in the core etherium infrastructure stack and looking
at their adoptions. Eagles and saying like is there
a need or is there a re use case for the work that we've done for
distribute validators and all the stuff that we know we've
learned from an external project building it not from a
foundation perspective actually which is the reality of where
layer 2 is there a bit more mature and there we sit outside
the foundation. We do our own things and we do
whatever. So you know flab rating with
those new groups of people has been quite an interesting
experience for us so yeah we're we're actively looking.
Two different growth strategies for DVT to see if I can be
helpful elsewhere. One of them is horizontal,
that's Cosmos. One of them is vertical that's
going into the sequence or topic and seeing if our technology
could be helpful there, Yeah, very interesting.
I guess I would also like, just like to hear your thoughts.
I guess you're like, very close in the end to like both the
validator ecosystem and sort of the other protocols.
And and I would just like sort of like to hear how you
currently think of the validator ecosystem.
And how do you see it evolving? I mean, obviously sort of like
one of the core ideas of the theorem is that there are these
homes takers. Like do you do you think that
like they're you Are much of those and will this grow
obviously a global potentially might help increase that, but I
guess just generally what's your view of the space.
Yeah, I've been surprised thoroughly at the number of
like, hybrid at home validators, I would call them, right.
They're basically like small groups of at home.
Validators who are starting small companies together and
there are tens and 20s and they're like growing by the
number, right? We kind of call them like the
tail end, validator segment and that's probably growing the
most, right? We're seeing a variety of new
and small value or entity. These pop-up we're starting to
see people from other ecosystems come to etherium and by means of
coming to etherium. They're doing so through DBT as
actually their first knowledge base which was also like a very
interesting thing is in our onboarding validators from other
ecosystems, not into the core configuration but into the DVT
base configuration from from the very beginning but are probably
some of the most like bullish honestly and exciting
conversations. We have with people are in the
like, hey me and my three friends just got together.
We started a company we're looking to like you know get
involved as a validator and light.
Oh we're looking to try to qualify.
There's there's a variety of small and mid, tier validators
that are trying to get voted into light.
Oh, and by means of increasing their chances, they're spending
a lot of time with Oberlin DDT, to make sure that they're
proficient and that make sure that they're educated by it.
So honestly, there's a lot of really good inertia at the
smaller end of the validator of embracing DDT and like using it
too. Advance themselves so they can
become more professional. And this is surprised me.
This is not, you know, like like a segment that I thought would
be such a core user and like, Pusher of the protocol, but I
think it's really like a. It's a sign of like the ethos of
the theory. Mm, it's like kind of crazy to
see actually write like that group of people feels empowered
to go build companies. So that's what they're doing.
And then they're using obol as a further like empowering
mechanism. To achieve those goals and it's
quite fascinating. So in the etherium roadmap, we
have this, this dank sharding concept that's coming in where
essentially these validators will end up becoming responsible
for data availability. So if you have like a single
centralized validator, it's kind of probably easy to understand,
we have to store some some kind of data on our side but how does
it interact with a no-ball cluster with there might be
three we're like three different parody does does it data?
Now need to be replicated across all three?
Good really Niche. Technical question, mayor.
And so on, this tank sharing is coming out in two phases, the
first one being prototyping sharding, and the second one
being folding shouting in Frodo dank shouting, they don't go to
the extreme where they don't have every node in the
blockchain kind of keeping and gossiping like all the data
availability. It's still, you know, everyone
sends everything everywhere. And If eventually with, you know
folder, Shouting you're signing data, availability witnesses to
prove that. Yes you know I did see this data
was available and oh yeah over the longer run there starts to
be you know trust assumptions between the the four nodes trust
them strong word but they have to decide.
Did we all see the surgeon at least any of us see the speed of
data blob so that we can include it in our block and like sign to
it. But in the near term and
prototyping shouting when it first comes in, it's more as a
best. Effort data availability.
It's done at the consensus layer and it's not, you know, you
won't be slashed or to my understanding or at least
they're not putting, they're not going to the side where, you
know, all nodes don't store everything which is the first
wave comes in. So yeah, when it comes in a
prototype sharding, not currently problem.
When it goes to folding sharding, the nodes do have to
say have we really seen this and you know we have to kind of
prove yourself at or as you said if you don't trust one another
everyone see the date availability before we sign off
if you want to be More cautious rather than more trusting.
But yeah, it's in the near term. It should be problem.
And then also, we proposed a builder separation.
A lot of the complexities of dang sharding is on the Builder
and the proposers it keeps the proposes relatively simple.
They just have to kind of propose the really fancy block
that a builder made for them. Maybe I like to end with kind of
one of the conceptual doubts I have with this entire aetherium
Elder roadmap, which is that sometimes I feel that via
meaning like ZZ validators and, like, you all of these
middleware Builders. We spent so much time and effort
building various products to make the etherium, validation
system work and be decentralized.
So many thought Cycles have been spent here.
And now when it comes to the question of scaling ethereum,
most of our effort is kind of it feels useless because it's going
to be scaled through the L2 is now.
These Elders are going to be running sequencers, and that's
like a completely different kind of validation stack, that's
that's being built. And like now you have noun, for
example, overall instead of reusing your work for etherium
directly to scale is helium in L2, you now have to go and think
of this new concept of a distributor sequence and wrongly
Android new software. Same for us extra.
Do you in some sense, think you're all our efforts are kind
of like not being wasted but being underutilized by the
theorem ecosystem. Yet throwing all my favorite
questions, my hair because I actually would suggest that we
don't have to throw stuff away and, you know, build new
software and stuff. And this is the idea of a
theorem equivalents that I think was kind of first coined Again,
by optimism, but they kind of astutely realize that if they
stay as close to the etherium execution architecture as
possible. It's easier for, you know, to
gain adoption and network effects and be able to reuse all
of the existing L1 stack. And for example, their very
first kind of MVP will call it was, you know, a modified, get
not unlike maybe get to some extent.
And then recently, or just in the coming weeks, they're moving
over to optimism bedrock and the main difference, there is David
abstracted all of their kind of code for the optimism kind of
fraud proof game, and into what they're kind of calling a
consensus client. And they talk only through
Engine API. The standard one that all of the
execution clients use and adopting, this kind of
standardized API for them, has allowed them to go from having,
you know, Opie get to also having Opie Aragon and
ultimately, probably all of the existing L1 execution clients in
the optimism world. And we recently like, announced
a Blog with segment just yesterday on distributed
sequencers. And the Crux of the argument is
exactly, I'm yeah, altitudes of already.
You've competed only theorem equivalents at the execution
layer. The next step in our head is to
add and etherium equivalent Beacon API to their code base of
the. So adopt PLS signatures adopted
API, dumb it down a little. It doesn't need that to take
attestations because it's not a proof of stake game but just
have, you know, proposals using that standardized API and the
benefit of that is you do get to reuse more or less everything
from the L1 particularly from the L1 staking side.
The ones probably most important is the private Key Management
side of things. So, you know, private keys are
always the most important thing. So if you if let's say optimism
for Simplicity, they add a beacon API to their L2 lycopene
owed stuck. They can reuse web three signer,
they can reuse Dirk and you know the benefit for all us they can
reuse distributed validators because it uses the same API and
they can more or less use it all out of the box.
So yeah, I I hear where you're coming from being, like, should
I choose really invent the wheel and I agree with you, they
probably shouldn't they should, you know, copy the L1 apis, as
much as possible. And then they get to kind of tap
into the network effects of code.
It's already built and already been used.
So yeah, pitch to them is you don't have to do all of the
decentralizing, sequencer work yourselves.
You can keep it a little simpler.
Have it be kind of a round-robin thing with BLS signatures but
then use distributed validator to actually go from, you know,
10 entities and round-robin to actually 10 distributed
sequence, Errors in round-robin type of setup.
So yeah, I agree that, you know, L 2, I think, you know,
generally will adopt this. They kind of see the network
effect trying to build something new and convince everyone to
come. Easy stuff.
Is hard trying to, you know, stay aligned with the existing
apis more work for them, but, you know, more Network effects
and easier adoption for their customers, and for everyone
else, right? So actually, actually, this then
seems very powerful for the old bowling Network that You can
effectively go to an L2 that has.
Let's say a centralized sequencer and maybe your product
is simply that instead of now this being a centralized
sequencer, it's actually distributed across five parties
or six parties and then if they can work out how to go from one
centralized sequencer to five and each of them now is a
no-ball validator with like five or seven.
Then you can Autumn easily get to 25 or 35 people running the
infrastructure eggs. Likely right.
So so all of your work done for is helium, kind of Yeah.
Scales like probably is more useful on the L2 layer, then,
maybe you're even on this idiom mean.
Net like that, could be a future for that.
Could happen for the overall project.
Yeah. That was actually something I
also pitched where seek like in the L1 is normally very small
machines and there's technically you know, 500,000 validators,
but sequencers, they often will be running like very large
machines. So you know five very large
machines run in a distributed sequencer setup makes a lot of
sense rather than you know, thousands of small machines.
The l2's. Mostly won't optimized for like
running on consumer Hardware. There, you know, meant to be a
scaling solution, but they do want to be, you know, as Trust.
- as possible. So yeah, big sequencers that are
running a distributed validator type of setup where if one of
them becomes malicious nothing happens they just you know like
stay online like a multisig, is it?
Yeah as I actually agree I think really makes more sense it out
to than either one and by others majority side of things.
Perfect. Yeah.
Awesome. That we went very deep.
Thanks so much for a dank episode emotionally Colin.
And yeah, thanks for for coming on the epicenter.
Maybe add, before we wrap up. You wanna shout out where people
can learn more about, oh, bowl or yeah?
How they can find you and they are.
Again, thanks so much for coming on.
Yeah, thank you guys for having us.
It's been a great discussion. He had to find out more about
obol, best place to probably linked into the communities
through Twitter. You can just find us a doable
Network and we have a cool ambassador program.
We have a great Discord, we just well tomorrow.
We're actually launching our Research Forum with the
distributed sequencer. Peace, as first one for people
to get some debate on and then we'll actually build out the
cosmos section of the Research Forum.
So if you guys are interested in getting involved there, In the
next. Well this proposal.
Yeah. In the coming days, you'll be
able to see it. And yeah, I'll pitch the sheen
but thank you guys for having us and really appreciate it.
Yeah. And nothing.
Major. Dad, thank you very much.
This has been super fun to talk in the nitty-gritty of
validators because normally we don't get to talk about.
You know bare metal version of cloud versus Cosmos or L2 and
their architecture. So I'm going to be a grateful of
this chance for to get really into the technical nitty-gritty
and podcast. I hope they're all as technical
as this one. Thank you for joining us on this
week's episode. We release new episodes every
week. You can find And subscribe to
the show on iTunes Spotify, YouTube SoundCloud or wherever.
Every listen to podcast. And if you have a Google home or
Alexa device, you can tell it to listen to the latest episode of
the epicenter podcast, go to epicenter, .t V /, subscribe for
a full list of places where you can watch and listen, while
you're there, be sure to sign up for the newsletter so you get
new episodes in your inbox as they're released.
If you want to interact with us guests or other podcast
listeners, you can follow us on Twitter and please leave us a
review on iTunes helps people find the show and we're always
happy to read them. Well thanks so much and we look
forward to being back next week.