[Music]
um I'm Piper as she said and I'm here to
talk to you guys about the portal
Network um so let's just get right into
it um the I work for the ethereum
foundation I already got introduced um
so this is about actually finally
bringing lightweight decentralized
access to the protocol and uh and yes
this has been kind of a a long-term
project to get us to where we're at um
here we go so let's like dive into kind
of at this high level what the portal
network is uh for me it's a giant white
whale that I've been hunting for a long
time and hopefully doesn't eat me in the
end um but the portal network
is uh five new decentralized special
purpose storage
networks uh that serve all of the data
that is necessary for interacting with
the ethereum protocol and this has been
a long road to get to here uh we spent
time way back trying to build
lightweight clients on the existing
networks and where we ended up was that
the existing networks don't give us what
we need to actually deliver lightweight
protocol access and thus we have these
five special purpose storage networks
that we are building out to serve this
data and to essentially realize this uh
this dream of lightweight access to the
protocol um the project has kind of
these highlevel design goals that kind
of informed what we needed to build and
how it needed to get built um and one of
the main things is that the portal
network is really user focused um all of
the clients that you hear about today uh
uh geff Basu Lighthouse all of that
stuff right it's infrastructure for the
protocol and and those clients are built
with the protocol in mind and and the
user facing stuff right the Json RPC API
they're not the lowest priority but at
the end of the day those clients serve
the protocol and not the
users um one way to look at this is that
if you want to interact with the
ethereum protocol today you have two
choices right it's the we upper right or
lower leftand corner of this graph you
can run a full node they're very heavy
and they're also awesomely decentralized
our there's a number of choices for what
to run but in general when we're talking
execution layer you're talking about
very heavy pieces of software we'll get
into the details of this in a minute um
on the other end of the spectrum you've
got lightweight but centralized options
like Alchemy or infura things like that
um somebody at the last conference told
me that I was a boomer for calling it in
fura I thought that was awesome um so
anyways you've got these lightweight
options but they're also centralized and
they can do things like correlating your
IP address with the transactions you
send or selling your data and things
like that right we the there are two
options at the far opposite ends of the
spectrum and we want to build this thing
in the upper leftand corner this kind of
adorable pink smart car that is both
lightweight and decentralized which
supposedly we care
about um this brings us to this
lightweight concept um like I said
ethereum clients are and we want we need
a network that allows lightweight
devices um to participate um ethereum
clients are heavy today because they
have to do a lot of things uh evm
execution is CPU intensive running the
transaction pool is CPU intensive and
there's gigabytes upon gigabytes of
history and state data and things like
that that they need to do um this means
that running a traditional ethereum
client is a inherently heavy thing and
you generally can't do it on things like
raspberry pies or
phones um over here on the left we've
got this nice little strong guy who can
hold it all up that's your like
traditional execution layer client our
goal is building out a network that lets
you spread things out that takes all of
the load for all of this data and
distribute it around all of the
participants of the network in a nice
kind of even way um the other thing that
we focus on is kind of removing some of
these height rest restrictions and by
height restrictions I
mean essentially Hardware restrictions
that keep you from joining the network
um this is one of the things that
blocked us from Building light a
lightweight client years ago was that
you've got these sort of you must be
this tall to ride things um you are not
allowed as a uh as a participant in the
the dev PTP Network that's the network
that supports execution layer clients
you can't be part of this unless you
have all of the state and all of the
history and enough processing power to
process every block and enough
processing power to run the transaction
men poool right if you aren't tall
enough you're not allowed into that
Network um we focused on a different
model we wanted people to to be able
people clients computers whatever we
needed a network that allowed you to
show up with whatever you had and to
contribute it to the network if you're
so willing the idea is that all of these
networks operate on this exact same
principle which is that as a client to
the network you can tune some parameters
that dictate how much storage space the
network is going to ask of you that
dictate how much processing power the
network is going to ask from
you and one of the other major things
that we focused on is kind of this ux
thing which means to me elimination of
sync times uh traditional clients have
bad ux in terms of like the user facing
stuff and that's because you either have
to when you start it up you've got hours
or days to wait for it to sink and if
you go offline for some period of time
you often have additional time to catch
back up to the tip of the chain these
sync times make ux for kind of like
enduser um interactions kind of
basically unbearable this is why almost
all of the userland traffic goes through
services like Alchemy or
infura um we've designed a system where
all that you need to do is have a view
of what you think what you trust as the
front of the chain and from there all of
the data is accessible to you which
means the difference between hours or
days of sync time from from zero to
being able to actually inter interact
with the network to being able to be
interacting with the network in a matter
of seconds or at the worst network
conditions a minute or two as it has to
peer with some some other peers in the
network so um really focusing on on user
facing things like
this uh the other piece that we needed
was something that was scalable um and
we're not talking this scaling this
isn't sharting scaling or transactions
per second scaling this is a number of
of network participants this is M having
potentially millions of nodes be part of
this
network some of the past work towards uh
ethereum like clients is Lees that's the
light ethereum subprotocol um and this
has been around for 5 years maybe um and
it is never really delivered on this
goal and the main reason here is that it
exists in this client server
architecture um L nodes on the network
are dependent on full nodes serving them
the data and what happens over time is
that a full node who's serving this data
uh ends up getting kind of just
assaulted by all of these Lees noes
constantly asking them for information
and they're expensive requests that
these nodes are making um and it hasn't
turned out super well um Lees has not
proven uh has has not delivered a
reliable like light protocol access and
the main reason is this imbalance
between client server stuff um that
there's no
incentive there aren't incentives to run
Lees servers running an Lees server just
costs you something and so the ones that
are out there are being run by the
goodness of hobbyists and other people's
hearts or people who misconfigured their
client on accident or something but
either way it it is it is a uh it it
cost you something and the clients in
this network are not able to contribute
back as an Lees client you are purely
taking from the network and that is just
the way the network is
designed in fura alchemy they're this
centralized model right their servers go
down everything stops working at Lees is
this decentralized model which we like
but because there aren't enough
incentives or anything for people to run
Lees servers uh it hasn't worked out
super well um we've moved all the way
into this distributed model where we
have a homogeneous Network where
everybody in the network is a client and
everybody in the network is a
server uh one way to think about this is
very akin to bit torrent where the in
Lees you have this like kind of
degenerative thing where the more nodes
you add into the system they take up a
limited amount of capacity and once you
exceed that it degrades service for
everybody in the portal Network context
we have built these networks around this
idea that the more nodes you throw at it
the more powerful it gets and that's
kind of the whole core part of
this all right um let's look at a
practical example of what uh uh how you
would serve this um uh essentially a
balance inquiry uh from the portal
Network I'll remind you we've got a
number of different networks here the
idea is that they're all sort of special
purpose partitioned off from each other
um clients can be part of any number of
them that they want um this example is
going to touch three of our networks so
what we're going to do here it's a very
simple example we're looking up your
ether balance in a tradition so this is
our traditional client you've got
databases over here on the right where
they're storing information it's running
this jsonrpc
server a request comes in to query my
balance the jsonrpc server is going to
do a couple of things here it's going to
reach into an index to figure out what
the client thinks the head of the chain
is it's going to look up the header for
that header from it store uh from
whatever database it stores headers in
once it gets that back it can look at a
field inside of that to see the state
route and then it reaches into the state
database to actually read your account
balance right this all happens very
quickly under the hood and the reason
that a traditional ethereum client can
do this is because it is maintaining
these three these databases that it is
constantly online and it is constantly
keeping these things populated the
portal Network concept is very similar
right there's very little right this is
like oh God did no wrong direction too
much uh so in the portal Network context
when this ethit balance uh request comes
in instead of reading from local data
bases what a client's going to do is
it's going to actually reach out into
this these networks that it's part of to
get the data um we have a network for
essentially tracking the head of the
chain that provides uh the uh Beacon
Light protocol data uh your client's
going to reach into there to know what
the front of the chain looks like which
uh what the head of the chain is it's
going to use that to pull the header
from the history Network which stores
all of the historical block bodies
headers receipts things like that um and
once it has that it can look up what
state route it's supposed to be looking
up things under and it can reach into
the state Network to grab that state
look up your balance and return it to
you uh this is a very simplistic example
but this is very representative of what
the majority of requests are going to
look like there'll be a little bit of
sampling of data from different networks
in order to get the information that you
need before it's returned to the
user all right where are we at um like I
said this has been a long road to get
here we had to build some of the wrong
things to figure out what the right
thing to build was um and and at and at
this stage this uh we're we are we are
past the research stage we are purely in
the get it built and get it out the door
stage uh we have three different imple
client implementations um this is
fantastic I'm so happy about this
because we wanted to build a protocol
not a singular client we wanted to build
something that had many clients to it
and that would instead of just one
reference implementation we've got Tren
written in Rust by my team at the
ethereum foundation we've got ultralight
written by in JavaScript by the
JavaScript team at the ethereum
foundation and we've got fluffy written
by the Nimbus team run by status and um
and here we are uh so here's our rough
timeline right now um software estimates
are garbage uh imminently we are right
at the edge of getting our first Network
really fully up and running that's the
history Network um in parallel to this
the merge has sort of kicked off us
having this Beacon Light Network and
that's sort of like our next major
priority and after that over the course
of 2023 we are going to be getting the
remaining networks online uh the zero to
one is a lot harder than than building
the subsequent networks that come after
that and we've spent a lot of R&D uh
getting to this stage where we almost
have the history Network up and
running um that is what I've got for you
today um if you want to get involved we
are are findable on the internet like
Danny has often said the doors are all
wide open and unlocked if this is a
project you'd like to get involved and
uh please feel free to reach out to me
and I've got some time for questions if
uh that's something we can do I think
we've got a guy with a mic walking
around uh I have a question related to
like the API endpoints which the portal
Network can
s will it be able to serve like ebug end
points that like need like a whole
archival stories on notes if I
understand correctly you're asking about
the debug spaced jsonrpc endpoints yeah
uh not initially um all of the data to
do things with those will in theory be
present um in the network but we are
really focused on like um human driven
wallet interactions that's kind of like
our primary use case that we're that
we're focused on delivering and the
debug in points just don't play a role
in that um and in general are going to
involve a much heavier level of requests
and like data access than is uh
traditionally involved in in kind of
standard wallet interaction so no the
debug name spaced in points are not
officially supported thanks from the
perspective of a application layer
client is the thinking that an
application would be like speaking
directly to like an application would
want to run one of these like clients
itself and speak to that or is the
thinking that for some reason you would
bundle the client itself into the
application or neither of those things
just trying to Gro what the use case is
I I think I understand the question um
so the the there's a lot of ideas on the
table and exactly which ones are going
to stick and which ones aren't is right
we'll find out as time goes on but the
general idea was to build a network
where the clients can be lightweight
enough that you might have two or three
of them actually running on your machine
at any given time because in theory
they're lightweight enough to actually
embed so if you're you know downloading
a desktop wallet um and the portal
Network's up and secure you know uh uh
up and live and production ready there's
it's entirely likely that it might just
bake the client right into the into the
application that you're running and
there might be two or three others
running alongside of it um one of the
things that my team's going to be
focusing on is sort of like a system
level process that's really easy to
download and install that just runs the
thing in the background which makes it
easy for you to do things like connect
metamask up to it or things like that so
I don't think that there there's one
model here I think some applications
might embed it some might treat it as an
external
dependency there y there we go yeah so
something that I'm from with the ls
client that um is that when you want to
execute for like a smart contract call
you might need to do several run trips
because you are basically every time
that you need to query State you are
going to uh go to the full node and ask
for something right and that maybe
creates like again several round trips
which increase the latency of like
whatever you're trying to do so is with
the portal Network you kind of have some
solution for that like trying to kind of
batch that uh I think the question is
because the requests are going out to
the network there's going to be some
inherent latency overheads that come
with
that um not that precisely but that
you're going to do multiple requests so
for example if you want to do rc20
balance off you need to download the
smart contract then you need to start
executing and every time you need to
access some part of like the state uh
database you're going to just go again
and make a query and so you are
basically doing multiple request
multiple current Json RPC request that's
the the kind of concept here yeah I
think currently you you do that
sequentially and so basically you are
increasing the total leny of like
balance off um but if you can find a way
of like doing that concurrently or batch
now that you only do a single request I
think that's going to be a thing that uh
individual portal clients figure out on
their own there's nothing inherent about
the networks that keep you from looking
up large swats of data in parallel at
the same time um and any anything that
can be parallelized at that networking
level will definitely benefit um total
amounts of latency that users
experience uh where do you or do you see
Zero knowledge being used in an
implementation of a like client for the
portal network uh currently it isn't
part of any piece of our road map it's
uh not my
expertise um so I don't know I think is
the concise answer there okay thank you
um just had one quick question
uh what what prevents me from running a
light client and making it like making
it a freeloader that does no work how do
you prevent against uh we don't um so
there's two things that I'll say here um
one is that we had to pick some cfff
points for what we were building because
this is big like like I I I I took a lot
of stabs at making lightweight protocol
access in smaller ways and this is what
came out of Really Trying a bunch of
things and then not working so so in
order to deliver this we needed to build
something that was much bigger than I
originally thought we were going to have
to build and in that we had to like kind
of cut it off at a point um the thing
that we're building is attackable there
is a attack surface that we that that
that that exists and the general idea
here is that those are solvable problems
and we're not going to focus on
absolutely trying to make sure that we
have them all solved on Day Zero uh the
portal network is not core
infrastructure not at the protocol level
the protocol as as we know it does not
depend on the portal Network for
anything and so if the portal Network
Falls over ethereum does just fine and
initially it's possible that somebody
attacks it and that probably means we're
doing something that's working because
it's worth attacking so that's the one
piece which is that we have built
something that we know we are going to
have to hone and fine-tune and work on
the security part of it I have a second
question that might be leading kind of
also curious if uh if I choose to make
my L client act maliciously and you
asked me for the E Bal go Freo got uh
the network is designed to like like if
there are too many freeloaders it'll
degrade performance for everybody um I'm
relying on essentially two things which
are uh the laziness of people so people
are inherently lazy and so going and
configuring your client differently than
how it ships is like something that
people often won't do if it's working
just fine and if we ship it with
sensible defaults that aren't running
your fan speeds at full speed and aren't
filling up your hard disk the chances of
you taking the time to go in and tweak
those settings are pretty small and
there's a and and and you can call it
altruism or you can call it laziness but
we're fundamentally built on this idea
that these small contributions of lots
and lots of people add up to it a lot
right bit torrent works you can download
things pretty fast on it because there's
a lot of people doing it and most of
them aren't screwing with their settings
too much to just Leech from the network
so um can we get the mic over
sorry yes I'll get you next uh yeah just
a small question you mentioned the
beacon line light client Network as well
so what sort of data are you planning to
distribute in the beacon date CLI
Network that you talk about um there's I
believe three data types that we'll be
working with um I am going to
potentially botch this if I list it off
the top of my head um Kim on the uh
fluffy team is the one kind of leading
the like R&D or the the specification
for what that Network serves but it's
the like client update objects um and
there's like one or two more but
essentially it's the minimal objects
that we need to be able to do the Beacon
Light protocol to jump to the head of
the beacon chain I can't hear you I'll
repeat your question I was just
wondering um when you're testing on a
day-to-day uh what user flows are you
using for your tests well so we are
designing at the Json RPC API level so
we're not necessarily building
interfaces for people we're taking the
Json RPC API which is like the standard
API that execution layer client Expos to
users right this is what Alchemy
generally exposes these are the things
that metamask is like calling to um and
so while we are user focused we are
building out clients that can serve the
Json RPC API which is still a low-level
thing right you're still talking about
computers talking to computers um the
wallets and things that get built on top
of this
um that's I think the type of user
testing you're potentially asking about
and that's kind of like outside of our
purview um are I I guess you could say
that the wallets are our primary clients
and that the users are the wallet's
client uh two questions are we talking
about one: one Json RPC compatibility
and then the second question is what
does the road map look like for l2s
because light clients are inherently
very useful uh for cheap operations and
that's kind of where stuff is going so
that's it I think you asked whether
we're building out a like one: one to
the Json RPC API we are not trying to
redefine the Json RPC API it is
established and has been successful and
is generally the backbone of any kind of
ethereum interactions that wallets and
things are making and so we are building
off of the existing standard um I don't
have an answer answer for you on the L2
thing um it's an open question we'll see
how it goes and that is all of my time
thank you all