►
From YouTube: The Portal Network by Piper Merriam | Devcon Bogotá
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/the-portal-network/
The Portal Network is the culmination of five years of development and research targeting lightweight access to the Ethereum Protocol. Learn what the Portal Network is, how it works, and what it will mean for Ethereum to have a reliable decentralized network tailor made for end users to interact with the Ethereum protocol.
Speaker(s): Piper Merriam
Skill level: Beginner
Track: Layer 1 Protocol
Keywords: Portal Network,Light Client,Protocol
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
I'm
Piper,
as
she
said
and
I'm
here,
to
talk
to
you
guys
about
the
portal
Network.
So
let's
just
get
right
into
it.
The
I
work
for
the
ethereum
foundation
of
I
already
got
introduced,
so
this
is
about
actually
finally
bringing
lightweight
decentralized
access
to
the
protocol,
and
and
yes,
this
has
been
kind
of
a
a
long-term
project
to
get
us
to
where
we're
at
we
go.
So,
let's
like
dive
into
kind
of
at
this
high
level.
What
the
portal
Network
is
for
me.
A
It's
a
giant
white
whale
that
I've
been
hunting
for
a
long
time
and
hopefully
doesn't
eat
me
in
the
end.
But
the
portal
network
is
five
new
decentralized,
special
purpose:
storage,
Networks
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.
A
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.
This
dream
of
lightweight
access
to
the
protocol.
A
The
project
has
kind
of
these
high-level
design
goals
that
kind
of
informed
what
we
needed
to
build
and
how
it
needed
to
get
built,
and
one
of
the
main
things
is
that
the
portal
network
is
really
user,
focused
all
of
the
clients
that
you
hear
about
today,
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.
A
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
are.
We
upper
right
or
lower
left
hand
corner
of
this
graph.
You
can
run
a
full
node
they're,
very
heavy
and
they're,
also
awesomely
decentralized.
Our
Network
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.
A
A
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
transaction
you
send
or
selling
your
data
and
things
like
that
right.
We,
there
are
two
options
at
the
far
opposite
ends
of
the
spectrum,
and
we
want
to
build
this
thing
in
the
upper
left
hand
corner
this
kind
of
adorable,
pink,
smart
car
that
is
both
lightweight
and
decentralized,
which
supposedly
we
care
about.
A
This,
brings
us
to
this
lightweight
concept.
Like
I
said,
ethereum
clients
are
heavy
and
we
want
that.
We
need
a
network
that
allows
lightweight
devices
to
participate.
Ethereum
clients
are
heavy
today
because
they
have
to
do
a
lot
of
things.
Evm
execution
is
CPU
intensive,
running
the
transaction,
pool
the
CPU
intensive
and
there's
gigabytes
upon
gigabytes
of
history
and
state
data,
and
things
like
that
that
they
need
to
do.
A
This
means
that
running
a
traditional
ethereum
client
is
a
inherently
heavy
thing,
and
you
generally
can't
do
it
on
things
like
Raspberry,
Pi's
or
phones
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
distributes
it
around
all
of
the
participants
of
the
network
in
a
nice
kind
of
even
way.
A
The
other
thing
that
we
focus
on
is
kind
of
removing
some
of
these
height
restrictions
and
by
height
restrictions,
I
mean
essentially
Hardware
restrictions
that
keep
you
from
joining
the
network.
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.
A
You
are
not
allowed
as
a
as
a
participant
in
the
the
dev
P2P
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
mempool
right.
If
you
aren't
tall
enough
you're
not
allowed
into
that
Network,
we
focused
on
a
different
model.
A
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
sync,
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
end
user
interactions,
kind
of
basically
unbearable.
A
A
A
A
Inferior,
Alchemy
they're.
This
centralized
model
right
their
servers
go
down.
Everything
stops
working
Les.
Is
this
decentralized
model
which
we
like,
but
because
there
aren't
enough
incentives
or
anything
for
people
to
run
Les
servers,
it
hasn't
worked
out
super
well,
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
one
way
to
think
about.
A
This
is
very
akin
to
BitTorrent,
where
the
in
Les
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.
Let's
look
at
a
practical
example
of
what
how
you
would
serve
this.
A
Essentially,
a
balance
inquiry
from
the
portal
Network
I'll
remind
you.
We've
got
a
number
of
different
networks
here,
and
the
idea
is
that
they're
all
sort
of
special
purpose
partitioned
off
from
each
other
clients
can
be
part
of
any
number
of
them
that
they
want.
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.
A
You've
got
databases
over
here
on
the
right
where
they're
storing
information,
it's
running
this
Json
RPC
server,
a
request
comes
in
to
query
my
balance.
The
Json
RPC
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
at
the
header
for
that
header,
from
its
store
from
whatever
database
it
stores
headers
in
once
it
gets
that
back.
A
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.
A
The
portal
Network
concept
is
very
similar
right,
there's
very
little
right.
This
is
like
oh
God,
no
wrong
direction
too
much
so
in
the
portal
Network
context,
when
this
eth
get
balance,
request
comes
in
instead
of
reading
from
local
databases.
What
a
client's
going
to
do
is
it's
going
to
actually
reach
out
into
this
net.
These
networks
that
it's
part
of
to
get
the
data.
A
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,
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.
A
A
All
right,
where
are
we
at
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
and,
and
it,
and
at
this
stage
this
we
are.
We
are
past
the
research
stage.
We
are
purely
in
the
get
it
built
and
get
it
out
the
door
stage.
We
have
three
different
Implement
client
implementations.
A
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
it
was
instead
of
just
one
reference
implementation.
We've
got
Trend
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-
and
here
we
are
so
here's
our
rough
timeline
right
now.
Software
estimates
are
garbage
imminently.
A
A
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.
The
zero
to
one
is
a
lot
harder
than
building
the
subsequent
networks
that
come
after
that,
and
we've
spent
a
lot
of
r
d
getting
to
this
stage,
where
we
almost
have
the
history
Network
up
and
running.
A
That
is
what
I've
got
for
you
today.
If
you
want
to
get
involved,
we
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
in,
please
feel
free
to
reach
out
to
me
and
I've
got
some
time
for
questions.
If
that's
something
we
can
do,
I
think
we've
got
a
guy
with
a
mic
walking
around.
B
B
A
Not
initially
all
of
the
data
to
do
things
with
those
will,
in
theory
be
present
in
the
network,
but
we
are
really
focused
on
like
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
endpoints,
just
don't
play
a
role
in
that
and
in
general,
are
going
to
involve
a
much
heavier
level
of
requests
and
like
data
access
than
is
traditionally
involved
in
in
kind
of
standard
wallet
interactions.
So
no,
the
debug
names
based
in
points
are
not
officially
supported.
C
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
grok
what
these
cases.
A
So
if
you're,
you
know
downloading
a
desktop
wallet
and
the
portal
Network's
up
and
secure,
you
know
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.
A
One
of
the
things
that
my
team
is
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's
one
model
here
I
think
some
applications
might
embed
it.
Some
might
treat
it
as
an
external
dependency.
D
D
So
something
that
I'm
familiar
with
the
Elias
client.
That
is
that
when
you
want
to
execute
for
like
a
smart
contract
call,
you
might
need
to
do
several
round
trips,
because
you
are
basically
every
time
that
you
need
to
query
State.
You
are
going
to
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
important
Network.
You
kind
of
have
some
solution
for
that,
like
trying
to
kind
of
batch
that.
D
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
database,
you're
going
to
just
go
again
and
make
a
query,
and
so
you
are
basically
doing
multiple,
multiple.
A
I
think
that's
going
to
be
a
thing
that
individual
portal
clients
figure
out
on
their
own
there's
nothing
inherent
about
the
networks
that
keep
you
from
looking
up
large
swaths
of
data
in
parallel
at
the
same
time,
and
anything
that
can
be
parallelized
at
that
networking
level
will
definitely
benefit
total
amounts
of
latency.
That
users
experience.
A
E
A
One
is
that
we
had
to
pick
some
cutoff
points
for
what
we
were
building,
because
this
is
big
like
like
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
they're,
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.
A
The
thing
that
we're
building
is
attackable.
There
is
a
tax
surface
that
we
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.
The
portal
network
is
not
core
infrastructure,
not
at
the
protocol
level.
A
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.
E
A
For
this
there
we
go
freeloading
yeah.
The
network
is
designed
to
like,
like
if
there
are
too
many
freeloaders,
it'll
degrade
performance
for
everybody,
I'm,
relying
on
essentially
two
things
which
which
are
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.
A
The
chances
of
you
taking
the
time
to
go
in
and
tweak
those
settings
are
pretty
small
and
there's
a
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.
Bittorrent
works.
A
F
A
Talking
about
there's
I
believe
three
data
types
that
we'll
be
working
with
I
am
going
to
potentially
botch
this.
If
I
listed
off
the
top
of
my
head
Kim
on
the
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
light,
client
update
objects
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.
G
A
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,
clients
exposed
to
users
right.
This
is
what
Alchemy
generally
exposes.
These
are
the
things
that
metamask
is
like
calling
to,
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,
the
wallets
and
things
that
get
built.
A
I
think
you
asked
whether
we're
building
out
a
like
one-to-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.