►
From YouTube: SFBW19 - VM Design: The EVM Isn't the Only Game in Town
Description
SFBW19 - VM Design: The EVM Isn't the Only Game in Town
Panelists:
Zaki Manian, Tendermint
Mark Miller, Agoric
Daryl Hok, CertiK
Jan Xie, Nervos
San Francisco Blockchain Week: https://sfblockchainweek.io/
A
So
what
we're
gonna
talk
about
today
is
like
the
world
of
smart
contract,
vm's,
smart
contract
platforms,
how
development
on
top
of
programmable
blockchains
sort
of
goes
mainstream.
We
have
three
excellent
guests
who
have
some
of
whom
have
been
doing
groundbreaking
work
in
this
section.
So
maybe
just
a
quick
introduction
who
you
are,
what
you've
been
doing
in
this
space
and
maybe
like
30
seconds
about
like
what
is
the
development
environment
that
you
guys
are
trying
to
bring
to
market.
B
My
name
is
Mark
Miller
I've
been
working
on
smart
contracts
since
1988
I'm,
chief
scientist
of
a
goreck
and
having
done
a
lot
of
research
exploration
on
languages
and
virtual
machines
for
doing
smart
contracts.
Well,
I
joined
the
ECMO
script
committee.
The
committee
that
standardizes
the
JavaScript
language
in
2007
and
I've
gotten
the
enablers
into
JavaScript
for
using
it
as
a
good,
secure,
smart
contracting
language,
which
is
what
the
Agora
platform
is
doing.
C
Hi
everyone
I'm
Jen
from
Novo's
I
joined
blockchain
space
in
2012
around
that
time
and
I
was
in
the
research
team
working
on
Casper,
sharding
and
I
I
also
built
permission
blockchain
before,
and
what
we
are
building
now
is
a
permissionless
blockchain.
That
is,
has
a
similar
architecture
to
Bitcoin
and
what
what
what
we
have
on
this
new
blockchain
is
what
we
call
ckb
VM.
It's
a
low-level
virtual
machine
and
yeah.
We
want
to
bring
something
new
here:
hi.
D
I'm
Daryl
Hawk
CEO
of
Surak.
We
are
focused
on
certified
software,
so
our
founders
are
both
professors.
The
Yale
computer
science
department
chair
as
well
as
a
professor
at
Columbia
University.
They
focus
on
making
formally
verified
software,
so
compilation
throughout
the
entire
stack
is
exactly
what's
supposed
to
do
and
doesn't
do
anything
more
than
that.
A
So
I
guess
so
you
know
of
our
panelists
two
of
you
have
chosen
to
sort
of
either
push
sort
of
your
existing
ideas
into
the
into
the
world
of
blockchains.
As
my
contracts
or
a
new
virtual
machine
into
the
world
of
blockchains
in
smart
contracts
and
I.
Think
our
friends
at
Zurich
are
sort
of
trying
to
see
how
far
you
can
go
with
things
that
are
related
to
like
the
EVM,
the
EVM,
you
know,
I
think
has
sort
of.
We
could
talk
a
little
bit
about
its
flaws,
but
it
also
has
been
you
know.
A
Hundreds
of
millions
of
dollars,
potentially
of
of
work,
have
gone
into
developer,
tooling,
infrastructure,
educating
community
of
people
around
how
it
works
so
I'm,
just
curious
to
the
panelists.
Why
do
you
think
it's
important
to
either
create
an
alternative
to
the
EVM
and
or
like?
Why
would
you
defend
sort
of
working
continuing
to
work
on
the
EVM,
especially
in
the
world
where
the
etherium
foundation
has
mostly
abandoned
EVM
in
their
current
roadmap?
So.
B
There's
two
aspects
of
the
EVM
there's
the
one
that
most
people
are
drawn
to
trying
to
fix,
and
there
is
the
actual
deep
problem.
What
most
people
are
drawn
to
trying
to
fix
is
having
a
better
virtual
machine
for
doing
computation
and
for
being
a
target
of
compilation
for
languages.
So,
for
example,
the
etherium
foundation
themselves
is
already
moving
from
EVM
to
e
wazzle,
where
wasm
webassembly
is
a
decent
virtual
machine
design
for
running
computation
and
for
being
the
target
of
compilation.
B
It's
very
much.
A
von
von
Lohmann
address
space
style
virtual
machine.
So
that's
the
easy
problem
is,
is
just
having
a
better
platform
for
computation
the
hard
problem,
the
essential
problem,
the
deep
problem
that
everybody
should
ask.
First,
when
looking
at
any
computational
smart
contracting
platform
is
what
is
the
semantics
of
the
enforcement
mechanism
that
stands
between
smart
contracts
that
are
mutually
suspicious
of
each
other.
B
The
semantics
of
the
enforcement
mechanism
is
the
semantics
of
the
security
primitives
that
all
of
your
inter
contract
interaction
depends
on
and
therefore
the
security
of
that
interaction
and
Eve
as
'm
preserves.
The
fundamental
flaw
of
the
EVM,
which
is
anyone,
can
send
a
message
to
any
contract
and
therefore,
when
the
contract
receives
the
message,
it
has
to
do
some
kind
of
access
check
to
decide
how
to
regard
the
message
that's
received
and
the
etherium
method
to
do.
B
The
access
check
is,
what's
known
as
message
sender:
it's
an
identity
based
access
check
on
the
identity
of
the
immediately
sending
process.
This
brings
us
to
identity,
based
access,
control
and
there's
a
whole
long,
literature
of
the
weaknesses
and
flaws
of
identity
based
access
control,
the
confused
deputy
problems,
the
inability
to
reason,
compositionally
about
correctness,
etc.
B
C
Yeah
I
totally
agree
with
that,
and
fortunately
what
we
are
trying
to
build
is
a
general
verification
platform,
not
a
computation
platform,
so
yeah
I
think
it's
more
about
it
actually
is
not
only
about
virtual
machine.
It's
about
the
runtime
model,
the
execution
model
of
smart
contract.
What
you
are
talking
about
that
the
massive
change
between
massive
exchange
between
smart,
conscious,
I
think
that's
a
yeah.
That's
a
problem
too
security,
so
I
I
want
to.
C
C
It's
actually
not
that
difficult
to
create
a
new
virtual
machine
if
you
can
adopt
some
existing
standards
right.
That's
why
we
chose
risk
5,
which
is
a
open
standard
created
by
Berkeley
and
is
widely
adopted,
implemented
tested
in
the
industry,
and
it's
the
the
daily
that
the
compilers
we
use
every
day
already
support
risk
for
instruction
set
like
GCC
our
VM.
So
what
we?
D
Yeah
I
would
say
it's
I'm,
just
thinking
about
it,
it's
funny
cuz.
The
question
is
like
they're
different
implementations
of
the
same
thing,
but
we
all
do
agree
on
some
of
the
problems
that
exists.
Our
method
of
doing
this
is
really
to
look
at
blockchain
and
how
difficult
is
to
a
developer
community,
so
in
different
chains
and
reproduction
of
bootstrap
it
aetherium
has
a
big
community
itself.
So
our
method
for
the
virtual
machine
for
the
CVM,
the
Serta
commercial
machine,
is
to
superset
the
EVM
as
well
as
extended
to
more
things.
D
So
there
are
problems
still
in
terms
of
smart
contract
to
smart
contracts,
interacting.
If
the
price
point
is
high
enough,
then
one
smart
contract
could
cheat
another
one
and
just-
and
you
wouldn't
know
because
it's
a
machine
interacting
with
another
machine.
How
do
you
know
that
it's
a
safe
counterparty
so
in
our
virtual
machine?
We're
gonna
have
proofs
on
chain
so
before
interacting
with
something
you
could
actually
say.
Give
me
proof
of
certification
of
the
formal
verification
of
specs,
whatever
it
is
machine
check.
Will
proofs
and
then
interact?
D
So
it's
not
uncommon
in
real
life,
you
don't.
If
it's
a
website,
that's
a
little
bit
sketchy,
you
might
not
want
to
send
much
money
or
buy
many
things.
If
it
is
something
that's
BBB
certified
or
all
of
these
different
accolades,
then
you
may
be
more
secure.
So
we
want
to
do
that
on
chain
and
it's
gonna
be
similar
to
I,
guess,
layers
of
autonomous
vehicles
where
we
have
level
1
to
level
5.
That's
how
autonomous
you
are
in
terms
of
curity.
It
could
be
level
1
to
level
5
of
how
secure
you
are.
D
So
did
you
get
formally
verified
or
what's
just
audited
and
different
means,
but
have
the
evidence
on
chain?
Our
token
will
be
used
as
an
ecosystem
to
tax
those
that
are
less
secure,
so
your
fees
will
be
higher
if
you're
certified
your
fees
will
be
lower,
but
ultimately
it's
to
solve
the
same
problems,
whereas
blocks
chains
get
more
complex,
the
interactions
will
only
grow.
So
today
we
do
have
a
lot
of
defy
smart
contracts,
interacting
with
smart
contracts.
We
haven't
yet
seen
a
cheating,
smart
contract,
that's
very
large
in
scope.
D
Maybe
it's
waiting
for
the
other
price
wants
to
be
higher.
We
don't
really
know
but
our
approach.
The
problem
is
to
super
set
the
existing
ecosystem
so
get
bootstrap
that
and
make
it
so
we're
actually
built
on
tournament
and
cosmos.
Today
you
could
run
a
solidity
code:
smart
contract
on
cosmos,
using
our
test
net.
So
it's
you
don't
need
to
do
anything
different.
You
just
deploy
it
on
that
side.
It's
all
still
in
work.
D
So
it's
a
test
net
phase,
but
the
approach
is
to
expand
to
more
but
not
to
have
people
pick
and
choose,
but
really
to
work
with
as
many
as
possible.
So
if
move
VM
seems
to
take
off,
then
it's
pretty
self-explanatory
how
to
to
incorporate
that
as
well,
because
it's
not
that
much
different.
The
EVM
as
a
resource
allocation
by
our
intention
for
the
VM
is
to
limit
logic
within
the
VM
layer
and
be
more
enterprise-ready
like
you're.
D
A
So
I
guess
the
you
know:
I'm
gonna,
try
and
keep
this
like
balance
between
like
technical
and
product
aspects
of
smart
contract
languages
and
it's
bm's,
and
all
of
this
stuff
and
I
think
one
of
the
biggest
open
questions
that
I
think
young
sort
of
hinted
at
is.
Our
big
challenge
is:
how
do
we
get
our
community?
Be
that
much
larger?
We
like
haven't
even
filled
this
room
on
this
in
this
panel
we
aren't,
you
know
the
the
existing
smart
contract
developer
community
is
quite
small.
A
So
I'd,
like
some
comments
from
the
panelists,
says:
what
are
the
missing
pieces
that
need
to
be
filled
in
in
the
smart
contract
landscape
in
order
for
there
to
be
actual
mainstream
adoption
of
this
mode
of
development,
for
people
to
feel
excited,
comfortable,
safe,
doing
building
this
kind
of
software
and
what
so?
What
are
the
missing
pieces,
and
maybe
a
little
en
I've
been
thinking
a
lot
about
recently
is
what
are
the
components
of
a
standard
library
for
building
smart
contracts?
I
think
that
seems
to
be
like
one
of
the
missing
pieces.
B
B
This
issue
of
wide
scale
adoption
is
why,
having
explored
the
programming
language
issues
of
supporting
good,
intuitive,
reliable
expression
of
smart
contracts
in
my
own
research
language
named
e,
that
I
was
working
on
in
the
90s
through
the
early
2000s.
Why?
In
2000,
2007
I
joined
the
ACMA
script
committee
and
did
the
much
harder
social
and
standards
work
of
getting
the
enablers
that
I
knew
from
the
earlier
II
work
that
were
needed.
Getting
those
enablers
into
JavaScript
is
because
a
brand
new
language
that
was
specialized
for
smart
contracting
was
always
going
to
reach.
B
Only
a
tiny
audience
would
have
tremendous
barriers
to
adoption
if
I
can
get
the
enablers
into
JavaScript,
suddenly
there's
20
million
JavaScript
programmers
that
are
our
potential
audience
more
than
that.
The
security
model
that
we're
using
is
the
object
capability
model
and
the
object
capability
model,
as
opposed
to
the
identity
based
access
control
model,
is
first
of
all
a
technically
much
superior
model.
It
does
support
compositional
reasoning
about
correctness.
B
It
does
support
very
well
the
principle
of
least
Authority
for
partitioning
risk,
but
more
than
that,
with
regard
to
adoption,
it
is
intuitive
for
object-oriented
programmers
to
learn
because
the
intuitions
that
they
already
have
of
how
to
use
object-oriented
encapsulation
for
the
sake
of
modularity
and
abstraction,
for
the
sake
of
information,
hiding,
object,
capabilities,
start
off
as
treating
security
as
the
extreme
of
modularity
that
you
start
off.
Building
security
abstractions
with
an
extension
and
natural
extension
of
the
intuitions
that
object.
Programmers
already
have
about
how
to
build
abstractions.
B
So
that's
the
first
element
of
how
we're
trying
to
reach
a
mainstream
audience.
Another
one
is
that
our
platform
is
chain
independent
and
distributed
and
works
across
chain
across
chains
in
the
initially
we're
building
on
the
cosmos
platform,
we're
building
as
a
Kosmos
own.
We're
also
collaborating
with
cosmos
on
IBC
as
the
inter
blockchain
protocol
that
enables
contracts
on
one
chain
to
send
messages
to
contracts
on
another
chain.
That
means
that
the
mainstream.
Looking
at
the
potential
of
adoption
realizes
with
this
platform,
there
is
no
lock-in.
B
I
can
write
smart
for
this
platform
and,
if,
tomorrow,
somebody
invents
a
brand
new,
better
consensus
protocol
and
we
want
to
move
over
to
that
chain,
all
of
their
investments
in
building
contracts
for
our
platform
are
is
a
portable
investment.
So
we
believe
we're
hitting
all
of
the
high
points
in
getting
mainstream
adoption.
Yeah.
C
As
I
mentioned,
I
think
we
should
embrace
moe-moe
embrace
the
existing
open
standards
instead
of
like
trying
to
invent
some
new
virtual
machine
in
blockchain
space
because
I
think
yeah.
So
we
we
actually
did
a
lot
of
experiments
on
our
own
virtual
machine
like
we,
we
try
to
compile
Ruby
interpreter.
If
you
know
Ruby
right,
I
I
tried
to
compile
the
interpreter
to
respond
instructions
and
run
the
interpreter
in
our
virtual
machine.
So
our
developers
can
use
Ruby
to
write
the
smart
contract,
which
we
do
the
same
thing
for
JavaScript.
C
We
do
the
same
thing
for
typescript.
We
we
we
try
to
compile.
Web
sembly
code
goes
to
risk
for
instructions
and
wrong
typescript
virtual
machine,
and
we
got
success
so
I
think
it's
a
it's
actually
a
fast
way
to
to
the
larger
developer
community.
It's
a
shorter
path
to
the
larger
developer,
community
and
yeah
and
and
another
thing
I
think
we
should
also
spend
a
lot
of
time
on
is
tooling
I.
C
Think
a
lot
of
strands
from
a
theorem
is
is
truly
the
like
the
chavo,
the
all
kinds
of
frameworks
built
on
top
of
ethereum
those
things.
It's
those
things,
helped
develop
developers
to
develop
smart
country
more
easily
and,
in
some
sense,
I
think
solid.
That
is
also.
It
is
also
to
build
on
top
of
EVM,
because
Mazhar
sorry
that
you
can
only
handwrite
like
evm
bike,
oh
right
so
I
think
truly
is
very
important.
Yeah.
So.
C
I,
think
they
this
this
system
developer
community
is
overlooked
in
at
this
time,
so
yeah.
So
our
strategy
knows
we
are
trying
to
attract
those
system
developers
to
attract
them
to
build
like
compilers
and
cryptography
libraries
on
top
of
our
virtual
machine.
So
it's
kind
of
different
from
like
beautification
directly
on
our
virtual
machine
I.
Think
it's
yeah,
we
will
say
I.
We
will
we
we
just
started
yet
so
I,
don't
know
how
we'll
develop,
but
yeah.
We
will
see
all
right.
A
D
Yeah
yeah
I
would
say
in
terms
of
adoption
two
things
kind
of
mine
of
the
problem,
so
one
is
the
number
of
developers
and
another
is
when
they
are
developers
which
camp
are
they
a
part
of
so
the
number
of
developers
I,
think
that
is
kind
of
a
chicken
or
egg.
In
some
ways
it's
a
really
bootstrap
a
bunch
of
developers.
Enterprises
that
want
to
develop
on
this
will
force
all
their
employees
to
be
developing.
In
that
sense,
they
may
be
waiting
for
different
things,
so
may
be
waiting
for
security,
which
is
hypothesis.
D
Scalability
is
another
hypothesis.
Maybe
it's
all
these
different
things,
use
cases
or
just
proof
of
concepts,
maybe
they're
happening
today
and
then,
when
there
are
developers
now
which
camp
the
camp
problem
I
think
the
way
we
see
it
is
stay
in
your
camp
that
you
decide
because
as
a
developer,
maybe
disrupt.
A
D
The
term
camp
campus
and
like
do
you
choose
to
do
one
language
like
let's
say
EVM
versus
something
else
in
non-interoperable
groups,
so
like
having
them
focus
on
just
this
and
you're.
Seeing
a
lot
of
combative
approaches
on
the
protocol
levels
so
like
I,
am
pro
whatever
protocol.
That
means
that
these
other
protocols
are
not
good
and
so
having
that
I,
don't
think
is
conducive
to
growth
of
the
space
now
having
the
ability
to
work
across
them.
D
More
interoperable
I
think
that
will
help
bootstrap
when
you
do
have
a
number
of
developers
that
they
could
continue
to
code
in
their
preferences,
yet
still
contribute
to
the
broader
ecosystem.
And
so
that's
why
our
approach
is
kind
of
very
similar.
The
compiler
approach
is
the
way
we
do
it
where
we
have
our
own
functional
language
called
deep
sea.
D
B
Which
is
the
framework
issue
yeah
in
the
early
web,
people
would
program
directly
to
the
Dom
API.
In
early
no
js'
nodejs
was
kind
of
a
bare-bones
platform
we
had
to
to
roll
your
own
complex
server
software.
These
days,
javascript
programmers
are
used
to
programming
in
rich
frameworks
which
have
a
lot
of
prefab
components
in
them
and
have
good
systems
for
composing
components.
B
B
You
know
covered
calls
various
other
options:
different
kinds
of
auction
institutions,
all
sitting
on
top
of
zoe,
which
Dean
explained
in
the
previous
talk.
That
gives
you
a
good
partitioning
of
risk
so
that
you
have
you
can
make
strong
statements
about
what's
not
at
risk,
even
though
some
of
your
software
has
flaws
in
it.
The
fact
that
object
capabilities,
support,
compositional
reasoning
about
correctness,
we're
raising
that
up
through
a
RTP
and
Zoe
compositional,
to
being
able
to
enable
people
to
take
these
components
and
compose
them
with
confidence.
B
Most
contracts
will
be
compositions
of
reliable
components
combined
with
parameterization
as
and
but
we
also
support
the
creation
of
reliable
new
smart
contracts
within
the
framework.
So
we
really
see
this
as
very
much
an
extension
of
what
JavaScript
application
developers
already
experience
of
rich
frameworks
for
other
domains.
Smart
contracting
needs
such
a
rich
framework,
so.
A
Do
you
guys
see
KVM
side
and
the
saertex
side?
Where
do
you
think
those
sorts
of
frameworks
are
going
to
come
from
I?
Think
it's
implicit
like
on
this,
he
gave
am
side
is
perhaps
it's
gonna
come
from
the
systems
developers
perhaps
yeah
is
that
is
that
that's
the
bet
that
you,
you
provide
a
VM.
It
tracks
the
system's
about
the
system.
Bell
words
built
the
frameworks,
and
that
is
what
attracts
the
application
developers
yeah.
C
I
think
what
we,
what
we
provides,
is
not
just
a
VM.
We,
we
provided
a
VM
which
adopts
a
open
standards,
so
you
can
use
your
existing
experience
on
our
block.
Chair
right,
I
think
that's
a
a
good
thing
for
those
system
developers
and
we
also
make
our
virtual
machine
very
abstract.
To
allow
system
develops
to
do
all
kinds
of
stuff.
C
You
can
do
that
on,
say:
KB
you!
You
can
do
that
on
in
ckb
VM.
You
just
need
to
find
some
system
developer.
Ask
them
to
help
you
to
deal
to
develop
this
new
crypto,
primitive
and
deploy
it
on
blockchain,
and
then
you
can
use
it.
You
don't
need
to
wait
like
the
blockchain
too
hard
for
to
add
a
new
crypto,
primitive
or
pre,
compile
into
the
virtual
machine.
I.
Think
yeah.
A
Well,
okay,
I
just
wanna,
like
kind
of
zoom
in
on
the
question
a
little
bit
more.
Like
you
know,
in
existing
software
development
we
don't
view
an
auction
or
a
market
maker
or
any
sort
of
economic
component
as
pre-existing
as
like.
It's
not
a
thing.
You
pull,
you
don't
download
a
market
maker
from
NPM
when
you're
building
a
website,
but
that
perhaps
is
the
story
for
how
we
do
it
in
smart
contracts
and
to
the
extent
that
I'm,
aware
of
existing
code
design
patterns,
etc.
A
There
really
only
exists
basically,
the
cosmos
SDK,
the
EVM
ecosystem
and
the
gorak
ecosystem.
That
has
those
pieces,
so
I
think
like
what
this
is
like
I
guess
what
I?
What
I'd
like
to
really
get
at
is
is
this.
Is
that
the
the
wedge
that
gets
you
to
mainstream
adoption
or
not
and
take
a
shot
at
at
first
on
the
CK,
VM
side
or
I
got
assertive
side
yeah.
D
So
I
actually
I
do
think
you
need,
like
the
training
wheels
or
especially
for
something
that's
new.
You
need
people
to
just
figure
out.
This
is
a
template.
That's
how
I
do
it.
These
are
the
the
best
practices.
Otherwise
you
run
into
a
lot
of
people
doing
new
things
for
the
first
time
that
could
be
detrimental
in
her
make
the
entire
space
move
backward,
especially
when
you
have
things
that
are
high-risk,
like
like,
let's
say
an
enterprise
where
it
exists
today
it
works.
D
That's
that's
similar
to
what
our
mindset
is,
because
we
don't
want
the
VM
to
be
meant
for
to
be
meant
for
smart
contracts,
but
more
to
be
meant
to
run
compiled
code
or
just
code
securely.
Now
all
the
logic
of
the
smart
contracts,
which
maybe
it's
something
else-
that's
not
smart
contract
right
on
the
VM.
As
well
we're
doing
in
a
way
that's
very
much
Enterprise
ready,
so
it'll
be
on
x86
arm
in
the
future.
We
actually
for
the
purposes
of
testing
security
wise.
We
have
our
own,
the
cert
ik
OS.
D
It's
a
the
world's
only
concurrent,
fully
verified
and
certified
hypervisor
as
well
as
OS
kernel.
So
that's
on
the
bottom
layer,
so
it's
right
above
the
metal
and
then
it
could
run
the
VM
within
that
in
a
sandbox.
So
a
smart
contract
that
is
not
proven
does
not
have
to
interact
with
the
main
chain.
It
actually
is
in
the
sandbox
and
could
show
its
breakage
in
that
way
and
then,
if
it
does
pass
it,
then
it
goes
into
the
main
chain.
So
it
doesn't
mess
up
anything
else.
A
So
I
guess
the
question
is:
where
do
the
economic
components
of
a
smart
contract
come
from
and
like
do
they
come
from
the
project?
They
come
from
your
developer
community?
How
do
we
make
sense
of
of
because
we're
not?
What
do
you
mean
by
economic
component?
I?
Think
unis
WAP
is
a
great
example
of
like
kind
of
like
a
universal
primitive.
A
C
Yeah,
that's
a
good
question,
so
it's
it
yeah!
It's
the
it's!
The
economic
component,
not
the
technical
and
so
I
think
it's
important
for
the
for
the
system.
You
design
to
show
some
properties,
some
some
advantages
over
existing
system
to
still
to
attract
developers
to
persuade
them
that
what
you
build
on
this
platform
has
some
economic
advantage
over
on
that
platform.
So
what
we
are
trying
to
do
is
not
like
I
think
this
is
more
about
the
whole
picture.
C
The
the
program
model,
not
just
about
virtual
machine,
because
what
you
machine,
yeah,
what
we
did
in
Novo's,
CK
B's.
We
changed
program
model
to
bu
TSO,
based
it's
not
a
account
based
mark
on
ship
model.
So
we
can
see
some
benefits
for
economic
components
in
this
system,
for
example,
that
the
deterministic
property
of
a
transaction
is
different
from
what
in
ethereum.
C
Like
if
you
think
about
because
it's
a
UTX
or
model-based
smart
counter
platform,
if
you
think
about
Bitcoin
right
the
the
result,
the
effect
of
this
transaction
is
determined
completely
determined
before
you
broke.
Has
the
transaction
to
the
network?
It's
different
from
a
theorem
where
you
you
actually
send
a
computation
request
to
the
network
and
network
will
do
the
computation
for
you
and
you
get
a
result.
A
very,
very
easy
to
observe
effect
is
on
Bitcoin.
All
those
transactions
are
valid.
C
Invalid
transactions
will
be
rejected
by
node
and
there
will
not
be
included
in
blockchain,
but
only
theorem.
They
are
out
of
gas
failure
transactions
that
those
are
failing.
Transactions
right,
I,
I,
think
that's
that's
one
of
the
reason
we
chose
to
build
aut
so
based
smart,
concha
motto,
because
we've
seen
such
deterministic
is
important
in
some
defy
scenarios.
We
need
that
kind
of
determinism,
yeah
Marc.