►
Description
Topics covered
-----------------------------
1:32 - Guest’s introduction
2:41- The roadmap for the talk
3:19 - What is the Portal network?
4:25 - Users (as opposed to protocol)
6:06 - Design goal
6:23 - Light (Resources constrained devices)
6:30 - What makes Ethereum clients heavy
7:04 - Spreading things out
8:45 - Contribute what you can
10:05 -No Sync (Acceptable UX)
11:21 - Scalable (Millions of participants)
13:05 - JSON-RPC (The foundation)
14:06 - A practical example
14:30 - Sending a transaction in the Portal Network
15:00 - The “Header Gossip” network
15:43 - Acquiring the “Latest Header”
17:27 - The “State Network”
18:05 - Acquiring “Account nonce”
19:42 - Estimating gas
20:35 - The “Transaction Gossip” Network
22:16 - Broadcasting a Transaction
23:22 - The “History Network”
23:52 - Monitoring for Transaction inclusion
24:50 - All the transactions happening here are being mined on the main network?
25:13 - Header network - How does it get DoS resistant in the proof of stake world?
26:35 - State distributed hash table - How do you get anonymity on that?
28:29 - Transaction network - What does it solve?
31:50 - Can you elaborate on the tx pool design?
33:39 - How do you prevent attackers from spamming a portion of the DHT to make state available?
35:25 - Project Status
36:39 - Looking ahead (The future Portal Network)
37:36 - Making traditional clients lighter
39:43 - Helping full nodes
40:56 - IPFS / IPLD / Filecoin
42:03 - Global Archive node
42:49 - What is the main target of the ultra-light client?
44:48 - How is the Portal network a better solution than third-party providers like Infura?
47:30 - Sub protocols - the upside of working independently?
49:34 - Beacon chain validator & the Portal Network - Is there visibility of other use cases of Portal network after the Merge.
51:49 - Have you envisioned any change in the client diversity ratio with the Portal Network?
Resources
--------------------
Slides - https://docs.google.com/presentation/d/1YTM7VnD3kOGErhn5o_9JD1AANp6SUByRjstL2wCZRCQ/edit?usp=sharing
GitHub - https://github.com/ethereum/portal-network-specs
Follow at Twitter
-----------------------------------------------
Piper Merriam @pipermerriam | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
another
exciting
episode
of
an
educational
video
series
where
we
learn
about
an
improvement
proposal,
upcoming
upgrades
and
ethereum
blockchain
basics,
I'm
your
host
pooja
ranjan
and
today
we
are
joined
by
piper
mariam
to
have
a
technical,
deep
dive
into
the
portal
network.
The
portal
network
is
an
ongoing
effort
to
enable
lightweight
protocol
to
make
the
resource
constraint
devices
be
a
part
of
the
network,
such
as
cell
phone
laptops
or
even
raspberry
pi.
A
As
per
the
github
repository,
the
term
portal
is
used
to
indicate
that
these
networks
provide
a
view
into
the
protocol,
but
are
not
critical
to
the
operations
of
the
core
ethereum
protocol
to
learn
more
on
what
portal
network
is
and
how
it
is
going
to
help
users.
Let's
welcome
piper
welcome
to
the
show
piper.
A
Super
excited
to
have
you
on
the
show.
First,
I
want
to
confess
that
I
have
been
a
big
admirer
of
your
work
since
I
joined
the
ethereum
community,
and
this
is
the
first
time
having
you
on
the
show.
So
generally,
we
ask
our
guests
to
provide
a
brief
introduction
and
would
love
to
hear
when
and
how
you
joined
the
ethereum
community.
B
B
A
Wonderful,
I
followed
your
work
and
have
watched
you
in
meetings
and
events
talking
about
and
giving
presentation,
it's
really
exciting
to
know
you
more
and
I'm
sure
not
many
people
knew
about
it.
So,
thanks
for
sharing
moving
on
to
the
portal
network,
I
understand
you
have
got
a
presentation
to
be
shared
with
our
viewers.
A
B
All
righty,
as
I
said,
I'm
piper
and
I'm
here
to
talk
to
you
about
the
portal
network.
There
we
go.
Let's
see
there,
we
go
cool,
so
here's
a
little
road
map
for
our
talk.
I'm
gonna
tell
you
as
like
just
objectively
and
simply
what
the
portal
network
is.
I'm
we're
gonna
go
into
the
design
goals
that
went
into
building
this
like.
B
I'm
going
to
do
some
brief,
covering
of
like
just
where
the
project's
at
and
what's
going
on,
and
then
we're
going
to
do
a
little
bit
of
a
look
ahead
as
to
what
I
think
comes
next
like
like,
as
this
thing
gets
live
and
as
it
becomes
real.
What
happens
after
that,
all
right.
So
what
is
the
portal
network?
The
portal
network
is
five.
B
Currently,
it's
it's
multiple,
five
different
decentralized
peer-to-peer
networks,
they're
all
special
purpose
and
generally
designed
to
do
one
thing
very
well,
so
it's
five
different
new
peer-to-peer
networks.
This
is
not
upgrades
to
previous
protocols.
This
is
not
the
dev
p2p
protocol
that
current
ethereum
clients
use.
This
is
new
protocols
built
on
top
of
the
discovery,
v5
protocol
that
do
these
things.
We've
got
three
networks
here:
the
state
network,
the
canonical
industries
network
and
the
history
network,
which
are
special
purpose
storage
networks
that
are
designed
there
to
store
data
and
make
it
retrievable.
B
And
then
we
have
these
two
gossip
networks,
the
header
gossip
network
and
the
transaction
gossip
network
that
are
there
for
their
independent
purposes,
header
gossip
for
following
the
chain
and
transactions
for
broadcasting
transactions.
So
in
a
simple
sense,
this
is
what
the
portal
network
is.
It's
five
different
networks
that
do
very
specific
things
and
that
are
generally
completely
independent
from
each
other.
B
But
the
real
thing
here
is
that
the
portal
network
is
a
effort.
That's
really
focused
on
users
rather
than
the
protocol.
Now,
there's
some
confusion
in
terminology
here,
because
the
portal
network
is
a
protocol
and
we've
got
this
other
protocol,
that's
the
ethereum
protocol,
but
the
idea
is
that
the
ethereum
protocol
is
really
focused
on
supporting
the
ethereum
protocol
right.
It's
about
keeping
full
nodes
up
and
miners,
and
that
stuff
that's
happening.
The
technical,
deep
things
as
as
blocks
are
made
in
mind
and
all
of
that
stuff.
B
This
network
is
focused
on
users
on
on
the
people
who
want
to
use
the
ethereum
network,
and
so,
and
so
we've
really
focused
on
that
as
our
design
goal,
because
because
the
two
things
have
very
different
needs
and
trying
to
do
everything
with
one
network
hasn't
worked
super
well.
Another
way
to
look
at
this
is
that
the
portal
network
is
aiming
to
fill
in
a
quadrant
of
this
graph
that
currently
doesn't
exist.
This
pink
smart
car
today,
if
you
want
to
interact
with
the
ethereum
protocol,
you
may
either
run
a
full
node
yourself.
B
That's
the
decentralized
and
heavy
corner
of
this
graph,
and
they
are
quite
heavy
we're
looking
at
like
500
gigs
of
hard
drive
space
and
that
grows
over
time.
You'll
see
some
of
my
slides
here,
probably
say:
400
gigs
because
they
were
made
at
different
times
or
you
can
sacrifice,
sacrifice
on
decentralization.
B
You
can
go
with
the
centralized
and
lightweight
approach
with
something
like
infuria
or
any
of
the
other
centralized
providers
who
also
have
access
to
everything
that
you
do
and
can
watch
you
do
it
we're
looking
at
filling
in
a
third
option
here,
an
option
that
is
both
lightweight
and
sticks
with
the
tenants
of
decentralization
that
we
all
care
so
much
about,
or
some
of
us
do
at
least
all
right.
So,
let's
get
into
some
design
goals.
This
is
the
the
like
philosophy,
the
the
the
the
motivation
behind
doing
this
primarily
we're.
B
B
We
wanted
a
network
where
that
data
could
be
easily
spread
around
among
all
of
the
nodes
in
the
network
and
that
they
could
help
share
the
load
right.
Some
of
them
can
hold
more
than
others,
but
in
general,
spreading
things
around
another
way
to
look
at
this
is
in
this
very
informationally
dense
table
that
I
have
here,
which
the
top
row
is
the
r
value.
B
I
got
this
like
the
rep
replication
value,
so
how
many
nodes
are
storing
in
any
individual
piece
of
information
and
in
the
left
column
we've
got
number
of
nodes
in
the
network.
So
if
we
say
that
a
node
takes
400
gigs
of
data
to
store
it,
then
that
upper
left
hand
cell
there,
where
it
just
says
400
gigabytes,
that's
what
one
node
takes
right.
B
B
B
You
need
to
be
able
to
receive
and
validate
and
gossip
and
pass
around
every
single
transaction
that
is
being
passed
around
and
if
you
aren't
that
tall,
if
you
don't
have
quite
enough
cpu
resources
to
throw
at
that
you're
not
going
to
be
able
to
be
an
effective
member
of
that.
Instead,
we
try
to
take
this
different
model
where
we
can
kind
of
like
let
people
you
know
stack
up
on
a
tr.
B
B
Another
thing
that
we're
looking
at
is
ux,
so
we
wanted
a
network
where
syncing
and
we
wanted
to
build
a
network
that
supported
clients
that
didn't
need
syncing,
because
syncing
is
really
bad
ux
having
to
wait
like
hours
and
hours
or
days
for
your
client
to
sync
before
you
can
use
it.
That
is
why
people
use
other
stuff,
among
other
things,
it's
just
a
really
unfortunate
ux
and
it's
fine
for
the
infrastructure
stuff
for
the
full
nodes
for
the
for
the
for
the
pieces
of
software
that
run
the
core
of
the
protocol.
B
If
you
have
a
header
that
you
consider
to
be
the
tip
and
reel
and
part
of
the
chain,
that
header
gives
you
everything
that
you
need
to
validate
all
of
the
rest
of
the
data,
so
it
is
possible
for
portal
client,
not
just
possible,
but
it
will
be
standard.
I
believe
for
portal
clients
to
be
able
to
be
downloaded
installed,
turned
on
and
used
immediately.
B
B
Past
efforts
to
do
light,
clients
to
do
to
do
light.
Protocol
access
were
largely
less,
which
is
the
light
ethereum
sub
protocol.
It's
been
worked
on
for
years
and
it
works,
but
the
problem
is
that
it
depends
on
full
nodes
serving
the
data,
and
what
has
happened
is
that
it
hasn't
been
very
reliable
because,
as
you
throw
more
nodes
at
it,
those
full
nodes
get
overloaded
and
it's
it's
not
actually
fine.
You
you,
the
light.
Les
has
not
provided
like
a
reliable
light.
Client
experience.
B
If
you
look
at
sort
of
this,
you
know
the
the
simple
graphic
of
centralized
decentralized
distributed.
Infuria
is
centralized
right,
centralized
providers
are
centralized,
les
is
decentralized,
but
it's
all
it's
all
clustered
around
the
full
nodes,
and
if
you
don't
have
enough
of
those
full
nodes,
then
there's
not
enough
capacity
for
all
the
nodes
that
want
to
ask
them
questions
about
the
ethereum
data.
B
B
B
By
reading
all
this
data
out
of
the
out
of
the
database,
the
portal
network's
not
incredibly
different
in
the
respect
that
a
portal
client
will
get
a
json
rpc
request,
but
instead
of
reading
it
out
of
a
local
database,
all
of
the
data
necessary
to
serve
the
json
rpc
responses
is
available
from
the
network
level
itself
without
them
having
to
have
done
upfront
work.
So
they
reach
out
on
the
network,
grab
a
bunch
of
data,
mend
it
a
little
bit
and
give
it
back
to
the
user
as
a
response.
B
All
right
does
anybody
have
questions
so
far
cool?
Well,
I'm
going
to
move
on.
If
you
have
something
feel
free
to
wait
for
the
next
pause
for
questions
all
right,
so
we've
got
a
picture
of
what
the
portal
network
is.
It's
a
set
of
new
peer-to-peer,
decentralized
networks.
We've
got
an
idea
of
kind
of
why
it
is
being
built
and
what
are
the
goals?
What
are
what?
B
Why
is
it
being
designed
the
way
that
it's
being
designed,
rather
than
go
through
a
bunch
of
slides
that
do
like
a
bunch
of
deep
dives
and
trying
to
like
convey
deep
technical
information?
I'm
going
to
take
you
through
a
practical
example
of
building
and
signing
a
transaction
building,
signing
broadcasting
and
waiting
for
a
transaction
to
be
included.
B
This
is
the
rough
shape
of
what
this
is
going
to
look
like
we're
going
to
start
in
the
header
network
work
our
way
through
a
couple
of
these
things
until
we've
waited
for
the
transaction
to
be
mined
here
we
go
so
the
first
thing
that
a
portal
client
needs
to
do
is
know
what
the
latest
header
is
right.
This
is
how
we
anchor
all
of
the
data.
This
is,
it
has
all
the
fields
like
the
state
route
for
proving
information
as
they
get
it
back,
and
so
this
is
what
the
header
gossip
network
is
for.
B
It
is
for
disseminating
new
headers
as
they
show
up
on
the
chain
and
then
one
of
the
other
things
that
we
needed
to
do
was
we
is
that
sort
of
same
that
you
must
be
this
tall
to
ride
thing.
The
whole
chain
of
history
of
headers
is
gigabytes
in
size,
it's
still
quite
large
and
and
that's
larger
than
we're
willing
to
require
clients
to
download.
So
we
took
a
cue
out
of
the
beacon
chain's
design.
They
use.
B
So
the
portal
network
does
not
dictate
how
you
acquire
the
latest
header.
We
leave
a
lot
of
room
for
this,
because
this
is
this
is
one
of
the
places
where
the
ux
gains
can
happen
on
one
far
end
of
the
spectrum.
We've
got
the
idea
of
just
delegating
trust
to
somebody
else.
You
could
just
ask
infira
what
is
the
latest
header
and
in
general
they
have
a
pretty
strong
incentive
not
to
lie
to
you.
I'm
not
saying
that
you
should
do
that.
I'm
just
saying
that
it
is
it
is.
B
It
is
one
end
of
the
spectrum.
On
the
far
other
end,
we've
got
the
trustless
approach.
Where
you,
you
see,
a
header
come
in
over
gossip
and
then
you
trace
the
parent
chain,
all
the
way
back
to
genesis
and
once
you've
verified
that
you
have
verified
for
sure-
and
this
is
still
everything
I'm
saying
right
now
is
still
like
anchored
in
the
proof
of
work
context.
Things
shift
a
little
bit
after
the
merge,
but
in
general,
these
things
hold.
B
We
acquire
the
latest
header,
we
have
it.
We
know
what
the
latest
state
route
is,
and
this
lets
us
dig
into
the
state
net
network
where
we're
going
to
get
our
account
knots
and
then
build
estimate
the
gas
for
a
transaction
and
sign
it
all
right.
This
takes
us
into
the
state
network.
The
state
network
is
responsible
for
the
storage
of
all
and
retrieval
of
all
of
the
accounts
and
contract
storage
information.
B
We've
got
a
couple
of
mechanisms
for
right,
bringing
data
into
the
network
as
well
as
mechanisms
for
making
sure
that
we
can
clean
up
old
tree
data.
That's
no
longer
needed,
so
we
don't
clog
up
all
the
storage
with
old
intermediate
tree
nodes
that
just
aren't
necessary,
but
in
general
the
state
network
is
for
managing
the
state.
It
is
the
most
complicated
and
the
hardest
of
the
networks.
B
It
was
the
hardest
thing
that
we
had
to
do
and
and
pretty
proud
of
the
design
excited
to
have
some
of
you
look
at
it.
So
this
is
a
real,
real
like
high
level.
Look
at
like
what
we
do.
So
the
idea
is
that
all
of
these
networks
are
dht's
they're,
all
kademylia
flavored
dhts,
which
means
that
they
have
like
a
30
dubai.
B
A
32
byte
key
space
and
dhts
have
this
sort
of
topology
to
them,
which
means
that
nodes
aren't
just
sort
of
floating
around
the
network
wherever,
but
they
have
this
concept
of
like
a
location
in
the
network,
that's
dictated
by
your
public
key
and
so,
and
so
what
we
do
is
we
is.
We
say
all
of
the
state.
Data
is
mapped
onto
that
key
space,
similar.
So
for
any
piece
of
data
that
you
want,
you
can
figure
out
where,
in
the
key
space
it
should
live
and
then
using
the
dht.
B
You
can
find
the
nodes
that
live
near
that
location
and
they
should
have
the
data
that
you
want.
Assuming
everything
works.
Well,
we're
not
going
into
anything
about
guarantees
about
data
availability.
There
are
absolutely
states
of
the
network
in
which
data
might
be
missing.
The
thing
is
that
we
can.
We
can
patch
those
things
up
very
cleanly,
I'm
not
going
to
get
into
those
mechanisms
today
for
today
we're
going
to
assume
a
healthy
network.
B
So
we
figure
out
where
the
account
is
that
that,
where
our
account
lives
in
the
dht,
we
go
find
the
nodes
that
live
near.
That
and
we
ask
them
for
information
about
our
account
now
that
we
have
our
knots,
we
can
kind
of
build
a
pseudo
transaction
that
will
run
through
a
specially
to
tune
tooled,
evm,
we're
going
to
stay
in
the
state
network
and
we're
going
to
estimate
the
gas
for
our
transaction.
Now
this
works
much
the
same
way.
Portal
clients
are
going
to
need
a
specially
tooled
evm.
B
That
knows
that
when
storage
lookups
happen
when
when,
when
any
of
the
lookups
into
the
state
happen,
instead
of
reading
off
of
a
disk
like
current
clients,
use
it's
going
to
read
the
data
out
of
the
network
from
somewhere,
it's
going
to
actually
go.
Look
it
up,
pull
the
data
back,
verify
the
proof
against
the
header
and
and
continue
with
execution.
B
B
After
estimating
the
gas
we're
able
to
like
fully
construct
our
transaction
and
sign
it,
at
which
point
we
need
a
miner
to
include
it
in
a
block
which
means
we
need
to
somehow
get
it
to
miners.
This
is
where
transaction
gossip
comes
in,
so
the
transaction
gossip
network
is
also
all
of
these.
Networks
are
dhts
by
the
way,
but
the
transaction
gossip
network
is
a
little
bit
special.
B
B
Individual
nodes
have
control
over
how
much
of
that
pool
they
process.
Full
nodes
might
keep
that
number
at
a
hundred
percent
if
they
choose
to
be
part
of
this
network
miners
front,
running
bots
arbitrage,
mev
people
will
probably
live
at
that
100
range
and
then
most
of
the
clients
are
probably
going
to
be
sitting
around
5
10
15
20,
something
like
that
processing,
a
small
piece
of
the
pool
and
then
passing
that
stuff
up
to
the
bigger
notes.
B
The
other
thing
that
we
have
to
figure
out
here
is
mitigation
against
dos
attacks,
because
you
can
assign
an
infinite
number
of
valid
transactions,
but
the
only
valid
ones
that
the
mempool
cares
about
are
ones
that
are
the
next
knots
or
maybe
like
the
next
one
or
two
nonces,
and
transactions
for
accounts
that
have
a
balance
of
ether
to
pay
for
the
gas.
The
way
that
we
do
that
and
again,
I'm
not
going
to
get
into
like
the
nitty-gritty
details
here,
but
we
just
attach
account
proofs
against
the
account
alongside
transactions.
B
These
can
be
benevolently,
updated
by
other
nodes.
If
they
wish
generally,
the
broadcaster
will
attach
a
proof
to
start
off
with
and,
and
so
this
allows
for
that
dos
mitigation
without
having
to
maintain
a
full
copy
of
the
state
locally,
which
is
otherwise
necessary
in
the
current
transaction
gossip
network
in
the
main
ethereum
network.
B
So
the
rough
shape
of
our
transaction
gossip
is
this
is
that
is
that
you've
got
all
kinds
of
different
nodes
in
the
network
that
manage
different
percentages
of
the
transaction
pool
and
the
transactions
generally
flow
from
the
lighter
nodes
up
to
the
full.
You
know
minor
nodes,
it's
it's
a
pretty
simple
gossip
network,
otherwise,
there's
not
a
lot
going
on
here.
So
our
client,
who
has
now
signed
our
transaction
as
part
of
this
network,
has
probably
been
processing.
B
B
One
of
the
changes
that
may
come
about
here
is
that
is,
it
may
be
more
conducive
for
clients
to
rebroadcast
their
transactions
every
once
in
a
while,
specifically
to
update
their
account
proofs
if
they're
sitting
in
the
pool
for
a
while,
so
in
order
to
monitor
for
inclusion,
we're
gonna
go
for
the
history
network.
This
is
the
most
boring,
probably
of
our
networks,
in
that
all
that
it
is
doing
is
storing
the
deep
history
of
headers
block
bodies
and
receipts.
It's
also
a
dht.
B
We
use
a
very
simple
map
to
we.
We
map
all
of
this
data
on
again
onto
the
topology
of
the
network
and
nodes
that
live
near
where
a
piece
of
data
is
mapped
to
are
generally
responsible
for
storing
it
so
to
monitor
for
transaction
inclusion.
A
client
is
going
to
do
this
kind
of
like
simple
flowchart
they're,
going
to
hang
out
in
the
header
gossip
networks.
B
As
they
see
new
headers
come
in
they're,
going
to
go
retrieve
the
block
body
from
the
history
network,
they're
going
to
scan
to
see
if
the
transaction
is
actually
present
in
the
block
body.
If
it
is
great,
their
transaction
got
mined
and
if
not,
they
hang
her
out
and
wait
for
another
header
to
come
in.
B
That's
the
whole
thing
this
is.
This
is
just
a
the
the
simplest
practical
example
of
how
the
portal
network
was
used,
I'll
point
out
that
it
did
not
use
all
five
of
the
networks.
We
have
this
additional
storage
network
here
that
we
call
the
canonical
indices
network,
that's
responsible
for
storing
the
mapping
from
block
numbers
to
the
hash
at
that
height
or
transactions,
to
the
canonical
block
that
the
transaction
was
included.
It
just
didn't
fit
into
this
example.
C
D
B
Like
like
a
like
a
header
like
a
the
other
thing
here,
is
that
a
client
could
just
not
even
be
part
of
the
header
gossip
network.
It
is
probably
fine
for
most
user
land
security,
stuff
users
doing
basic
wallet
interactions
for
them
to
get
their
header
information
from
centralized
sources.
It's
not
great.
I
don't
want
that
to
be
the
only
thing
that
people
do,
but
the
header
network
is
maybe
the
least
important
and
most
boring
of.
D
B
B
I
can't
find
the
word
I'm
looking
for
here,
but
yes,
it's
not
exactly
obfuscation,
but
you
know
if,
if
you
can
mine
out
a
spot
in
the
network
so
that
you
have
like
pretty
reliable,
you
know
a
pretty
reliable
picture
of
like
who's
accessing
which
you
know
the
uniswap
contractor.
Whatever
right
people
might
do
that,
one
of
the
things
we've
talked
about
is
just
having
the
data
slowly
shift
around
the
network.
It
doesn't
exactly
solve
this
problem,
but
it
at
least
keeps
there
being
individual
actors
who
are
constantly.
B
You
know
in
charge
of
the
same
piece
of
information,
but
I
think
the
real
answer
here
is
that
this
is
not
something
that
we
have
tried
to
design
for,
and
this
is
kind
of
why
I
want
more
people
to
be
part
of
this
project,
because
we
can't
do
all
of
this.
Like
like,
it
was
we'd
like
kind
of
draw
some
pretty
firm
boundaries
over
what
we
were
going
to
solve
for
in
this
initial
state
and
what
we
weren't.
D
Right,
let's
see
okay
and
my
last
question
is
about
the
transaction
network,
so
I'm
I'm
not
exactly
clear
on
what
it
solves
like.
Why
do
I
mean
clearly,
as
you
said,
like
whoever
builds
the
blocks
and
in
the
future
that's
going
to
be
quite
centralized
actors,
I
imagine,
because
they
are
the
ones
who
are
able
to
extract
mab
for
anyone
else.
D
B
B
D
B
D
B
C
B
C
B
Yep,
so
we
just
let
you
constrain
the
down
to
a
percent,
it's
effectively
a
percentage.
You
say
I
will
take
transactions
within
this
range.
Basically,
and
you
take
the
transaction
hash
map
it
onto
the
32
by
key
space,
and
if
the
transaction
is
close
enough
to
you
within
that,
then
it
is.
Then
people
will
send
it
to
you
and
if
it's
not,
they
won't
try
to
gossip
it
to
you.
So
the
idea
is
that
you're
publishing
this
sort
of
like
range
value.
That
says,
do
not
give
me
anything.
B
But
but
the
idea
here
is
that
now
you
will
not
receive
the
full.
You
know
fire
hose
of
the
full
mim
pool
you'll
step
into
the
network,
and
you
might-
and
you
might
say,
cool.
I
really.
I
want
to
tune
this
to
the
point
where
I'm
only
throwing
like
half
a
cpu
core
at
it,
and
so
you
play
around
with
that
range
number
until
the
number
of
transactions
you're
receiving
fits
it
is,
is,
is
being
processed
in
the
amount
of
time
that
you're
willing
to
allow
allocate
towards
it.
B
B
We
don't
we
are
not
tackling
the
the
so
one
of
the
core
things
here
is
that
this
is
not
a
consensus,
critical
set
of
protocols.
This
is
a
protocol
aimed
at
users
that
isn't
to
say
that
people
won't
attack
it
or
there
won't
be
problems.
But
if
somebody
does
that,
then
you
just
get
degradation
in
user
land,
and
then
we
have
a
good
problem
to
solve.
B
There's
sort
of
just
some
whitewashing
of
we
have
a
problem
and
we
have
to
solve
it
but
like.
If
people
are
using
this
and
dosing
a
piece
of
the
dht
degrades
that
user
performance,
then
it
means
that
we've
built
something
that's
useful
and
it's
worth
us
attacking
that
design
problem.
It's
just
a
hard
design
space
and
again
we
set
pretty
firm
boundaries
on
what
we
were
going
to
solve
for
and
what
we
weren't.
B
B
We
have
three
legitimate
implementations
underway
fluffy
by
the
status
team
trin
by
the
snake,
charmers
team.
That's
my
team
in
the
ef
ultralight
by
the
javascript
team
symbol
and
some
volunteers
we're
looking
for
supporting
more
implementations.
If
anybody
wants
to
join
the
club,
I'd
love
to
have
a
like
a
wallet
in
bed,
somebody
who
wants
to
really
take
this
and
embed
it
in
their
wallet.
B
B
Cool
looking
ahead
so
the
future.
I
see
this
actually
expanding,
there's
already
people
in
the
apprenticeship
program.
Looking
at
how
we
can
put
beacon
chain
data
into
the
portal
network,
not
into
the
portal
network
right.
This
will
be
a
new
network
in
the
portal
network.
That's
in
that's
designed
to
hold
the
specific
beacon
chain
data
right.
B
It's
either
a
special
purpose,
storage
network
or
potentially,
a
kind
of
special
purpose
gossip
network,
depending
on
on
what
you're
looking
at
there
are
people
working
on
this
right
now,
I
think
the
lodestar
team
has
started
started
looking
at
it,
along
with
a
bunch
of
people
from
the
apprenticeship
program,
have
been
kind
of
digging
into
this
realm.
So
I
see
the
portal
network
expanding
as
as,
as
things
come
along
it,
the
the
the
the
fundamental
designs
of
like
dhts
in
the
network
seem
really
conducive
to
doing
this
stuff.
B
Well-
and
I
think,
there's
another
piece
here
which
I'll
get
to
in
a
minute
where
this
stuff
starts
contributing
back
to
full
nodes.
So
one
of
the
things
I
see
coming
is
traditional
clients.
That's
your
your
guest,
your
baesu
nether,
mind
eragon,
oh
god.
I
hate
when
I
start
listing
them,
because
I
feel
I
forget
somebody,
I'm
sorry
if
I
forgot
somebody
I
probably
did
but
making
those
clients
lighter
one
of
the
things
I've
seen
a
number
of
the
clients
looking
at
doing
is
dropping
receipts
like
right.
B
B
I
would
encourage
all
of
the
client
teams
to
potentially
come
look
at
what
we're
doing,
because
the
portal
network
gives
you
a
way
to
drop
this
data
while
still
being
able
to
serve
it,
to
other
you
to
your
users
or
to
other
clients
on
the
network.
If
you
want
to
proxy
it
into
the
devp
network.
So
there
are
opportunities
here
for
traditional
clients
to
lighten
themselves
in
very
simple
ways.
B
B
Another
thing
that
I
see
the
portal
network
doing
is
just
kind
of
like
helping
the
the
the
consensus
network,
the
full
network,
the
the
the
the
full
nodes
and
everybody
else
like
that.
So
like
snap
sync
right
now
was
built
for
a
much
faster
version
of
syncing
the
state
and
what
it
basically
depends
on
is
for
you
to
make
requests
to
other
nodes
across
ranges
of
the
storage
space
and
for
them
to
be
able
to
give
you
those
responses
back
very
efficiently.
B
Another
thing-
that's
really
neat
is
one
of
the
apprenticeship
program.
People
loves,
ipfs
and
or
protocol
labs
and
kind
of
the
protocols
that
they've
designed,
which
I
only
have
loose
understandings
of
it,
turns
out.
There's
a
really
clean.
I
don't
know
if
client
clean
is
the
right
thing.
There
is
a
way
it's
really
hard
to
use
general
purpose
storage
networks
for
storing
our
data.
B
Well,
it
looks
like
protocol
lab
solved
some
of
this
with
ipld,
and
one
of
the
guys
in
the
apprenticeship
program
has
a
proof
of
concept
where
we're,
where
he's
serving
the
ethereum
data
over
ipld,
using
kind
of
like
our
native
hashes,
and
things
like
that,
if
anybody
wants
to
collaborate
with
them
on
this,
I
know
that
keenan
would
be
very
happy
for
that.
This
is
a
link
to
his
github.
B
He
calls
it
a
low
ethereum
orbit.
I
I
really
like
the
name
good
naming
there,
and
the
other
thing
that
I
think
will
be
interesting
is
if
the
network's
big
enough,
we
can
build
a
global
archive
node
that
everybody
can
access.
Geth
archive
nodes
is
somewhere
around
10
terabytes
eragon's
like
one
to
two,
so
we're
looking
at
like
a
two
to
ten
terabyte
spread,
put
that
across
a
million
machines,
10x
replication
and
you're.
Looking
at
20
to
100
megabytes
stored
a
piece
if
this
hits
a
scale.
C
B
That,
essentially,
is
just
I'm
not
going
to
pretend
it's
perfect
or
that
we've
dug
deep
into
it,
but
we
have
prototype
portal
clients
running
in
the
browser
talking
with
regular
portal
clients
outside
of
the
browser
over
the
normal
protocol,
with
with
neither
of
them
with
the
with
the
one.
That's
not
a
browser,
one,
knowing
nothing
different
is
going
on.
We
use
a
proxy
because
disk
v5
traffic
is
all
encrypted.
B
So,
like
any
of
the
wallets
that
ship
electron
apps,
who
might
want
to
ditch
their
centralized
infrastructure
or
give
their
users
a
way
to
interact
with
the
protocol
that
doesn't
go
through
that
centralized
infrastructure,
this
is
sort
of
the
other
route
for
that
client.
The
ultralight,
typescript
client
is
the
idea
of
embedding
it
in
an
app
like
that,
and
then
you
open
up.
A
Well,
thanks
for
this
nice
presentation,
I
know
it's
technical
and
deep
into
it.
I
may
have
a
couple
of
basic
questions
which
are
like
for
people
who
are
planning
to
join
the
edm
network.
In
one
of
your
presentation
slide,
you
did
mention
about
infuria
and
it
seems
like
portal
network
would
be
a
better
option
for
running
nodes.
But
could
you
elaborate
a
little
bit
more
like
how
is
it
going
to
be
a
better
solution
than
the
third
party
note
providers.
B
I
don't
think
it's
definitively
better
across
the
board,
there's
going
to
be
more
latency
overhead,
and
things
like
that.
So
I
will
just
be
upfront
that
that,
like
a
wallet
using
infura
and
a
wallet
using
the
portal
network,
it's
very
likely
that
you're
gonna
see
a
bit
more
just
latency
delays
and
fetching
balances
and
looking
up
data
or
like
estimating
the
gas
for
very
large
complicated
transactions
that
those
things
you
might
actually
see,
multi-second,
delays
and
and
fetching
the
data
from
the
network.
B
We
have
just
generally
run
a
bunch
of
back
of
the
napkin
numbers
on
like
looking
at
standard
ethereum
transactions,
looking
at
how
much
tree
data
it
accesses
and
then
and
then
doing
some
extrapolation
on
okay.
If
we
can
look
those
things
up
in
this,
many
milliseconds,
then
we're
fine
because
it
looks
like
we
can
do.
You
know
normal
estimations
for
erc20
token
transfers
and
things
like
that
within
within
a
second
to
a
second
and
a
half,
or
something
like
that.
B
So
so,
and
then
the
other
piece
here
is
right
that,
from
a
browser
context,
you
cannot
natively
talk
the
protocol
that
the
portal
network
runs
right.
We
do
require
this
proxy
so
from
a
browser
context.
If
you
were
doing
a
portal
network
in
the
browser
you're
going
to
be
passing
over
this
proxy,
I
don't
know
if
that's
going
to
end
up
being
a
completely
clean
and
viable
and
just
easy
drop-in
solution.
I
think
it
will
be.
B
I
think
that
there's
definitely
a
route
there,
but
I
need
some
smart
people
to
come
in
and
help
figure
that
out
people
who,
like
working
in
browser
land,
I
don't
know
if
metamask
wants
to
join
the
club-
and
I
don't
know
if
you're
paying
for
your
infuria
access
metamask,
but
this
might
be
cheaper,
so
so
infuria
is
still
going
to
be
faster
right.
If
you,
if
you
want
to
like
do
big
loads
of
stuff
they're,
going
to
be
able
to
respond
to
requests
faster,
but
for
most
things
that
users
do
human-driven
wallet
interactions.
B
A
That's
interesting.
My
next
question
is
about
these
sub
protocols.
You
mentioned
that
it
is
like
a
different
protocol,
state
network
history,
network
and
all,
and
each
of
these
network
is
designed
to
deliver
a
specific
unit
of
functionality
and
the
portal
clients
will
be
participating
in
all
of
these
networks
at
the
same
time.
At
the
same
time,
these
networks
are
designed
to
be
independent
of
each
other.
B
What's
the
upside
of
providing
this
independence,
so
it
would
be
very
easy
to
write
a
command
line
transaction
broadcaster
that
only
knew
how
to
talk
to
the
transaction
network
and
literally,
you
gave
it
a
signed
transaction
or
it
knew
how
to
sign
them,
and
the
only
thing
that
it
does
is
just
connect
to
that
network
and
send
transactions.
Similarly,
portal
clients
that
need
to
run
on
really
lightweight
places
might
choose
to
drop
out
of
the
transaction
network.
B
B
We
want
people
to
be
able
to
make
incredibly
lightweight
clients
that
do
very
special
purpose
things
if,
if
there's
value
there,
the
other
piece
here
is
that
it
makes
for
upgradability
and
for
the
network
to
evolve
in
a
in
a
much
like
nicer
way
in
that
like
when
vertical
trees
hit,
we
might
ditch
the
state
network
entirely
and
just
make
a
new
one
rather
than
trying
to
do
some
upgrade
path.
It's
very
reasonable.
To
just
say,
old
state
network
is
old.
State's
new
vertical
state
network
is
new
vertical
state.
A
B
There
are
a
bunch
of
write-ups
that
the
apprenticeship
program
people
have
done
on
kind
of
like
how
we
might
map
the
like,
like
what
is
it
the
beacon
chain
needs
and
how
does
that
map
into
the
portal
network,
if
at
all,
there's
some
write-ups
on
that?
This
is
not
my
area
of
fluency.
So
I
can't
like
go
into
the
details.
B
There
there's
there's
people
in
the
r
d
discord
who
are
working
on
this
in
the
light
clients
channel
you
can
find
stuff
there
you
can
find,
but
in
general
the
portal
network
is
like,
like
it's
pretty
good
like
we
have
good
primitives
for
building
quite
easy
kind
of
plug-and-go
networks,
for
you
have
data
that
you
want
to
shove
into
the
network
and
have
it
kind
of
spread
around
everywhere,
and
then
you
want
it
to
be
retrievable.
That's
special
purpose,
storage
networks.
B
So
I
think
that
we're
moving
towards
a
place
where
there's
a
gossip
network,
that's
in
charge
of
gossiping
around
again,
not
my
domain
of
expertise,
but
the
light
client
gossip
pieces
that
are
needed
for
light
clients
to
track
the
header
chain
and
then
an
actual
one.
That's
just
about
retrieving
whatever
piece
of
the
beacon
chain
state
you
want
to
retrieve
at
any
time,
so
I
think
the
two
of
those
make
up
the
primary
beacon
chain
functionality,
that's
being
ideated
about
how
we
map
that
to
the
portal
network.
A
A
All
right,
yeah
I've
got
just
one
more.
I
wanted
to
bring
it
up
in
case.
We
have
time
because
it's
not
directly
related
to
the
portal
network,
but
I'm
hoping
it
may
bring
up
some
solutions.
So
last
summer
I
remember
we
had
a
long
discussion
on
the
client
diversity
at
the
all
corner
meeting
and
you
published
a
blog
post
on
snake
chalmers
wrong
opinions
about
this.
That's
right
yeah,
so
I
I'm
just
wondering
like.
A
B
B
Everybody
else
was
gone
and
I
was
like
okay
well,
I
guess
I
can
try
to
solve
this
problem
over
the
and
then
we
spent
years
trying
to
figure
out
how
to
be
a
client
and
it
turns
out
building
a
client
is
really
hard
turns
out.
Ethereum
clients
are
really
heavy
and
hard
pieces
of
software.
That's
it's
hard
and
your
choices
today
are
kind
of
try
to
be
better
at
being.
Death
than
geth
is
or
maybe
try
to
be
better
at
being
aragon
than
aragon
is
right.
B
Aragon's
got
this
like
sweet
archive
mode
thing
and
guests,
just
like
your
like
stock
go
for
it.
Client,
that's
been
at
it
for
years,
it's
hard
to
be
better
at
geth
than
being
geth
they've
had
years
to
optimize
what
they're
doing
and
the
functionality
that
they
that
they
they
expose,
and
it
turns
out
that
the
protocol
that
ethereum
clients
run
on
does
not
give
you
very
much
flexibility
over
what
functionality
you
can
build
or
not
build.
B
It
says
you've
kind
of
got
to
build
all
of
this
functionality,
and
so
what
it
means
is
that
if
you
want
to
build
a
client
today,
let's
say
that
you're
going
to
come
and
like
fix
our
client
diversity
problem,
you
are
just
going
to
have
to
try
to
be
better
at
being
guest
than
geth
is
and
there's
not
a
lot
of
flexibility.
For
you
to
be
very
different
from
what
it
does.
B
We
tried
to
build
trinity
as
like
this
naively.
As
this
like
we're
going
to
build
a
lightweight
client,
guess
heavy,
let's
be
light,
and
it
was
just
it
wasn't
viable.
It
wasn't
reasonable
and
I
don't
think
the
client
diversity
problem
gets
fixed
until
clients
are
easier
to
build,
and
I
think
that
the
portal
network
makes
clients
easier
to
build,
because
I
think
it's
going
to
make
the
devp2p
network
evolve
or
change
or
something
because
we're
presenting
all
of
the
functionality
that's
present
in
the
devp
traditional
ethereum
protocol
in
a
different
way.
B
A
That's
quite
optimistic,
and
I'm
also
hoping
that
we
get
this
diversity
lately
we
have
been
hearing
about
it
a
lot
and
with
a
lot
of
education
materials
going
out,
I'm
hoping
that
new
users
are
going
to
choose
some
other
clients
and
try
to
contribute
in
this
section
in
one
of
your
slides.
You
already
mentioned
about
some
of
the
resources
and
the
github
repository
where
people
can
go
and
follow
the
progress.
A
B
C
A
B
B
A
A
A
The
vision
of
this
idea,
the
vision
of
this
series,
is
to
provide
information
on
what's
coming
up
on
ethereum
blockchain,
and
I
hope
many
of
you
may
have
learned
something
new
today
and
you
would
like
to
share
it
with
your
peers.
So
people
extend
your
support
by
sharing
this
video
link
with
people
interested
in
learning
about
the
portal
network.