►
Description
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
Okay,
let's
get
started
so
hi
everyone,
I'm
bowen
for
those
who
don't
know
me,
I'm
leading
the
teams
that
work
on
mostly
protocol
development
and
yeah
today
I'll
be
talking
about
the
work
that
we
have
been
doing
and
also
some
of
the
future
works
that
we'll
be
working
on
so
yeah.
Let's
get
started.
A
Rather,
our
goal
is
to
to
make
this
such
that
we
can
serve
the
needs
of
the
developers
and,
truly,
you
know,
be
aligned
with
the
vision
of
near
so
that
that
means
today
we're
building
a
charity
pro
stick
boxing,
but
if,
in
the
future,
there's
some
change
to
the
technology,
for
example,
some
zero
knowledge
proof
become
technology
become
mature
enough
that
we
can
use
it
to
replace
some
of
the
things
that
we
have
today
we'll
be
happy
to
do
that
and
yeah
just
a
brief
overview
of
the
entire
development
process.
A
We
started
back
in
august
of
2018
back
sentencing.
We
started
the
prototyping
in
python.
We
spent
a
couple
months
doing
that,
but
then
yeah.
Actually,
I
think
that
was
not
the
most
the
best
use
of
our
time
and
we
actually
went
down
to
pursue
a
completely
different
different
paths
and
then
we
launched
mainnet
phase
zero
in
april
2020.
A
This
was
a
proof
of
authority
mainnet
that
only
has
values
wrong
by
the
neo
foundation
and
then
gradually
we
start
introducing
more
validators
from
the
community
and
eventually
around
well
on
october
13th
2020,
the
vote
for
mainnet
phase
2
happened.
A
I
think,
eight
months
now
and
it
has
one
chart-
and
I
think
yeah,
if
you,
if
you
have
seen
froze
post
yesterday,
we
produced
more
than
40
million
blogs
on
amazon
and
that's
that's
a
great
achievement.
A
A
So.
The
first
priority
is,
of
course,
safety
and
stability
of
the
network,
because
you
know
if
the
network
is
malfunctioning
or
has
some
critical
vulnerability
that
is
exploited.
Are
the
network
just
stopped
or
like
kind
of
shut
down
or
some
some
someone
tax?
The
network
and
steal
like
a
ton
of
money,
then
obviously
that's
extremely
extremely
bad
for
everyone
who's
using
the
network.
I
will
not
only
cause
applications
to
stop
working,
but
also
people
would
lose
trust
in
us.
A
After
that
is
performance
and
the
scalability,
but
this
also
ties
somewhat
into
the
the
developer
developer
friendliness,
because
all
the
problem
with
ethereum
today,
for
example,
is
that
they
have
such
low
throughput.
That
makes
it
very
painful
for
developer
to
to
build
applications
and
make
it
very
expensive
for
them
to
run
any
applications.
A
And
finally,
we
also
want
our
blocks
and
clients
blockchain
nodes
to
to
be
runnable,
meaning
that
whoever's
wants
to
run
a
node,
whether
it's
validator,
whether
it's
rpc
providers
or
some
other
partners
or
developers,
for
example.
They
wouldn't
have
no
trouble
doing
that.
A
Okay,
let's
actually
talk
about
the
protocol
itself,
so
roughly
on
the
kind
of
high
level.
There
are
three
components
to
it.
So
the
first
component
is:
is
this
peer-to-peer
network
and
our
focus
there
is
to
build
a
reliable
and
scalable
peer-to-peer
network
that
powers
communication
between
blockchain
nodes.
A
So
essentially,
this
is
a
custom
built
protocol
that
enables
communication
between
blockchain
nodes.
This
includes
message
routing
and
things
that
we
will
talk
later
about,
but
there
is
no
essentially
no
good
existing
solution
for
this
problem
and
then
there's
chain,
which
is
this.
You
can
think
of
this
data
structure
that
that
ox
trade-
everything
on
the
on
the
blockchain.
So
this
includes
how
consensus
works.
This
also
includes
how
how
sharding
works
on
the
on
the
high
level.
A
I
mean
like
how
how
blocks
and
the
chunks
which
which
are
sharp
blocks,
are
produced
and
distributed,
and
then
there's
also
runtime,
which
is
this
execution
engine,
that's
basically
a
price
brock's,
the
state
transition
and
so
on
so
yeah.
Let's
actually
go
into
each
of
the
components
and
discuss
in
more
detail
what
what
we
do
there
so
yeah.
A
As
I
said
about
the
network,
it's
a
peer-to-peer
communication
protocol
and
since
it's
purely
peer-to-peer
means
there's
no
centralized
entity
control
controlling
how
how
the
nodes
interact
with
each
other.
They
essentially
follow
some
kind
of
custom
protocol
on
how
they
establish
connections
to
each
other,
how
you
know
they
send
messages
to
each
other.
What
the
format
of
messages
are
so
on
and
so
forth,
so
every
node
has
has
a
unique
key
that
identifies
themselves
on
the
network
now.
A
A
So,
in
general,
in
terms
of
like
routing
on
the
network,
there's
two
types
of
routing
algorithms,
one
is
called
bank
state
routing
another
one
called
this
vector-based
routing.
The
differences
mostly
lies
in
whether
the
the
the
client
or
the
node
stores,
all
all
the
information
about
the
network,
or
only
stores
information
about
its
neighbors.
A
So
so,
essentially
we.
What
we
do
is
that
each
node
kind
of
maintains
its
own
view
of
the
network
and
then
when
the
node,
when,
for
example,
when
new
node
joins
it
receives
that
view
from
from
other
nodes.
And
then
when
some
when
the
topology
of
the
network
changes,
for
example,
when
two
nodes
start
connecting
to
each
other
or
some
node
disconnected
from
the
network.
That
essentially
means
that
a
new
edge
is
added
to
the
graph
or
a
edges
removed
from
the
graph.
And
then
that
is
essentially
broadcasted
to
the
entire
network.
A
B
A
C
C
A
Okay,
I
think
I've
admitted
all
of
them
yeah
yeah,
for
people
who
just
joined.
I'm
sorry,
I
didn't
check
the
then
the
notification
there.
Okay,
so
let's
continue
so
I
guess
I
was
talking
about
how
messages
are
sent
through
the
network.
A
Essentially,
once
we
establish
this
this
entire
process,
every
node
would
have
a
a
view
of
the
network
and
then
it
would
know,
for
example,
if
it
wants
to
send
some
message
to
some
specific
node
in
the
network,
how
it
should
be
sent
essentially,
because
the
network
can
can
grow
very
large.
The
every
node
does
not
necessarily
have
direct
connection
to
every
other
node.
A
So
now,
let's
talk
about
some
of
the
challenges
and
the
future
work
that
we
will
be
doing
in
terms
of
the
peer-to-peer
network.
So,
first
of
all,
we
want
to
make
sure
that
the
spirit
of
gear
network
that
we
build
is
is
safe
and
is
robust.
A
It
means
that
we
need
to
prevent
mauritius
attackers
from
finding
ways
to
cause
other
network
other
nodes
in
the
network
to
malfunction.
This
means
that
then
the
attackers
would
not
be
able
to
create
some
kind
of
attack
such
that
the
node
would
crash
because,
for
example,
they
they
run
out
of
memory,
because
the
attackers
send
them
some,
some
very
large
message
or
the
attacker
somehow
tries
to
spread
the
network
into
half
such
that
the
the
two
halves
cannot
communicate
with
each
other.
A
For
some
reason,
and
then,
of
course,
we
want
the
network
to
be
scalable
as
well.
That
means
what
we
have
today,
which
is
maintaining
a
view
of
the
entire
network.
It
doesn't
actually
scale
very
well
when
there's
a
very
large
network,
let's
say:
there's
a
million
nodes
in
the
network,
then
maintaining
an
entire
view
of
the
network
becomes
less
feasible.
A
So
one
of
one
of
the
directions
we're
working
towards
is
to
design
new
ways
to
for
nodes,
to
maintain
kind
of
local
view
or
some
information
locally
about
the
network
and
then
route
messages
based
on
that
and
then
yeah.
That
kind
of
is
an
ongoing
work
also
in
terms
of
performance.
A
The
current,
the
current
routing
algorithm,
doesn't
really
take
latency
into
into
conservation.
It
essentially
routes
based
on
the
shortest
path
in
terms
of
a
number
of
like
hops.
It
needs
to
take,
but
it
doesn't
actually
distinguish
those
different
parts
in
terms
of
the
latency.
That's
that's
incurred
by
sending
messages
through
that
route,
so
another
another
thing
that
we
can
so
today,
the
net
every
node
has
kind
of
a
fixed
number
of
connections
to
other
nodes,
and
that
number
is
actually
quite
small.
A
So
we
are
also
thinking
about
being
optimized
doing
some
optimization
there
to
enable
more
connections,
more
direct
connections
to
to
reduce
latency
yeah.
So
that's
pretty
much
every
single
network.
So
let's
move
on
to
chain
so
yeah
for
change,
I'm
mostly
just
going
to
give
a
very
brief
overview
of
consensus
and
sharding
those.
So
so
each
of
those
topics
can
require
like
an
entire
presentation
now
and
so
on.
A
So
I
will
not
delve
too
much
into
the
details
here
and
I
will
just
try
to
give
like
a
a
very
high
level
overview
of
what
we
need
to
do
and
and
how,
how
it
kind
of
works
so
yeah
the
consensus
is
called
doomsdog
for
people
who
are
familiar
with
brandon
sanderson's
work
fiction.
Skyward
doomsdlog
is
this
creature?
A
Well,
this
is
actually
a
picture
here
that
is
well
without
giving
any
spoilers.
It
is
very
fast.
So
that's
why
we
picked
the
the
name.
Oh
that's,
why
alex
picked
the
name
so
dumaslike
essentially,
is
this
block
production
and
the
finality
gadget
and
without
describing
in
detail
how
it
works?
We
can
talk
about
some
kind
of
the
property
that
it
has
essentially
blocks
require
two
servers
of
approvals
from
other
block
producers
to
be
produced
and
then
yeah.
A
If
there
are
essentially
three
consecutive
blocks
with
three
consecutive
heights
building
on
top
of
each
other,
then
that
will
finalize
the
first
block
and
also
final
brush
blocks
cannot
be
reverted
unless
more
than
one
third
of
the
state
clues.
So
that
is
kind
of
the
euro
bft
stuff,
okay,
so
yeah.
So
similarly,
the
sharding
design
is
called
nightshade
and
yeah.
A
Nightshade
is
the
the
main
character
in
skyward
there's
some
very
interesting
interaction
between
nightshade
and
the
doom
slug
in
the
in
the
book,
so
yeah
for
people
who
are
interested
and
read
the
book
skyward.
So
the
the
kind
of
one
interesting
design
choice
that
we
made
in
knife
shade.
That's
somewhat
different
from
some
of
the
other
blockchains,
including
the
original
ethereum
2.0
design,
is
that
we
we
only
maintain
essentially
one
chain
and
for
all
the
shards.
A
Essentially
they
only
have
sharp
blocks
and
the
blocks
are
kind
of
sharp
router,
which
we
call
chunks
are
actually
contained
in
the
blocks
on
the
on
the
main
chain.
So
this
kind
of
simplifies
things
a
lot,
meaning
that
we
don't
have
to
maintain
separate,
searching
and
have
to
think
about.
You
know
when
there
are
forks
on
the
short
chain.
How
do
we
deal
with
crosstalk
transaction
because
you
can
have
transaction
from
one
one
fork
of
one
char
to
another
fork
of
another
chart?
A
And
then,
when
that
kind
of
changes,
it
leads
to
a
bunch
of
problems,
including
like
atmospheric
failure
and
things
like
this.
So
so,
essentially,
we
we
simplify
these
things
a
lot
by
only
maintaining
one
chain,
and
then
the
blocks
on
the
chain
would
include
chunks
from
different
shards
and
then
chunks
are
distributed
to
broad
producers
through
erasure
coding
well,
without
actually
explaining
too
much
in
detail
how
what
that
is.
A
It
essentially
means
that
it
allows
it
allows
us
to
have
to
cons
reconstruct
the
chunk
with
only
a
fraction
of
the
broad
producers.
So
we
choose
the
number.
A
So
I
think
in
the
paper
it
chooses
one
one
six
and
as
here
in
the
actual
implementation,
we'll
use
one
third,
so
essentially
one
third
of
the
block
producer
or
anyone
sort
of
the
block
producer
can
reconstruct
the
any
given
chunk
by
having
the
the
erasure
coded
part
and
then
block
producers
would
send
approvals
once
they
receive
and
process
block
to
attach
to
the
validity
of
the
block
and
also
the
data
ability
of
the
of
the
block,
meaning
that
they
have
received
their
their
parts
for
the
for
the
chunks
included
in
the
block.
A
So
that's
kind
of
a
very
short
overview
of
how
chain
works.
So
some
of
the
the
future
works
are
those
things
that
we're
we're
actually
working
on,
including
moving
from
where
stars
or
modbus
charts.
So
when
we
first
launched
main
that
we
didn't,
you
know
at
the
time,
there's
no
essentially
no
usage,
and
it
doesn't
make
a
lot
of
sense
to
have
multiple
shards.
A
A
So
how
this
is
going
to
be
done.
Is
that
essentially,
there's
going
to
take
we're
going
to
take
like
a
multi-staged
approach
where,
in
the
first
stage
we
upgrade
to
a
simple
nice
shade,
meaning
that
there
will
be
like
eight
charts
and
there
will
be
separate
trunk
producers,
but
all
the
block
producers
will
track
every
shard
and
then
later
on,
once
challenges
and
dynamic
recharging
are
implemented,
will
actually
upgrade
to
to
the
full
knight
shape.
That's
specked
out
in
the
in
the
white
paper.
A
The
problem
is
that
challenges,
and
also
dynamic,
resulting
is
on
their
own,
requires
a
lot
of
effort
to
to
implement
yeah.
I
will
not
actually
talk
in
details
about
you
know
what
those
things
are
and
and
why
it's
hard
to
build
them,
because
that
that
don't
honestly
take
a
very
long
time
to
explain
so.
Another
thing
that
we
are
working
on
is
to
to
increase
number
of
validators
on
the
network.
A
A
There
are
multiple
things:
I'm
working
on,
for
example,
we're
working
on
once
we
transition
to
synchronization
there
will
be
a
lot
more
validators
who
are
also
trunk
producers
and,
at
the
same
time,
we're
also
thinking
about
ways
to
increase
the
number
of
block
producers
on
mainland,
so
yeah,
that's
kind
of
the
stuff
that
we're
working
on.
A
Okay,
let's
move
on
to
runtime.
So,
as
I
talked
about
before
the
runtime
is
an
execution
engine,
that's
responsible
for
state
transitions,
so
very,
very
naive
or,
like
very
simplistic
view
of
runtime.
A
Essentially,
you
can
single
this
black
box
that
you
know
you
feed
it
with
the
the
current
state
and
then
you
you
give
it
the
the
current
block,
and
then
it
will
return
you,
the
state,
after
applying
the
applying
the
block
so
yeah,
that's
kind
of
a
simplistic
view
of
how
it
works,
and
actually
underneath
or
rather
inside,
that
black
box
there's
a
lot
of
stuff
going
on
to
actually
make
it
work.
A
So
just
let's
just
kind
of
briefly
work.
Through
an
example.
Let's
say
there
is
transaction
from
alice
to
bob
meaning
that
is
the
sender.
Bob
is
the
receiver.
So
how
it
works.
Is
that
the
transaction?
A
Well,
no
matter
what
kind
of
transaction
it
is,
whether
it's
transfer
function,
call
whatever
will
be
first
sent
to
you
to
address
chart
to
be
to
be
processed,
it
will
charge
the
transaction
fees
from
the
from
alex
account,
that's
necessary
to
convert
it
into
a
receipt
and
and
after
that,
the
receipt
is
sent
to
bobster
to
be
executed
further
and
then
that
receipt
of
course
can
create
other
receipts
that
go
to
maybe
some
other
chart
so
and
that
process
just
goes
on.
A
So,
as
you
can
see
here,
the
execution
is
not
synchronous
like
a
synchronous
execution,
meaning
that
in
each
serum
a
transaction
would
just
be
executing
in
one
block
and
it
would
just
be
down
here.
A
transaction
execution
can
actually
take
multiple
hubs.
A
So
overall,
like
the
developers
would,
you
know,
write
some
contracts
and
then
in
in
a
language
that
we
support,
and
then
they
would
compile
the
contracts
to
to
have
assembly
binaries
in
whichever
comp
in
the
compiler
of
whichever
language,
they're,
writing
and
then
they
will
send
essentially
a
deploy,
a
contract
transaction
to
deploy
the
contract
to
some
account
and
then
so
we're
actually
so
yeah.
A
It
will
be
the
case
that
the
that
the
contract
is
compiled
when
when
it
is
deployed
to
to
some
vm
module
and
then
when
the
function
call
is
invoked
a
transaction
that
essentially
means
that
they
send
a
transaction
to
to
the
to
the
network
to
to
call
some
method
on
the
on
the
contract,
and
then
the
runtime
would
would
take
that
in
and
it
would
start
the
vm
to
actually
round
the
round
web
assembly
code
yeah.
That's
a
very
brief
overview
of
how
it
works
yeah.
A
And
then,
when
that
happens,
it
just
becomes
a
completely
mess
and
the
state
would
just
be
very
messed
up.
And
then
we
have
to
it's
very
hard
for
that
to
recover,
because
essentially
then
we
need
to
do
some
kind
of
hard
work
to
change
the
state
which
is
not
easy
to
do
and-
and
things
like
this
actually
do
happen
right.
So
for
people
who
are
following
more
closely
with
the
development
cycle,
we
recently
found
some
parking
in
washington,
for
example,
that
would
cause
this
kind
of
behavior,
so
yeah.
A
It's
very
important
that
we
work
on
this.
Improving
the
stability
and
robustness
of
runtime
and
we're
also
some
other
things
that
that
will
be
working
on,
including,
like
figuring
out,
better
ways
to
to
charge
for
transactions.
This
means
that
want
to
estimate
the
better
the
the
cost
of
different
operations
and
also
optimize
some
of
the
the
operations,
including
like
host
functions
like
storage,
read
and
storage
right,
and
also
we're
working
on
better
ways
to
price
the
the
gas
price
of
the
network
and
addressing
some
developer
concerns
around
gas
and
storage.
A
I
mean
today
it
is
all
confusing,
because
gas
is
not
something
that
people
just
intuitively
understand
and
also
storage
storage
cost
is
high
and
also
today,
developers
have
to
use
some
storage
management
standard
to
manage
their
storage
once
when
there
is
some
measuring
their
contract
that
allows
users
to
increase
the
contract
storage.
So
yeah
there's
like
a
lot
of
work.
A
That
needs
to
be
done
to
improve
the
developer
experience
here,
okay,
so,
finally,
I
just
want
to
mention
briefly
about
node
experience,
because
this
is
essentially
a
kind
of
horizontal
thing,
meaning
that
it
crosses
cross
paths
with
all
the
team.
Other
components
that
I
mentioned
before
essentially
here
we
want
to
make
the
experience
of
running
near
those
better.
So
some
of
the
kind
of
feature
requests
and
the
performance
improvements
are
working
on,
including
things
like
you
know.
A
For
example,
validator
wants
to
have
a
longer
time
between
when
the
protocol
upgrades
is
voted
and
when
the
protocol
actually
switches
to
the
new
version
and
also
things
like
separation
of
different
types
of
nodes.
Today
they
all
use
the
same
binary.
A
They
all
read
essentially
the
same
kind
of
data
to
the
same
database,
but
that's
actually
essentially
a
waste
of
variety,
their
storage
in,
in
a
lot
of
cases
that
they
don't
actually
they're,
storing
some
kind
of
data
that
they
don't
actually
need
to
store
and
also
we
will
be
working
on
further
optimizing,
cpu
and
memory
consumption
of
near
nodes.
I
think
today
the
cpu
usage
is
mostly
good.
A
I
think
some
still
some
issue
with
memory
consumption
and
also
we'll
be
working
on
testing
of
the
stability
of
the
of
the
near
nose
through
more
integration
tests
and
larger
scale
tests.
So
yeah.
I
think
that's
all
what
I
wanted
to
present.
I
think
yeah
also
it's
almost
exactly
30
minutes
yeah.
I
think
I
think
we
still
have
a
time
left
to
answer
some
questions
right,
cindy.
A
Okay:
okay,
yeah
thanks
yeah
any
any
questions
about
the
yeah
yeah
austin.
D
Yeah,
I
just
had
one
question
about
the
you
mentioned
in
the
presentation
and
then
also
in
that
government
or
the
governance
post,
that
you
wanted
to
increase
the
amount
of
validators.
Is
that
a
protocol
or
technical
change,
or
is
that
just
onboarding
more
validators
to
to
get
them
on
the
network?.
A
Yeah,
so
it's
kind
of
both,
but
today
we're
both
enact
on
the
protocol
side
that
there
is
a
higher
requirement,
the
hard
description
that
there
can
be
at
most
a
hundred
validators
in
the
network
and
also
because
of
the
validator
how
the
variator
selection
algorithm
works.
It's
actually
very
difficult
to
reach
that
maximum
amount,
because
the
essentially
the
uneven
distribution
of
stake
would
lead
to
some
violet
are
not
being
able
to
get
a
seat
and,
as
a
result,
we
kind
of
plateaued
at
around
60
validators.
D
B
Oh
actually,
I
was
about
to
ask
whether
we
can
post
it
on
youtube.
We
can
share
with
you
would
love
to
have
such
material,
which
goes
on
with
over
over
you
and
hello,
and
I
find
they
talk
pretty
well
defined
in
in
this
specific
area
of
like
going
through
everything
in
just
half
an
hour.