►
Description
In this episode of NEAR Blockchain Concepts, we go over the concepts that are involved in bootstrapping NEAR Protocol network from scratch.
We will briefly cover some of the network configuration options that can be tweaked in the genesis file, and how the network makes its first step with the help of validation nodes, and how the validation nodes rotate on the high level.
Speaker: Vlad Frolov, Engineering Manager of Public Interfaces Team at NEAR
Useful links
- NEAR Block Explorer - https://explorer.near.org/
- JSON RPC APIs documentation - https://docs.near.org/docs/api/rpc
- Learn more about Epoch - https://docs.near.org/docs/concepts/epoch
- Learn more about Validators and Staking - https://docs.near.org/docs/validator/staking-faq
- Reference-level documentation on Genesis Configuration - https://nomicon.io/GenesisConfig/GenesisConfig.html
- Reference-level documentation on Validators Selection - https://nomicon.io/Economics/README.html#validator-selection
Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol
A
I
will
probably
use
explore
to
navigate
us
through
so
basically
exploring
some
terminal.
Basically,
the
blockchain
consists
like
the
from
something
from
the
name.
You
may
assume
that
blocks
are
the
core
piece
of
it,
but
it's
it
doesn't
help.
I
would
say
most
of
the
time,
so
let
me
start
from
where
the
like
how
the
blockchain
builds
up
and
where
it
starts
and
how
it
grows.
A
So
what
we
have
is
our
near
core
is
a
piece
of
software
which
defines
the
behavior
and
the
the
rules.
How
like
the
system,
will
work,
and
there
is
some
configuration
that
you
need
to
start
from,
and
this
configuration
is
is
called
genesis.
So,
basically,
genesis
is
a
configuration
that
all
the
parties
in
this
decentralized
world
agree
upon
and
they
reviewed
main,
so
they
should
review
it.
Let's
put
it
this
way.
A
A
There
is
a
hate
of
like
we
will
talk
about
it
a
bit
later,
but
what
I
want
to
mention
here
that
blockchain
does
not
need
to
start
from
like
completely
scratch
from
like
zero,
and
there
are
a
lot
of
different,
obscure
configuration
at
least
in
here
in
your
core.
There
are.
The
the
important
part
is
the
that
we
have
costs
for
different
operations
on
the
network
and
these
costs
are
set
in
this
file
as
well.
A
A
But
last
year
during
like
our
rush
to
release,
we
realized
that
it
would
be
too
much
of
the
effort,
and
it
would
be
like
quite
hard
to
follow
for
to
to
make
to
make
in
like
in
time
whenever
we
had
any
like
deadline.
We
always
like
missed
it.
So,
instead,
what
we
decided
to
go
is
to
launch
main
net
in
phases,
and
you
can
hear
that
we
refer
to
some
like
phase
two,
for
example,
thing
which
essentially
enabled
what
was
the
last
phase
to
launch
the
main
net.
A
It
unlocked
transfers,
and
that
was
the
last
piece
and
there
was
phase
one
at
phase
zero.
Those
three
phases,
starting
with
zero,
were
happening
last
year
and,
like
all
the
configuration
you
can
re
like
try
to
read
about
them
in
a
way,
but
I
covered
most
of
the
important
settings
over
there
and
there.
B
A
Without
these
records
like
there
is
no
way
so
if,
for
example,
blockchain
does
not
have
an
account,
you
any
accounts,
you
cannot
create
a
new
transaction
because
you
can
confirm
that
your
account
belongs
to
the
network.
So
it's
natural
for
a
blockchain
to
have
this
initial
state.
There
is
the
thing
called
total
supply,
so
it's
an
amount
of
near
tokens
available
on
the
network
when
it
starts
and
there
are
certain
balances
on
each
of
those
accounts
by
the
way
it's
in
yorkton
year.
A
So
it's
a
10
to
the
24th
power.
So
it's
essentially
like
something
around
like
this
is
five
near.
I
believe,
or
something
like
like
that,
so
it's
not
like
ridiculously
high
amounts,
it's
quite
small,
but
these
contributors
that
near
and
foundation.near
were
quite
loaded
balances.
I
believe-
and
also
these
nf
validator
accounts
as
well.
So
you
can
see
that
there
are
like
records
of
type
account
and
if
we
scroll
down
a
bit,
you
can
see
that
there
are
contracts
deployed.
A
A
A
Account
name
account
id,
you
always
need
a
signature
and
to
have
a
signature,
you
need
to
have
a
key
player
and
one
of
the
public
key
should
be
recorded
on
the
blockchain.
So
we
can
see
those
accounts
have
access
keys,
and
this
is
this
is
basically
all
on
the
genesis
side.
We
have
also
the
data
record,
which
is
essentially
a
state
of
that
contract
that
we
just
saw
linear
account,
and
there
are
like
some
other
configuration
options
just
for
near
needs.
C
A
All
right,
so,
basically,
this
is
the
how
the
blockchain
starts.
You
need
this
file
and
you
need
the
piece
of
software
that
understands
it
and
can
operate
on
top
of
the
protocol
with
whatever
like
we,
we
call
it.
We
just
have
numbers
here
so
protocol
number
29
is
what's
required
to
run
genesis,
so
it's
near
protocol
version
29.,
whatever
it
means,
and
then
you
have
these
four
machines
nf
validators.
A
A
I
will
cover
them
later,
but
overall
validators
are
in
charge
of
creating
blocks
and
chunks,
so
they
do
it
regularly,
every
second
or
roughly,
every
second
in
near
core,
and
you
can
see
on
explorer's
side
that
there
is
some
average
block
time
production,
and
you
can
also
see
this
number.
It's
changing
so
essentially
look
up
the
latest.
A
A
So
that's
how
we,
how
this
number
is
counted
block
8,
is
essentially
a
number
of
the
the
block
number
that
is
produced
on
network
one
thing
I
want
to
mention
that
it's
monotonically
increasing,
but
it
it
does
not
need
to
like
not
every
block
exists,
sometimes
due
to
validators
being
offline,
they
skip
their
their
turn
and
they
don't
produce
block
and
then
another
validator
will
come
in
and
produce
their
block
that
is
scheduled
to
produce
for
them.
So
they
they
the
the
numbers.
A
The
blockade
is
not
sequential,
meaning
that
there
could
be
some
like
missing
blocks
in,
like
in
general,
they're,
quite
sequential
and
usually
like
most
of
them
exist,
but
there
are
some
hiccups
here
and
there,
when
you
can
observe
that
quite
many
of
them
are
missing.
So
every
second
we
produce
a
new
block.
A
A
What
whatever
this
hey,
we
had
that
state
where
we
had
just
a
few
accounts
yet,
and
some
of
them
had
some
like
balance,
changes
and
like
some
balances
on
them,
and
this
happened
last
year
in
august
21st.
Since
then
we
arrived
to
36
million
blocks.
36
million
blocks
is
the
latest
blockade,
so
basically
20
26,
27
million
blocks.
A
That's
what
happened
around
a
month
ago
with
testnet.
Actually
testnet
is
not
that
heavy.
I
would
say,
but
still
the
current
genesis
file
this
one
for
testnet
with
records
is
five
gigabyte
json
file.
We
call
this
process
hard
fork,
even
though
it's
like
it's
it's
a
wrong
term.
I
would
say
it's
a
hard
reset,
so
we
essentially
reset
the
network
to
the
to
these
values
we
can
edit
it.
We
can
edit
the
json
file.
What,
whenever
whatever
like
to
whatever
state,
we
feel
is
needed,
we
could
remove
accounts.
A
A
I
can't
say
that
it
was
the
best
decision,
but
anyway
main
net,
so
we
don't
want
to
make
this
such
hard
reset
on
mainnet,
because
we
will
lose
the
history
and
we
cannot
really
prove
that
these
records
will
be
correct,
so
it
will.
It
would
be
quite
a
quite
a
major
incident
if
we
would
need
to
do
hard
reset.
A
That's
why
we
have
a
lot
of
migrations.
We
have
a
lot
of
quirks
here
and
there
and
that's
why
we
sometimes
introduce
new
protocol
version
just
to
patch
certain
behavior
and
bringing
missing
data
that
for
some
reason
we
like
didn't
process
during
the
like
operation
of
the
network
before
so
we
have
quite
a
few
bugs
that
caused
us.
A
few
inconsistencies
in
the
network
and
we
had
to
implement
some
patches
with
the
protocol
version
upgrade.
So
that's
how
we
upgrade
the
network.
But
let's
get
back
to
the
core
concepts.
A
B
A
Could
we
could
have
like
a
essentially
a
process
where
validator
would
just
come
and
say?
Well,
I
want
to
start
valeating
and
we
would
allow
them
to
do
so,
but
that
would
be
quite
challenging
to
implement,
because
those
validators
need
to
have
history.
Those
all
leaders
need
to
be
ready
to
to
operate
also
the
other
like
the
schedule,
needs
to
be
changed.
As
I
mentioned,
there
is
a
schedule
where
each
validator
is
allocated
to
produce
certain
block.
A
A
A
D
A
A
A
As
you
can
see,
it's
exactly
the
epoch
length
variable
here.
However,
sometimes
this
specific
block
13
at
the
end
will
be
missing
and
but
you
still
need
to
have
some
block
produced
to
conclude
the
end
of
the
epoch
and
that's
why
at
some
point
you
can
see
13
13,
13,
13.,
okay,
it
was
fine,
but
then
it
turned
to
be
17..
A
What
happened
is
essentially
the
there
was.
There
were
no
validators
to
produce
those
four
blocks
and
only
like
three
three
blocks
and
only
on
the
fourth.
After
the
thirteen
on
on
the
seventeenth
block,
we
finally
produ
the
exam
validator
finally
produced
a
block
and
the
epoch
was
ended
or
rather
started
a
new
epoch
or
rather
ended
yeah.
I
guess
it's
a
last
block
in
the
epoch,
so
it's
it's
the
end
of
the
epoch
answer
your
question.
A
A
They
like
what
I
want
to
point
out
here
is
that
validators
produce
blocks
no
matter
what,
even
if
there
is
no
transactions
at
all
blocks
are
produced.
That
is
because
you
cannot
prove
that
there
is
like
something
does
not
exist.
You
can
only
prove
that
there
exists
zero
transactions
when
you
produce
a
block.
A
A
A
C
Her
question
in
this
regard
like,
for
example,
in
this
situation,
we
have
four
validators
a
specific
amount
of
blocks
like
it's
constant
and
in
the
statistics
we
have
like
one
validator
completely
missed
the
epoch,
so
it
doesn't
mean
that
we
actually
miss
that
amount
of
blocks
and
how
come
in
this
file
like
if
we
sum
up
all
the
expected
blocks
numbers,
we
won't
get.
This
43
020
blocks.
C
C
D
D
It's
it's
not
about
this
team,
but
about
previous
team.
I
can,
I
can
add
the
information.
So
when
you,
when
you
are
looking
at
the
the
blocks
and
looking
at
the
number
of
transactions
that
were
included
in
this
block,
even
if
there
is
zero,
it
does
not
mean
that
nothing
was
nothing
was
making
at
this
block
because
it
could
be
hard
right
now,
apart
from
transactions,
we
have
receipts
and
it's
possible.
I
just
checked
it:
it's
possible
that
this
block
has
a
receipt
process.
B
C
D
C
A
A
A
A
There
are
some
other
useful
information
over
here.
What's
interesting
is
there
is
like
prehash,
which
is
the
previous,
the
hash
of
the
previous
block.
There
is
a
hash
itself:
where
is
it
yeah?
It's
it's
hash
over
here,
it's
a
block
hash
and
there
is
a
hate.
So
I
just
queried
this
number,
and
so
it's
no
surprise
that
we
see
it
and
what
else
conversion
timestamp
is
the
is
a
number
in
nanoseconds
where
the
block
was
produced.
A
A
A
We
built
sharding
into
near
protocol
design
and
blocks
are
essentially
a
virtual
entity
which
does
not
include
transactions
by
itself.
Blocks
contain
like
records,
the
chunks
that
are
included
in
the
in
the
block,
and
they
don't
care.
What's
inside
the
chunk,
they
the
block,
only
care
about
which
chunks
are
included,
and
then
each
chart
tracks
different
charts,
charts
are
are
just
like
there
is
a
chart.
Id
chart
id
is
a
is
an
integer
from
0
to
n
minus
1,
where
n
is
the
number
of
shards?
B
A
On
here
operates
with
single
chart,
which
means
that
we
don't
leverage
scalability.
Yet
the
reason
is
we
just
don't
need
it,
given
that
we
only
have
like
three
transactions
in
a
block.
It's
not
a
problem
to
handle
for
near
protocol,
but
overall
in
the
future,
we'll
enable
the
feature
the
the
support
and
configuration.
Essentially,
it
will
be
configuration
change
to
have
more
charts
and
each
chart
has
their
own
produce
their
own
blocks
in
a
sense
of
regular
blocked,
other
other
blockchains.
A
A
There
will
be
a
hiccup,
but
it's
like
okay,
we'll
produce
block,
not
the
next
second,
but
the
second
after
that.
So
there
is
no
problem
for
the
operation
of
the
network.
The
same
goes
with
chunks.
Chunks
are
produced
by
like
different
validators
as
well,
and
if
chunk
is
missing,
it's
fine
block
will
still
be
produced
in
the
case
of
a
single
chart.
This
could
mean.
Well,
then,
does
this
mean
that
we
can
all
like
have
an
empty
list
of
chunks?
A
In
theory,
you
can
view
it.
This
way
like
there
could
be
blocks
without
chunks
in
practice
in
year
protocol
again
just
to
prove
that
something
does
not
exist.
You
need
to
prove
that
something
exists
and
to
do
so
when
there
is
no
chunks
at
all.
In
like
a
new,
there
is
no
new
chunks
to
be
included
in
the
block
block
producer.
The
validator
that
is
in
charge
of
producing
block
will
include
the
chunk
from
a
previous
known
block,
so
it
will
send
from
the
json
like
from
the
rpc
point
of
view.
A
C
I
have
another
question
while
we're
here.
I
thought
that
like
why,
especially
with
the
data
wants
to
be
a
validator
is
because
a
reward
like
producing
the
block
is
rewarded
by
the
network
like
by
producing
a
new
coin.
If
I'm
not
mistaken-
and
this
coin
goes
to
the
validator
who
produced
the
block-
and
currently
we
can
see
that
field
validator
reward
is
zero.
C
B
B
A
A
A
If
if
validator
was
online
for
more
than
90
percent
of
the
time,
so
it
has
great
online.
They
are
rewarded
according
to
this
ratio
and
also
according
to
the
stake
that
they
they
have.
So
if
you
look
here,
different
values
have
different
stake.
So,
according
to
this
number,
the
the
higher
the
stake,
the
higher
is,
the
reward.
The
reward
is
constant,
but
it's
it's
computed
based
on
the
stake
that
each
validator
has
and
this
on
offline
can
affect
them
and.
C
A
A
C
A
A
C
C
A
C
A
B
A
B
A
E
A
E
A
C
From
my
perspective,
having
the
proof
of
stake
is
actually
like,
I
don't
think
if
you
have
a
validator
node
like
which
enough
to
run
near
core
that
it's
too
hard
for
you
to
produce,
not
not
them
not
empty
blocks
like
it's
not
so
hard
for
you
as
producing
empty
blocks
like
we're
not
proving
the
work,
so
it's
kind
of
not
very
heavy
stuff.
So
I
guess
it's
useless
to
hug
the
node
and
risk
your
stake
to
get
this
like
this
hearty
thing.