►
From YouTube: Sam Williams, Arweave – SmartWeave
Description
Speaker: Sam Williams, founder & CEO at Arweave
Topic: SmartWeave: Exploring The effects of Lazy Evaluation on JS+WASM Contract Execution
Arweave https://www.arweave.org/
Wasm in Web3 workshop https://avive.github.io/wasm_on_the_blockchain_2021/#/
A
Okay,
now
people
can
see
my
screen
great.
Yes,
the
trade-offs
you
make
by
taking
this
approach
and
also
how
wasm
and
other
similar
execution
environments
fit
into
this.
I
guess
version
of
the
smart
contract
stack,
so
lazy
evaluation
is
a
concept
that
comes
from
functional
programming,
originally
basically
in
the
functional
programming
world.
What
it
means
is
simply
only
executing
the
code
that
is
required
to
gain
a
result
at
the
last
possible
moment.
So
I
think
the
most
well-known
example
of
this
is
in
a
programming
language
called
haskell.
A
A
This
will
get
to
a
result,
because
it's
building
up
this
kind
of
call
stack
and
then
it's
only
would
you
say,
executing
the
sub
components
when
it
needs
to
at
the
last
possible
second,
rather
than
in
you
know,
sort
of
a
more
traditional
programming
environment.
If
you
ask
the
computer
to
generate
for
you
an
infinite
list,
well,
obviously,
it's
never
going
to
terminate.
So
this
is
a
model.
That's
well
used
in
functional
programming.
It's
I
wouldn't
say
the
the
dominant
model,
but
it
is
like
not
that
uncommon.
A
Obviously,
in
the
smart
contract
world
I
mean
something
slightly
different
right,
so
in
smart
contracts,
we're
used
to
the
idea
being
that
we
should
have
consensus
in
typically
a
blockchain
networking,
also
exclusively
in
a
blockchain
network,
about
the
state
of
the
smart
contract.
Well,
if
we
apply
the
kind
of
lessons
of
lazy
evaluation
to
that
system,
we
can
say
instead
well
actually,
why
don't?
We
simply
come
to
consensus
about
the
contract
source,
the
initial
state
and
then
the
state
inputs,
so
the
interactions
with
that
contract.
A
Why
don't
we
come
to
consensus
about
that
and
only
lazily
come
to
consensus
or
even
lazily
calculate
the
actual
state
of
the
contract,
and
so
obviously
this?
This
is
something
that
we
were
thinking
about
when
thinking
along.
You
know
what
are
the
different
models
that
we
could
use
for
smart
contracts
on
top
of
our
weave,
because
our
weave
is
a
permanent
information
storage
system.
A
So
it
focuses
on
having
endowment
backed
data
storage,
which
just
never
forgets
stuff
right,
so
the
base
layer,
really
all
it
cares
about-
is
yeah
storing
data,
and
so,
if
you
want
to
build
a
smart
contracting
model
on
top
of
that,
the
kind
of
natural
conclusion
you
get
to
it's
something
around
lazy
evaluation,
and
then
it
turns
out
when
you,
when
you
look
into
it.
It
has
like
this
whole
bunch
of
really
interesting
and
exciting
properties.
So
we
could
say
that
essentially,
the
model
here
is
simply
leave
execution
to
the
client
right.
A
So
come
to
consensus
about
all
of
the
inputs.
What
the
initial
state
is,
what
the
contract
is
and
then
everything
else
we
just
move
to
not
off
chain
in
the
traditional
sense
of
you
know:
there'll
be
some
layer,
two
network,
necessarily,
although
you
you
can
do
that
for
the
execution
itself,
but
actually
you
could
just
push
it
to
the
clients.
A
So
this
has
a
bunch
of
interesting
effects
that
I
think
the
primary
one
of
which
is
you
can
now
let
the
virtual
machine
that
will
be
used
by
a
smart
contract
be
a
decision
for
the
developer,
so
in
in
the
first,
the
first
iteration
of
smartweave,
we
supported
literally
raw
javascript
and
then,
of
course,
on
top
of
that
you
can
have
wasm
loaded
in
that
javascript,
environment
or
obviously
evm
or
even
beam.
Someone
built
a
version
of
this
model.
A
It's
actually
not
smart
view
if
it
is
built
on
top
of
our
weave
that
uses
the
abstract
machine
found
inside
erlang.
If
you're
aware
of
that
programming
language,
but
you
could
do
it,
you
know
you
could
very
easily
see
this
working
with
jvm
and
so
on
without
modification.
That's
the
kind
of
strange
part
of
all
of
this,
because
we're
pushing
the
execution
to
users,
and
so
the
trust
no
longer
stands
between
developer
node
operator
and
user.
So
in
a
traditional
blockchain
network
we
think
of
yeah.
A
The
programs
have
to
be
very
well
locked
down
because
the
the
node
operators
that
are
going
to
come
to
consensus
in
the
system
are
going
to
have
to
execute
code
written
by
the
developer.
So
obviously
that
code
has
to
be
safe
right
and
then,
of
course,
the
user
is
going
to
come
along
and
they're
going
to
try
and
access
that
state
or
in
in
in
some
networks
they
they
actually
do
the
computation
themselves.
But
it's
you
know
kind
of
varies
from
stack
to
stack,
but
the
basic
principle
is
you've
got.
A
This
kind
of
node
operator
has
to
trust
every
single
developer
in
the
ecosystem
and
the
user
also
trusts
the
developer.
That
is
the
security
model.
Essentially.
Well,
if
you
push
execution
to
the
client,
you
have
a
security
model,
that's
much
closer
to
something
you
would
find
in
a
traditional
operating
system.
So
when
I
go
to
the
web,
I
download
a
piece
of
software
onto
my
hard
drive
and
then
I
run
it
locally
right
and
there's
a
sort
of
implicit
trust
that
the
developer
is
not
going
to
screw
up
my
machine.
A
So
now
the
the
trust
relationship
is
just
developer
and
user,
but
we
can
apply
exactly
that
same
thing,
but
to
smart
contracts
and
subsequently
yeah
you.
You
can
essentially
let
that
smart
contract
do
really
really
powerful
and
potentially
unsafe
things.
So
there
are
many
smart
contracts
in
your
ecosystem
that
will,
when
you're,
trying
to
compute
them,
for
example,
write
to
your
hard
drive-
or
you
know-
do
other
really
really
frankly
crazy
things
in
a
traditional
smart
contract
environment.
A
So
I
think
that
at
least
in
the
smartweave
model,
what
we've
done
is
we've
said:
okay.
Well,
this
is
a
pretty
powerful
and
interesting
possibility
and,
if
used
in
the
right
way,
can
allow
you
to
do
lots
of
really
cool
things.
What
we'll
do
is
we'll
make
all
of
that
power
available
to
the
user
and
then
have
this
sort
of
yeah
we'll
use
frameworks
to
make
things
safer
to
write
smart
contracts
inside
further
down
the
the
stack.
A
So
another
really
interesting
thing
that
this
enables
is
unmetered
compute,
because
of
course
you
know
traditional
blockchain
network,
you
can't
just
let
your
functions
or
you
can't
just
let
your
contract
implications
run
for
arbitrary
amounts
of
time,
because
you,
you
know,
you've
got
things
to
do
right.
You've
got
to
come
to
consensus
about
the
output
of
that
compute,
whereas
of
course,
in
the
in
the
model
described
here.
We
don't
do
that.
We
push
that
to
the
users,
and
so
actually
you
can
you
know,
and
the
user
is
saying
basically
well.
Okay.
A
If
I
want
to
interact
with
the
smart
contract
enough,
I
will
wait
for
it
to
come,
wait
for
it
to
compute
yeah,
and
so
you
can
push
that
cost
and
also
the
danger
of
you
know:
infinite
loops,
all
sorts
of
other
errors
to
the
user
and
again
this
comes
down
to
this
different
trust
model
right.
So
now
you
just
have
well.
If
the
user
doesn't
want
to
run
it,
then
they
won't
or
if
the
the
code
sucks,
then
the
user
won't
like
the
developer
anymore
and
then
move
on
and
do
something
else.
A
A
Another
interesting
thing:
this
is
a
bit
more
smart
view
specific,
is
that
they
can
ingest
arbitrary
amounts
of
data.
So
you
can
you
can
ask
the
r-weave
network
hey,
please
go
get
me
this
data
and
then
you
can
process
it,
which
is
yeah
really
wild.
I
mean
we
have
people
running
smart
contracts
that
have
got
gigabytes
and
gigabytes
of
data
ingested
into
them,
which
of
course
you
could
just
never
do
in
a
you
know
typical
evm
model,
smart
contracting
system.
A
Can
you
can
just
go
and
you
can
transfer
that
property
of
doing
arbitrary
amounts
of
compute
if
you
want
into
this
safer
environment,
so
there's
kind
of
safety
in
multiple
axes
here,
there's
the
safety
of
hey?
Is
it
going
to
go?
You
know,
do
http
requests,
or
is
it
going
to
touch
my
hard
drive
that
kind
of
safety
and
there's
on
the
other
side?
Hey?
Is
it
actually
going
to
terminate?
A
I
should
I
should
mention
if
this
wasn't
clear
by
now.
Obviously,
if
someone
inserts
a
an
invalid
transaction
execution
into
the
flow
for
a
contract,
you
you
simply
ignore
it
right.
So
the
stack
is
you
know
you
take
that
initial
state.
You
take
each
of
the
interactions
with
the
contract.
You
just
run
them
in
turn
and
you
throw
out
anything
that
doesn't,
you
know,
doesn't
compute
and,
of
course
the
the
program
should
make
sure
that
the
user
can't
arbitrarily
cause
an
infinite
loop
or
something
like
that.
A
So
anyway,
yeah
we,
we
have
this
kind
of
multiple
multi-axis
view
of
of
safety,
where
something
like
the
emazing
work
which
is
meted
is,
is
pretty
interesting,
but
we
don't
necessarily
need
it
like
you
can.
You
can
have
different
trade-offs
if
you
want
to
so
another
big
trade-off
is,
of
course,
the
the
time
complexity
of
calculating
or
getting
rather,
the
state
of
a
contract
on
a
client
is
is
bigger
transactions,
and
this
goes
linearly
with
the
number
of
interactions
we
have
right.
A
The
solution
to
this
is
compute
engines,
so
this
kind
of
throws
it
back
to
a
different
model
back
to
a
kind
of
compute
system,
but
I
mean
for
a
start,
this
might
not
be
a
problem
for
some
use
cases.
So
we
see
a
lot
of
atomically
associated
nfts
on
our
weave,
we're
like
who
cares?
I
mean
how
many
interactions
are
you
actually
gonna
have
maybe
like
20
over
10
years,
something
like
that
yeah.
It's
really
not
that
big
a
deal,
so
you
know
just
don't
don't
be
concerned
about
it.
A
Basically,
that's
that's.
Definitely
a
viable
option
for
for
some
smart
contracts,
but
also
some
other
smart
contracts
where
you're
doing
things
like
you
know,
one
that
we're
very
interested
in
is
putting
gpt
neo
inside
the
smart
contracting
system
and
having
it
execute
yeah
using
that
kind
of
amount
of
compute.
It's
not
clear
that
you're
you'll
want
the
same
compute
engine
as
someone
that
you
know
wants
to
wants
to
truncate
state
access
for,
for
example,
I
don't
know
a
dex
right
so
anyway,
a
compute
engine.
A
In
this
context
as
we
define
it,
is
something
that
allows
you
to
cache
the
state
one
way
or
another.
You
know
there's
there's
numerous
models
for
this,
and
I
think
this
is
one
of
the
exciting
things
about
this.
This
architecture
for
a
smart
contract
system
is
that
you
can.
You
can
essentially
swap
out
a
bunch
of
the
different
components
so
the
base
there
you've
got
some
sort
of
system.
That's
getting
for
you.
A
You
know
that
initial
contract
state
initial
source
code
and
the
the
list
of
interactions
in
a
row
for
you
to
apply,
but
that's
basically
it.
That
is,
if
you
want
like
the
motherboard
of
the
system
and
then
the
cpu
of
the
system
you
can
swap
out.
You
know
js
for
wasm.
You
can
swap
out
a
wasm
for
jvm.
If
you
really
want
to
yeah
there's
this
kind
of
flexibility
there
and
then
on
the
other
side
you
can.
A
Yes,
you
can
swap
out
what
these
like
yeah
there's,
there's
no
direct
analogy
for
this
in
the
in
the
physical
machine
world,
but
this
this
component
that
allows
you
to
catch.
I
guess
the
state
so
that
you
don't
have
to
execute
everything
each
time
obvious
worst
case.
Implementation
of
this
is
like
a
centralized
cache
right.
You
just
rent
state
access
from
someone
and
have
them
sign
it,
and
then
say
you
know
you
can
do
floor
proofs
and
stuff,
but
yeah.
That's
one
option.
A
A
That
basically
has
a
system
of
validators
and
archivers,
and
you
can
give
it
some
reasonably
constrained
code
and
you
say:
okay,
please
go
compute
for
me.
The
state
of
this
smart
contract
and
some
people
archive
the
state
of
one
person,
archives
of
state
and
everyone
else,
validates
they're
all
staked
in
the
system,
and
so,
if
the
archiver
believes
or
sorry
writes
a
state
to
the
chain
that
is
false,
then
everyone
else
can
slash
them.
A
And
then
you
essentially
start
a
sub
pool
inside
this
kind
of
system
for
storing
the
present
state
of
any
contract.
And
so
you
have
a
kind
of
dow
style
compute
on
top
of
the
base
smartweave
engine
and
the
interesting
thing
about
that
is
that
you
know
you
can
still
have
it
basically
do
whatever
kind
of
compute
you
want.
A
As
long
as
the
pool
operators,
you
know
are
willing
to
take
the
risk
to
execute
your
contract
for
you,
and
you
also
provide
sufficient
tokens
to
to
get
that
that
compute
done
so
there's
a
ton
of
different
ways.
You
can
you
can
solve
this
problem
if
you
even
need
to
solve
it
at
all,
but
that
is,
I
would
say,
the
main
trade-off
of
this
architecture.
A
A
Every
single
day
it
ingests
gigabytes
of
logs,
which
for
start
for
a
smart
contract,
is
really
really
crazy.
You
just
couldn't
do
this
inside
any
other
model.
I
don't
think,
and
it
also
even
performs
http
calls
directly
from
inside
this
contract.
This
is
yeah
one
way
of
thinking
about
it.
Is
it's
insanely
unsafe?
It's
also
a
question
of
well.
Actually,
how
are
you
doing?
Those
http
calls.
A
A
Then
you
know
just
saying
http
getgoogle.com
or
whatever
it
is,
but
you
could
theoretically
do
that
if
you
wanted
to
so
you
have
it
doing
basically
arbitrary,
massive
compute
on
arbitrary
inputs
of
data,
and
it's
doing
http
calls
on
those
cuban
just
really
really
wild
stuff
that
you
know
for
a
smart
contracting
system.
It's
been
running,
live
in
production
for
six
months,
so
this
is
a
model
that
really
works,
there's
actually
an
ecosystem.
A
You
know
like
hundreds
of
applications
now
on
top
of
the
smartweave,
and
it's
not
very
well
known
in
the
crypto
space,
but
it
exists
yeah,
and
so
thank
you
everyone
for
for
watching.
I
hope
this
gives
you
some
kind
of
ideas
about
well,
hopefully
how
you
can
apply
the
wasm
vm
work
to
your
own
smart
contract
chains
in
slightly
different
way,
making
different
tradeoffs,
because
I
think
basically
what
we've
outlined
here
is
well.
You
can
just
take
stock
wasm
if
you
want
like
no
one's.
This
model
is
perfectly
aligned
with
that.
A
Although
you
have
to
make
these
different
trade-offs
around
like
okay,
well,
how
the
compute
engine
is
going
to
work,
then
how
is
the
trust
model
going
to
be
between
node
operators
and
so
on,
and
indeed
you
could
swap
out
wasm
or
js
with
whatever
virtual
machine
you
want,
but
I
think
that
this
is
an
interesting
model
to
pursue
for
sure
anyway.
So
I
hope
that
was
interesting
yeah.
Let
me
know
if
there
are
any
questions.