►
Description
Mina's ecosystem partner, O(1) Labs, goes over the architecture for Snapps on Mina Protocol.
🔦 Featuring 🔦
Izaak Meckler – CTO, O(1) Labs
What is Illuminate?
Illuminate is a free virtual event that took place on March 28th, 2021, and which celebrated Mina’s mainnet launch and exciting protocol milestones.
Participants heard from a range of blockchain experts, industry leaders, and community members about Genesis and the road ahead. The one-day event featured panels and sessions on Mina’s use cases, advancements in zk-SNARKs, Staking-as-a-Service, industry insights and so much more. Illuminate is also a big thank-you to Mina’s vibrant community, who have made incredible contributions to the network over the past two years.
📧 Sign-up here to be the first to find out about the next illuminate conference: https://bit.ly/MinaNewsletter
💥 Follow us on Crowdcast: http://bit.ly/MinaCrowdcast
A
Hello,
everyone
welcome
to
this
session
today.
Oh,
let
me
introduce
myself
so
I'm
isaac
meckler,
I'm
cto
and
one
of
the
co-founders
of
owen
labs
and
one
of
the
co-initiators
shall
we
say
of
mina,
and
today
I'm
going
to
be
sharing
a
bit
about
kind
of
the
architecture
for
snaps
on
mina,
so
you
might
be
asking
yourself
what
are
snaps.
You
keep
saying
this
word,
but
what
does
it
mean?
A
Well,
it's
let's,
first
remind
ourselves
what
is
dapps
so!
Oh,
let
me
also
add
sorry
before
I
get
too
much
further
into
it.
Bonusri
lead
cryptographer
at
onelive
is
also
going
to
be
helping
out
with
some
questions
in
the
chat
later
on
so
yep.
So,
okay.
So
what
are?
What
are
stops?
Well,
let's,
first
talk:
dapps
daps
is
an
application.
Okay
right!
A
That's
the
f
part
with
public
data,
usually
censorship,
resistant
execution,
and
that's
that's
pretty
much
it
so
that's
kind
of
what
defines
the
dap
d.
It
means
decentralized.
I
guess
that
refers
to
the
fact
that
there's
censorship,
resistant
execution,
basically
snaps
are
applications
with
private
and
or
public
data,
so
could
be.
Private
could
be
public
also
with
censorship.
Censorship,
persistent
execution,
but
they
add
a
few
things.
So
the
first
is
this
kind
of
unifi
universal
verifiability.
A
So,
let's
kind
of
first
by
start
by
just
covering
what
is
the
transaction
model
of
snaps
and
the
the
idea
is
basically
a
snap
transaction
is
a
sequence
of
bear
with
me.
Okay
authorized
predicated
updates,
updates
to
accounts,
and
what
are
these
updates?
It's
stuff,
like
changing
the
balance,
changing
the
nots
changing
some
state
in
the
account,
but
this
is
all
very
confusing.
A
A
So
as
a
first
attempt,
let's,
let's
just
say
that
a
transaction
is
a
sequence
of
updates,
updates
to
accounts
what
kind
of
updates
well
balance,
change,
knobs
change,
etc
and
more
we'll
see
later-
and
this
will
be
our
first
working
definition
of
what
a
transaction
will
be
to
make
things
really
concrete
and
give
an
example
here
would
be
an
example
of
a
transaction
that
is
a
sequence
of
updates.
It
would
consist
of
two
updates.
This
is
a
simple
payment
transaction,
the
first
update.
A
You
know
it
has
sort
of
the
identifier
of
the
account
that
it
operates
on
the
public
key
and
the
token,
and
it
modifies
the
balance.
It
decrements
the
balance
by
10,
and
it
increments
the
nonce
in
that
account
by
one
and
then
that's
on
the
sender
side
and
then
on
the
receiver
side.
We
see
again,
you
have
the
account
identifier,
the
token
and
the
public
key,
but
then
we
also
have
the
balance
increment
okay.
So
this
is
like
two
updates
right.
A
Update
sender
account
in
this
way
update
the
receiver
account
in
this
way.
I
hope
that's
clear.
So
let
me
just
elaborate
a
little
bit
on
this
idea
of
a
sequence
of
updates
to
just
give
an
example
of
like
what
a
token
swap
transaction
would
look
like.
So
there's
two
tokens,
there's
the
amino
token
and
let's
say
there's
the
abc
token,
and
these
two
parties
are
trying
to
swap
samina
for
some
abc.
A
So
this
public
key
b62q,
not
a
q
and
subg.
They
have
some
mina,
this
other
public
key
b62qp
emj7.
They
have
some
abc
and
they're
swapping.
So
how
do
they
swap
the
first
person's?
Their
mina
goes
down
the
second
person.
Their
meeting
goes
up.
The
second
person,
their
abc
token,
goes
down
the
other,
the
first
person
their
abc
goes
up.
Okay,
so
that's
a
swap,
but
there's
a
problem
with
this,
because
we
need
some
kind
of
authorization
right.
We
don't
want
to
just
allow
anyone
to
update
any
accounts.
A
There
needs
to
be
some
kind
of
authorization,
and
probably
everyone
knows,
but
how
do
you?
How
do
you
authorize
with
signatures?
So
here's
like
the
kind
of
raw
transaction
of
updates,
but
then
you
have
to
add
some
authorization,
so
each
update
has
it
has
some
authorization
attached
to
it
for
the
senders
we
have
signatures
and
for
the
receivers
we
have
nothing,
there's
no
authorization
needed
to
receive
funds.
Typically,
we
can
now
amend
our
definition
and
say
that
transaction
is
a
sequence
of
authorized
updates
and
this
will
be
our
new,
provisional
working
definition.
A
Okay,
a
sequence
of
authorized
updates:
okay,
fine,
but
actually,
if
you're
thinking
this
is
not
enough
either,
because
this
can
just
be
replayed
whenever
right.
Let's
say
I
make
this
transaction
right
now.
Okay,
now
I
want
to
just
repeat
it:
I
can
just
broadcast
it
again
say:
do
this
again,
do
this
again
do
this
again
and
of
course
we
don't
want
that
right.
No
one
agreed
to
that.
What
we
need
is
some
kind
of
predicate
which
constrains
application.
Well,
I
mean
predicate.
A
A
A
It's
the
non-sequality
check
on
the
sender,
nothing
on
the
receivers
and,
what's
the
update
on
the
senders,
we
decrement
the
balance,
we
increment
the
amounts
and
on
the
receivers
we
increment
the
balance
and
don't
touch
the
mods
okay.
So
that's
that
all
right,
so
this
is
sort
of
a
very
generic
setup.
Obviously
these
are
specific
authorization
specific
predicate.
So
this
is
not.
I
said
nothing
about
snaps.
So
far,
this
is
just
sort
of
normal
transactions.
A
So
how
would
snaps
be
different?
It's
in
the
choice
of
data
for
these
three
things
so
for
the
authorization
we
now
make
it
possible
not
just
for
a
signature
to
be
authorization,
but
actually
a
snark
proof
to
be
authorization
and
for
the
predicate
we
also
generalize
that
so
it's
not
just
a
non-sequality
check.
It's
a
range,
a
range
check
so
checking
that
a
value
is
in
a
particular
range
or
an
equality
check
on
any
field
in
an
account
or
in
the
blockchain
state.
A
So
things
like
current
block
height,
you
know
current
balance.
Whatever
say
you
know,
this
transaction
can
only
go
through
if
my
if
the
current
block
height
is
between
1000
and
1010,
and
what
is
the
update?
Well,
the
update
will
be
sort
of
arbitrary
updates
to
any
fields
in
an
account
with
some
constraints.
A
What
are
the
constraints?
First
of
all
balances
can't
go
below
zero,
okay,
obviously
so
right
so
we're
kind
of
explaining.
Now
how
what's
the
snap
transaction,
how
does
it
differ
from
a
normal
transaction?
I'm
saying
it
just
differs
in
the
choice
of
what
kind
of
data
we
have
permit
for
these
three
things
right,
so
there's
some
constraints
on
the
update.
A
It's
not
totally
arbitrary,
like
total
balance,
change
can't
be
has
to
be
negative,
so
you
have
to
be
not
creating
money
out
of
thin
air
unless
the
account
is
a
sort
of
permission
to
do
that
and
right
and
in
general
sort
of
updates
have
to
be
permitted
by
an
account's
permissions.
So
that's
all
very
nice.
You
know
I
mentioned
that.
There's
some
fields
I
said
arbitrary
updates
to
fields.
Let
me
just
be
specific
about
what
those
will
look
like
in
a
standard
account.
You
know
which
is
running
on
mina
right
now.
A
You
have
the
following
data:
there's
a
public
key,
there's
an
id
for
the
token
there's
the
delegate,
there's
the
nonce
there's
the
balance,
there's
actually
a
little
bit
of
extra
data
too.
A
snap
account
has
all
of
the
data
of
a
normal
account
plus
a
few
other
things.
It
has
a
verification
key
so
that
controls
how
the
what
snarks
are
allowed
to
sort
of
authorize
updates
the
account
and
it
has
an
application
state
and
the
application
state
is
an
array
of
field
elements.
Currently,
eight.
A
You
know
we'll
well
the
subjects
change,
okay
and
that
can
be
used
to
hold
whatever
data
that
the
application
might
need
and
we'll
see
a
few
examples.
So
let's
do
a
really
silly
example,
just
to
make
sure
that
we
understand
things
well.
So
how
is
the
silly
example
going
to
work
so
we're
going
to
have
an
application,
which
is
it's
an
account
that
you
can
only
move
money
out
of
on
fridays
and
only
once
per
friday,
and
anyone
is
allowed
to
move
money
out
of
it?
A
It
just
has
to
be
friday,
and
it
has
to
be
the
case
that
no
one
else
has
moved
money
out
of
it
on
this
friday.
Yet
I
hope
that
makes
sense.
It's
sort
of
a
this
is
like
a
who
can
get
the
first
transaction
in
to
take
money
out
of
the
account
every
friday.
I
guess
that's
the
game
right
so
remember.
We
have
our
authorization,
so
here
is
the
authorization.
It's
a
proof.
It's
going
to
be
a
proof
that
has
to
verify
against
the
verification
key
stored
in
this
account
vk1.
A
So
it's
going
to
be
against
the
verification,
key
vk1,
this
proof
and
it's
going
to
accept
the
whole
transaction
as
input,
so
the
circuit
that
is
hiding
behind
vk1
is
going
to
be
able
to
consider
the
whole
transaction
and
think
do
I
want
this
transaction
to
go
through
or
not.
So,
let's
unpack
that
a
little
bit.
How
is
vk1
going
to
make
that
decision?
Well,
let's
just
take
a
second
to
look
at
this
transaction,
so
we
have
the
proof.
Fine.
A
A
The
current
slot
is
kind
of
like
the
current
time,
and
I
looked
it
up
and
I
made
sure
that
this
is
a
friday.
I
think
it
may
have
been
last
friday,
so
it
says
you
know
I'm
currently
being
applied
on
friday
on
some
on
a
particular
friday
and
the
current
state
zero
should
be
equal
to
eleven
hundred.
Eleven
hundred
was
a
slot
that
was
a
week
ago.
A
So
we
want
vk1
to
do
the
following.
We
want
to
accept
the
transaction
that
is
provided
as
input.
If
the
following
is
the
case,
the
predicate
constrains
the
current
slot
to
be
on
a
friday
and
that's
something
we
can
check,
because
we
can
take
the
current
slot.
We
can
take
the
remainder
mod.
You
know.
A
Maybe
we
divide
it
by
the
number
of
slots
per
day
and
then
you
know
we
sort
of
take
the
remainder,
mod,
7
or
something
we
can
see
whether
it
actually
the
current
slot
predicate
says
today's
friday
and
vk1
will
enforce
that
state.
Zero
should
be
at
least
one
week
in
slots
before
that,
and
that's
also
something
we
can
check.
It's
just
you
know
check
the
difference
between
this
number
and
that
number
is
at
least
whatever
the
num
one
week.
A
However
much
one
week
is
3000,
something
and
vk1
will
also
say:
the
update
must
do
the
fault.
The
update
part
of
the
transaction
must
do
the
following.
It
must
set
state
0
to
the
beginning
of
the
interval
that
was
specified
for
the
predicate,
so
the
total
effect
of
this
is
you
can
only
transact
in
this
account
if
currently
it's
friday
and
the
last
time
the
account
was
touched,
which
is
recorded
in
state
zero
was
at
least
a
week
ago
and
yeah.
So
that's
that's
a
silly
example.
I
hope
that
makes
sense
right.
A
So
this
was
the
example:
here's
the
transaction.
We
have
these
two
parties,
the
sender
and
the
receiver,
and,
moreover,
I
want
to
stress
that
a
lot
of
privacy
could
be
added
to
this
example.
Okay,
how
well
for
one
we
could
make
the
verification
key
private.
We
could
change
this
application
and
actually
we'll
sort
of
be
this
way
by
default,
which
is
no
one
will
have
any
idea.
What
is
the
logic
governing
this
account?
That
would
be
totally
hidden.
You
know-
and
maybe
that's
a
good
thing.
A
A
A
The
transition
is
only
permitted
if
you
demonstrate
this
kind
of
knowledge,
or
this
kind
of
computation,
for
example,
that
today
is
a
friday
and
blah
blah
blah
blah
and
furthermore,
these
transition-
these
state
machines,
can
talk
to
each
other,
so
you
can
also
sort
of
condition
transitions
on
other
transitions
occurring.
In
other
snap
state
machine
accounts,
so
it's
really
kind
of
a
full
featured.
A
You
know
smart
contracting
sort
of
system
for
controlling
these
little
state
machines
which
are
running
instead
of
these
little
midnight
accounts.
And,
furthermore,
these
state
machines
are
optionally,
private,
so,
for
example,
this
they
can
be
hidden
or
the
like
in
this
case
over
here
where
the
state
is
hidden,
but
the
logic
is
public
or
the
state
can
be
hidden
and
also
the
logic
can
be
hidden.
So
you
can
totally
the
only
things
that
are
public
are
sort
of
which
other
state
machines
is
it
talking
to
and
the
the
balance.
A
So
I
think
there's
like
a
common
belief
in
in
this
industry,
and
I
think
you
know
it's
not
anyone's
fault
that
they
believe
this.
I
think
there
is
a
lot
of
pressures
that
cause
it
to
be
the
case
that
people
have
to
think
this
way,
which
is
that
technology
can
determine
social
relations
or
in
other
words
you
can
sort
of
restructure
society
or
how
people
relate
to
each
other
or
something
purely
through
technology.
A
I
don't
think
that's
the
case
at
all.
I
mean,
maybe
occasionally
that
happens,
but
very
rarely
is
that
the
case-
and
you
know
sometimes
yeah,
so
sometimes
it
can
sort
of
do
that,
but
more
often
than
not
it's
a
lot
more
affected
by
the
other
other
forces,
and
so
I
think
this
is
a
really
good
example.
To
keep
in
your
mind,
for
that
this
is,
it
was.
This
is
called,
what's
called,
aioli
pile,
okay.
A
This
is
a
basically
a
steam
engine
which
was
described
by
a
guy
named
hero
in
alexandria
in
the
first
century,
a.d,
so
like
you're,
50
or
something
so
they
invented
the
steam
engine.
But,
as
we
know,
it's
not
like
they
had
an
industrial
revolution
in
ancient
alexandria
and
the
reason
some
speculate
is
they
had
no
need
for
this
because
they
had
a
lot
of
slave
labor.
A
They
had
a
system
of
slave
labor
in
their
society,
and
their
society
was
not
organized
around
the
the
idea
of
unending
growth
of
productive
capacity,
so
there
wasn't
really
any
use
for
this
thing.
They
had
plenty
of
labor
to
go
around
and
there
was
no
constant
demand
for
increasing
productive
capacity.
So
I
think
this
is
just
a
really
good
example
to
kind
of
keep
in
your
mind
as
like
an
example:
the
fact
that
technology
does
not
it's
the
social
relations.
You
know,
above
all,
that
determine
the
impact
that
a
technology
will
have.
A
A
A
A
There
will
be
two
components:
one
will
be
some
kind
of
device
that
controls
the
lock
on
the
apartment.
What
does
it
mean
to
own
an
apartment?
I
guess
it
means
you
control
the
lock
and
other
people,
hopefully
don't
come
in,
and
then
there
will
be
like
a
snap
account
that
maintains
some
state
about
the
an
individual
resident.
Okay
and
there
will
be
a
key,
a
verification
key
in
that
account
resident
vk,
which
will
sort
of
govern
the
logic
of
this
little
state
machine
of
this
account.
A
So,
let's
just
dig
in
a
little
bit
to
what's
in
this
device.
What's
the
state
that's
in
this
device,
this
will
be
state
which
is
local
to
the
device
that
controls
the
lock.
So
it's
not
on
any
block
on
a
blockchain.
There
will
be
a
key
pair
secret,
key
public,
key
ska
pka,
and
there
will
be
some
state
recording.
What
is
the
public
key
of
the
current
resident?
A
So
it's
either
publicly
of
someone
or
it's
not
okay
and
then,
what's
in
the
snap,
there's
going
to
be
a
privacy,
preserving
commitment,
kind
of
like
a
hash
of
a
list
of
attributes
about
that
person,
for
example,
a
list
of
attributes
that
says
house
public
key.
You
know
the
public
key
of
the
house
that
this
person
is
currently
living
in
is,
but
none
of
that
is
visible
on
chain.
It's
private,
because
it's
a
a
hash.
Okay.
How
do
you
what's
the
flow
kind
of
for
moving
into
a
new
place?
A
First,
you
move
out
of
your
old
place.
You
send
a
snap
transaction
setting
house
pk.
You
know
this
house
pk
in
your
account
to
know,
although
no
one
sees
that
they
just
see
that
you've
changed
the
hash
and
then
you
tell
the
house.
You
know
that
you're
trying
to
move
into
that
you'd
like
to
move
in
and
you
prove
to
that
house-
that
little
mac
icon
computer,
that
your
current
house
pk
field
is
null.
So
that's
how
you
prove
to
them.
Hey,
I'm
not!
You
know
I'm!
A
Currently
I
don't
have
a
house,
then
the
house
sort
of
outputs,
a
signature
saying
yep,
I'm
good,
I'm
unoccupied
and
you
are
approved
to
move
in
and
then
you
send
a
snap
transaction
setting
your
house
bk
field
to
that
new
house's
public
key.
So,
just
to
kind
of
illustrate
this
a
little
bit
at
the
beginning.
The
local
state
would
kind
of
look
like
this.
A
This
is
if
you're
living
in
this
house
with
pka,
your
snap
account
would
have
pka
inside
of
it
and
the
local
state
of
the
machine
governing
house
a
would
have
your
public
key
pkx
inside
of
it.
Then
you
move
out
what
happens?
The
resonant
becomes
null
your
house.
Pk
becomes
null.
Let
me
just
kind
of
step
through
a
little
bit
how
the
state
machine
looks
just
to
you
can
see
the
this
is.
A
I
think,
a
nice
example
of
how
the
blockchain,
how
the
amino
blockchain,
plus,
like
some
devices,
interacting
with
it,
can
make
kind
of
a
cool
system.
The
same
machine
will
look
like
this.
Okay,
the
state
has
the
keeper
and
the
resident
okay,
the
keypair
is
never
going
to
change.
The
state
works
in
the
following
way.
If
you
input
a
signature
from
pkx
on
the
message,
I'm
moving
out
and
pkx
you
know,
is
equal
to
the
current
resident
then
set
the
current
resident
to
null
and
output,
a
signature
from
you
that
says
yep.
A
This
person
moved
out.
I
approve
and
then,
if
someone
wants
to
move
in
what
do
they
have
to
provide,
they
have
to
provide
a
signature
on
from
their
new
public
key.
This
is
a
new
new
guy.
Why,
on
the
message,
I'm
moving
in
and
a
zero
knowledge
proof
that
the
on
chain
commitment,
the
on-chain
hash
corresponding
to
pky's
account,
has
house
pk
set
to
null.
So
it
proves
hey.
A
A
Well,
there's
the
following
situation:
if
you're
in
a
situation
where
your
state
says
house
bk
equals
no
that
and
you
ish,
you
can
provide
a
signature
from
some
public
pka
on
the
message
you
know:
pkx
has
moved
in
then
you
are
allowed
to
update
your
state
so
that
now
house
pk
is
pa
and
then
that's
moving
in
and
what
about
moving
out?
Well,
if
you
can
provide
a
signature
from
on
the
message
from
you
know,
from
pka
on
the
message
pkx
moved
out,
then
you're
allowed
to
set
your
housebk
to
null.
A
So
in
that
way
we
kind
of
make
sure
that
these
two
state
missions
are
totally
in
sync
and
just
a
reminder.
This
is
happening
on
the
mina
chain.
So
I
just
want
to
take
a
second
now
to
kind
of
step
back
and
appreciate
some
patterns
illustrated
by
this
example.
So
the
first
is
using
commitments
for
the
privacy
of
on-chain
data.
So
in
this
way
we
can
have
some
data
that
lives
on
the
chain,
but
is
hidden
okay,
so
no
one
knows
what
your
current
house
public
key
is.
A
They
just
see
basically
a
hash,
okay
and
the
second
is
use
of
on-chain
data
to
interact
with
off-chain
processes
that
access
the
menu
chain
directly.
So
this
is
really
kind
of
where
the
succinct
blockchain,
like
really
kind
of
shines,
which
is
that
these
you
know
you
could
have
off-chain
devices
that
are
able
to
synchronize
to
the
current
chain
and
say
yep
you're
really
approved
for
this.
So
right,
let
me
just
take
a
second
just
like
remark
on
this.
Obviously
this
could
have
many
dystopian
uses
as
well.
A
A
So
let
me
just
comment
now
and
then
we'll
go
to
questions
about
some
work.
That's
currently
under
actors
element
that
I
think
is
very
exciting.
So
this
is
what
we're
sort
of
provisionally
calling
http
snaps,
so
it's
like
https
but
snaps,
and
this
will
basically
allow
importing
data
off
data
from
websites
basically
onto
the
media
chain
and
and
to
use
in
applications.
So
I
for
some
reason
silly
examples
helped
me
understand
how
the
thing
works,
like
my
stupid
example
before
of
the
friday
account.
A
A
A
silly
example
is
you
could
make
a
snap
account
that
has
maybe
some
tokens
in
it
and
would
let
anyone
move
money
out
of
it
if
they
prove
they
produced
a
tweet
that
had
at
least
ten
thousand
likes
that
contains
the
word
pizza.
So
you
could,
you
know,
have
sort
of
a
decentralized
marketing
campaign
for
pizza
and
then
just
a
comment
before
I
end
and
go
to
questions
on
kind
of
looking
forward.
So
there's
this
http
snaps
work,
which
is
in
development.
A
Now
you
know
shout
out
to
everyone
who's
working
on
that
bonusri
vitali,
joseph
dan
matthew.
I'm
excited
for
how
that
will
develop
and
then
there's
the
snaps
developer
sdk,
which
is
also
under
development
and
we'll
have
more
to
sound
later
and
yeah.
With
that,
I
will
say
thank
you
for
watching
and
let's
see
I'll
see
if
there
are
any
questions
in
the
friday
example,
the
next
state
zero
must
be
exactly
one
week
later,
rather
than
at
least
one
week
later.
Otherwise
you
have
a
dos
attack.
A
A
How
does
amina
resolve
that?
Okay,
decentralization
problem,
it
looks
like
monetary
is
given
a
good
answer
to
this?
Are
there
plans
of
bootstrapping
snap
development
through
hackathons
and
or
something
like
an
incentivized
testnet?
So
I
let
me
not
comment
too
much
on
that
we,
we
will
certainly
be
having
some
kind
of
snap
development
program.
I
look
forward
to
to
you,
know
kind
of
sharing
more
about
that.
A
In
the
future
would
adapt
like
yours
won't
be
deployable
on
mina,
so
von
sri
says
yes,
and
I
will
just
echo
that
yep
you
can
implement
something
like
uniform.
It's
we
actually.
Actually.
This
is
a
great
example
because
we
actually
tried
to
spec
out
like
if
things
like
that,
how
many
people
work
on
you
know
you
can
find
it
from
there
sure.
So
is
a
state
machine,
validating
snarks.
A
So,
yes,
basically
each
state
machine
in
order
to
transition
that
state
machine,
you
need
to
provide
a
snark,
the
advantage
of
being
22
kilobytes.
So,
okay!
Well,
I
maybe
don't
I
won't
say
anything
about
this
20
kilo
kilobytes
thing,
because
it's
actually,
I
think,
slightly
smaller.
But
let
me
I
probably
shouldn't
say
anything
about
that.
A
The
advantage
of
being
really
small,
like
22
kilobytes,
for
example,
is
that
any
application,
even
with
the
crappy
internet
connection,
can
easily
you
know
any
device
can
easily
sort
of
get
that
data
and
then
verify
that
data
and
interact
with
that
interact
with
the
chain
directly
in
that
way.
Okay,
oh
it's
11,
kilobytes,
otherwise,
join
us
in
the
discord.