►
From YouTube: NEAR Core | Episode 01: Runtime Overview
Description
An in-depth code overview of NEAR Runtime.
Follow the latest from NEAR Protocol on,
Website: https://nearprotocol.com/
Discord: https://near.ai/discord
Medium: https://near.ai/medium
Twitter: https://near.ai/twitter
GitHub: https://near.ai/github
#NEARCore #Blockchain #FutureIsNEAR
A
Thanks
for
joining
this
is
the
series
on
the
internals
of
the
near
protocol
and
we're
going
to
be
focused
mostly
on
the
runtime.
This
time
and
runtime
in
your
protocol
is
quite
complex
and
to
understand
why
certain
things
are
done
this
way
in
the
runtime.
We
need
to
understand
the
motivation
about
it.
A
Motivation
behind
the
near
runtime
is
that
we
want
to
have
a
very
good
developer
experience
for
people
writing
contracts
in
near
run
time,
and
what
it
means
is
that
we
don't
want
them
to
think
that
they're
running
on
the
blockchain
too
much
or
that
our
blockchain
is
sharded.
We
don't
want
to
expose
the
internals
of
our
of
our
blockchain.
A
What
it
means
for
us,
as
the
developers
of
the
blockchain,
is
that
we
want
to
hide
the
complexity
that
we
would
otherwise
expose
to
developers
inside
the
blockchain
protocol
and
the
place
that
it
hides
all.
This
complexity
is
called
the
runtime
or
more
specifically,
transaction
runtime,
so
transaction
runtime
is
this
black
box
that
have
has
lots
of
logic
about
how
to
process
transactions
and
how
to
execute
the
contracts
in
such
a
way
that
it
looks
very
friendly
to
the
contract
developers.
A
This
is
going
to
be
a
series
of
videos
about
the
transaction
runtime,
because
this
topic
is
very
complex.
It's
going
to
take
quite
some
time
to
explore
it.
The
video
today
is
going
to
be
mostly
about
the
overview
of
the
transaction,
runtime
and
yeah.
So
we're
not
gonna
dive
into
the
details
of
exactly
how
web
assembly
is
executed
or.
A
Here
we
go
so
our
near
blockchain
is
started,
which
means
we
have
a
bunch
of
shards
executing
staff
in
parallel
in
the
near
blockchain.
Both
execution
and
state
is
sharded,
some
blockchains.
They
don't
charge
state,
but
in
here,
which
are
both
execution
and
state
which
allows
to
not
have
huge
disks
for
the
nodes
if
they
choose
to
follow.
Only
one
chart
on
your
blockchain
each
of
the
shards
has
its
own
runtime.
A
That
means
that
it's
gonna,
this
abstraction,
is
gonna
spill
over
into
the
contract
execution.
So
the
contracts
will
be
doing
a
synchronous
contract
contracts
in
some
cases,
as
opposed
to
synchronous
controls
that
are
typical
to
ethereum
blockchain,
because
ethereum
blockchain
is
not
sharded,
but
we're
not
going
to
dive
into
the
details
of
why
what
is
asynchronous
contract
calls
is
from
the
perspective
of
the
contract
developer.
A
What
you
need
to
take
from
here
is
that
there
are
multiple
runtimes
running
on
your
blockchain
one
runtime
per
shard,
and
this
runtimes
execute
in
parallel,
and
you
can
think
of
each
runtime
as
a
state
machine,
and
now
I'm
gonna
show
you
more
or
less.
What
is
the
input
and
output
of
the
state
machine.
A
B
A
A
So
this
is
a
bit
janky
here,
so
don't
put
too
much
attention
to
it.
What
we
actually
should
be
should
have
had
here
is,
we
shouldn't
have
had
struct
runtime,
because
you
know
it's
stateless,
there's
nothing
inside
and
we
should
have
removed
all
this
reference
cell
from
this
methods,
because
self
is
not
actually
used.
Here
I
mean
there
is
no
state
itself,
so
this
is
just
fyi.
This
is
the
code
that
needs
to
be
refactored,
but
things
that
you're
looking
at
the
runtime
are
basically
two
functions,
apply
and
apply
genesis.
A
Can
you
see
them
in
this
pop-up
window
that
I'm
just
presenting
to
you
cool
so
apply
function
here?
It
is
and
navigate
it
to
it.
That's
basically
where
you're
gonna
get
like
60
of
your
knowledge
about
the
runtime.
Just
by
looking
at
the
signature
of
this
function,
like
you
can
meditate
on
it,
take
a
nap
and
think
about
it
like
tomorrow.
What
the
signature
of
this
function
is,
but
this
is
where,
like
60
of
the
knowledge
of
what
runtime
is
doing
is
actually
concentrated
in
the
signature,
the
signature
represents
the
state
machine
of
the
runtime.
A
A
So,
as
I
said,
runtime
is
a
state
machine
and
one
step
of
the
state
machine
of
the
runtime
is
execution
of
the
one
block
or
because
our
blockchain
is
sharded
execution
upon
chunk.
So,
if
you
don't
know,
chunk
is
basically
a
struct
that
contains
the
transactions
and
the
state
on
a
specific
chart
and
chunks
are
aggregated
together
into
the
block
across
all
shards.
B
A
Time
executes
one
chunk
on
that
chart
and
the
two
major
two
main
inputs
into
the
state
machine
are
the
receipts
and
transactions
and
what
it
spits
out
in
the
apply
result.
If
you
go,
there
are
more
receipts
and
some
other
data
that
I
will
also
go
over.
Basically
more
receipts
and
some
information
of
what
is
the
execution
result
of
this
thing.
A
You
see
here
also
there's
some.
There
are
some
fields
about
the
state,
we're
gonna
touch
it
later
and
some
stats
some
proofs.
This
is
all
useful,
but
not
as
critical
for
the
runtime
execution.
Most
of
the
important
stuff
is
in
outgoing
receipts
and
outcomes.
Right
now,
that's
what
you
need
to
focus
on.
A
A
With
is
basically
a
message:
that's
been
sent
between
shards
right.
We
don't
want
charts
to
work
in
a
completely
insulation,
because
if
they
were
working
in
complete
isolation
that
there
wouldn't
be
any
use
of
having
a
shared
blockchain,
that
would
be
just
like
a
bunch
of
separate
blockchains,
so
blockchain
the
shards
need
to
communicate
with
each
other
and
the
way
they
communicate
with
each
other
is
using
the
receipts.
A
A
A
Some
of
them
they
circle
back
and
being
reprocessed
by
the
same
chart
on
the
next
step,
and
that's
essentially
the
high
level
step
of
the
of
the
state
machine
of
the
runtime.
It
takes
transactions
and
the
receipts
and
spits
out
the
receipts.
So
the
question
is
where
transactions
are
coming
from.
Transactions
are
coming
from
the
rpc,
so
that's
our
pc
server
of
the
of
the
blockchain
node
accepting
the
transactions
from
its
users.
Well,
more
specifically.
A
First
it's
rpc!
Then
it
gets
into
the
transaction
pool,
but
you
got
the
idea.
Basically,
the
users
provide
the
transactions
once
they
go
for
the
transaction
pool
put
into
the
chunk
they
end
up
with
with
the
runtime
and
runtime,
consumes
transaction
receipts
and
spits
out
more
of
the
receipts
all
right.
Now,
let's
go
back
to
the
code
and
look
at
the
at
the
body
of
the
receipts
and
transactions.
A
Second,
so
here,
as
I
said,
this
is
the
very
most
of
your
focus
should
be
if
you're
trying
to
understand
the
runtime.
The
apply
method
of
the
runtime
structure
and
two
important
fields
here
are
incoming
receipts
and
transactions.
So
incoming
receipts
are
what
I
just
said.
Those
are
the
receipts
incoming
from
the
other
shards.
Some
other
chart
wants
us
to
process
this
on
some
shard.
You
know
a
wants
to
process
on
shard
b,
that's
how
they
relieve
the
receipt
and
that's
where
it
gets
into
the
runtime
and
here's
the
signed
transaction.
A
So,
let's
look
at
the
signed
transactions
signed
transaction
has,
as
I
said,
the
signature.
The
hash
the
hash
is
computed
on
the
fly
is
not
actually
serialized
and
passed
through
the
network.
It's
it's
computed
upon
the
decentralization
of
the
transaction,
and
then
there
is
the
transaction
by
itself.
A
A
Sorry
the
receipt
receipt
here,
if
you
go
all
the
way
deep
into
the
action
receipt
and
I'm
going
to
talk
later,
what
action
receipt
versus
data.
I
said
you
also
see
that
there
is
a
bunch
of
actions
in
there,
so
this
is
basically
the
body
of
the
body
of
the
receipt,
the
the
list
of
the
actions
and
the
body
of
the
transaction.
Also
the
list
of
the
actions.
A
All
other
information
is
kind
of
auxiliary
the
signer
id
again
output
data
receivers,
we're
going
to
go
through
all
that,
but
most
of
the
stuff
is
inside
the
actions
both
for
the
receipt
and
the
transaction.
And
what
is
the
action?
It's
actually
what
we
want
to
do
we
want
to
do.
We
want
to
create
an
account
with
this
transaction
on
this
receipt.
Do
we
want
to
make
a
function?
Call
transfer
some
some
newer
tokens
stake.
We
have
proof
of
stake,
blockchain
delete
a
key,
add
a
key
and
delete
an
account.
A
So
these
are
the
actual
things
that
we're
gonna
execute
in
our
blockchain
they're
stored
inside
the
action
and
the
reason
why
we
have
a
list
of
actions
both
in
the
transaction
and
the
receipt
is
because,
unlike
many
other
blockchains,
our
transactions
are
batched,
meaning,
if
you
want
to
do
multiple
things
in
here,
you
don't
need
to
execute
multiple
transactions.
If
I
want
to
create
an
account,
deploy
a
contract,
add
access
key
call,
some
function.
A
A
The
execution
of
the
entire
city
is
atonic,
so
if
one
of
the
action
fails,
then
the
whole
receipt
is
unrolled
or
rollback.
Sorry-
and
this
is
useful
when
you
want
to
issue
a
very
typical
batch
transaction,
which
is
create
account,
deploy
a
contract
in
call
initialize
method
on
this
contract
add
an
access
key.
A
This
is
like
you
know,
four,
very
typical
actions
that
you
frequently
want
to
bundle
together,
and
what
we
don't
want
to
happen
is
that
we,
we
created
an
account
deployed
a
contract,
but
our
initial
initialization
function
failed,
and
so
we
have
this
contract
hanging
in
the
air
without
even
access
key
being
added
to
it.
So
no
one
can
do
anything
with
it
and
and
to
avoid
this,
the
entire
set
of
actions
is
getting
rolled
back,
so
the
entire
receipt
is
atomic.
C
A
It's
important
for
them
to
be
performed
in
the
same
order,
and
there
are
also
even
some
crazy
things
that
you
can
do
with
these
actions.
For
instance,
you
can
create
an
account,
deploy
a
contract,
call
the
kind
of
methods
on
it,
delete
this
account
because
you
don't
need
it
anymore.
Maybe
I
don't
know
and
then
create
another
account.
No,
I
mean
you
cannot
create
another
account
currently,
but
you
get
the
idea.
You
can
do
this
kind
of
crazy
stuff
right
now
and
that's
that's
that's
the
point.
A
There
are
some
restricted
sequences
that
you
cannot
do
with
this
for
certain
reasons,
because
we
either
didn't
implement
it
yet
because
it
would
be
hard
to
implement,
for
instance,
creating
two
different
two
different
accounts
in
the
same
receipt.
You
cannot
do
it
right
now.
You
can
only
create
one
account.
A
You
cannot
do
multiple
times
create
delete
back
and
forth,
because
that
would
make
us
grindable,
because
deletion
of
the
contract
is
very
expensive.
Just
like
on
ethereum
ethereum
also
has
issue
with
this,
and
it's
actually
one
of
the
economic
vulnerabilities
of
ethereum
deleting
a
very
large
contract
with
a
very
large
state.
A
E
A
So
destination
and
sender
are
here
so
again.
I
said
that
the
auxiliary
information
of
the
receipt
and
transactions
differs
slightly
right.
So
in
case
of
the
receipt
you
have
a
fixed
receiver
id.
You
see,
it
even
leaves
several
level
levels
above
the
the
actions
right.
It
doesn't
leave
even
a
receipt,
a
knob
and
doesn't
leave
an
action
receipt.
It
leaves
all
the
way
up.
Here
is
the
receiver
id
who
is
receiving
this
receipt
and
receiver
id
also
identifies
what
would
be
the
name
of
the
con
on
the
of
the
account
that
you're
creating.
A
So
when
you're
creating
an
account,
your
action
is
going
to
be
create
account
and
your
receiver
id
is
going
to
determine
what
is
the
name
of
the
account
that
you're
creating
that's.
Why,
when
you
go
all
the
way
into
the
actions,
and
you
look
at
what
is
the
create
account
action?
There's
nothing
in
here
like
it's
empty,
it
doesn't
say
what
account
you
want
to
create,
because
the
account
name
has
been
determined
from
the
receiver
id.
C
A
Yeah,
so
the
reason
why
the
classic
compatibility
breaks
is
because
the
the
classic
ethereum
composibility
allows
you
to
do
atomic
multiple
on
multiple
contracts.
At
the
same
time,
the
thing
about
near
is
that
these
contracts
can
live
on
different
shards,
and
so
you
cannot
create
atomic
operation,
yet
not
gonna
spoil
anything
not
not
yet,
maybe
in
the
future.
Who
knows
but
right
now
you
cannot
have
an
atomic
operation
that
spans
two
contracts
that
live
on
different
shares
because
they
don't
live
on
different
charts.
A
A
Technically,
we
could
have
actually
allowed
it,
but
the
way
we
designed
the
runtime-
and
this
is
like
a
really
great
segue
question-
to
how
the
reasons
why
our
runtime
is
designed
like
that
is,
we
didn't
want
to
create
any
incentives
for
the
people
to
try
to
collocate
their
contracts
on
the
same
chart
with
someone
else,
because
when
you
have
these
incentives,
it's
going
to
create
very
perverse
system.
People
will
try
to
collocate
with
exchanges.
A
Right,
okay
present
in
the
correct
window.
This
time
is
that,
for
instance,
if
I'm
on
this
chart
a
right
and
I'm
calling
from
contract
lsm
contract
contract
bob
if
contract
bob
leaves
let's
say
actually
in
here.
What
is
going
to
happen
is
that
alice
contract
will
emit
the
receipt
that
was
going
to
fly
to
the
chart
with
bob
contract
and
that's
where
it's
going
to
be
executed.
So
it's
going
to
be
executed
one
step
later
right.
A
We
still
have
blocks
now
blocks
chains,
so
in
in
block
x,
alice
is
going
to
be
executed
in
block
x,
plus
one
bob
is
going
to
be
executed
and
the
way
it's
going
to
be
executed
with
bob
contract
is
going
to
receive
the
receipt.
That
says,
please
call
bob
if
bob
was
leaving
actually
not
on
this
shark,
but
on
the
same
chart
with
alice.
A
I
don't
know,
cut
the
latency
or
somehow
create
some
kind
of
atomic
execution,
or
anything
like
that,
and
this
is
kind
of
important
for
us,
because
we
don't
want
to
think
about
this
additional
adversarial
vector
where
people
are
trying
to
jam
things
on
the
same
chart.
This
is
like
this
makes.
This
creates
a
new
level
of
complexity.
If
you
try
to
think
of
right
now,
we
have
to
protect
from
people
trying
to
put
things
on
the
same
chart.
A
You
have
a
new
game,
theoretic
model
in
there
you
need,
like
you,
have
different
attack
vectors
that
you
didn't
think
before.
So
we
simplified
this
thing
and
said:
okay,
there
is
no
reason
for
people
to
collocate
on
the
same
chart,
and
also
we
were
thinking
and
we're
still
thinking
about
dynamic,
resharding
right.
A
We're
thinking
that
our
shards
are
going
to
be
dynamically
repartitioned
in
the
future,
so
if
one
chart
accidentally
bloats,
we
need
to
cut
it
into
pieces,
you
know
and
and
repartition
it,
and
if
people
try
to
game
this
system,
try
to
work
against
the
dynamic
or
sharing
when
they've
been
you
know,
put
on
a
separate
chart
and
then
they
try
to
go
back
to
the
original
chart
again,
then
it's
going
to
be
just
a
nasty
game
with
our
protocol.
Again,
we
don't
want
to
think
about
it.
So
this
this
whole.
A
A
All
of
the
actors
are
now
blockchain
about
validator
nodes
that
you
know
accept
the
chunks
again.
The
chunks
is
the
piece
of
the
block
specific
to
the
shard
and
they
are
emitting
those
receipts
like
changing
them
with
each
other
in
certain
way
that
allows
to
ensure
that
those
receipts
are
actually
received.
But
there
is
no
like
additional
actor
in
the
play.
Who
is
you
know,
takes
the
receipts
and
puts
it
into
the
other
chart
there
is.
A
There
is
some
mechanism
of
broadcasting
that
allows
to
do
it
pretty
securely
with
certain
guarantees
yeah,
but
that's
like
it's
a
different
topic
which
goes
into
the
direction
of
our
consensus
and
how
blocks
are
produced
and
how
synchronization,
between
the
between
different
charts
is
happening,
all
right.
So
going
back
to
the
runtime.
A
A
So
you
see
we
trading
all
the
transactions
in
this.
In
this
method
we
take
these
transactions
and
what
we're
doing
we're
producing
the
receipts
out
of
them.
So
you
see,
there's
a
method
called
process
transactions,
but
transaction,
but
what
it
spits
out
is
without
a
receipt.
So
this
method
will
basically
does
a
text.
Transaction
gives
a
receipt
exactly
the
same
set
of
actions
stripped
out
of
the
signature,
because
the
receipt
is
basically
a
trusted
transaction
right.
A
We,
when
we
exchange
the
receipts
between
the
shards.
We
know
that
we
can
trust
the
cersei's,
because
originally
this
receipts
were
transactions,
so
we
already
verified
the
signatures
and
we
also
verified
that
the
amount
of
gas
that
was
attached
to
this
receipt
is
also
something
that
you
know
the
the
the
transaction
signer
can
pay,
because
we
actually
have
deducted
it
from
the
account.
A
So
that's
a
very
short
cycle
of
life
cycle
of
the
transaction
inside
the
runtime.
It
becomes
a
receipt
quite
quickly
and
it
can
fail
to
become
a
receipt
if,
for
instance,
the
person
who
signed
the
transaction,
the
account
did
not
exist
or
didn't
have
enough
assets
actually,
when,
if
the
account
did
not
exist,
it
might
actually
be
filtered
out
even
before
it
enters
the
runtime.
A
A
That's
where
your
contract
lives
or,
like
your
account
lives
when
there's
the
transaction
is
signed,
alice
needs
to
specify
how
much
gas
needs
to
be
attached
for
all
kind
of
operations
in
this
transaction
right,
it's
very
similar
to
what
a
serum
has,
but
in
assume
you
have
max
gas
limit,
so
you're
kind
of
specifying
the
maximum
amount
of
gas
that
you're
going
to
use
in
our
case,
you're.
Just
saying
that
it's
not
the
max
gas
limit,
it's
actually
what
I
can
attach
to
my
transaction.
A
A
A
C
C
A
So
what
the
previous
scenario
that
we
examined
was
alice
has
a
contract
on
chart
a
and
alice's
contract
wants
to
call
bob's
contract
on
chart
on
chart
b,
assume
that
alice
doesn't
have
a
contract
and
alice
just
wants
to
call
contract
bob
here,
for
that
alice
needs
to
have
an
account
because
you
need
to
in
order
to
to
execute
anything
on
the
blockchain.
You
need
to
have
an
account,
so
suppose.
A
A
A
A
Nsb
and
it's
flying
to
bob's,
to
to
sharp
b
with
bob's
contract
and
and
shard
b,
doesn't
need
to
verify
that
yes,
alex
indeed
has
this
amount
of
tokens
because
receipt
says
so
receipt
says
that
don't
worry.
We
have
already
deducted
all
this
gas
from
somewhere,
and
this
is
the
amount
of
gas
that
you
can
use
for
your
own
execution
and
when
bob's,
when
bob's
contract
is
done
executing
it,
it's
gonna
send
the
refund
back
to
alice's
to
the
lss
chart.
It
happens
automatically.
The
user
doesn't
need
to
do
it.
A
So
receipts
receipts
are
produced,
as
receipts
are
artifacts
of
executing
transactions
right,
just
like
the
state,
for
instance,
in
ethereum
like
when
you
execute
your
own
transaction,
the
input,
the
the
batch
of
transaction,
the
artifact
is
the
new
state
route
or
the
new
state.
Try
right.
One
of
the
artifacts
in
our
chunk
execution
is
a
batch
of
receipts.
A
Not
only
we
give
you
new
state
on
the
chart,
but
we
also
say
here
is
the
set
of
the
receipts
that
you
need
to
execute
on
other
shards
and
just
like
with
the
state
route.
You
trust
it
because
validator
signed
this
block
this
chunk
layer
set.
This
is
the
chunk
executed.
This
is
a
new
state
route.
This
is
the
new
set
of
the
receipts
that
you
need
to
execute
on
other
shards,
so
it
has
the
same
kind
of
level
of
security
as
the
new
state
route
and
therefore
the
receipts.
A
As
I
said
at
the
beginning,
unlike
transactions,
they
don't
have
signature
they're
stripped
of
the
signature.
You
just
trust
them,
because
the
only
thing
that
you
can
produce
the
receipt
is
the
validator.
When
they
process
an
unlock
user
cannot
submit
receipt
from
the
outside
user
can
only
submit
transaction.
A
So
you
trust
if
the
receipt
says
certain
gas
was
attached.
You
trusted,
because
some
validator,
you
know
computed
it
and
deducted
this
amount
of
gas
from
someone's
balance.
So
this
money
are
coming
from
somewhere,
okay,
cool
all
right,
so
this
whole
dynamic.
So
like
how
refunds
work
and
like
the
receipts,
it's
quite
complex
and
we
can
like
go
from
multiple
scenarios.
A
A
So
if
we
were
to
write
a
spec
of
the
runtime
which
we're
trying
to
do
for
quite
a
long
time
right
now,
you
would
actually
go
over
our
code
and
reverse
engineer.
What
is
the
spec
like?
What
are
the
rules
like
how?
What
are
the
rules
like?
Do
you
execute
transaction
first
before
the
receipt,
so
you
first
execute
the
receipts
that
are
coming
from
the
other
chart.
A
A
A
A
A
Convert
them
to
the
receipts.
Using
the
following
algorithm
then
take
something
that
is
called
local
receipts
that
I
haven't
explained
yet
and
do
something
with
them.
Then
processing
common
receipts
then
check
the
balance.
At
the
end,
the
the
the
order
of
operation
is
extremely
important
here
and
if
you
accidentally
working
with
the
runtime
code
and
you
switch
something
that
is
actually
correspond
to
the
spec
rather
than
implementation,
then
you
might
actually
break
the
protocol.
For
instance,
I
can
switch
this
to
this
lines
together
and
nothing
actually
is
going
to
happen.
A
It's
quite
obvious
in
this
initial
initialization
functions.
They
don't
do
anything
right,
it's
not
a
spec,
but
if
I,
for
instance,
replace
the
signed
transaction
and
with
local
receipts
first,
then
I
might
break
the
spec.
So
this
is
the
big
nuance
of
working
with
the
runtime
code.
Is
that
you
had
you
got
to
write
carefully?
A
Something
can
be
the
specs,
something
can
be
implementation
and
if
you
might
define
it,
you
need
to
know
which
one
is
which
and
the
only
way
to
know
which
one
is,
which
is
to
get
this
kind
of
knowledge
transfer,
that
we
are
doing
right
now
and
and
to
actually
learn
what
is
spec
and
what
is
implementation
all
right.
So,
let's
just
walk
through
the
supply,
apply
a
function
step
by
step
and
and
I'm
gonna
explain
to
you
on
high
level
what
is
happening
here.
A
A
A
I
know
that
all
of
the
errors
that
can
happen
when
runtime
processes,
the
block
or
the
chunk,
are
gonna,
be
in
here
in
this
runtime
error,
so
I'm
gonna
look
into
it
and
I'm
gonna
try
to
find
something
that
gonna
tell
me
that
that
something
is
that
some
error
that
says
that
the
block
wasn't
correctly
composed
and
what
I'm
looking
into
the
storage
here,
I
don't
think
that's
it's
here,
balance
mismatch.
This
is
going
to
explain
you
later
what
it
corresponds
to
a
later
error,
epoch
manager.
This
is
not
it.
A
So
this
is
about
how
we
distribute
the
rewards
between
the
validators
and
receipt
validation,
error,
and
here
you
can
see
certain
things-
is
that
we're
gonna
spit
out
an
error.
If
you
don't
have
the
sign
already
like,
for
instance,
someone
tried
to
create
a
chunk
with
transactions
that
just
don't
have
signer
like
that,
then
we're
gonna
spit
out
there.
So
at
least
partially.
The
answer
to
your
question
is
yes,
we're
gonna
have
runtime
barfing
out
an
error.
E
E
A
A
It
doesn't
return
your
vector
affairs,
it
returns
you
one
error,
so
this
error
that
says
that
signer
id
is
invalid.
It
corresponds
to
the
entire
chunk.
So
it
basically
says
in
the
chunk:
there
is
a
receipt
with
invalid
signer
id.
So
that
means
from
that.
I
deduce
you
know
by
by
reading
this
code
is
that
the
block
is
going
to
be
rejected,
because
otherwise,
why
would
you
return
an
error
like
this
for
the
entire
chunk
yeah?
A
So
what
you
see
here,
something
about
the
state
state
is
probably
going
to
be
a
separate
video,
how
exactly
we
modify
the
state
when
we
process
the
when
we
process
the
blocks,
so
I'm
gonna
skip
it.
Just
ignore
this,
nothing
is
happening
here,
move
along
then
validator
account
updates.
So
what
are
the
validator
accounts?
A
A
So
there
is
something
is
happening
on
each
chunk
in
terms
of
in
terms
of
like
how
we
maintain
the
solidarity
accounts,
and
we
don't
need
to
go
right
now.
Deep
into
this,
it's
going
to
be
a
separate,
probably
video
about
how
we
actually
manage
validator
accounts,
how
we
distribute
the
rewards
on
what
is
the
cadence
there?
What
are
the
rules
of
updating
the
distributing
the
rewards
and
updating
the
validator
accounts?
A
Now,
there's
a
bunch
of
initializations,
let's
not
go
through
them,
let's
actually
go
through
the
through
the
code
here.
So
this
is
something
I
have
explained
to
you
already.
The
first
thing
we
do.
We
take
the
transactions
that
are
meant
to
be
produced
processed
in
this
block
and
we
convert
all
of
them
into
the
receipts.
Each
one
transaction
means
once
receipt,
and
here
you
see
a
very
interesting
thing
happening
here,
so
this
was
actually
added
at
some
point
later.
This
is
not
necessary.
A
This
is
kind
of
an
optimization
of
usability
of
our
time,
depending
on
whether
transaction
is
being
is,
has
the
same
signer
as
the
receiver.
We
do
something
different
in
here,
so
exactly
we
do
different.
We
do
a
small
optimization,
which
says,
if
alice,
for
instance,
calls
let's
say
its
own
contract
living
on
its
own
account
right,
lx
calls
itself,
then
we
don't
need
to
send
produce
the
receipt
that
would
fly
and
and
and
let's
say,
to
a
different
chart
or
be
processed
on
the
next
step.
A
We
tried
to
actually
process
it
right
away
and
that's
what
is
called
the
local
receipt.
Local
receipt
has
received.
It's
been
tried
to
process
right
away,
and
given
this
whole,
you
know
conversation
that
I
gave
you
about
how
we
don't
want
to
incentivize
people
to
collocate
on
the
same
chart.
This
actually
doesn't
create
any
kind
of
perverse
incentives.
A
A
Call
that
calls
itself
that
just
allows
people
to
to
wait
in
most
of
the
cases
fifty
percent
shorter
when
they
do
the
contract
on
the
near
blockchain,
because
most
of
the
contract
calls
your
blockchain
is
just
a
single
contract,
there's
no,
no
crosshard
invocation
and
instead
of
waiting
for
like
two
blocks,
they're
gonna
wait
for
one
block
here
to
be
finalized.
So
it's
just
an
optimization
here.
A
A
Also,
you
can
see
we
keeping
a
count
of
how
much
gas
was
burned,
and
this
is
going
to
be
important
later
and
we
are
like
recording
the
outcomes
so
outcome.
It's
basically
our
way
to
record
the
result
of
of
performance
or
an
action.
In
this
case,
a
conversion
transaction
into
the
receipt,
so
converting
transaction
to
the
receipt
might
produce
certain
errors
and
people
who
do
this
on
near
blockchain.
They
want
to
see
them
in
rpc.
A
Then,
let's
keep
this.
This
is
also
like
implementation
details
here.
This
is
lambda.
Also
we
don't
need
to
look
into
what
is
inside
the
lambda.
Let's
look
at
these
large
cycles,
so
basically,
the
second
point
of
focus
that
you
want
to
have
while
reading
the
apply
method
code
is
those
large
cycles
like
when
you're
iterating
over
the
transactions
or
you're
iterating
over
the
local
receipts
or
iterating
over
there.
You
know
this
is
like
not
for
cycle,
but
it's
also
important
or
you
trading
over
the
incoming
receipts.
A
So,
let's,
let's
just
focus
on
these
cycles
right
now,
because
we
have
only
a
few
minutes
left.
So
the
next
thing,
as
I
said,
is
after
right
after
you
convert
a
transaction
to
the
receipts,
you're
gonna
try
to
process
the
receipts
that
are
local
receipts
that
correspond
to
the
transactions
that
call
the
contract
or
the
account
on
the
same
chart.
A
A
Time
what
you're
doing
one
second
at
the
same
time,
what
you're
doing
is,
while
you're
doing
all
that
you're
keeping
track
of?
Am
I
outside
the
gas
limit,
because
you
have
a
limit
for
the
for
the
for
the
gas
in
our
chunks,
so,
while
you're
doing
all
that
you're
keeping
track
of
the
total
gas
limit?
And
if
you,
if
you
did
exceed
the
gas
limit,
then
instead
of
processing
this
receipt
and
executing
the
function,
call
or
create
an
account.
What
you're
doing
is
now
you
make
it
a
delayed
receipt.
A
A
So
in
our
in
our
blockchain,
it's
very,
very
important
to
not
drop
the
receipts
and
always
execute
them
once
received
is
produced
by
a
converting
transaction
to
the
receipt
or
by
doing
a
cross-contract
call.
It
should
be
pro
it
should
be
processed,
because
this
is
the
guarantee
that
you
need
to
have.
If
you
want
to
build
any
kind
of
defy
on
on
near
blockchain,
if
you
don't
have
guarantee
that
the
receipt
is
going
to
be
eventually
executed,
you
cannot
have
any
kind
of
you
know.
Like
lock
and
unlocking
scenario.
You
cannot.
A
A
This
is
the
difference
between
let's
say,
theorem
and
us
that
have
delete
resist
queue
that
lives
in
a
single
in
each
single
chart,
and
so
what
we're
doing
here
with
the
delete
receipts
we're
trying
to
process
them.
So
once
we
went
for
the
local
receipts
and
now
we're
gonna
we're
gonna
process
them
so
somewhere
here
we
have
processor
seedlings.
C
A
A
So
somewhere
here
you
process
delete
receipts.
I
don't
remember
where
wait,
delete
receipts
so
delete
receipt
indexes
next
available
index,
so
yeah
uterine
over
there.
So
basically
this
function,
what
it
does
it
pops
the
delete
receipts
from
this
qa
that
lives
in
the
state
and
processor
yeah.
Here's
processor
sit
so
you're
extracting
it
here
from
from
the
state
you
literally
here,
you
can
kind
of
see
that
you
you
go
into
the
state
and
you
say:
okay,
what
else
haven't
we
processed?
Yet?
What
is
the
delayed?
A
A
So
then,
after
you're
done
with
the
delayed
receipts,
you
process
incoming
receipts,
so
you
you
first
take
care
of
the
receipts,
that
of
your
own
races,
you're,
the
sharky.
First,
you
care
about
all
about
your
own
stuff.
You
care
about
your
own
local
receipts.
You
care
about
your
own
delayed
receipts.
A
A
It
converts
transactions
to
the
receipts,
it
processes,
local
receipts,
it
processes,
delete
receipts.
It
processes
incoming
receipts
like
four
things,
four
major
things
that
it
does,
in
addition,
of
course,
to
doing
some
work
for
updating,
validator
information
and,
finally,
the
the
last
important
thing
that
you
see
here
is
this
check
balance.
A
So
the
check
balance
is
an
extremely
important
method
that
we
have,
that
prevented
a
whole
bunch
of
bugs
in
our
system
and
what
it
does.
It
makes
sure
that
money
are
not
coming
from
nowhere
and
they're
not
disappearing
into
nowhere
when
the
chunk
is
produced.
So
it's
basically
an
assertion.
It's
just
like
a.
This
is
basically
an
assertion
living
here.
It's
a
very,
very
large
and
heavy
an
assertion
that
we'll
tell.
A
Yeah,
it's
invariant
make
sure
that
invariant
holds.
It
goes
over
this
different
manipulations,
with
the
balances
that
we
had
all
this
gas.
That
was,
you
know
converted
from
tokens
talking
tokens
converted
from
gas.
Even
validator
rewards
distributed
gas
burned.
Sometimes
it
can
be
accidentally
burned
and
it
makes
sure
it
just
adds
up
like
it
may
just
make
sure
that
you
know
these
two
variables
what
should
be
and
what
shouldn't
you
know
that
this
invariant
actually
holds
otherwise.
D
A
A
I
mean
we
only
saw
it
in
the
ci.
I
think,
because
we
have
a
pretty
good
nightly
with
this
nadak
and
all
that,
so
it
only
happened.
I
think
when
we
just
forgot
something
like
some
specific
corner
case
and
it
was
caught
so
yeah,
it
only
happened
when
we
were
actually
merging
things
not
in
production.
I
don't
think
it
happened
in
production,
yeah.
C
A
That's
it,
I
think,
that's
a
good
high
level
overview
of
the
apply
method
and
if
you
focus
on
this
on
the
signature
again
of
the
apply
method
on
the
signature,
try
to
understand
what
gets
in
what
gets
out
on
these
four
major
cycles
that
I
gave
you
overview
of.
You
will
already
have
like
60
percent
of
understanding
of
the
runtime
that
you
might
need
if
you're
working
with
the
runtime
code,
like,
for
instance,
if
you're
working
with
evm
or
with
rpc
or
like
a
building
breach
things
like
that.
C
A
A
Oh,
oh
yeah,
yeah,
yeah,
good
point
good
point,
so
the
limit
for
the
gas
pen
and
transaction
and
on
everything
else
is
different.
So
you
have
a
you:
have
a
basic
50,
50
split
of
the
gas
limit
separately,
for
processing,
converting
transactions
into
receipts
and
for
processing
receipts,
and
this
is
also
something
that
needs
to
be
revisited
because
it's
a
it's
a
questionable
game,
theoretic
solution
here
we
might
want
to
revisit
it
later,
but
because
it's
two
separate
thresholds,
they
just
the
code,
is
in
different
places.
All
right.