►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/new-paradigms-by-non-evm-compatible-l2s/
As L2s become bigger, several like StarkWare, Aztec and Fuel have built a VM that doesn't resemble the EVM for multiple reasons.
EVM is great. We love the EVM. But non-EVM based L2s bring about new paradigms, and innovations and expose us to new possibilities that are just not possible on the EVM. These L2s truly are expanding the scope of Ethereum and we should explore these more!
Speaker(s): Rahul Kothari, Nick Dodson, Joe Andrews, Louis Guthmann
Track: Layer 2s
Keywords: L2s,EVM,experimentation
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
I
see
these
layer
tools
not
just
as
a
scalability
solution,
but
rather
a
way
to
extend
what
ethereum
can
be
could
be,
or
it
perhaps
should
be
so
I'm
very
delighted
that
I
have
with
me
these
three
amazing
people
who
are
running
like
what,
in
my
bias
opinion,
is
perhaps
the
most
unique
and
coolest
layer
tools
in
the
space.
So
I
would
love
for
three
of
you
to
just
introduce
yourselves
talk
about
what
you're
building,
very
briefly
before
we
get
into
like
the
cool
things
of
your
systems.
B
C
Hi,
my
name
is
Louis
I'm
ecosystemia
stockware.
We
have
to
talk
with
over
three
years
and
a
half
so
star
queer
is
building
Security
Solutions
using
xero
knowledge,
proof
more
specifically
Starks.
Our
first
product
you
may
have
used
is
called
star
X.
It
is
the
one
powering
sore
immutable,
dydx,
diversifying
plenty
of
others,
and
in
the
last
year
and
a
half
almost
now
we
starting
to
work
on
Stark
net,
which
is
a
general
purpose.
Layer
2
on
top
of
ethereum,
enabling
scaling
using
during
complete
language
called
Cairo.
D
D
You
know
optimistic
roll
up,
no
multi-sig
anything
and
to
describe
what
we
do.
We
have
a
new
kind
of
transaction
processing
system
and
this
can
take
the
form
of
something
like
of
Lydia.
It
could
take
the
form
of
something
like
a
layer.
Two
we
use
egxos
for
this.
We
use
a
different
Paradigm
from
you
know,
typical
ethereum
systems.
We
have
our
own
language
called
sway
which
is
used
to
Target
this
system.
We
have
our
own
tooling
We,
have
basically
a
revised
version
of
everything,
ethereum
offers
and
yeah.
D
A
Very
cool
all
right,
so
we
have
like.
We
have
a
good
mix
of
people
here
we
have
like
two
companies
building
zero
knowledge.
We
have
two
companies
using
utxos,
but
if
all
of
you
have
like
such
unique
branding
and
products
so
like,
let's,
let's
go
for
a
very
first
principle
approach
before
I:
ask
why
you
chose
non-edm.
Can
I
ask
why
not?
Why
should
blockchains
just
not
use
normal
VMS
like
I,
know
x86
or
Ram?
Why
is
it
so
necessary
to
build
something
new.
A
D
One
so
x86,
and
these
other
instruction
sets
are
really
designed
for
different
Computing
architectures.
So
you
know
when
you're
designing,
x86
you're,
designing,
arm
you're,
designing
them
to
Target
a
hardware
system,
and
so
that's
going
to
come
with
its
own
criteria
and
its
own
restrictions
and
physics,
whereas
with
a
blockchain
virtual
machine,
you're
you're
designing
for
a
different
kind
of
physics,
so
you're
pricing,
every
operation,
you're
designing
for
adversarial
scenarios,
and
because
of
this
you
end
up
having
odd
design
constraints.
D
That
really
put
you
in
a
corner,
and
you
have
to
really
understand
those
physics
to
design
a
good
virtual
machine
that
will
both
be
you
know
great
for
processing,
but
also
be
great
for
security.
So
it
really
is
kind
of
an
art
designing
some
of
these
systems
and
we've
learned
a
lot
since
the
you
know
kind
of
inception
of
Bitcoin
in
2008
all
the
way
through
to
to
now-
and
you
know,
basically,
those
those
instruction
sets
are
for
different
purposes.
Whereas
you
know
virtual
machines
for
blockchains
are
categorically
a
different
thing.
D
B
I
was
just
going
to
add
I.
Think,
like
compatibility,
is
one
of
the
main
kind
of
reasons
why
we
have
to
limit
the
feature
set
on
blockchain
kind
of
VMS,
like
you
have
multiple
clients
trying
to
all
get
to
the
same
kind
of
state
update
and
that
doesn't
exist
in
the
world
of
kind
of
like
Intel
chips.
So
it's
just
yeah
it's
a
much
harder
problem
and
that
usually
means
we
get
a
limited
feature
set
like
we
have
in
the
evm.
C
A
B
I
think
just
a
starting
point
is
probably
like
the
more
complex
the
VM
is
I
think
the
harder
it
is
to
scale
we're,
seeing
this
with
kind
of
people
trying
to
prove
computational
evm,
and
you
need
like
giant
data
centers,
to
actually
construct
that
proof.
So
a
simple
kind
of
maybe
tailored
feature
set
of
the
VM.
It's
probably
going
to
result
in
more
scalability.
This
may
be
the
first
point.
B
C
Yeah,
so
so
the
thing
is
that
what
we
were
expecting
from
a
VM,
the
blockchain
VM
before
now
changed
it
changed
significantly
between
the
origin
of
Bitcoin
and
ethereum,
and
what
we
know
now
and
I
guess.
One
of
the
main
difference
is
that
we
now
realize
more
than
ever
that
we
need
scalability,
and
we
now
discover
that
we
either
are
Tech.
That
gives
that's
going
to
be
T1,
preserving
the
core
principle
of
blockchains
and
the
core
principle
of
blockchain.
C
Is
you
know,
trustlessness
and
verifiability,
and
before
and
I'm,
going
to
toot
my
own
war
and
obviously
in
and
talk
about
DK
here
before
the
the
arrival
of
ZK
as
a
practical
technique
to
bring
very
fast
verification.
We
just
went
to
to
the
source
to
the
simplest,
which
was
the
vvm
and
now
that
we
we
are
looking
at
those
new
tech
and
this
new
knowledge
that
we're
learning
you
know
what
Fury
is
doing
or
what
surana
is
doing
and
what
others
chain
are
doing.
D
Compatibility
was
something
that
you
know
it
was
was
not
really
kind
of
in
part
of
the
picture
and
I
think
it's
ended
up,
locking
us
into
a
design
that
wasn't
really
educated
on
what
could
potentially
happen.
If
we
had
this
design
and
so
we're
just
sort
of
stuck
with
it,
so
you
know
I
think
the
expectations
are
that
you
know
again
you
design
a
safe
VM.
D
You
design
a
virtual
machine
that
can
provide
all
the
behaviors
we
like
for
ethereum
but
as
well
open
up
a
lot
of
new
kinds
of
designs
that
we
currently
don't
see
that
we'd
like
to
see,
and
then
on
top
of
that
you
know
just
designing,
for
you
know
a
lot
of
different
scenarios
where,
if
you
could
have
done
it
a
different
way,
you
would
have
factored
in
all
the
research
that
we
have.
You
can.
Basically,
you
can
create
a
new
reality
for
blockchain.
B
Yeah
I
was
going
to
say:
I
mean
like
one
example
is
probably
like
the
curve
that
we
all
sign
over.
So
we've
all
got
a
seed
phrase
and
it's
kind
of
hasn't
really
changed
in
a
while
people
have
tried
doing
smart
contract
wallets.
But
if
you
control
the
VM,
everyone
in
the
room's
got
an
iPhone
or
an
Android.
That's
got
a
TPM
in
it
and
you
can
actually
build
that
into
the
VM
and
help
get
adoption
so
yeah.
C
And-
and
you
know
specifically
about
the
the
change
that
we
are
expecting
now
from
the
VM-
there
are
a
couple
examples
which
are
just
so
significant,
so
clear
that
the
the
target
gold
Target
moved
Aragon
when
they
launched.
They
were
like
you
know
these
massive
Os
or
for
Dao
with
like
very
well
filled
out
the
point
that
it
was
way
too
expensive
I
mean
back
then
no
one
cared,
you
know
when
they
started.
C
He
always
was
a
mistake
in
retrospect
and
the
problem
that
EOS
is
that
they
put
us
in
a
local
equilibrium.
There
is
no
way
smart
contract
wallet
will
pick
up
on
ethereum
today,
because
it's
always
cheaper
to
use
EOS,
it's
very
cheaper
to
my
priorities,
and
so
there
is
no
incentive
for
the
dabs
to
actually
build
their
application
to
be
very
well
compatible
with
redconnect
or
just
you
know,
to
work
well
with
smart
contract
wallet
and
some
even
some
just
reband
them,
because
they're
smart
contract
and
so
in
the
connect
stock
Network.
C
We
because
we
don't
have
EOS,
we
don't
use
a
Smart
contract
and
therefore
only
smart
contract
wallet.
We
have
people
using
the
native
curve
of
the
network
or
the
start
curve,
and
now
we
are
also
people
trying
to
build
using
the
trusting
Enclave
of
your
iPhone
So
within
the
same
wallet.
You
can
actually
use
your
iPhone,
you
can
you
you
can
use
any
care
that
you
want.
C
D
Yeah,
just
just
to
speak
to
that
too.
So,
like
I've
done,
my
share
of
gas
golfing
like
I,
just
I,
want
to
say
I'm
like
you
can
check
my
GitHub
like
it's,
it's
sort
of
like
an
art
for
me,
but
it
was
more
of
a
therapeutic
thing
to
gas
golf
than
it
was
like
a.
This
is
a
good
use
of
my
time.
Mind
you
that
was
before
I
worked
with
fuel,
so
you
know
started
fuel
so
essentially
yeah.
D
The
thing
is,
is
you
can
gask
off
all
you
want,
but
it's
not
enough
and
it's
never
enough,
because
when
enough
people
use
the
system,
it
just
gets
congested
and
then
you're
you're
back
to
where
you
started,
and
you
keep
asking
the
same
questions
like
well.
How
could
we
do
this?
How
could
openc
run
in
this
way?
You
know
and
then
the
thing
is.
D
D
If
you
want
some
spice,
but
anyway,
the
the
the
reality
is,
is
you
know
I've
been
sitting
here
looking
at
this
machine
for
years,
like
years
and
years
and
years,
and
it's
held
a
lot
of
different
kinds
of
designs
back
because
it
can't
move
forward
like
it
really
is
very,
very
difficult
to
move
forward.
So
you
know
the
fact
that
these
teams
are
sort
of
bold
enough
to
still
be
part
of
ethereum,
but
try
to
do
it
differently.
Just
for
the
sake
of
like
getting
to
Global
adoption
and
getting
somewhere
else.
D
I
think
is
a
is
a
you
know.
It's
a
sign
of
how
good
the
ethereum
community
is,
because
you
know
we're
not
afraid
to
challenge
what
people
have
made
a
culture
of
the
system
and
I.
Think
that
that's
a
it's
a
very
beautiful
thing.
You
know
so,
but
yeah,
it's
not
all
just
vitalik
and
Gavin's
design
that
gets
to
run
the
show.
You
know
I
mean
we
can
try
to
do
other
things
and
with
layer
twos
we
can
now.
So
it's
great
yeah.
C
Yeah
yeah
about
the
you
know,
everyone
come
to
say
about
yeah.
It's
always
about
cheap.
No,
it's
not
about
cheap,
really,
not
about
cheap
I
can
give
you
a
few
examples
of
things
that
are
being
built
that
you
just
like
dream
of
anywhere
else
in
ethereum
and
so,
for
instance,
Sparkle.
Chocolate
is
most
specifically
like
an
important
one
because
smoking,
the
wallet,
is
not
working.
Crypto
crypto,
if
will
not
get
Global
adoption.
C
Things
are
getting
unlocked,
for
instance,
urgent
around
here
actually
or
it's
working
on
extensively
on
Stark
net
and
they're
working
on
the
plugin
system,
meaning
you
can
actually
install
an
app
in
your
wallet,
meaning
that,
for
instance,
every
time
you
spend
10
goes
to
saving
or
every
time
you
you
want
to
play
a
game.
You
actually
don't
have
to
sign
your
transaction.
You
can
open
a
decision
key!
That's
going
to
last
six
hours
and
that
is
only
authorized
to
do
a
set
of
operation,
and
so
really
the
cheap
transaction
is
like
an
afterthought.
C
It's
just
a
requirement
and
honestly
to
be
honest,
I
don't
think
it's
going
to
last
long
like
l2s
himself
will
not
be
cheap.
I
have
a
theory
which
is
you
can't
have
a
cheap,
successful,
economical
layer,
because
there
is
no
reason
in
the
universe.
What
that
my
ticketing
app,
that
is
trading
or
where
I
can
change.
My
my
Nifty
of
my
ticket
being
packed
it
by
the
fact
that
the
big
price
of
Eve
dropped
by
20
and
all
of
a
sudden,
my
app
doesn't
work
anymore,
and
so
that
just
doesn't
happen.
A
B
A
E
E
D
Gonna
try
to
keep
my
Shilling
in
a
kind
of
a
dome,
so
some
some
highlights,
but
okay,
so
first
of
all,
the
fuel
VM
is
highly
inspired
by
the
ebm.
So
all
the
lessons
that
we've
learned
with
the
evm
over
the
years
it
tries
to
incorporate
it,
doesn't
leave
that
behind.
It
doesn't
try
to
say
we're
arrogant
enough
to
rebuild
everything.
So
that's
the
first
thing:
we've
basically
taken
all
the
great
eips,
all
the
great
research
that
the
ethereum
community
has
done
and
other
blockchain
communities
have
done
and
put
it
into
a
virtual
machine.
D
Now
we've
made
some
very
interesting
decisions
and
they
all
impact
the
kinds
of
things
you
can
build.
The
the
kinds
of
experiences
you
can
create
and
as
well
the
scale
that
you
can
achieve
with
this
particular
system.
So
some
highlights
are
it's
utxo
based,
so
that's
the
first
thing.
Secondly,
you
get
smart
contracts,
just
like
ethereum,
there's
no
loss
in
any
kind
of
behavior
from
a
developer.
Secondly,
Scripps
is
another
one.
So
in
ethereum
you
have
to
go
through
a
smart
contract
to
make
multiple
calls
it's
ridiculous.
It
never
should
have
been
that
way.
D
So
we
have
scripts
and
then
we
as
well,
we
have
account
abstraction
via
what
we
call
predicates,
and
so
this
allows
you
to
send
to
the
hash
of
a
script
and
essentially,
if
the
script
returns
true,
then
you
can
spend
the
output,
and
this
gives
you
all
kinds
of
things
you
can
do.
For
example,
we
can
support
signing
with
a
Solana
key
over
a
utxo
that
is
usdc
from
ethereum.
You,
like
that's
pretty
nuts,
you
know,
and
that
can
happen
at
it's
cool
and
then
that
can
happen
in
like
an
output.
D
Sorry,
if
you're
not
an
engineer,
so
it's
just
bear
with
me,
but
when
you
make
a
call,
you
don't
need
to
re-serialize
the
data
between
smart
contracts,
it's
all
in
one
chunk
of
memory,
but
the
memory
is
segmented
per
call
frame
and
what
that
does
is
it
allows
you
to
go?
I'll
write
5000
things
to
memory
here.
I'll
call
this
contract
over
here
and
that
other
contract
can
just
reference
any
one
of
those
items,
so
you
can
imagine
trading
engines.
Things
like
this
would
love
that,
because
you
can
write
so
much
to
memory.
D
You
can
really
abuse
memory
and
you
can
abuse
compute,
which
we
have
a
lot
more
of
and
not
storage.
So
we
give
you
far
more
options
to
use
that
are
not
storage
oriented,
so
these
are
all
part
of
the
processing
model,
but
so
you
know
lastly,
for
the
last
bit
of
shill
this
also
because
it's
a
utxo
model,
you
get
all
the
nice
things
of
ethereum,
but
you
get
full
complete
parallel
processing.
D
So
you
can,
you
know,
basically
have
all
the
benefits
of
some
of
these
newer
ecosystems
that
are
parallel
processing
but
because
the
fuel
VM
is
designed
to
be
arbitrated,
it
can
also
be
a
roll
up
or
layer
2
on
ethereum
directly,
and
on
top
of
that
it
has
trust,
minimized,
light
clients,
so
you're
not
leaving
behind
the
nice
security
properties
what
we
have
with
ethereum.
So
that's
my
shill
on
the
VM
yep.
You
go.
B
Okay,
as
is
also
utxo
model
I'm,
a
big
fan
of
utxos
they're
very
difficult,
but
they
do
enable
kind
of
some
important
features
which
the
account
model
lacks
and,
in
our
case,
that's
privacy.
So
it's
very
hard
to
do.
Privacy
in
account
based
model,
because
every
time
you
update
an
account
you
leak,
which
account
you're,
updating,
so
an
utxo
model.
We
can
create
and
Destroy
utxos
and
they
all
look
random.
B
So
it's
one
of
the
key
kind
of
design
choices
we
had
to
make
to
get
privacy
and
then
kind
of
more
into
the
VM.
We
also
have
account
abstraction
built
into
Aztecs.
So
we
have
this
concept
of
a
viewing
key
and
a
spending
key
when
things
are
encrypted,
there's
a
different
set
of
people
who
may
need
to
see
the
data
to
those
who
can
spend
it
so
I
think
yeah
being
able
to
control.
That
has
been
a
super
beneficial
for
our
architecture.
B
Actually
compute,
the
snark
in
the
browser
in
Noir
prove
the
correct
running
of
the
program
and
then
send
that
kind
of
packaged
up
kernel
circuit
to
a
rollout
provider,
and
that
means
you
actually
get
really
cool
features
like
code,
privacy,
confidentiality
and
anonymity.
So
we're
excited
about
that.
C
So,
in
the
context
of
Stark
net
and
starkware,
we
also
in
creating
our
own
VM,
but
and
focusing
only
on
on
scaling.
You
can
similarly
to
fuel
and
I
just
want
to
sort
of
make
a
differentiation
in
terms
of
scaling
between
the
field
approach,
to
which
is
basically
polarization
enabling
the
execution
layer
to
do
more
and
the
ZK
approach,
which
is
basically
requiring
less
from
the
verifier
and
those
are
orthogonal
completely
orthogonal.
C
So
you
can
get
both
potentially,
but
the
reason
why
I'm
making
that
that
that
the
differentiation
is
because
the
in
some
way
the
way
darknet
scale
is
by
saying
you
know
what
validators
can
have
stronger
machines
than
the
rest
of
the
world.
Today,
when
you
look
at
ethereum
or
any
blockchain
like
Bitcoin,
the
the
your
your
limit
scaling
is
limited
by
the
weakest
machine
in
the
network,
and
so
when
we
compare
the
TPS
or
whatever
I
mean
the
not
the
throughput
of
Bitcoin
versus
ethereum
versus
the
fruit
of
Solana.
C
C
C
The
network
needs
to
have,
and
so
when
you
use
a
regular
traditional
execution
layer
without
using
crypto
cryptography
to
scale
it,
you
basically
don't
really
change
this
symmetry
you,
the
guy,
who
makes
money,
is
still
requiring
the
same
machine
that
the
the
guy
would
verify
it
in
his
in
his
garage
and
regardless
of
the
fact
that
these
miners,
this
validator,
can
spend
millions
of
dollars
at
stake
or
million
dollars
in
machine.
It
will
roughly
run
on
the
same
laptop
that
you
had
at
home
and
so
ZK
breaks
that
breaks.
C
That's
that
parallel
all
of
a
sudden
it
it
doesn't
matter
what
kind
of
machine
the
validators
have
I
can
verify
it
on
my
phone
in
a
millisecond,
and
so
they
can
have
a
data
center
for
like
here.
I
can
still
verify
it
on
my
phone,
so
the
the
start
were
created
its
own
VM
called
Cairo,
because
the
pro
that
we
have
with
existing
VM
is
that
they
are
optimizing
for
a
different
programming
paradigms
that
zkps.
So
the
best
way
to
explain
it
is
that
you
talked
before
about
x86,
so
you're
really
good.
C
You
know,
regular
VM
is
optimizing
for.
Basically,
your
CPUs
and
your
transistors
and
transistors.
You
know
one
thing
very
well,
which
is
Boolean
logic
and
beats
and
bytes.
The
thing
is
what
you're
underneath
the
KP
environment
you
are
working
in
the
arithmetic
environment,
where
the
base
element
you're
working
with
is
what
we
call
a
film
a
field
element
which
is
basically
a
big
uint
and
the
cheap
operation
that
you
get
is
multiplication
addition
division,
subtraction
and
Boolean
logic
is
expensive.
C
C
You
want
to
have
Optimum,
you
prefer
to
have
a
VM
that
is
optimized
for
the
computing
paradigms,
and
so
these
specific
dimensionality,
as
I,
said
these
orthogonal
to
the
execution
layer
and
so
start
net
right
now
is
basically
roughly
taking
the
same
structure
execution
model,
then
than
if
ethereum,
with
a
few
distinction
like
we
try
to
do
optimistic
polarization
we
try
to
do.
We
are
looking
into
different
data
structure
while
remaining
using
the
remaining
of
the
Constructor
of
Eve.
C
Also
expanding
and
what's
the
new
state
of
the
art
is
coming
like
a
thing
like
three
uttos,
we
are
looking
into
what
they're
doing,
because
it's
cool
it's
useful,
and
so
what
matters
is
that
you,
that
is
a
separation.
So
start
that
is
focusing
on
the
the
separation
between
the
validators
and
the
rest
of
the
world,
and
then
afterwards,
we
are
looking
into
optimizing
the
execution
layer
to
provide
the
num,
the
the
the
the
brought
the
transistorical.
That's
even
expect.
D
Let's
just
say
one
last
word,
because
node
requirements
came
up
so
I'll
just
I'll
just
make
one
comment,
which
is:
you
know
we're
in
Latin
America,
and
this
is
a
new
place
for
ethereum
to
be
I.
Think
you
know
having
been
through
a
bunch
of
them.
It
was
a
bunch
in
Europe,
Etc,
I,
think
with
fuel
and
the
way
that
we
interpret
node
requirements.
D
A
B
Yeah
I
think
it
gets
worse
for
privacy
because
there's
like
a
censorship
component.
So
if
you
kind
of
restrict
like
your
kind
of
nodes
to
AWS
Google
cloud
and
Microsoft
quite
quickly,
you
don't
have
a
decentralized
privacy
Network.
You
have
Fang
so
yeah
our
node
requirements.
We
we
do
the
same
as
fuel
and
we
have
to
kind
of
think
about.
How
do
we
get
it
working
on
a
laptop?
C
C
And
and
that's
that's
the
target,
that's
what
we
should
achieve
so
so
maybe
it's
not
practical
and
the
fact
that
it's
not
practical
is
irrelevant.
The
fact
that
it's
a
Gore
is
what
matters.
That's
what's
drivers,
that's
what
brings
us
towards
one
point
and
so
that
I
I,
really
don't
I,
really
want
you
know,
ideally
in
the
future.
Inferior,
would
be
make
redundant
to
some
extent,
of
course,
not,
but
to
some
extent
of
this
on
your
on
your
phone
or
you
should
be
able
to
run
the
network
locally.
A
B
B
We
actually
have
to
look
at
kind
of
the
network
layer
of
privacy,
so
we're
moving
to
looking
using
something
like
Nim,
so
you
can
actually
request
utxos
from
a
kind
of
more
centralized
data
store
without
revealing
who
you
are
and
if
the
utxo
is
completely
random.
When
you
request
that,
through,
like
a
network
layer,
privacy
layer,
you
get
the
same
anonymity
as
kind
of
a
full
sync.
So
there's
ways
to
do
it,
but
it
requires
kind
of
the
whole
privacy
stack
in
our
case
and
some
pretty
Advanced
web
browser.
D
D
You
can't
really
have
it
because
with
their
model,
you
had
to
sort
of
sign
off
on
the
change
state.
But
what,
if
you
don't
know
the
change
state?
So
what?
If
there's
a
bunch
of
people
in
front
of
you
and
behind
you
in
the
mempool
who
are
actually
manipulating
the
state
of
this
one
thing,
then
when
you
produce
the
result
of
the
utxo?
Well,
you
don't
know
what
it
is
so
in
their
model.
D
They
couldn't
do
that
so
so
it
caused
this
issue
where,
like
you,
would
use
uni,
Swap
and
there'd,
be
like
one
transaction
per
block
for
that
one
app,
because
you
you
didn't
know
what
the
state
was,
so
you
had
to
just
use
it
one
after
the
other.
Obviously
this
is
horrible,
like
you
know,
Imagine,
One,
TX
or
whatever
for
per
block
per
unit,
swap
on
ethereum,
like
we
wouldn't,
probably
wouldn't
even
be
doing
Devcon
or
something
like
that.
You
know
so.
D
Basically,
you
know
the
reality
is
is
that
that
was
more
of
a
design
decision
on
the
whole
system
and
it
doesn't
actually
relate
necessarily
to
utxos
per
se.
Utxos
are
just
a
way
to
notate
and
Define
the
transaction
model,
which
is
something
that
you
can
do
in
various
ways
so
with
fuel.
If
you
have
a
smart
contract
as
an
input,
you
can
have
like
say
a
uni
swap
like
system.
That's
one
input.
When
the
state
is
manipulated,
we
basically
have
an
output,
so
it
is
noted
that
it
changes
the
state
but
like
ethereum.
D
There
is
this
kind
of
reasonable
malleability
of
what
could
happen
under
the
constraints
of
the
system
such
that
you
know
this
output.
Basically,
is
you
know
it's
notating,
there's
a
change,
but
it's
under
certain
constraints,
in
certain
conditions,
similar
to
what
we
expect
with
ethereum
and
uni,
swap
when
you
use
uni,
swap
you
don't
always
know
what
the
state's
going
to
be
or
what
it's
going
to
change
to,
but
in
ethereum
we're
willing
to
accept
that
reality
under
certain
constraints.
So
I
use
the
word
determinism
here.
D
Maybe
the
academics
don't
like
that,
particularly,
but
it
is
sort
of
how
I
would
interpret
the
situation,
but
with
fuel
we
don't
have
any
of
those
problems
at
all.
You
can
build
a
uni
swab
leg
system
or
whatever
you
can
use
the
transaction
utxo
model.
We
get
all
the
parallelism
benefits.
There's
no
downsides
to
that,
and
it's
not
an
issue.
It's
really
just
it
was
publicized
as
an
issue
and
utxos
were
related,
but
in
our
case
we
have
different
designs
that
don't
feature
this
issue
at.
C
D
So
so,
basically,
fuel
has
just
normal
smart
contracts,
so
you
can
have
a
smart
contract
that
calls
many
smart
contracts.
If
it
does
then
you're
notating
those
various
other
smart
contracts
as
ugxos
as
well,
their
inputs
to
the
system,
you're
outputting
potential
changes,
so
it's
very
simple
in
its
design,
we've
inherited
a
lot
of
the
work
that
was
done
in
research
for
State
access
lists
for
ethereum.
So
really,
this
is
just
a
reinterpretation
of
that
research,
but
it's
in
a
cleaned
up
model
which
is
in
a
utxo
setting.
D
So
we
again
get
all
these
nice
benefits
from
utxos,
but
we
don't
lose
the
user
experience
or
behavioral
elements
of
what
we
get
with
ethereum.
So
it's
a
really
nice
model
in
that
sense,
and
then
scripts,
just
scripts
just
allow
you
to
make
a
transaction,
you
could
say,
call
multiple
contracts
so
for
Trans,
you
know
proven
transfer
from
you
have
to
make
two
transactions
in
ethereum
from
the
origin
sender,
which
is
ridiculous.
Why
are
we
doing
that?
That
makes
no
sense
at
all
and
it
should
never
have
happened
and
the
main
thing.
The
main
reason.
D
Why
is
because
of
just
the
design
of
ethereum
itself
is
funneling
everything
through
single
accounts
and
that
restricts
you.
So
you
know
with
again
a
utxo
model
and
with
scripts
you
can
just
have
a
script
that
calls
you
know,
approve
and
then
transfer
from
in
the
same
transaction
and
that's
it
and
you
don't
need
to
deal
with
that
anymore.
So
it's
really
not
crazy.
D
C
So
the
question
was:
how
does
darkwear
look
at
this
question
of
State
Management
and
basically
the
question
we're
asking
is
here:
is:
can
how
do
you
paranize?
How
do
Paradise
stuff,
roughly
speaking,
so
the
start
Stark
net
at
the
moment,
do
not
do
polarization
as
of
now,
because
we
were
focusing
on
making
the
whole
thing
work
right.
We
had
a
new
VM,
a
new
language.
C
We
focused
on
make
things
work,
and
so
we
took
we
went
for
the
simplest
model,
which
was
the
one
that
was
used
in,
and
you
know
Bulletproof
by
ethereum,
and
now
that
we
have
like
all
the
features
that
we
are
focusing
on.
Actual
execution
scaling,
so
I
just
want
to
say:
I
want
to
separate
verification,
scaling
from
the
from
execution
scaling,
and
so
one
other
thing
we
are
going
to
have
relatively
soon,
which
would
dramatically
improve
our
the
throughput
of
the
system
is
optimistic
execution.
C
So
it's
not
it's
not
an
intimate
solution.
It's
it's
as
some
downtime.
It
has
theoretical
negative
like
let's
say
that
adversary
adversial
reaction
that
could
be
impactful
of
the
network.
We
are
planning
to
solve
it,
one
after
the
other.
It's
not
right
now,
we're
focusing
on
you
know,
bringing
scale.
C
Another
thing
that
we're
looking
into,
which
is
within
the
line
of
this
systemistic
polarization
that
otxo
enables
we
are
looking
at
various
that
time
structure
like
the
model
that
exists
in
the
space
we
look
at
Solana.
We
look
at
Aptos.
We
look
at
sui.
We
looked
at
all
the
sort
of
like
chain
that
are
actively
building
vaporization
and
look
at
how
they
did
it.
C
We
still
wanted
the
account
model
because
a
lot
simpler
and
we
already
have
enough
mind
change
with
like
the
new
language,
so
we
focused
on
you
know,
bringing
keep
it
simple
in
that
sense,
and
but
we
are
looking
as
I
said,
into
the
new
ways
whether
or
they
are
doing
and
take
the
best
idea
that
exists
there.
So
we
should
actually,
you
should
expect
more
on
that
front
in
the
coming
month,
but
there
is
nothing
to
announce
because
it's
Syrian
research
race
at
the
moment,
Alpha.
C
So
so,
but
that's
not
okay,
so
it's
actually
it's.
So
we
already
focusing
on
the
on
the
on
the
scaling
of
the
execution
and
TVM
itself,
the
the
the
parallelization
the
recursion
enables
you
to
do
partition
of
the
verification,
but
you
have
to
know
today
on
Stark
net
verification
is
not
an
issue
whatsoever.
Yeah,
like
the
verification
proving
is
not
the
issue
right
now.
Our
problem
is
the
sequencer.
A
Developer,
who
is
trying
to
use
one
of
your
systems
throughout
the
panel?
All
of
you
have
dropped
some
really
really
interesting
paradigms.
Let's
talk
a
bit
more
like
I
know,
if
you
all
spoke
about
having
these
scripts
and
stockwest
broke
about
having
no
EOS
whatsoever
and
direct
like
contract
wallet,
and
you
use
the
term
programmable
privacy
I'd
love
for
like
everyone
to
like
think
about
what
these
new
features
are,
but
thinking
about
it
from
a
developer
or
adapt
developer
perspective.
D
Yeah
I
mean
from
a
developer
perspective.
You
know
it
at
fuel.
We
look
at
it
mainly
from
a
few
different
points
of
vision,
my
own,
which
again
is
reflective
of
many
many
years
of
trying
to
build
apps
on
ethereum
and
struggling
with
a
lot
of
key
things
in
the
system
that
make
both
the
developer
experience
horrible.
But,
secondly,
the
end
result
being
a
sort
of
odd,
disjointed
experience
between
the
wallet.
What
the
wallet
can
do
and
then
what
the
application
can
do
and
then
as
well
the
kinds
of
applications
you
can
design.
D
So
with
fuel,
we
open
up
a
lot
of
the
compute,
so
you
have
far
more
available
to
you.
You
have
far
more
memory
to
use
you're,
far
more
just
just
general
compute
to
build
anything
you
you
want.
You
have
more
options
for
user
experience
with
things
like
account:
abstraction
and
with
kind
of
other
apps
aspects
like
native
meta
transactions,
so
in
fuel
you
can
have
a
party
that
just
builds
a
piece
of
a
transaction.
D
A
A
D
Just
having
a
lot
more
access
to
RAM
and
memory
and
being
able
to
do
a
lot
more
with
it
and
across
many
other
contracts,
so
just
having
that
kind
of
access
is
enormous.
It's
huge!
It
gives
you
so
much
more
flexibility
because
with
the
evm
instead
paradigms
you're
so
constrained
by
so
many
factors,
the
kinds
of
designs
you
can
do
are
extremely
limited.
So
from
my
personal
perspective,
I've
walked
around
Devcon
a
lot.
I've
heard
a
lot
of
new
designs
for
a
lot
of
new
defy,
and,
to
be
honest,
it's
still
okay.
D
B
I
think
it's
like
maybe
healthy
to
kind
of
also
tell
developers
that
not
every
kind
of
VM
is
going
to
be
suitable
for
them.
So
we
focus
on
privacy
and
you
work
for
Reddit
and
Reddit
has
a
a
point
system.
That's
public
so
like
that's,
not
really
a
good
fit
like,
but
like
a
high
throughput
VM.
That
kind
of
focuses
on
public
data,
maybe
a
better
fit.
So
some
of
I
think
our
competitors
in
the
zika
evm
space
kind
of
pitch
everything
as
possible.
B
All
the
time
and
I
think
that
wastes
a
lot
of
Dev
time,
because
you
have
to
kind
of
go
through
the
test
net,
try
and
build
something,
and
you
realize
kind
of
a
while
later
that
it's
not
possible
so
for
Aztec.
What
we
really
care
about
is
applications
that
have
private
state.
That
could
be
things
like
CK
games,
Consumer
Finance,
which
is
just
doesn't
exist
on
on
D5.
Today
we
have
over
clatterized
lending.
B
You
can't
really
have
Consumer
Finance
unless
you're
willing
to
have
a
public
passport
salary
address
on
chain,
so
I
think
privacy
is
kind
of
what
we
care
about
you're,
not
going
to
build
an
ammo
on
Aztec,
because
by
definition
it's
it's,
the
ratio
of
two
public
pools
so
being
really
transparent
about.
What
you
can
and
can't
do
I
think
is,
is
something
we
all
need
to
do
to
help
attract
the
right
developers.
So.
B
Yeah,
so
each
each
user
basically
controls
their
utxos
which
are
encrypted,
and
you
can
feed
those
into
an
Aztec
transaction
and
prove
something
about
it
and
then
kind
of
in
an
Aztec
program.
If
you,
if
you
prove
that
your
salary
is
above
X,
you
may
be
entitled
to
a
loan
or
not
entitled
to
a
loan.
So
having
that
data
being
able
to
be
fed
in
as
an
encrypted
input
to
a
program
is
really
powerful.
In
our
case,
you.
A
B
C
100
and
so
Stark
net
is
not
beautiful
privacy
whatsoever,
but
that's
not
nature.
What's
what's
true
with
that,
you
can
build
privacy
protocol
on
top
of
it,
and
so
I
was
literally
saying
in
a
random
idea
yesterday
to
to
Joe
here.
Why
not
I
mean
Aztec
and
Noir?
You
know
I
mean
there
is
no
reason
they're.
Not
you
could
have.
You
know
the
scale
of
composibility
just
not
the
same
purpose,
so
you
ask
what
kind
of
like
things
you
can
like.
C
You
know
things
you
can
build,
so
the
main
thing
that
you
can
build
on
Stark
net
I
always
give
like
a
three
to
it
as
a
Dev.
The
only
thing
you
care
about
three
things
which
are
you
get
cheap
computation,
cheap,
core
data
and
I
can
obstruction,
and
you
get
like
a
three
and
a
half
which
is
a
long-term
vision
of
scaling,
which
means
that
even
if
you're
priced
out
of
this
layer
itself,
you
can
go
a
layer
up
which
would
be
cheaper.
C
C
So
now,
when
you
come,
you
combine,
for
instance,
chip
computation
you're
starting
to
have
people
making
physic
engine
on
on
the
blockchain
so
I
had
we
have
someone
like
a
company
called
topology
on
stock
net
that
is
building
a
physic
engine,
so
you
can
prove
Collision.
You
can
prove
like
you
know,
games
that's
existing
in
the
80s
or
90s
worms
like
you
know,
you
can
make
that
happen
directly
on
chain.
C
You
can
Implement
things
like
infinite
risk.
You
know
like
an
infinite
map
using
apparently
noise
or
Advanced
algorithm
the
generic
Maps,
and
we
have
those
people
making
it
today
on
on
the
ecosystem.
So
when
you
get
cheap
core
data
and
cheap
computation,
you
get
things
like
that,
when
not
possible
in
ethereum
before,
like
practical
storage
proof.
So
if
you're
not
familiar
with
storage,
proof
storage
proof
enables
you
to
prove
the
state
of.
If
in
the
past
to
if
in
the
present,
so
why
is
that
useful?
C
A
You
so
much
yeah
I,
know
we're
running
out
of
time.
All
I'll
say
is
all
the
dab
developers
I
think
because
we
work
in
crypto.
We
kind
of
owe
ourselves
to
Destin
broad
I
say
that
as
a
meme,
but
what
I
really
mean
is
I
think
we
are
here
to
experiment
and
try
these
new
languages
like
Sway
and
Cairo
and
Neuer
and
stuff
so
I
hope
you
all
like
actually
go
out
and
at
least
read
up
on
what
these
cool
things
are
doing.
I
know
if
you
have
time
but
I'm
happy.
B
I'll
just
say
if,
for
our
case,
none
of
the
languages
other
than
circum
are
built
for
kind
of
private
State,
and
we
found
that
circum
was
too
low
level
and
we're
trying
to
Target
kind
of
web
2
developers
or
solidity
developers,
and
they
shouldn't
have
to
kind
of
know
how
to
be
a
cryptographer.
So
our
language
abstracts,
the
cryptography
part,
and
so
you
can
just
write
an
application
and
nothing
was
out
the
box.
C
So
is
it
working
circum
is
not
sure
incomplete
as
simple
as
that,
and
so,
if
you
want
to
do
an
if
statement
which
you
kind
of
need
for
so
stock
net
is
on
OS.
The
real
name
of
starting
is
a
protein
system
right,
it's
like
in
other
words,
and
so
everything
every
Cisco
in
stock
net
is
written
in
Cairo.
C
So
if
you
don't
have
a
system,
if
statement
your
program
is
going
to
be
quite
big,
and
so
another
thing
that
circum
doesn't
allow
you
to
do
is
being
able
to
prove
multiple
program
within
the
same
proof,
which
is
something
that
carries
through
sharp
enables
you
to
do,
and
so
we
needed
to
create
our
own
language
for
that
purposes.
And
finally,
circum
is
I
mean
I.
Guess
is
that's
actually
material
Targets
in
stock,
but
that's
not
yeah.
Remove
that.
D
D
The
main
reasons
are
the
some
of
the
existing
programming
languages
like
C
or
Russ,
for
example,
they're
really
not
designed
to
Target
a
blockchain
and
there's
a
lot
of
different
ramifications
around
targeting
A
blockchain
system
that
you
want
to
catch
in
different
stages
of
of
the
compiler,
so
that
was
one
strong
motivation
for
us
to
have
our
own
language.
Secondly,
the
compiler
and
the
tooling
have
to
work
really
hand
in
hand.
D
So
in
a
blockchain
environment
you
want
the
developer
to
have
extreme
control
over
every
aspect
of
the
system,
so
they
can
really
simulate
everything,
so
the
developer
experience
was
another.
And,
lastly,
we
wanted
to
create
a
rustish
like
language
that
really
targets
blockchains,
not
just
the
fuel
VM.
So
the
way
that
our
compiler
is
designed
is
such
that
you
know-
and
this
is,
unlike
others
in
the
space
it's
designed
to
be
very
modular.
D
So
if
we
want
to
Target
a
back
end,
you
know
like,
like
you,
know,
Cairo
or
wanted
to
Target
the
mine
VM,
or
we
wanted
to
Target
a
different
language.
The
language
ecosystem
will
be
set
up
to
Target
many
different
kinds
of
blockchains,
including
the
evm,
so
one
we're
working
on
right
now
is
targeting
Yule
and
that's
with
Foundry,
so
you'll
be
able
to
use,
sway
and
maximize
its
value
and
its
design
without
having
to
want
to
rebuild
languages
again
now
mind.
D
You
I,
think
some
of
the
ZK
teams
have
different
criteria,
different
stages
of
the
compiler,
that
they
really
have
to
factor
into
their
design.
So,
like
you
know,
we
can't
speak
for
all
ZK,
VMS
or
anything,
but
it's
a
good
harness
of
a
blockchain
language.
That's
rustish!
That
people
will
like
yeah.
E
I'm
not
sure
how
relevant
the
question
is
to
your
environments,
because
I
haven't
looked
too
deep
into
it.
But
if
you
build
something
like
an
only
swap
on
it,
which,
like
excludes
Aztec
already,
would
math
be
a
problem
on
those
networks
as
well,
because
the
indexes
could
sort
transactions
differently
or
is
the
summer
solvable.
C
B
So
it
doesn't
really
exclude
Aztec,
like
we
have
swaps
from
Aztec
connect
to
UNI,
Swap
and
probably
the
most
liquid
uni,
swap
because
it's
on
mainnet,
so
liquidity
doesn't
get
fragmented.
We
just
have
to
kind
of
acknowledge
that
uni
swaps
are
public
application,
so
we
can't
make
it
private,
but
we
can
make
the
users
private,
so
users
come
to
Aztec
and
in
this
case
they
bridge
out
to
L1
in
a
batch
to
get
scaling
and
privacy.
D
And
then
for
us
you
know
we
don't
make
any
claims
about
Med,
so
you
could
probably
extract
it.
If
you
know
in
a
decentralized
sequence,
you
know
setting,
but
I
will
say
that
we
actually
take
a
slightly
different
approach
in
the
sense
that
we
actually
want
to
give
the
node
as
many
abilities
as
possible
to
extract
as
much
Mev
as
possible
or
provide
teams
that
either
try
to
fight
Mev
or
actually
try
to
Advantage
it
the
best
tools
that
they
can
have,
because
we
don't
really.
D
B
For
internal
Aztec
transactions,
they're
kind
of
if
they're,
fully
private,
you
can't
see
what's
happening,
so
our
approach
is
usually
to
try
and
push
it
to
L1,
and
then
you
can
use
something
like
flashbots
to
kind
of
solve
it
in
the
way
we
currently
know
how
but
yeah.
If
there
was
kind
of
public
components
to
an
Aztec
L2
application,
then
there
would
be
Mev
on
the
network,
but
yeah
I
think
trying
to
push
it
down.
One
is
a
good
strategy.