►
From YouTube: Wasm in Web3 Workshop with Maksym Zavershynskyi
Description
Maksym Zavershynskyi is Head of Engineering at NEAR Protocol.
In this talk at the Wasm in Web3 workshop series sponsored by Fluence, Max covers the role of Wasm on the NEAR platform, covering key design choices and topics that are relevant to anyone building dApps on NEAR or considering contributing to other areas of the platform.
---
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
Hey
everyone,
my
name
is
max.
Just
like
anna
told
you
I'm
a
head
of
engineer
engineer
and
for
those
of
you
who
don't
know.
Nier
is
a
sharded
proof
of
stake.
Blockchain,
with
a
special
focus
on
developer
friendliness
and
sharding
is
just
one
of
the
ways
why
how
we
achieve
developer
friendliness
because
chardonnay
allows
us
to
be
scalable.
A
So
currently
we
support
two
languages
rust
and
a
sandwich
script.
So
most
of
you
are
familiar
with
rust
and
most
of
the
web
assembly
enabled
blockchains.
They
actually
use
rust
as
their
primary
smart
contract
development
language
for
many
good
reasons,
so
one
of
them
is
that
rust
is
the
first
class
citizen
as
a
web
assembly
language,
not
surprisingly,
because
the
community
that
develops
wasm
and
rust
is
heavily
overlapping.
So
it's
frequently
the
same.
People
who
work
on
rust
and
wasm.
A
Also
brust
is
a
very
safe
language,
as
we
all
know
has
drawn
typing
and
lifetimes
and
prevents
all
kind
of
ways
of
shooting
yourself
on
a
food.
So
that's
why
we
default
to
rust
as
our
primary
smart
contact
language,
but
we
also
allow
people
developing
an
assembly
script
and
for
those
of
you
who
don't
know,
assembly
script
is
a
dialect
of
typescript.
A
It
has
been
developed
by
a
small
group
of
people
that
we
are
the
biggest
sponsor
of,
and
what
they're
trying
to
do.
They
try
to
get
the
right
balance
between
having
a
developer
friendly
language
for
for
people
coming
from
the
web
and
mobile
development.
So
many
people
coming
from
web
development
they're
already
familiar
with
typescript,
so
assembly
script
is
just
a
dialect
of
typescript.
It
looks
almost
exactly
the
same
as
typescript,
but
it
has
some
extra
annotations
for
type
safety
and
whatnot
and
it
tries
to
also
be
as
close
to
webassembly
as
possible.
A
So
it
tries
to
be
easier
to
compile
to
our
assembly
than
typescript
and
many
people.
Many
developers
come
into
our
blockchain
they're,
with
only
the
knowledge
of
typescript
they're
able
to
develop
an
entry
and
a
centralized
application.
Just
in
typescript.
You
know
like
write
a
contract,
an
assembly,
script,
front-end
and
typescript.
You
know
they
deploy
it
on
a
minute
in
a
matter
of
minutes
or
hours,
depending
on
the
complexity
of
their
project,
the
other
two
languages
that
we
are
going
to
support
very
soon,
as
our
smart
control
development
languages
is
green
and
sick.
A
We
also
sponsoring
them
and
they
have
already
and
a
better
sdk
on
near
that
is
gonna
soon
to
be
productionized
and
a
grain
also
strikes
really
good
balance
between
like
rust
and
typescript
kind
of
language.
It
doesn't
have
manual
memory
management,
which
is
kind
of
a
strength
of
rust
because
with
manual
memory
management,
you
don't
have
this
spikes
of
cpu
usage
when
you're
garbage
collector
kicks
in,
but
for
most
of
the
languages.
They're
going
to
explain
to
you
later
that
have
non-manual
memory
management.
A
We
actually
just
disable
garbage
collection,
because
smart
contracts
are
short-lived
anyway
and
we
can
afford
to
never
delicate
memory
in
the
first
place.
So
the
grain
is
the
case
coming
very
very
soon
in
the
next
week
or
a
couple
of
weeks
and
zig
is
another
language
that
we've
been
developing.
Sdk
for
zig
is
also
quite
popular.
It
compiles
the
web
assembly
quite
easily
and
yeah,
so
this
we're
going
to
have
four
languages
as
a
smart
contract
which
is
so
near
blockchain
soon.
A
So
the
question
is
how
many
languages
are
we
going
to
have
in
the
near
future?
What
are
our
plans
and
our
plans
us
to
have
like
every
single
language
that
compiles
to
assembly
and
every
language
that
we
can
lay
our
hands
on
as
language
for
smart
contract
development
and
near,
and
it's
just
a
matter
of
time
and
the
matter
of
the
resources,
but
we're
going
to
get
to
all
of
them.
A
It's
quite
a
big
code
base,
so
once
we
get
more
clarity
and
confidence
with
using
apps
script
and
we're
going
to
have
c,
plus
plus
sdk
on
near
java
python
and
go
turn
out
to
be
very
heavy
in
the
compilation
to
web
assembly,
specifically
python
programs,
their
order
of
magnitude
larger
when
compiled
webassembly
than
equivalent
programs
written
in
rust.
And
that's
because
python
is
not
meant
to
be
compiled
to
web
assembly.
A
It
has
pretty
heavy
runtime
and
the
contracts
that
I
would
usually
be
like
100
000
bytes
in
size.
They
become
like
two
megabytes
in
size
when
compiled
when
written
in
python
and
compiled
web
assembly,
but
we'll
we'll
figure
something
out
in
the
future.
We
might
narrow
down
these
languages.
You
know
again
use
some
kind
of
a
dialect
to
make
them
easier
to
compile
to
webassembly,
or
we
might
even
raise
the
minimum
the
maximum
contract
size
on
on
near
blockchain
to
be
able
to
accommodate
all
of
these
languages.
A
There
are
various
virtual
machines
that
we
are
using
to
run
web
assembly
program
set
near
so
right
now
we're
using
wasmer
and
single
pass
and
wasam
time
and
light
beam.
So
these
are
both
non-optimizing
back-ends
for
web
assembly
compilation.
There
are
reasons
why
we
don't
want
to
use
optimizing.
Compilers
first
of
all,
is
that
optimizing
compilers
like
lvm
and
crane
lift.
A
They
are
they're
quite
large
in
their
code
base
size,
and
we
want
to
be
very
confident
with
the
webassembly
back-end
that
we
integrate
in
into
our
blockchain
client,
and
so
we
just
try
to
stay
away
from
them
for
now,
but
also
optimizing
compilers.
They
have
much
more
complex
behavior
they
prone
to
compiler
bombs,
sometimes,
and
we
just
don't
want
to
deal
with
it
yet
so
we
we
still
use,
we
use
wasmer
and
single,
pass
and
vasem
time
plus
light
beam
right
now.
A
So
right
now
we're
using
wasmer
0.17
as
as
our
default
execution
environment,
but
we
are
slowly
migrating
to
osmo.
2.0
osmore
2.0
has
a
faster
compilation,
time
of
loading,
the
module
into
memory
and
faster
execution
of
webassembly
code
in
general,
so
we're
going
to
have
at
least
twice
faster
contracts.
Once
we
migrate
to
osmo
2.0,
we've
just
been
extra
careful
with
fixing
all
safety
issues
in
wasmer
2.0
before
migrating
to
it.
A
We
also
have
azam
time
and
light
beam,
integrated,
an
engineer
blockchain.
We
don't
use
it
by
default.
However,
any
validator
can
switch
to
we're
using
wasm
time
plus
slide
them
if
they
want
to
and
the
reason
we
have
it.
There
is
just
in
case.
You
know
we
find
any
kind
of
bug
and
wasmer
and
single
pass.
A
We
will
be
able
to
signal
to
our
leaders
to
switch
to
azam
time
plus
light
beam
while
we're
fixing
this
bug,
but
this
hasn't
happened
yet
surprisingly,
even
though
wasmer
and
single
pass
and
bosom
time
plus
light
beam,
have
very
different
code
bases,
entirely
different
approaches
to
compilation
light
beam
as
a
streaming
compiler,
their
performance,
at
least
for
asmr
0.17-
is
quite
similar
on
most
of
our
benchmarks.
So
that
was
a
very
interesting
discovery.
A
We
are
also
looking
into
the
interpreters,
so
parity
has
been
used
in
wasmi
since
the
beginning.
There
is
also
wasn't
free
and
very
popular
interpreter
right
now
we
might
be
looking
into
using
them,
because
the
advantage
of
the
interpreter
is
that
they
have
a
very
a
simple
warm-up,
unlike
the
compilers
that
need.
You
know,
a
complex
module
loading
before
you
can
start
executing
the
smart
contracts.
A
Interpreters
are
really
easy
to
start
up,
even
though
they're
much
slower
when
you
actually
execute
wasm
code,
so
we
might
add
them
in
the
future
and
allow
people
to
choose
which,
which
wasn't
virtual
machine
to
use
when
executing
the
smart
contract.
So
they
might
be
able
to
use
interpreters
for
really
really
tiny
contracts
and
pay
even
smaller
fees,
for
them.
A
We're
also
going
to
be
looking
into
the
optimizing
compilers
too.
So
we
talked
to
crane,
lift
core
developers
and
it
seems
like
there
is
a
way
to
run
crane
lift
in
an
optimizing
way,
get
rid
of
some
optimization
stages.
I
need
to
make
it
also
smaller
in
code
size
that
might
allow
us
to
have
crane
lift
as
as
another
as
another
webassembly
back
end
for
webassembly
execution
at
near.
A
The
interesting
thing
is
that
running
charted
proof
of
stake.
Blockchain
actually
has
strong
advantages,
so
one
of
them
is
that
we
have
an
inherent
incentive
for
validators
to
run
multiple
virtual
machines.
So
right
now
you
know
that
some
virtual
machines
they
have
implementations
of
their
protocols
back
in
different
languages.
A
But
what
frequently
happens
is
players?
Do
not
really
have
incentive
to
diversify
the
clients
that
they're,
using
and
frequently
the
bloc
the
network
just
converges
to
one
client,
because
which
is
you
know
the
cheapest
or
the
faster?
So
whatever
has
better
configuration
parameters
which
undermines
the
whole
point
of
having
multiple
implementations,
because
you
know
if
50
percentable
leaders
are
running
the
same
light
client
the
same
client,
then
you
know,
if
you
have
coordinated
error,
it's
going
to
go
down
anyway,
with
sharded
blockchains.
A
A
So
what
has
happened
on
some
short
blockchains
and
what
you
want
to
avoid.
Is
that
that
when
slavishing
happens
because
of
some
bug
which
happened,
hasn't
happened
to
near,
we
also
haven't
enabled
sharding
yet.
But
if
validators
want
to
really
avoid
being
slashed,
because
there
is
a
bug
in
the
in
the
code
or
because
they
have
messed
up
the
devops
the
setup,
then
they
might
have
an
incentive
to
run
multiple
clients
with
different
implementations
side
by
side.
And
if
they
disagree
on
the
block
production,
then
they
would
terminate
their
clients
without
producing
any
block.
A
A
So
what
I
mean
by
deterministic
versus
ephemeral
errors
is
that
the
deterministic
error
is
the
kind
of
an
arrow
that
has
been
introduced
by
the
contract
developer.
Let's
say
they
have
written
a
program
that
you
know,
does:
division
by
zero
or
exceeds
the
the
maximum
allowed
stack
sizing
in
web
assembly.
A
Think
that
there
is
an
ephemeral
arrow
and
what
we
do
with
the
femoral
errors
is
that
we
just
shut
down
the
node.
We
don't
want
to
deal.
We
don't
want
to
have
a
special
cover
mechanism
when
you
have
a
discorruption
happening.
So
we
just
shut
down
the
note
in
this
case,
and
if
we
make
a
mistake
and
miss
categorize
humanistic
air
force
primaril,
then
someone
can
crush
the
entire
network,
which
hopefully
doesn't
is
not
possible
to
happen.
If
you
miscategorize
a
femoral
error
for
deterministic
error,
then
what
might
happen
is
that
some
nodes?
A
So
it's
it's
the
top
of
our
mind
to
the
separate
deterministic
and
ephemeral
errols,
very
precisely
for
the
buzzing
virtual
machines
and
occupies
a
lot
of
our
time.
Doing
it
correctly.
Full
compatibility
with
violism
standard
also
turned
out
to
be
not
super
trivial,
because
there
are
very
tiny
corner
cases
around
trap.
Handling
that
we
found
out
are
not
handled
precisely
on
about
the
virtual
machines,
and
this
is
something
we
had
to.
We
noticed
only
post
facto
forward.
A
Compatibility
with
wasm's
turner
is
also
important
for
us,
so
I'm
gonna
be
talking
later
on
how
we
do
the
gas,
injector
and
instrumentation
vason
contracts
and
the
new
way
of
doing
the
gas
injector
makes
a
strong
assumption
that
certain
parts
of
azam
standards
are
not
going
to
be
extended
in
the
future,
and
so
that's
basically
an
assumption.
So
forward
compatibility
wasn't
standard
that
we're
going
to
talk
about
later.
A
Then
you
also
want
to
canonicalize
the
floats.
This
is
something
that
we
do
for
all
our
contracts.
Initially,
we
decided
to
just
sanitize
our
contracts
and
prohibit
deploying
the
contracts
on
on
your
blockchain.
That
uses
use
the
floats,
but
we
very
very
quickly
found
out
that
this
leads
to
very
bad
developer
experience
because,
like
ras
developers,
they
just
want
to
import
libraries
when
they
develop
smart
contracts.
And,
surprisingly,
even
if
you're
importing
some
library
that
doesn't
use
flows
for
like
math
operations,
let's
say
you're
importing
some
cryptographic
library.
A
And
finally,
this
entanglement
implementation
of
other
virtual
machines
from
the
protocol
turned
out
to
be
also
not
super
trivial.
There
are
some
minute
details
about
how
the
stack
handling
is
is
being
done
by
it
was
in
virtual
machines
or
how
how
was
virtual
machines
interact
with
your
instrumentation
that
made
some
of
these
details
leak
into
a
protocol
spec
and
ties
to
a
specific
implementation
of
the
vason
virtual
machine
that
we're
currently
slowly
removing.
A
A
Usually
it's
not
the
best
case
scenario,
because
if
you,
if
you
optimize
your
fees
to
target
for
the
best
case
scenario,
then
your
blockchain
is
going
to
be
vulnerable,
someone
might
be
able
to
trigger
the
worst
worst
case
scenario,
so
yeah
the
the
worst
case
scenarios
dictate
the
fees
which
did
dictate
tps
on
your
blockchain.
At
the
end
of
the
day,
you
can
try
to
special
case
best
case
scenario
and
say,
for
instance,
that
if
your
contract
hits
doesn't
hit
some
corner
cases,
then
the
fees
are
generally
lower.
A
Unfortunately,
that
leads
to
bad
devex.
Well,
first
of
all,
your
fees
might
be
unpredictable,
so
if
developers
find
out
that
in
certain
cases,
the
smart
contract
execution
is
much
more
expensive
than
in
other
cases
based
on
some.
So
like
super
low
level
internal
mechanism
and
how
webassembly
virtual
machine
functions,
then
the
box
is
going
to
be
pretty
bad,
but
also
special
case.
In
best
cases
will
lead
to
increased
complexity
of
the
protocol,
which
we
also
want
to
avoid.
We
try
to
keep
our
protocol
pretty
simple.
A
We
also
want
the
execution
time
to
be
similar
on
similar
platforms.
We
have
a
target
hardware
at
near,
but
we
want
people
to
be
able
to
run
our
notes
on
almost
any
four
core
cpu
plus
16
gigabytes
of
ram
machine.
So
we
don't
want
the
execution
time
to
vary
drastically
across
different
platforms
and,
finally,
big
challenge
with
determinism
is
how
do
you
decide?
What
are
your
fees-
and
this
is
a
completely
separate
topic
that
I'm
gonna
get
to
soon.
B
A
Sorry
sorry
skip
the
slides.
There
are
performance
challenges
with
virtual
machines,
so
one
of
them
is
the
time
to
start
it's
just
the
time
that
it
takes
for
your
virtual
machine
to
warm
up
before
it
starts
running
the
smart
contract
and
there
are
multiple
factors
that
contribute
to
time
to
start.
One
of
them
is
this
visualization
time,
so
it
does
matter
what
kind
of
the
serializer
you
use
to
store
your
compiled
module,
and
there
is
also
the
contributing
factor
of
the
io
cost.
A
A
A
A
number
of
the
methods
in
wasm
surprisingly
also
frequently
contribute
to
the
time
it
takes
to
load
the
module,
and
obviously
a
number
of
the
imports
also
contribute
to
that
then
call
contracts
is,
is
a
big
problem.
Someone
can
deploy
a
contract
that
they
never
call
for
many
years,
and
then
they
try
to
call
it
two
years
later
and
it
can
be
living
in
a
cold
storage.
A
The
compilation
time
is
is
a
challenge
even
with
single
pass
and
streaming
compilers
compilation
takes
slightly
different
time,
and
so
what
we
had
to
do.
We
had
to
go
all
over
the
wasmer
code
and
remove
things
like
randomly
seated
hash
maps
and
like
some
multi-threading,
to
make
the
compilation
time
consistent.
Yeah.
A
Yeah,
so,
finally,
how?
How
do
we
decide
the
fees?
So
this
is
the
big
problem
for
every
blockchain,
because
obviously
every
operation
on
a
blockchain
should
take
certain
amount
of
money
right.
You
don't
want
stuff
to
be
executed
for
free
on
your
blockchain.
So
how
do
you
decide
what
costs?
What
and
especially
when
it
comes
to
the
virtual
machine
that
has
a
very
complex
internal
mechanisms
so
the
way
many
blockchains
address
it?
A
They
either
do
the
educated
guess
sometimes,
because
if
they,
if
you
have
host
functions,
which
are
cryptographic
primitives,
you
might
be
able
to
guess
how
much
it
should
cost,
but,
most
of
the
time,
the
way
blockchains
do.
It
is
by
running
time-based
benchmarks,
like
they
execute
operations
over
and
over
and
over
and
time
them,
and
determine
based
on
the
timing,
how
much
they
should
cost.
A
We
we
took
a
big
part
of
our
node,
which
is
runtime
and
roxdb,
and
virtual
machine
and
we're
running
it
on
the
cpu
emulator
qmu,
and
I
told
you
we
also
removed
a
bunch
of
the
sources
of
non-determinism,
and
so
now
we
just
count
the
actual
cpu
instructions
that
our
node
takes
to
execute
those
various
separations,
and
we
were
able
to
achieve
precision
and
represent
reproducibility
for
most
of
the
fees
to
be
within
five
percent
and
for
a
couple
of
fees
that
are
specifically
involved
with
io.
It's
within
10
15.
A
Precision,
which
I
think
is
a
is
a
good
result.
I
mean
estimating
diffuse,
is
still
very
difficult.
Well,
first
of
all,
something
that
we
haven't
addressed
yet
is
that
different
cpu
operations
obviously
have
different
complexity
and
different
execution
time.
We
do
treat
them
the
same
right
now.
We
run
lots
of
files
and
to
make
sure
we
are
not
abusable
in
this
way
that
someone
cannot
really
easily
construct
a
contract
that
abuses
certain
cpu
operation
and
also
iu
operations,
are
really
difficult
to
benchmark
and
assign
the
fees
to
it.
A
It's
a
well
known
that
benchmarks
for
ssds
are
especially
tricky.
So
we
don't
even
try
to
write
our
own
ssd
benchmark.
We
use
third-party
benchmarks
to
estimate
it,
and
finally,
I
mean
just
running
things
in
emulator
is
extremely
slow
and
we
do
want
to
run
stuff
for
many
iterations,
even
inside
emulator.
For
several
reasons.
One
of
it
is
just
to
reduce
the
volatility
in
case
we
forgot.
You
know
some
of
them
randomly
seated
hash
maps
and
stuff
like
that,
but
another
one
is
to
catch
the
corner
cases.
A
A
Is
they
inject
a
global
variable
that
they
modify
without
crossing
the
host
guest
boundary
and
they
just
modified
on
every
wasn't
block
and
they
do
this
injection
in
the
middleware.
So
we
we
took
the
same
approach.
We
just
modified
pivaz
materials
in
our
fork
to
do
this
kind
of
instrumentation,
so
anyone
any
blockchain
that
uses
wasm,
you
guys
are
welcome
to
use
this
modify
and
pivazo
motels.
A
Unfortunately,
gas
injector
design
does
leak
into
the
protocol
spec,
not
something
that
we
wanted
to
have,
and
this
is
because,
when
you
inject
a
different
amount
of
assembly
code
into
your
webassembly
smart
contract,
now
your
contract
might
run
out
of
memory
earlier
or
later
or
like
might
might
hit
the
stack
size
limit
earlier
or
later.
So
it
does
kind
of
leak
into
the
protocol
spec,
which
is
quite
unfortunate.
A
We
haven't
figured
out
what
to
do
with
it
yet,
and
but
the
good
news
is
that
you
can
actually
write
a
very
suboptimal
gas
injectors,
at
least
at
near.
We
don't
do
gas
injection
on
upon
the
contract
execution.
We
do
it
upon
the
contract
deployment
and
the
contract.
Compilation
and
contract
deployment
is
already
quite
expensive.
So
you
can
run
a
very
simple
and
suboptimal
gas
injection
there
and
not
don't
don't
worry
too
much
about
its
performance
yeah.
A
A
Memory
management
like
assembly,
script
and
grain
is
that
you
can
actually
just
turn
off
their
garbage
collection,
because
the
contracts,
as
I
said,
are
short-lived
and
we
can
totally
afford
allowing
them
using
mini
megabytes
of
memory
if
they
need
to
without
delocating
it.
So
that's
an
upside
of
using
languages
like
that.
A
And
actually,
we
haven't
made
our
mind
whether
we're
going
to
support
a
garbage
collection
on
a
protocol
level.
Yet
because
I
mean
garbage
collection
is
coming
to
the
web
assembly
spec.
So
we
have
an
opportunity
to
support
a
garbage
collection
on
a
particular
level,
but
we
haven't
made
our
mind
yet
about
it.
A
We
had
to
do
lots
of
sdk
site
optimizations,
because
people
writing
contracts
are
near.
They
want
their
contracts
to
be
smaller
in
size,
because
that
means
the
fees
are
going
to
be
smaller
for
compiling
such
contracts
or
for
executing
such
contracts.
Technically,
it
is
possible
to
run
extremely
tiny
contracts
on
near.
A
So
you
want
to
sometimes
dive
into
the
std
implementation
and
make
sure
that
when
you
compile
to
webassembly
you're
compiling
exactly
what
you
want
to
compile,
because
it
can
be
complete
different
code
and
the
other
interesting
thing
is
that
we
don't
actually
use
all
these
cool
tools
that
web
assembly
ecosystem
has
for
optimizing.
The
web
assembly,
like
wasm,
opt
and
wasn't
snip,
and
mostly
because
we
don't
want
our
developers
to
shoot
themselves
in
the
foot.
A
A
A
A
So
it
means
you
can
write
in
some
cases
highly
optimized
contracts
with
with
assembly
script
in
green.
The
disadvantages,
of
course
of
these
languages
is
that
they
have,
they
still
have
small
community.
That
means
you
have
very
few
libraries,
and
it's
still
the
case
that
when
you
want
to
write
a
smart
contract,
an
assembly
script,
you
need
to
import
assembly
script.
Library
like
you,
cannot
at
least
not
on
near.
You
cannot
import
a
library
written
in
another
language
in
compiled
web
assembly.
A
Yet
we
haven't
enabled
this
a
possibility
yet
and
also
they
haven't
been
battle
proven.
Unlike
rust,
you
know
that
large
companies
like
google
and
mozilla
are
using
for
their
browser
development
assembly,
script
and
grain
haven't
been
battle
proven,
so
we
just
don't
advise
our
defy
projects
on
using
them.
Yet.
A
A
Finally,
I
wanted
to
tell
you
how
we're
planning
to
test
these
contracts,
so
we
do
have
already
quite
a
few
tests
and
frameworks
that
peop
that
various
projects
used
to
test
web
assembly
contracts
on
nir.
But
we,
we
came
up
with
this
cool
idea
of
having
a
unifying
unified
testing
approach
to
any
kind
of
contracts
that
people
are
deploying
on
your
blockchain,
and
this
is
achieved
by
basically
test
and
web
assembly.
A
Assembly
contracts
like
there
were
live
contracts,
so
you
would
take.
You
would
take
a
test
test
and
you
would
compile
it
together
with
the
contract
in
such
a
way
that
the
tests
themselves
are
basically
your
contract
cost
functions.
Then
you
would
deploy
this
stuff
to
to
your
node
and
then
you
would
interact
with
with
test
as
if
there
was
contract
functions
which
allow
you
to
unify
lots
of
the
experience
around
the
run
and
the
contra
code
and
make
your
testing
experience
as
close
to
production
to
production
as
possible.
A
So
your
code
and
test
is
going
to
be
highly
reproducible
in
production
too.
So
that
was
it.
That
was
not
a
very
long
presentation,
but
if
you
have
any
kind
of
interest
in
wasm
languages,
if
you
like,
not
just
grain
and
zig,
but
there
are
other
languages
that
you
like
and
you
want
and
you
want
them
and
you
want
to
build
an
sdk
for
them
or
you
like
some
web
assembly,
virtual
machine,
a
compiler,
please
write
us
and
we
might
give
you
a
grant
to
work
on
it.
B
A
Well,
so
nier
is
a,
I
mean,
developer
focus
blockchain,
so
we
want
people
coming
to
near
to
have
zero
barrier
when
they
develop
on
us,
and
you
know,
people
have
developers
have
all
kind
of
backgrounds.
Some
people
used
to
work
mostly
with
c
plus,
plus
some
people
used
to
work
with
python.
So
we
don't
want
to
force
them
to
use
rust.
We
want
them
to
be
able
to
come
to
near
and
just
find
whatever
language
they've
been
using
all
their
life
as
a
language
that
we
support
and
start
developing
on
it.
A
B
A
So
this
is
something
that's
been
working
from
from
the
start.
So
right
now
we
have
a
single
chart,
but
in
test
environment
we
run
in
like
eight
shards
and
we're
gonna
roll
out
eight
shards
very
soon
in
the
next
couple
of
months.
So
this
is
not
something
that
we
add
later.
This
has
been
already
built
in
from
the
start.
A
When
people
develop
smart
contracts
on
near,
they
don't
even
think
which
chart
the
smart
contract
is
running
on.
This
is
very
similar
to
how
you
write.
Javascript
programs
like
when
you
write
javascript
program
and
use
promises.
You
don't
think
which
cpu
core
is
running,
which
part
of
your
javascript
program
right
now.
You
just
you
know,
use
promises
and
it
somehow
gets
executed
behind
the
scenes.
A
You
don't
even
know
either
right
on
the
same
chart
or
are
they
running
on
different
charts,
and
there
is
like
no
incentive
in
here
to
collocate
to
collocate
contracts
on
the
same
chart.
We
don't
want
to
have
any
kind
of
perverse
incentive
for
people
to
try
to
fight
and
and
co-host
on
the
same
chart
with
some
exchange
or
something
like
that.
A
It's
all
exactly
the
same,
exactly
the
same
fees,
exactly
the
same
finality
time
for
cross-contract
interactions
when
they
talk
either
within
the
same
chart
or
across
different
charts
and
actually
in
a
in
a
year
or
two
we're
going
to
enable
dynamic
resharding.
That
is
going
to
be
rebalancing
our
shards
to
be
of
the
same
size,
and
in
that
case,
even
if
you're
on
the
same
chart
with
some
contract
right
now
in
the
next
hour.
It
might
change
and
it
might
be
resharded
and
you
might
end
up
on
different
shards.