foreign
[Music]
o I'm one of the co-founders in the
general manager for infuri and I'm
joined today with my colleague Tim Myers
one of our lead engineers at inferior so
you've seen the title of the talk you
might have caught our announcement at
East Berlin a month ago we're here to
talk about decentralizing inferior it's
something that's been on the Twitter
waves and crypto Twitter for years
something that people ask us about all
the time like is inferior centralized
how are you going to decentralize
are you going to decentralize this is
this is the talk where we answer quite a
few of those questions for you we gave
you a preview at eath Berlin if you're
able to see the recording from that talk
this is going to go more into the
details of the why behind it the why now
what now and especially the technical
details that go into decentralizing
inferior
so
inferior was launched in 2016 with the
sole purpose of providing utility for
ethereum and ipfs Developers
it's something I say in all of my talks
because I I want to make it very clear
that inferior was always about the
developers and making sure that
developers that are building on web3
which for us was initially ethereum and
ipfs could quickly get started and we
did that
at Devcon 2.
it was four of us from the inferior team
we flew to Devcon at the time we were a
small team within the larger consensus
organization focused on trying to build
something that would be useful
and so we all went to this conference
and we were saying that we were going to
get up on that stage and say there's a
lot of innovation that's happening in
this space we've created this new
service called inferior and it's a
traditional SAS service that you can use
to connect to blockchains
and we had a lot of apprehension about
that like what would the reception to
that be because at the time we were all
running our own infrastructure we were
all running our own nodes there was very
much a lot of interest in like clients
verifiability of data and we were saying
don't run your own infrastructure trust
us to run your infrastructure and so the
the reception at Devcon was a little
mixed some people were like okay great
I'm going to use that other people said
but why would I want to do that I can
just run my own node and it's going to
sink in an hour and then I don't need
you anymore
and uh so we said well
that might be the case but we're going
to try it like we're just here to try to
provide something useful and maybe that
will be useful and maybe it won't be and
uh so we went up on stage and we we
announced that we were going to be doing
this
and then during Defcon 2 the ethereum
network was uh subjected to the denial
of service attacks that almost brought
down the network and some of the many of
the heroes that helped save the network
from that are either in this room or
definitely at this conference the people
that helped mitigate the attacks on the
network and inferior's role in that at
the time was trying to keep our endpoint
up that was already being used to sort
of metamask mother mask had launched uh
two three months beforehand and uh
thousands of users were already using
metamask every day to send ether do some
basic interactions with some of like the
early maker contracts that were out
there some of the early other
experiments that were out there around
that 2016 time
and we said
well we can't do anything actively to
fix that client we're not the protocol
core developers the core developers are
solving that problem but there was
already this issue where
we were in Shanghai the Wi-Fi there was
awful even worse than at most
conferences and nobody was able to like
get access to their infrastructure to
update their clients once the actual
client development teams had put out
these updates and so our inferior team
was sitting there in the lobby of the
hotel updating our endpoints so that the
thousands of users that were using
metamask that might have been pointing
metamask at their own infrastructure
could use inferior until their
infrastructure came back online
and so that started to highlight one of
the value props that we saw which was by
having this centralized point we could
simplify
um or try to eliminate a lot of the pain
for these users by
um yes we'll take on this like aspect of
centralization but for the most part
it'll be beneficial and so we're going
to keep doing that until it gets to the
point where we feel like it's crossed a
Tipping Point and we need to try to do
things differently
and when you look around the space
there's other points of centralization
that have paths to decentralization
things like Fiat on-ramps and
centralized exchanges and how there's a
transition from those to Alternatives or
decentralized truly decentralized ways
of doing the same operation my favorite
example is when you talk about Roll-Ups
and how initially Roll-Ups start as
having a single entity that's creating
the Roll-Ups and the roll-up teams have
a road map of how they will eventually
get to being more decentralized so
that's how we thought of ourselves as
inferior started to centralize and we'll
see when we get more decentralized and
we're going to have a
a solution for how we do that
and the reason is because we had to
create quite a bit of uh
proprietary infrastructure to serve the
traffic that we've done over the last
six seven years what we run today as
inferior is far more complex than what
we ran with in 2016. if uh if you had
tried to replicate what we had in 2016
um maybe a month or two after we
launched you could do it within a week
or two now it would take you probably
years to try to replicate the systems
that we've had to build because
between 2016 and now we went through the
2017-2018 Ico bubble the 2019 crypto
winter
2020 D5 summer all of the explosion of
nft growth and with every single one of
those things you might have run into an
inferior production incident something
uh that showed Oh this didn't scale
exactly right and every time it didn't
scale exactly right we improved our
system right and so it forced us to
innovate every single time take data
like back in the day we used to send
requests directly to ethereum nodes and
there was really no virtualization as we
call it custom services that would
handle the traffic because we didn't
ever want to be in a position of
providing the wrong data to you because
that would be really bad that'd be the
end of our service if we ever provided
you the wrong day that like that
and especially in 2021 we ran into this
issue where
we tried to be very uh conservative with
how often we updated our clients because
uh early on the clients were a little
bit uh bleeding edge and a little bit
unstable the closer you tracked to the
latest release and because of that users
were complaining like maybe give us a
little more stability less of the
absolutely latest client that ended up
biting Us in 2021 when we were running a
client that was about six months old and
a bug was triggered by by a team that I
won't mention because there was an
accident and they apologized to us but
um it took down inferior for six hours
and that was our first multi-hour outage
that we have ever had and it's still our
worst outage that we've ever had and so
that really made us think maybe that was
the Tipping Point maybe that's the point
where we need to start considering Now's
the Time to do things differently
because for us decentralization was
always the plan we said we're going to
get there it's just not the first step
in that plan
we said that we are going to set out to
prove that web 3 could be served by SAS
we're going to say that we're going to
run a SAS service and that's going to be
beneficial for uh the ecosystem and it's
going to bring more developers in it's
going to bring in more investor interest
a lot of activity is going to come into
this space because people will see oh I
can actually make a living and support
myself running a business in web 3 when
at the time it wasn't very clear Which
models would work and so now inferior is
not the only game in town There's dozens
like they can't even fit on this screen
anymore and we feel like we've
accomplished that goal we've proved that
SAS Works in web 3 and so now we want to
prove that web 3 models can be used to
serve SAS and that's what we took as our
approach to decentralizing inferior and
that's where we are today and the first
step to that is open collaboration and
transparency we don't have the entire
solution in a white paper form that
we're going to upload to ipfs and you're
all going to read it right now like
we're still in that design phase but
we've already started collaborating with
other people in the ecosystem on that
design we've been working on it for a
year and a half this is where we want to
start showing you more of the technical
details of what goes into that
what does decentralizing inferior look
like it could people have said oh are
you just going to create a dow so that
we can like have some governance over
what inferior does is that good enough
or is it some sort of uh utility
function that we're going to try to have
as part of this network what are the
incentives of participating how do we
incentivize the right behaviors and
what people were especially asking was
does participating in this decentralized
infrastructure Network mean like
inferior still owns and controls
everything and that's the biggest
question that we got in the last month
since we announced it East Berlin and
the answer to that no it that's that
defeats the purpose of what we're seeing
with a decentralized infrastructure
Network that's supposed to be a
permissionless network so inferior is
going to just be a partner in a
decentralized permissionless network one
of an equal amount of or one of equals
in operators
so now I'm going to pass it over to my
colleague Tim and we're going to start
sharing some of the technical details
with you
thanks oh sorry uh yeah so as EG
mentioned we don't have all of the
details of this figured out yet we're
still pretty deep in the design phase uh
but the next 10 minutes I'm gonna try
and walk you through as much as we have
figured out right now as I can and then
hopefully save about five minutes for
any questions you all might have uh so
first I want to start with just a really
high level overview of what we see as
the network participants in this
decentralized inferior Network so first
of course you have your end user who
wants to connect to a web3 network maybe
they just need to send a transaction to
a blockchain maybe they need to read a
bunch of data from it either way they
need some way to access the API that a
blockchain node typically exposes and so
the first participant to support that
are the infrastructure providers of
course and they're the ones that are
going to actually be writing the
blockchain nodes off the supporting
infrastructure that makes that possible
to allow for high throughput of requests
to send all the transactions to read
historical data all of those things that
you typically do with the centralized
provider and they'll provide this
service in return for a reward
um which is what's going to motivate
them to want to do this uh the next
participant we're calling the network
status Watchers uh this party will
provide performance and capability
reports of the infrastructure providers
uh so they'll be there to kind of check
and keep them honest you know they'll
they'll see that they're keeping up with
the head of the chain they'll check that
they're you know responding quickly that
their uh answers are accurate all the
things that you would hope that an API
does and finally we have this concept of
an Ingress node they kind of act as an
intermediary they will sell the actual
network resources to users after
purchasing them from the infrastructure
providers and later I'll also show how
they're not entirely necessary but they
can provide a ux option that I think is
useful so more detail on the
infrastructure providers the first thing
of course to note is that instead of now
with just a single centralized provider
we'll have many of them and they won't
be run by a single party so here we just
have a little simple diagram we have
inferior we'll probably run one of
course uh you'll also see other named
providers that you're used to seeing
that we hope will collaborate with us
and you might also have Anonymous
providers so you never really know who
they are but through the mechanisms of
the network you can come to trust that
they are going to provide a good service
so these infrastructure providers they
commit to providing capacity on the
network they'll specify the protocols
and capabilities that they support so we
envision this network working for
ethereum but we also Envision Envision
it supporting all of the sort of new
networks that inferior has added over
the last couple of years the layer twos
new layer ones but not every
infrastructure provider is going to want
to serve all of those so they can pick
and choose and specify what they want to
support they'll also say the
capabilities so you might be used to
having you know archive nodes for
ethereum and then sometimes you need
that sometimes you don't and running
archive traffic is a lot harder so some
providers might do that some might not
they'll also give an idea of the amount
of throughput that they're capable of
specifying and this may take a couple
different shapes but you know you could
think of it as like a thousand requests
per minute when someone registers as a
provider they're saying I can support
this much and so that people can then
buy that back and of course they'll be
compensated for for doing this
I want to talk a little bit about what
it actually looks to be a node provider
um and so this is a diagram of what
inferior does and what other big
centralized providers do it's
complicated as EG said it's become much
more complicated since 2016. to start of
course you have your blockchain nodes
these are the the ones that are produced
by the client teams that interact with
the peer-to-peer Network that sync
blocks that verify it but
um there's a lot of supporting
infrastructure around that so first we
have a snapshot system uh if you've ever
tried to sync a node you'll know that it
takes a very long time so we typically
take the disk of a blockchain node save
it to our own private Secure Storage and
then when we need a horizontally scale
out those nodes we use that as a seed
for new blockchain nodes so it's
downloaded onto a server and then sync
from there which makes it much faster
you also have various indexers and
accelerators so if you've ever tried to
do like a big wide get logs query for
events from a blockchain node you'll
know it's really slow so we have special
indexers to speed that up also for
things like nfts in front of that you
have a load balancer that makes the
decision of what accelerators to send
your request to maybe for just sending a
transaction it goes directly to the
nodes and in front of all of that we
often have a consistency system that
helps make sure that users see a
canonical view of the chain so this
helps with reorgs to make those a little
less painful for the user and also make
sure that if they like query a block it
doesn't change in between requests and
this is something that is altogether
quite complicated there's been several
uh projects out in open source land that
have attempted to help with this I think
most of them are you know more on just
running the blockchain nodes running
several of those but to really provide
good service you need a lot more than
that and we will be releasing our own
open source infrastructure kit that node
providers can use to help them
participate in this network of course
there's also going to be parties that
already know what they're doing and
we'll probably just run their own flavor
of infrastructure to provide the same
service in the end
uh next we have the network status
Watchers again there's multiple of these
run by different parties these will
periodically test the infrastructure
providers by sending them a small volume
of requests they'll measure the
performance and check for correctness of
those responses they'll report all this
to a Federated status page so if you're
thinking about using this network you'll
be able to go there look through the
different providers see how they perform
what their you know capabilities are of
those things and also in cases of
provably incorrect responses so there
are certain requests on the ethereum
Json RPC API that you could prove with
Merkle proofs rather easily so in those
cases those might also be used to inform
penalties to the node providers and we
hope over time as stateless clients
start to improve that there will be more
and more of that API surface that is
verifiable
a picture of kind of what it looks like
to run a network status Watcher they
will have to run some small amount of
blockchain infrastructure themselves not
nearly on the scale that an
infrastructure provider would because
they're not serving a high volume of
requests but they need sort of a
baseline to compare to they want to
check that the infrastructure providers
are near what they think is the head of
the chain
um and then of course they'll have all
these periodic tests that they're
running to see if the providers are
operating well so they'll interact with
the infrastructure providers they'll
potentially send things to a Smart
contract on chain for those provably
incorrect responses and then they will
also send their results to a Federated
status page where you can view more
detailed information and then last we
have the Ingress node so as I mentioned
this kind of serves as an intermediary
between the end user and the
infrastructure providers so an end user
will send their Json RPC request to an
Ingress node and then that Ingress node
May then forward that to multiple
different infrastructure providers maybe
they generally send it to one and if
that goes down they have a fallback
maybe they round robin in maybe they
choose to actually send it to all of
them and do a quorum of that and return
it to the user this will be something
that the Ingress node can actually
choose how they want to do it and one
reason for having this Ingress node is
that you can use it to give the same web
to ux of the centralized providers today
so I think there's a reason that
inferior and centralized providers have
been so successful it's provided a an
easy entry point for people to come and
swipe their credit card and get access
to the network and that doesn't
necessarily align with a decentralized
ethos but it's also brought a lot more
people to our our world and so an
Ingress node might allow users to
actually pay them in Fiat and then give
them API access but this will still have
better results than the current model
because they can then be sending the
traffic to multiple infrastructure
providers and get some of those benefits
uh in addition to that though an Ingress
node might purchase resources from
several node providers and then register
themselves as a node provider uh with
the sort of the you know the sum of all
of that capacity and then an end user
can go and pay for that provider in
crypto
um and then you have a fully crypto
native experience so there's options
here the node provider lets you do a lot
of interesting things with uh combining
other providers so the on chain registry
is what we're typically calling our
smart contract that kind of coordinates
all of this and the main way to think
about it is it's basically the data
structure of your node providers so we
have a very simple example of what that
kind of looks like this is uh just one
detail but you have your name providers
and the protocols that they're
supporting so uh as inferior maybe we're
supporting the five that are listed here
but maybe operator a is only supporting
Ethan polygon this is where you would
also be able to see things like maybe
what region they exist in
um whether they support archive nodes
things like that
uh gonna look sort of of the timeline of
how this all operates so first of course
the smart contract is deployed uh some
amount of time later your infrastructure
providers come in and they register they
specify the protocols the capabilities
and the throughput that they'll support
uh some amount of time later you'll have
Network watches that will register they
may only want to participate watching
for certain protocols maybe they're only
capable of checking certain capabilities
maybe you have a watcher that can't
check that a node or that an
infrastructure provider can support
archive access but they want to help
with you know the the near head requests
and see that those are good for
providers
and then finally you have your consumers
who come in and purchase throughput so
that might be an end user who wants to
go directly to a node provider or it
could be an Ingress node that wants to
combine them
and once you put all of that together
you get sort of what we view as our
decentralized architecture uh so in the
center you have the on-chain registry
you have your network Watchers your
infrastructure providers your blockchain
API consumers and your Ingress nodes
that all will register with that on
chain registry and then once that's all
set up your blockchain API consumers can
send their requests to the various
infrastructure providers that they've
chosen or to an Ingress node which is
sort of helping them do that and yeah uh
we hope once we have that all figured
out that it'll give us a self-sustaining
reliable and robust network of
infrastructure providers uh that's built
to really serve the high throughput that
inferior can today or other centralized
providers can today uh for all of the
blockchain API requests that you you
need
um but instead of what we have now it'll
remove a single point of failure uh we
help to hope to do this out in the open
as much as possible and really follow
that collaborative web3 Spirit uh this
is we hope really going to improve
reliability for these for the users and
get a lot closer to that kind of 100
uptime dream
um but also which I think is important
still provide the ability to have that
really easy web to ux if you want it uh
we could also have the crypto native uh
and yeah that's it uh we're seeking
strong web 3 infrastructure providers to
work together with us if you're
interested in joining and participating
in this network I encourage you to snap
this QR code it takes you to a form that
you can fill out provide a little
information on your experience and your
interest and we'd love to work with you
um that's it I've got about four and a
half minutes for questions if anyone has
any
thank you so much
um please raise your hand if you have
questions so our volunteers can lend you
the microphone
one two yeah so do you plan this whole
decentralization to be more creative or
censorship resistant sorry what was the
first you said censorship yes so either
you have for example a list of creative
providers for quality or you have a
censorship persistently so providers
that will treat any request from anyone
regardless of definitely improved
censorship censorship resistance because
it's permissionless anybody can
participate in the network by meeting
the criteria to join the network which
is technical
um technical criteria of meeting a level
of performance right if you can meet a
level of performance you can participate
in the network we're not going to be
selecting who can participate and then
as a consequence what if a provider
constantly perform badly
uh they would be penalized by the
network right there's there would be a
financial incentive to provide the
minimum level of performance and uh they
would get penalized by the network if
they're not meeting that level of
performance additionally that Network
Watcher that or in status monitor that
we're talking about is continuously
checking and Reporting on both the
capabilities of the network as well as
the performance so you can see here's a
new provider that just joined they've
only been part of the network for seven
days they support seven networks of
those seven networks this is the
performance criteria of that right and
all of that's going to be published in a
stream of information that people can
consume from to make routing decisions
so a user can like a very technical user
that wants to be in control of that can
say this provider is coming from this
region or this providers coming from
that region and this is their
performance and make selection criteria
of how their traffic gets routed or they
can pick their level of decentralization
and ease of of years by going through an
Ingress operator that can make those
routing decisions on their behalf
can you um give an example of what the
centralized infrastructure currently
looks like in terms of like number of
servers and bandwidth and so on and what
you expect will be when it's
decentralized will there be overhead
will it will it need more servers to do
the same performance that kind of thing
by number of servers are you talking
about inference current current yeah
um dozens of subsystems hundreds of
different instances or servers providing
different types of functionality so like
we have a separate subsystem subsystem
that all it does is index event logs and
when you query events from uh like erc20
token events and things like that it's
pulling from that subsystem and then we
have this consistency system that tries
to keep all of that in sync when you're
querying one subsystem versus another
um so that's the challenge that we've
had is we built that as quickly as
possible to solve problems and it's very
proprietary Cloud specific and we've
been working on how do we retool that so
that it's something that can be not just
open source and something that somebody
else can run but can run with like not a
team of dozens of operations people and
so it's not what we're going to release
in the node kit is what we think is an
minimum level of functionality of
performance where this is better than
running a bunch of nodes behind a load
balancer because it now has some of
these indexing and performance
optimizing systems but it's something
that can be taken on by hopefully an
individual but
um at the very least a small team much
smaller team than the current inferior
team
do you think it's uh likely that this
unchain registrations of the providers
will be a new yet to be launched
dedicated chain or is it more likely
that it will be on an existing chain
like this you remain at
uh that's one of the things that we've
been considering as we're going through
the design we're leaning towards don't
don't start a new chain for that like
try to use something that exists and
that goes back to the why are we doing
it now rather than in 2016 when people
are talking about like micro payments
between providers and like you use State
channels for that and all these other
things like we would have had to develop
a significant amount of our research
just on that problem whereas now a lot
of these Primitives are out there and we
can try to use some of the things that
already exist to build the network uh
yeah can you tell me who is the entity
or people who decide what the
requirements are to become an operator
and who decides which operators or
providers would meet those requirements
and then how they would change in the
future
okay so multi-part so who decides who
can be an operator so this form to sign
up is to participate in like a
permission beta um similarly to like how
uh when other people are uh developing
new networks we're going to have to
start with a small group to try to test
and iterate iterate with and for that
we're looking for people that already
have experience with the infrastructure
and that we can reach out to and get
feedback from
um pretty quickly on the technical front
but once we actually launch this network
it's fully permissionless the criteria
of that is what we're defining as a
protocol in the design of this would be
you know the amount of resources that
you would have to provide or this would
be the minimum level of performance so
you have to at least support one network
you have to at least support this level
of performance and then as long as you
can meet that it's um anybody hey
Lefteris here I'm from Rocky right in
front of you I just wanted to ask about
the Ingress nodes will there be a
requirement or will they be optional
you should say like the indexing notes
no no Ingrid at the end grass yeah it'll
definitely be optional um so I can't
quite get to the slides it'll take too
long uh but you can still have a
consumer who will go directly to the
contract to purchase resources and go
directly to one or multiple node
providers that they choose the Ingress
node is kind of an option where if you
don't want to go to the trouble of doing
that maybe you want to use one that
allows you to pay in Fiat that you can
but it's an option
this this was our last question but if
you have more questions please reach out
to our speakers that we're going are
going to be here thank you so much