►
From YouTube: Run Your Own Beaconcha.in | 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/run-your-own-beaconchain/
In this workshop we will show participants how to setup and run the [beaconcha.in-explorer](https://beaconcha.in) for existing networks (mainnet, prater, sepolia) as well as for custom networks. Also we will explain how to analyze the network using the explorer and how to monitor validators. By doing this workshop we hope to learn about problems people are running into while trying to run the explorer on their own and improve the usabilty of the explorer in general.
Speaker(s): Patrick Pfeiffer, Stefan Starflinger
Track: Staking & Validator Experience
Keywords: explorer,validators,staking
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
A
We
will
go
first
to
how
we
came
to
the
beginning
expert
and
what
what
the
architecture
of
the
project
look
looks
like.
And
finally,
we
will
show
you
how
you
run
the
Explorer,
but
before
we
go
to
anything,
we
need
you,
anyone
who
wants
to
participate.
We
need
you
to
to
download
a
few
things.
So
are
there
any
anyone
who
wants
to
participate
on
this
laptop?
B
B
The
we've
been
basically
active
since
the
beginning
of
ethereum.
In
this
space
we
actually
created
one
of
the
first
block
explorers
but
kind
of
let
it
slack
a
bit.
So
that
was
etherchain.org,
it's
one
of
the
older
ones
and
then
later
on,
we
kind
of
regretted
not
putting
more
effort
into
that
Explorer
and
then
we
kind
of
decided
now
that
there's
gonna
be
ethereum,
2.0
or
basically
the
merge.
B
We
decided
to
create
another
Explorer
specifically
for
phase
zero
and
that
Explorer
kind
of
ended
up
being
the
beacon
chain
Explorer
and
it
started
out
where
everyone
could
basically
see
all
the
information
about
the
beacon
chain.
Maybe
you
shall
of
hands
who
has
used
the
Explorer
before,
maybe
just
to
kind
of
get
a
feel
so
about
half
of
the
people
have
used
the
Explorer
before
so
maybe,
if
you
want
to
show
off
hand,
who's
running
a
validator,
okay,
quite
quite
a
few
of
the
people
that
are
using
it.
B
So
basically
we
we
wanted
to
create
a
nice
place
for
you
to
understand.
What's
actually
going
on
with
the
validator
to
see
the
different
states
of
the
validator
to
kind
of
make
sure
you
don't
get
slashed
and
we
also
operated
one
of
the
bigger
mining
pools
called
ethermine.org
that
was
now
retired
since
the
merge
and
we
kind
of
shifted
away
from
mining
a
bit
and
focusing
we're
focusing
a
bit
more
on
staking
so
kind
of
to
chill
a
bit
our
other
products.
B
We
have
staking.ethermine.org
now
where
you
can
stake
with
less
than
32
each
and
we
have
eat,
pool
if
you're
too
lazy
to
run
your
own
validator.
You
can
just
upload
your
validator
key
and
we'll
kind
of
take
care
of
that
for
you
and
then
a
brief
history.
I
kind
of
already
touched
on
that.
So
it
started
out
in
2019
end
of
2019
with
the
first
test
networks,
so
even
before
the
Genesis
of
the
beacon
chain.
B
B
So
that's
kind
of
how
how
this
whole
project
began
and
it
kind
of
exploded
a
bit
more
and
more
and
with
the
merge
we
tried
to
add
more
information,
not
just
the
phase,
zero
information
and
it
kind
of
grew
and
grew.
And
this
presentation
will
also
be
kind
of
about
how
we
kind
of
handled
the
scale
and
also
give
a
kind
of
a
workshop
where
you
can
help
us
with
with
kind
of
finding
ways
to
scale
better
yeah.
So
let's
go
a
bit
to
the
architecture.
B
So
in
the
beginning
this
is
kind
of
a
very
simple
view.
What
the
beacon
chain
Explorer
looked
like
I,
also
presented
this
a
similar
slide.
I
think
it
was
etcc
a
year
ago
where
we
had
just
the
prism
node
we
had
infuro
node
and
the
funeral
node
was
mainly
to
get
the
deposit
data
from
East
one,
and
then
we
had
an
exporter
that
just
basically
wrote
everything
into
postgres
database
and
that
worked
really
well
in
the
beginning.
B
So
the
numbers
now
are
that
we
switched
to
Lighthouse
and
we
have
a
32
slot
sync.
So
there's
different
kind
of
sync
versions
that
you
can
choose
and,
depending
on
what
amount
of
stats
you
choose,
the
more
information
is
stored,
but
the
quicker
you
can
retrieve
information
and
we
basically
want
to
store
everything
and
that's
already
a
five
terabyte
disk
that
you
need
for
that
Lighthouse
then
Aragon
is
2.1
and
our
postgres
database
is
huge,
so
kind
of
the
tables
and
the
indexes
that
we
have
in
the
postgres
database.
B
They
just
don't
scale
that
well,
so
it's
already
10
terabytes
big
and
we
don't
only
run
the
mainnet.
We
also
run
the
test
net
and
the
test
net
is
just
that
amount
and
even
a
bit
more
for
different
test
Nets.
So
it's
a
huge
amount
of
data
and
it's
getting
a
bit
expensive
running
that
in
the
cloud.
So
we're
going
to
talk
about
how
we
kind
of
started
migrating
away
from
that
and
basically
the
the
scaling
challenges
during
the
merge.
B
So
this
is
kind
of
a
analytics
view
that
we
had
so
we
had
concurrent
sessions
of
2267
people
that
were
looking
during
the
merge
because
we
had
like
this
nice
slot
view
that
you
saw
before
where
people
could
see.
Okay
during
the
transition.
What
was
happening.
It
was
it's
a
nice
visual
way
of
kind
of
tracking
it
and
we
had
a
lot
of
people
we
kind
of
were
kind
of
prepared.
B
So
you
have
this
Super
Mario
mushroom
that
should
power
you
up,
but
that
mushroom
was
kind
of
overpowered
by
the
people
looking
at
it,
because
the
way
the
architecture
was
designed,
it
just
didn't
scale.
Well,
we
have
front-end
instances
that
kind
of
have
to
query
the
same
stuff
like
if
we
have
five
front-end
instances,
they
do
five
times
the
same
queries,
because
we
don't
just
have
like
one
layer
that
updates
our
cache.
We
just
have
every
front
and
instance
that
has
its
own
cache.
B
So
these
are
things
we
kind
of
try
to
try
to
improve,
and
then
again
we
have
very
expensive
indexing
as
well.
In
bigtable
and
big
I
know
a
big
table.
That's
going
to
get
to
later
in
past.
Chris
and
pascals
also
has
to
get
a
lot
of
the
table
into
memory
to
be
able
to
query
stuff,
which
is
a
lot
of
the
times,
not
very
efficient,
especially
with
huge
amount
of
data,
and
so
what
we
try
to
do
is
we
have.
B
We
started
out
with
one
big
binary
where
everything
runs
and
we
try
to
strip
away
things
from
that
big
binary
and
kind
of
isolate
that
in
microservices
that
not
every
binary
does
everything,
and
if
we
duplicate
one
binder,
we
don't
do
unnecessary.
Work
and
kind
of
the
migration
is
kind
of
a
bit
challenging
for
us,
because
then
we
have
to
kind
of
make
sure
that
we
manage
a
lot
of
the
technical
depth
that
we
kind
of
have
and
are
maybe
adding
through
changing
Technologies.
A
B
Okay,
great
I,
hope
the
internet
is
good,
let's
pray
a
bit
because
when
we
tried
it
or
tested
it
before
it
took
a
while.
So
here
you
can
see
I
kind
of
touched
on
that
the
scaling
and
large
table
so
in
postgres
in
the
beginning,
we
didn't
have
any
partitioning
at
all
so
later
on.
When
you
can
just
maybe
hold
out.
I
can
hold
it
up
and
you
can
maybe
okay.
C
Let's
go
so
Cloud
first
I
think
still
makes
sense,
especially
for
like
dos
or
whatever
you
guys
might
need
that
for
in
terms
of
front
end,
I
don't
know
if
this
is
a
bottleneck,
but
we
mentioned
thought
about
clustering
or
some
Auto
scale
for
this,
or
even,
if
we're
going
to
the
web3
ethos
of
let's
put
this
on
ipfs
or
like
distribute
it
somehow
and
merely
make
it
un
undeniable
Service
scaling
that
way
or
it
could
be
just
some.
Some
Auto
scaling
surf,
Some,
Cloud,
run
or
gcp
or
whatever
I
use.
C
For
that.
So
I.
Don't
think
this
would
be
the
bottleneck,
anyways
the
front
end
itself,
I
think
that
and
if,
depending
on
what
you
have
here,
this
could
be
heavily
statically
generated.
So
it
might
be
something
that
you
wouldn't
be
a
problem.
Then
second
layer,
we're
talking
about
cash,
so
I
imagine
most
people
are
our
team
imagines
that
most
people
are
looking
at
past
data,
so
you
probably
don't
have
to
have
direct
access
to
the
database.
You
don't
have
to
do
like
real
queries
against
it.
C
You,
like
cash,
heavily
previous
data
that
was
already
from
previous
blocks.
That
will
never
change
so
things
that
could
be
like
pretty
much
Frozen
there,
because
it's
not
it's
really
static
and
and
and
and
stale
deal.
It's
called
like
that.
So
this,
depending
I,
guess
there's
probably
lots
of
ways
of
doing
this
catch
layer.
This
could
be
like
a
DB
level.
This
could
be
some
like
redis
cash
flow
or
something
like
that.
C
But
yeah
really
really
something
before
the
data
business
itself
then
on
database,
our
friend
I
forgot
his
name,
but
our
friend
there
give
idea
of
maybe
we
can
start
sharding
this,
maybe
some
sharding
based
on
transaction
hash
or
something
like
that
which
same
thing
since
this
is
mostly
data
that
will
live
forever
and
not
touch
it
again.
We
probably
have
a
part.
C
That's
only
read
only
so
it's
there
very
high
output
for
reads
not
that
much
in
terms
of
Rights
and
a
part
which
will
be
the
right
part,
which
this
part
here
would
have
more
direct
access
to
the
actual
nodes,
and
then
the
nodes
probably
make
sense,
have
multiple
archive
nodes.
If,
if
the
RPC
calls
my
be
a
problem,
I
don't
know
if
it
makes
sense
to
have
lots
of
different
machines
running
those
instead
of
inferior
inferior
for
us
in
our
company
is
always
a
problem
and.
C
C
A
A
This
is
the
solution
we
have
right
now
with
which
we
part
of
the
of
the
of
the
of
the
data
set.
We
now
store
and
pick
table
instead
of
important
postgres,
so
we
thought,
like
it's
not
really
necessary,
to
have
a
relational
database
for
this
kind
of
data
set
and
bigtable
scales
really
well.
So
I
think
that
we
we
were
able
to
to
indexed
all
of
the
current
each
one
transactions
in
five
hours.
So
it's
like
really.
A
It
scales
really
well
depictable,
so
we
now
store
the
blocks,
the
balances
of
the
validators,
every
transaction,
all
of
the
attestations
in
bigtable,
and
this
resulted
in
a
really
much
more
stable
in
index
time.
So
now
you
can
see
it
takes
us
like
really
Stables
30
seconds
to
export
all
the
data
of
one
epoch.
A
C
A
A
A
The
next
thing
we
want
to
do
is
to
start
it
one
indexer.
We
called
it
that,
because
we're
not
really
creative
but
it
indexes
like
I,
think
it.
It
first
gets
the
blocks
from
the
execution
glands
and
encoded
in
protopath
and
still
using
into
big
table
encoded
in
protobuf,
and
then
we
index
as
after
that
we
index
the
the
blocks
with
all
the
the
fields
and
values
and
then
transaction
as
well.
So.
A
One
one
big
thing
is
like
we're:
actually
not
using
bigtable
from
from
Google
chart.
We
are
using
emulator
from
the
company
P
key.
What's
up
it
just
emulates
the
the
peak
table,
API
and
stores
it
in
sqlite
database
and
I
think
like
for
for
just
storing
and
then
analyzing
the
data
it
works.
Well,
it's
not
like
it
will
not
scale
for
for
a
thousand
requests
per
second,
but
for
analyzing
the
data.
It's
a
like
a
really
good
solution
solution.
In
our
opinion,.
A
So
the
the
thing
here
is,
we
are
not
able
to
to
reach
the
nodes.
We
we
think
before
the
the
workshop
in
the
cloud.
Somehow
we
don't
get
access.
We
have
this
wi-fi
fan,
so
we
are
now
running
the
nodes
on
our
laptops,
and
that
is
where
you
see
some
errors,
because
the
nodes
are
not
synced
and
it
it's
not
like,
doesn't
work
well,
but
foreign.
A
The
last
thing
we
start
is
the
front
end
and
we'll
get
started
with
the
with
the
cache
up
data
and
then
the
front-end
itself,
which
is
a
golang
web
server,
which
just
queries
all
the
databases.
So
all
the
things
are
running
now
and
we
can
browse
the
pink
chain
Explorer
on
localhost
8080.
The
thing
is,
since
the
nodes
are
not
synced,
it
will
take
some
time
until
any
data
will
show
up
this.
One.
A
A
A
We
will
try
to
make
it
more
easy,
but
the
thing
is
we
really?
What
does
it
saying
We
Stand
by
the
decision
to
make
the
secure
open
source?
So
it's
not,
we
will.
We
will
try
to
to
make
it
available
for
everyone.
It's
not
like.
We
made
the
decision
to
go
into
bigtable
from
from
Google
and
to
run
it
in
gcp
just
to
to
make
the
scaling
issue
like
gone,
but
that
doesn't
mean
it's.
It's
not
available
for
everyone.
A
A
B
B
If
you
have
a
lot
of
validators,
it's
nice
among
other
things
or
if
you
want
to
use
our
API
Services,
you
can
use
the
code
over
the
website
not
directly
over
the
mobile
and
yeah.
If
you're
running
a
validator,
the
mobile-
and
you
don't
know
about
the
mobile
app,
it's
pretty
nice,
it
lets
you
look
at
your
validators
on
the
go.
It
lets
you
get
notifications
when
you
propose
a
Blog
and
kind
of
see
if
you've
gotten
those
30,
East
block
Rewards
or
something
like
that.
A
B
If
you
want
to
contribute
here's
kind
of
the
overview
of
kind
of
the
resources,
so
we
have
a
good
coin.
Grant,
that's
linked
below
you
can
tweet
at
Peak
and
chain.
If
you
see
any
issues
or
something
create
issues
on
the
GitHub
repository,
that's
also
linked
there
and
oh
did
anyone
still
want
to
take
a
picture
or
no
thanks,
yeah.
That's
basically
it
from
us
thanks.
So
much
for
participating
and
listening.
B
If
you
have
any
questions,
yours
right
now
that
you
personally,
it's
called
so
it's
one
of
the
test-
Nets,
it's
a
bit
smaller,
so
it
should
be
able
to
think
in
a
reasonable
amount
of
amount
of
time.
The
Wi-Fi
isn't
the
best
here
so
here
it
could
take
a
while,
but
it's
a
lot
smaller
than
Plata
or
which
is
girly
or
mainnet,
which
are
pretty
huge
right
now.
B
A
Especially,
but
we
looked
also
at
other
DPS,
but
in
the
end
we
took
something
that
also
fits
in
our
team,
like
we
don't
have
so
much
resources.
I
was
like
so
much
take
so
much
man
hours
to
get
into
a
new
technology,
and
for
us
this
looked
at
the
best
fit
and
right
now
we
are
really
happy
with
it.
So.
B
Yeah,
we
basically
went
from
an
export
time
of
30
plus
seconds
for
attestation
assignments
to
like
five
seconds,
which
is
a
lot
better
and
there
was
less
contention
between
different
queries
on
bigtable
now
that
we
moved,
but
that
can
change
if
we
have
everything
on
bigtable
we're
just
starting
to
migrate.
So
I
hope
it
stays
good.