►
Description
The first engineer at MemSQL responsible for building sharding implementations that now powers the likes of Goldman Sachs, Uber, Pinterest, Akamai, and Comcast shares his experiences of building industrial-grade solutions and applying it to blockchain scalability. Near Protocol (http://nearprotocol.com/) has 3 early engineers of MemSQL & multiple winners of ACM ICPC worldwide coding competition who are on the way to building the first working implementation of sharding by state for blockchain infrastructure.
Alex Skidanov (https://twitter.com/AlexSkidanov) walks the audience through how sharding is done in a commercial database space, and what's the missing ingredient in scaling blockchain today.
Follow the latest from NEAR Protocol on,
Medium: https://medium.com/nearprotocol
Twitter: https://twitter.com/nearprotocol
GitHub: https://github.com/nearprotocol
LinkedIn: https://www.linkedin.com/company/near...
Telegram: https://t.me/cryptonear
Discord: https://discord.gg/gBtUFKR
#FutureIsNEAR
A
A
Let
me
first
introduce
myself:
I
was
engineering
number
one
that
company
called
mem
sequel,
it's
a
distributed
database
it
it
is
used
for
analytical
processing.
It
is
deployed
today
at
a
lot
of
Fortune
500
companies-
goldman
sachs
Akamai
over
and
there
wasn't
way
number
one.
It
was
responsible
for
hardening.
So
I
was
the
first
implementation
of
charting
I
was
driving
all
consecutive
trading
efforts
performance.
It
was
at
Microsoft
and
before
Microsoft
I
was
participating
in
this
MCP
semi
CPC
is
a
competitive
programming
event
which
happens
every
year.
I
was
a
gold
medalist.
A
Introduced
new
protocols
in
your
protocol
is
a
hard
surface.
Take
public
blockchain.
It
is
a
direct
competitor
over
theorem
and
the
reason.
The
reason
why
we're
building
yet
another
public
chain
is
that
this
isn't
a
good
project
today
which
will
linear
the
scale
as
the
network
grows.
So
there
are
multiple
projects
you
probably
like
each
of
you
probably
can
name
like
a
thousand
chains
which
are
being
built
today.
Most
of
them
would
scale
compared
to
the
theorem.
A
couple
orders
of
magnitude
would
be
hold
effect.
A
A
Finally,
we
have
a
somewhat
unusual
team
for
a
blockchain
company.
There
is
no
famous
PhD
leading
it
it
doesn't.
Everybody
in
our
team
is
from
industry.
We
have
few
people
from
Mexico.
Besides
myself,
there
are
two
other
people
who
are
responsible
for
building
distributed
transaction
execution
engine.
We
have
fans
Googlers,
including
one
person
who
is
doing
tensorflow
and
among
ourselves.
We
have
for
a
specific
metals.
So
it's
a
ridiculous
is
from
Tim
coming
from
doing
this,
and
before
we
start,
I
would
like
to
understand
better
the
audience.
How
many
people
here
are
actually
technical
people?
A
A
So
I
will
start
with
a
funny
how
starting
data
with
this
board,
but
before
we
get
there,
let's
see
why
why
we
care
about
certain
data
bits
and
how
is
it
too
late
relevant
for
block?
It
is
relevant
because
many
people
think
of
blockchain
as
a
distributed
ledger,
has
the
the
entire
history
of
what
was
happening
in
that
particular
blockchain.
A
However,
interestingly,
the
ledger
itself
is
not.
It
was
just
the
means
of
this
or
security.
What
people
actually
care
in
in
the
blockchain,
such
as
a
theorem,
is
the
present
state
right.
For
example,
you
know
if
it's
cube,
taquitos
you
care
about
who
has
kids
today,
you
don't
even
care
how
this
kid
is
worth
channel
or
moving
the
forth
and,
and
you
use
a
theorem
talk,
teach
to
make
changes
to
state,
so
you're
sending
transactions
which
affect
state
will
change
the
state
so
effectively.
A
A
subset
of
any
modern
blockchain
is
a
data
right,
so
you
would
not
expect
a
blockchain
to
be
easier
to
build
than
a
distributed
victims
right.
So
so,
let's
see
how
is
to
do
today
to
visit
we're
evolving,
so
we
will
go
back
to
2004.
Let's
say
in
2004:
you
want
to
build
in
you,
it
could
be
online
game
social
network,
you
name
it
most
likely
in
2004.
A
When
you
develop
it,
you
would
have
a
single
instance,
my
sequel
or
country
that
will
be
handling
all
your
queries
and
then
it'll
all
work
very
well
until
users
start
coming
and
it
doesn't
doesn't
scale
anymore.
So
what
you
will
do
next,
most
likely.
The
first
thing
you
will
do
is
you'll
put
main
cast
in
front
of
it.
So
you
will
you
write
your
application
layer
so
that
it
first
goes
to
memcache
and
only
fits
the
database
when
it
means
back
system
code
beta
right.
A
The
question
is
why
we
would
do
all
that,
instead
of
just
deploying
a
charted
database,
because
our
database
did
not
exist
matter
of
2004.
Today's
2018
probabilistically
you-you-you
do
some
of
that
as
well.
So
there
is
still
not
a
baby.
There's
not
would
shorten
transactional
tables.
You
might
use
firebase
for
that.
That
could
be
a
better
idea
or
one.
A
So
why
why
doesn't?
Why
is
it
so
hard
to
build
a
target
thickness?
So
I
was
back
from
two
problems.
There's
way
more
to
promise.
One
is
cluster
management
right.
If
you
have
a
single
box
database,
it
can
take.
You
know
it
will.
It
will
be
up
for
five
years
once
every
five
years
it
will
go
down.
You
will
recover
from
a
backup.
You
will
have
one
day
back,
that's
perfectly
fine.
If
you
have
100
nodes
cluster,
one
node
will
be
going
down
every
couple
weeks.
So
that
point
you
cannot,
you
cannot
afford
downtime.
A
So
you
need
some
sort
of
plasma.
The
way
usually
would
be
done
is
some
multi-tiered
approach
where
most
of
the
nodes
have
no
idea
there.
There
is
even
a
cluster.
They
will
be
just
storing
the
data
they
responsible
for
and
processing
it.
But
there's
gonna
be
a
few
nodes
which
orchestrate
the
cluster
among
themselves.
Let's
say
it's
ten
nodes:
they
need
to
reach
a
consensus
about
which
data
is
actual.
Who
is
online?
Who
is
offline,
which
not
exist
which
do
not?
A
That
is
significantly
easier
problem
than
maintaining
a
blockchain
cluster,
because
there's
no
at
your
stereo
behavior,
all
the
notes
are
running
binary.
You
wrote
so
the
only
other
state
of
behavior
which
is
possible
is
that
some
not
actually
being
unavailable
and
yep
most
of
the
distributed
databases
lose
data
under
stress.
There's
this
incredible!
Okay,
if
you
haven't
seen
it
before
I'd
recommend
going
through
it,
it's
called
Jackson
and
that
block
they
deploy
product
databases
like
MongoDB,
Valdivia
Cassandra,
and
they
stress
them
and
each
and
every
one
of
them
loses
data
under
stress.
A
So,
despite
the
fact
that
this
is
a
significantly
simpler
problem,
reaching
a
consensus
among
ten
nodes
without
adversarial
behavior,
nobody
can
properly
solve.
The
second
problem
is
query
fees,
so
this
is
less
relevant
to
blockchain.
Today
it
will
become
relevant
within
couple
years.
We're
going
to
talk
about
that
today,
but
once
you
start
charting
your
data
now,
every
node
is
only
responsible
for
some
subset
of
data,
and
so
for
as
long
as
the
query
you
run
only
touches
sound
only
uses
data
from
a
single
shot.
You
find
right.
So,
let's
consider
example.
A
So
for
a
particular
user,
his
information
and
their
orders
are
gonna,
be
on
the
same
chart
in
that
case,
if
you
want
to
execute
any
crossword
query
which
touches
both
tables,
they
will
be
executed
efficiently
because
the
joint
contains,
if
it
would
only
chart
separately
and
then
you
just
aggregate
the
resulting
data,
which
is
usually
relatively
small,
you
can
aggregate
on
a
selection,
it
all
becomes
very
serious
ones.
You
start
running
cross
surgeons,
joints
which
you
want
to
join
data,
only
key,
which
is
not
a
short
key
for
one
of
the
tables.
A
At
that
point,
you
need
significantly
more
sophisticated
processing
approaches
such
as
much
on
max
a
full
map
or
menus
which
are
not
rocket.
Science
MapReduce
has
been
around
for
15
years
now,
and
you
have
very
few
young
database,
essentially
users,
and
definitely
not
a
single
blockchain
and,
as
I
mentioned
before,
is
practically
no
transaction
practically
no
transaction
database.
Today,
that's
of
course
cross
our
joints
you
can.
This
is
Google
spanner,
which
is
billed
by
Google
engineers,
and
there
is
a
PI
GB,
which
is
built
on
top
of
spark
sequel,
which
I
don't
know.
A
How
many
of
you
know,
Sparks
equates
spark
sequel
is
slower
than
putting
all
the
data
on
a
single
machine
and
executing
jointly
possible.
So
if
actually,
there's
no
cross
reference
in
transactional
process,
there
are
their
analytical
database,
such
as
Mexico,
that's
of
course,
but
they
are
expensive
and
they
design
for
competitive
juices.
A
A
There
is
one
practically
use
and
practice
distributed
decentralized
blockchain,
which
supports
smart
context
that
that's
a
TV.
So
there
are
others
these
skills,
which
is
not
quite
decentralized.
There
are
others,
but
this
one
it
is
actual
use
in
practice.
That's
a
theorem
and
the
theorem
is
effectively
single
for
videos
in
the,
in
the
sense
that
in
the
theorem,
every
transaction
is
processed
by
every
single
node
in
the
cluster,
meaning
that
the
entire
system
is
as
slow
as
a
single
known
that
operates
the
system
all
right.
So
what
people
do
to
address
it?
A
Well,
the
most
active
Africa
donating
foundation
today
is
called
plasma,
which
is
a
factory.
You
would
drive
a
sequel
to
be
the
best
secure
blockchain,
which
is
way
faster
than
with
you,
and
you
will
process
transactions
on
that
blockchain
and
you
have
a
secure
way
of
moving
assets
between
a
fume
and
plasma
chain
which
effectively
person
the
way
that
even
if
the
plasma
chain
or
curators
are
malicious,
they
cannot
prevent
you
from
moving
your
assets
from
the
plasma
chain
back
to
their
village.
So
to
an
extent,
plasma
chain
is
man
caste.
A
It
is
a
a
way
to
address
scalability
issue
short
term,
which
is
which
is
not
generalizable
to
all
possible
use
cases
and-
and
it's
a
terrible,
very
short
term,
so
most
likely
plasmon
will
become
used
actually
within.
Maybe
before
the
end
of
this
year
that
one
of
the
next
year
Padma
was
quite
quite
advanced.
There
are
some
other
protocols
that
some
of
you
might
have
heard
about
I
put
two
of
them,
the
time
of
thunder
and
so
on,
I'm
sure
these
more
being
developed
where
the
idea
is
well.
A
Let's,
let's
put
one
very
big
server
and
process
all
transactions
on
that
bitty
server
and
find
some
way
to
make
sure
that
that
server
is
not
behaving
maliciously
and
if
it
does
to
kick
it
out,
then,
and
replace
it
right.
So
that
is,
that
is
what
scaling
up
effectively
is
in
the
past.
In
the
past,
you
would
buy
a
more
expensive
server,
similar
approach
here
again,
it
is
a
huge
benefit
of
this
approach.
A
Is
it
is
a
cheerful
server,
so
founder
promises
to
launch
their
main
nothing
to
them
here,
Solana
promises
to
launch
the
humane,
nothing
to
them
to
be
here,
so
we
will
see
how
that
goes,
but
so
why?
The
question
is
why
not?
Why
not
started
well
again,
because
charting
is
hard,
and
so
let's
see
how
charting
would
actually
be
built
and
how
it
is.
A
A
So
this
way,
if
they
need
to
read
any
information,
that
information
is
available,
if
they
need
to
write
any
information
with
some
smart
way
of
communicating
between
nodes,
they
can
also
update
any
piece
of
information
that
would
that
isn't
as
challenging
as
starting
the
entire
system,
and
there
are
companies
which
do
that.
Silica
is
one
of
the
most
famous
examples
of
a
company
that
will
start
the
processing
without
charging
data.
A
There
is
a
big
problem
charting
processes
processes.
This
chart
displays
the
size
of
the
etherium
state
over
time,
and
it
is
clearly
a
linear
dependency
between
the
size
of
the
state
of
time
right
and
so,
as
of
today
not
the
day,
I
think
it's
September
20
medium.
It
is
100
gigabytes
right
and
that
is
at
14
transactions
per
second.
So
if
you
want
to
scale
the
system
to
thousands
of
transactions
per
second,
the
state
will
will
grow
to
terabytes
very
quickly.
So
that
is
charting
processing
is
a
very
short
term
solution.
A
Well
then,
we
need
to
start
to
take
as
well.
So
when
we
start
state
now,
each
node
is
responsible
for
some
sort
of
state
again
the
same
as
it
was
in
databases,
world
and
every
node
only
processes
transactions
that
affect
the
part
of
the
state
that
it
is
responsible
for,
so
that
that
about
how
starting
to
take
usually
defined,
usually
that
in
starting
state.
That
is
not
a
not
a
requirement,
but
it
does
make
much
sense
to
start
state
and
Lunsford
process.
A
So
we
will
assume
that
if
we
shorten
state
processing
is
officer
now
at
this
point
of
time,
most
of
the
research
on
serving
state
assumes
that
every
smart
contract
will
only
designed
on
a
single
shot
right,
so
contact
do
not
send
multiple
short
contracts.
Do
not
spend
multiple
shirts.
If
you
want
to
execute
the
contract,
you
find
a
surety
belongs
to
goes
to
the
chart,
execute
the
code
and
an
example
of
a
product
is
building.
A
A
A
It
will
primarily
be
used
for
people
to
propose
themselves
as
validators
in
the
in
the
making
chains,
and
so
all
they
mainly
change
the
perfect
steak
and-
and
there
are
pollinators
who
participate
in
maintaining
the
remaining
chains
now,
there's
a
large
full
of
validators
and
a
subset
of
pollinators
processes
every
front.
So
there
are
multiple
shots.
Each
short
process
is
a
subset
of
transactions
and
maintains
part
of
the
state
and
the
some
sort
of
validators
processes
every
shot.
A
There
is
a
big
program
here,
which
is,
let's
say
we
have
thousands
of
validators
that
staked
a
lot
of
money.
Let's
say
a
million
million
dollars
to
participate
for
them
to
collude.
They
would
have
to
lose
something
on
the
order
of
1
million
dollars.
Now,
let's
say
we
have
4,000
charts
and
those
validly
there's
a
split
across
charts.
Now
we
have
now
something
would
only
have
to
lose
something
on
the
order,
how
much
2500,
maybe
even
10
times
less
yeah.
A
So
it's
it's
significantly
smaller
amount
of
money
right,
so
each
short
is
significantly
less
secure
than
the
entire
network.
So
the
way
a
theorem
addresses
the
problem
is
in
every
chart.
The
transactions
after
they
processed
the
a
certain
message,
is
sent
to
a
special
chain
called
beacon
chain
and
the
beacon
chain
actually
has
a
larger
set
of
validators
with
a
larger
state
and
the
beacon
chain
reaches
a
business
team
consensus
on
what
on
what
is
the
state
and
so
now
for
for
the
history
to
be
written.
A
So,
okay,
so
now
what
is
the
problem
with
this
approach?
There's
one
problem
which
is
cross
card
transactions.
Imagine
that
Ellison
bought
one
to
transact.
He
responds
to
sent
money
to
book
and
they
reciting
different
shows
canvases
one
shot.
One
board
is
inferred
that
creates
a
problem
that
maintain
years
of
chart.
One
cannot
add
money
to
book
because
they
that's
not
part
of
their
state.
The
main
tenets
of
short
to
cannot
subtract
money
from
Ellis
because
that's
one
part
of
their
state.
A
So
we
need
some
sort
of
cross
start
communication
in
place
and
at
this
point
cross
card
communication
is
an
active
area,
research
and
notice.
I,
don't
think
any
charting
proposal
has
a
full
story
of
how
their
cross
card
communication
would
work.
So
I
will
just
go
through
some
proposals
which
are
not
mutually
exclusive.
Some
of
them
complement
each
other,
but
in
fact
what
people
were
proposing
for
crosser
communication,
one
of
the
easiest
solutions,
the
one
that
we
will
be
using
for
smart
controller,
says
as
long
as
something
is
within
a
chart
executed
in
parallel.
A
If
you
need
to
execute
any
preferred
transactions,
how
the
entire
parallel
execution,
as
you
could
all
the
cross
card
transactions
serially
unhulled
execution-
that
is
parallel,
so
that
that
works
very
well.
If
you
assume
that
cross
card
transactions
are
extremely
rare,
and
so
you
can
most
of
the
time,
you
will
be
executing
transaction
parallel.
Occasionally
you
will
stop
the
parallel
execution
and
executive.
You
crush
your
transactions,
the
second
easy
approach.
Is
we
internally
call
it
Beanstalk?
If
the
factor
that
says
well,
let's
not
have
any
preferred
communication
and
specifically
for
payments
that
actually
works.
A
We
just
say
every
participant
has
an
account
on
every
single
shard,
and
if
you
want
to
send
money
to
someone
to
someone
else,
you
just
find
a
Chardon.
We
should
have
sufficient
amount
of
money
and
send
money
on
the
chart.
If
you
don't
have
any
service
a
sufficient
amount
of
money,
you
just
get
a
subset
of
shirts
and
some
money
in
all
the
subsets
of
shirts.
So
in
the
extreme
case
you
would
have
to
send
an
every
short.
Then
you
get
no
benefit
from
realization,
but
that
extreme
case
is
supposedly
rare.
A
Most
of
the
time
you
will
have
one
short
wishes.
You
get
a
lot
of
fertilization,
there's
one
not
well-known
blockchain
that
uses
a
called
letter
and
I'm,
not
necessarily
heating
for
flat
above
their
papers,
actually
pretty
interesting.
It's
very
simplistic
and
provide
an
interesting
approach
to
serving
then
one
of
their
favorite
proposals
is
called
merge
blocks
where
they
effectively
saying
they
have
it
at
the
kick
which
for
two
blocks
on
two
different
shirts.
A
Okay
can
probably
guarantee
that
either
both
blocks
will
be
present
in
their
corresponding
block
chains,
or
neither
block
could
be
present
in
their
crystal
ball
chains,
and
so
this
way,
when
the
merge
look
is
created,
the
validators
on
those
two
shards
can
then
load
the
state
for
both
shirts
and
execute
a
neo
transaction
which
affects
both
charts
by
having
access
to
the
entire
state.
That
proposal
has
many
advantages
of
them.
The
primary
disadvantages
it
has
is
a
you
can.
A
We
cannot
have
those
large
blocks
for
any
particular
pair
of
charts
too
often,
because
these
N
squared
pairs
of
charts-
and
so
you
only
have
linear
number
of
batches
of
validators.
It
would
take
order
n
iterations
before
the
merge
code
can
be
created
together,
and
the
second
disadvantage
is
that
it
only
works
for
cursor
transactions
that
effect
at
most
two
shots.
A
So
if
we
have
any
transaction
which
affects
more
than
two
charts,
that
approach
doesn't
work
and
then,
finally,
the
the
more
sort
of
obvious
working
approach,
which
probably
is
also
going
to
be
executed,
implemented
somewhere
in
the
theorem.
It's
definitely
the
way
that
plasma
communicates
to
to
the
man
to
the
main
map,
and
it
is
not.
It
is
not
unique
to
cross
your
communication
to
the
old
people
can
also
be
used
to
implement
cross
chain
communication.
We
know
the
etherium
would
be
communicating
to
us.
A
It's
called
three
seeds
or
the
idea
is
that,
if
we
want
to
execute
the
transaction
which
affects
multiple
charts
on
Moodle
or
multiple
chains,
to
execute
the
first
step
on
one
chain,
create
a
proof
that
that
step
was
executed
and
is
persisted
on
the
chain,
send
up
proof
to
another
chain
or
char,
and
then
that
chain
or
start
execute
the
second
step.
Knowing
that
it
was
executed
in
the
first
chain.
A
A
A
Well,
for
there
is
only
for
the
rest
of
this
talk,
we
will
be
using
receipts
as
they
as
the
way
to
implement
for
our
transactions,
and
so
here's
a
gorgeous
drawing
of
how
that
works.
If
Alice
wants
to
send
money
to
Bob
Ellis
does
the
transaction
to
charge
zero
where
she
resides
on
that
chart?
That
transaction
is
executed,
that
subtracts
money
from
her
and
then
every
suit
is
created
with
the
proof
that
that
transaction
is
executed.
A
A
Now,
when
they
sit
in
mind
in
mind,
let's
see
how
Charlie
can
book
couple
years
from
now.
Let's
talk
about
reading
smart
contracts,
so
in
the
in
all
the
approaches
we
discussed
so
far,
every
and
and
in
all
the
approaches
proposed
today.
Each
smart
contract
belongs
to
a
single
shark,
and
that
is
more
than
that
for
today,
in
today's
world,
the
most
used
smart
conferences
and
to
dip
the
key.
A
Just
online
exchanges
have
between
500
and
1500
active
users
per
day,
so
that
at
that
scale
a
single
smart
contract
can
easily
when
a
single
chart,
and
it
can
scale
up
to
orders
of
magnitude
and
still
probably
probably
be
able
to
live.
But
at
some
point
I
am
vision,
a
bright
future
in
which
everything
I
have
on
my
phone
is
running
on
watching
and
not
a
single
large
corporation
can
steal
my
data
and
once
we
move
to
that
bright
future,
a
smart
contract
cannot
live
on
the
scene
with
heart
anymore
right.
A
So,
let's
see
how
it
can
look
so,
first
of
all,
let's
assume
that
receipts
are
actually
available
is
a
primitive
so
that,
let's
assume
that
all
the
problems
that
exist
with
these
sheets
are
solved,
and
what
we
do
now
is
that
the
state
of
the
smart
contract
now
will
be
shared
Charlotte
across
multiple
shots.
And
so
we
will
talk
about
few
approaches
today
to
implement
that
it's
a
table,
cost
scattered,
collect
and
messages.
So,
first,
let's
talk
about
tables
and
we
will
use
uber
as
an
example.
A
Let's
say
we
want
to
build
cover
on
the
watch
and
and
that's
you
know
that
will
be
scaled
up
scaled
out
and
now
nothing
fits
on
a
single
shot.
So
we
would
naturally
want
to
have
some
information
about
cars
which
are
available
at
this
time
and
that
will
probably
be
charted
by
car
ID,
because
if
you
won't
update
any
information
about
the
car,
that's
the
only
way
to
find
it.
A
At
the
same
time,
if
I'm
calling
an
uber
from
my
phone
I
need
to
quickly
find
a
car
in
location,
so
there's
got
to
be
some
index
on
the
cars
that
is
charted
by
the
kitchen,
so
they
can
quickly
identify
charge
which
is
possible
for
particular
locations
and
find
cars
which
exist
in
the
chart.
Right
so,
let's
say
now:
a
car
is
driving
through
the
city,
so
let's
say
we're.
Consider
Berkeley.
We
split
Berkeley
into
greed,
of
salads,
largest
largest
location
chunks.
A
A
The
problem
with
this
function
is
that
each
of
those
four
lines
can,
in
theory,
required
to
be
executed
on
a
different
shot
right,
and
so,
if
we
want
to
do
some
general-purpose
language
for
writing,
smart
context,
we
would
have
to
use
reflection
at
the
very
like
at
extreme
capacity
to
actually
sleep
that
that
smart
contract
into
multiple
lines
execute
them
separately
on
different
shirts.
More
importantly,
the
problem
for
developer
here
that
the
developer
can
accidentally
create
a
smart
contract
which
will
execute,
which
will
involve
a
lot
of
cross
our
communication
without
in
the
study
item.
A
A
0
update
the
card
moves
to
chart1,
update
the
location,
move
back
to
charge,
0
updated
location
and
department,
so
the
way
to
build
it
in
a
way
that
it
is
more
obvious
for
the
developer
that
they
having
some
preferred
communication
and
is
also
significantly
easier
for
the
system
to
split
the
the
code
into
individual
chance
is
to
use
what
is
called
pale
calls,
or
it
is
also
it
known
as
continuous,
passing
continuation
patterns.
Thank
you
we're
in
a
factory.
What
we're
saying
is:
there's
one
function,
which
is
the
entry
point
in
this
guy
case.
A
It's
move
car
and
what
it
does
is.
The
first
argument
is
what
it
is
charted
in
this
case.
The
first
argument
is
Carnegie,
so
the
keurig
is
what
will
be
used
to
determine
the
chart.
It
will
go
to
the
short
for
that
particular
car
engine
and
the
entire
body
of
the
function
will
be
executed
on
the
chart.
So
the
developer
needs
to
understand
that
only
data
that
resides
on
the
chart
is
available
to
them
and
once
they
want
to
move
to
a
different
shirt,
they
they
effectively
invoke
another
function.
A
Passing
is
the
first
argument,
the
short
key
for
that
for
that
auto
function,
and
they
they
are
only
allowed
to
call
that
function,
has
the
very
last
instruction
of
the
function.
That's
why
it's
called
tail
call
this
is
to
move
a
car,
will
first
go
to
the
short
with
the
car
will
identify
the
location
and
unknowns.
It's
just
a
way
to
prevent
some
race
conditions
and
then
the
second
step
needs
to
be
executed
on
the
part
of
the
car.
A
So
we
invoke
a
function
that
will
me
that
will
perform
the
second
step
and
the
second
step
identifies
perform
some
operations
to
avoid
race
conditions.
Have
you
considered
both
if
and
else
as
the
last
instruction,
the
body
of
them
has
another
function?
Call
which
will
go
to
another
shop,
but
importantly,
both
of
them
would
be
the
very
last
instruction
of
the
function
right
and
so
the
way
good
look
ultimately
is
one
short
one
moved
home
of
card
so
left
to
right.
A
A
An
example
of
that
is
me
calling
a
cab
in
uber
times
and
I
belong
to
specific
mile
by
mile
location,
but
I
could
be
at
the
very
boundaries
right,
so
as
I'm
searching
for
the
car,
I
probably
want
to
look
at
all
the
locations
around
medication,
so
without
loss
of
generality.
Let's
say
we
want
to
look
at
the
nine
locations
which
is
around
me,
and
so
there
is
that,
let's
say:
I
belong
to
short
one.
A
That's
where
my
user
ID
is
located
and
as
I
call
the
car,
it
goes
to
my
location,
some
of
them
the
one
closer
to
zero.
Some
of
them
belong
to
short
one.
Some
of
them
belong
to
short
tooth,
and
so
it
will
scatter
the
calls
to
those
charts
in
each
article
execute
some
code
and
then,
ultimately,
all
those
charts
will
gather
back
again
together
to
my
shirt
in
which
the
final
processing
will
be
performed.
A
Now
they
come
to
the
problem
with
that
is
that
so
scatter
is
actually
very
simple
right
if
I
want
to
call
nine
instances
of
single-function
I'm,
just
sending
a
receipt
with
the
proof
that
the
first
step
was
executed
on
my
chart
of
all
nine
charts
and
each
of
the
nine
charts
will
just
execute
the
step.
Gather
is
a
little
more
complex
because
at
this
point
let's
say
Chartier
herbs
that
you
do
this
step
faster
than
everybody
else
and
they
sent
back.
They
received
a
short
one
short.
A
The
beauty
of
scatter
collect
is
that
when
we
scatter,
we
know
how
many
instances
of
the
of
the
function
we
call
them
like.
In
our
case,
it's
going
to
be
nine,
and
so
gather
knows
how
many
of
you,
since
it
is
expected,
gather,
know
that
each
of
them
needs
to
send
back
the
response
to
these
going
to
nine
and
so
the
validators
in
in
the
chart
that
is
performing,
gather
or
or
rather
collect.
They
will
wait
for
nine
receipts
and
once
they
receive
all
nine,
they
know
that
they
can
continue
so
here.
A
A
So
the
way
it
would
look
is,
let's
say
the
user.
The
Wumpus
are
to
the
user,
calls
find
hard,
and
then
these
nine
point,
five
hard
eternal,
will
show
the
executive
on
the
next
time
stem
in
multiple
terms
and
then
the
third
time
stamp.
They
all
send
information
back
to
one
chart
where
the
last
step
is
executed.
A
So
so
that
on
itself
is
already
a
pretty
powerful
execution
framework,
for
example,
in
google,
a
lot
of
things
are
implemented
on
top
of
big
table
and
big
table
effectively
allows
you
to
change
one
row
at
a
time
without
any
looks,
and
a
lot
of
a
lot
of
products
can
be
built
on
top
of,
but
ultimately
it
still
has
quite
a
few
challenges.
I
challenge
number
one:
let's
actually
look
at.
How
is
its
work
in
the
field
or
the
how
they
could
work
in
the
theorem
in
the
future?
A
So
let's
say
we
start
selling
the
cucm
in
short
one
and
from
the
very
first
block
we
we
do
the
execution.
Now
we
want
to
send
a
receive
to
another
short
before
we
can
send
ABC.
The
transaction
needs
to
be
finalized
right
for
for
the
poor,
another
heart
to
be
certain
that
the
transaction
has
happened.
The
transaction
should
be
can't
be
reversible,
so
in
the
theorem.
That
means
that
that
transaction
needs
to
be
cross
linked
to
the
beacon
chain.
A
Each
heart
chain
publishes
blocks
every
eight
seconds,
so
we're
looking
at
least
for
eight
seconds
before
it
even
gets
cross
link,
transfer
consensus
queues
about
instantaneous,
it's
quite
a
few
validators
reaching
a
Byzantine
consensus,
it's
a
slow
procedure,
and
then
it
takes
another
eight
to
sixteen
seconds
to
get
back
to
to
the
other
Shore.
So
we're
looking
at
you
know
30
seconds
to
a
couple
minutes
per
one
cross
heart
communication.
A
If
we
using
this
approach
in
a
theorem
in
a
naive
way
right,
so
some
other
approach
needs
to
exist,
I,
don't
know
exactly
what
the
thing
is
planning
to
do
and
I
think
they.
That
is
not
their
present
focus
this
they
right
now.
They
mostly
building
the
beacon
chains
cross.
Our
transactions
I
get
to
be
figured
out.
That's
my
understanding!
A
Then
challenge
number
two
is
concurrency
control,
so
in
my
example
of
uber
app
that
particular
code,
if
it
was
working,
would
have
a
lot
of
race
conditions.
So
so
the
way
it
is
built
it
would
probably
not
work
right,
and
very
often
you
need
to
make
sound
is
using
one
short
based
on
some
data
in
another
chart
which
can
change
as
you
help
you
as
you
making
progress.
A
That
problem
has
been
researched
extensively
in
the
data
world.
There
are
multiple
approaches,
there's
a
pessimistic
concurrency
control
in
which,
if
you
have
some
data,
which
we
depend
on
you
just
lock
it
and
you
prevent
anyone
from
changing
it.
That
has
a
lot
of
problems
in
the
blockchain
world.
If
you
lock
some
data
and
then
you
disappear
for
the
data's
collude
or
anything
that
data
is
unavailable,
there's
an
opportunity,
concurrency
control,
in
which
you
actually
give
the
entire
function,
assuming
David
you've.
No
change
and
then
you
check
if
it
changed
if
it
changed,
you
like.
A
A
Ultimately
I
think
the
most
promising
approach
for
the
blockchain
world.
The
other
thing
is
what
they
seem
studying
to
do.
That
is
what
we
most
likely
going
to
be
building
is,
if
you
need
to
have
to
process
data
from
multiple
charts
in
a
way
that
requires
concurrency
control,
you
temporarily
move
all
the
data
to
a
single
short
processed
in
a
single
chart,
and
then
you
distribute
it
again
then.
Finally,
scatter
collect
that
I
showed
is
a
it's
a.
A
Subset
of
a
more
general
framework
called
MapReduce
and
MapReduce
is
it
enables
significantly
more
powerful
use
cases.
However,
in
the
blockchain,
in
a
naive
approach,
the
types
that
it
would
not
quite
work
because
in
fact,
I
collect
the
huge
advantage
was
that
by
the
time
we
collect
we'll
know
exactly
how
many
issues
we're
expecting.
If
we
scattered
ten
instances
of
some
function,
we
expecting
ten
digits
when
we
collect
and
MapReduce
in
general,
every
particular
invitation
of
a
function
can
scatter
more
than
so.
You
know
at
the
beginning.
A
You
call
map
on
ten
partitions
that
can
call
map
on
20,
partitions,
etc
and
reduce,
or
group
by
in
general,
doesn't
have
to
seem
to
have
to
go
to
a
single
shot.
So
it
could
be
that,
as
we
grew
by
those,
the
data
is
sent
to
multiple
charts
and
aggregated
on
them.
So
in
this
example,
I
have
here,
they
reduce
it
on
the
very
last
step
sends
three
receives
to
one-third
introduced
another
shot.