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