►
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/a-snarks-tale-a-story-of-building-snark-solutions-on-mainnet/
We tell the story of deploying a real-world solution using SNARKs as a core primitive; highlighting many cutting edge SNARKs and their limitations in the hope to identify opportunities for the community to make Ethereum more SNARK friendly, creating a diverse ecosystem where SNARKs built upon a variety of unique primitives can thrive.
Speaker(s): Jackson Blazensky, Severiano Sisneros
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: SNARK,applications,EIP
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
So
the
next
talk
is
going
to
start
in
a
bit.
It's
going
to
be
a
tail,
a
snark's
tale,
a
story
of
building
snark
Solutions
on
the
mainnet
by
Savvy
Accord
from
from
the
graph.
But
before
we
get
ready,
does
anyone
have
any
interesting,
snark,
Tale
where's
the
do
people?
Do
people
actually
use
zkps
here
in
any
like
user
way,
or
is
one
person
that's
nice?
A
A
B
So
first
I
think
everybody
here
has
at
least
heard
of
a
snark.
So
let's
just
kind
of
quick
recap
of
the
main
character
of
our
story.
This
is
the
you
know.
The
expanded
acronym
of
snark
succinct,
non-interactive
arguments
of
knowledge
in
particular.
What
we
care
about
is
the
sickness
property
of
these
snarks.
So
it's
kind
of
like
that
computation
compressing
the
scalability
solution
for
ethereum
those
properties,
one
like
notable
Omission
from
our
from
our
snark
here's.
We
don't
have
the
ZK
piece,
and
so
in
our
Solutions.
B
We
don't
necessarily
care
too
much
about
the
ZK.
The
Privacy
piece,
which
is
like
really
this
scalability
piece
that
we're
after
and
also
as
I'm,
laying
out
the
acronym
snark
I
notice,
something
that
one
of
my
co-workers
10
year
old
daughters,
noticed
and
she
said
shouldn't
it-
be
called
a
snack
and
she's
not
wrong.
So
all
right,
so
our
story,
every
story
has
a
challenge,
a
reason
for
it
to
exist,
and
this
is
our
challenge.
B
Let's
see,
you
can't
really
see
the
bottom
line
there,
but
that's
all
right,
the
so.
Basically
what
we're
trying
to
do
is
we
are
trying
to
use
a
snark
to
resolve
like
one
million
independent
payment
channels
within
the
graph
protocol,
so
the
graph
protocol,
the
way
that
the
ensure
indexers
get
paid
is
they
have
an
entity
called
the
gateway
and
every
time
the
indexer
provides
a
result
from
a
query.
You
know
they
get
paid
some
amount,
and
so
then
the
Gateway
issues
them
a
receipt.
B
They
need
to
somehow
prove
that
all
one
million
of
these
receipts
have
valid
signatures,
that
none
of
these
receipts
have
been
repeated
and
that
the
total
value
adds
up
to
the
total
value
that
they
claim
that
they're
owned,
and
so
one
way
they
could
do
this
right.
Is
they
just
take
that
bundle
of
a
million
receipts
throw
that
on
chain
and
then
run
some?
B
You
know,
BL
signature,
verification
on
all
one
million
receipts,
but
you
know
that's
a
little
costly,
so
we
want
a
better
solution
and
so
the
solution
seems
like
really
well
suited
for
a
snark
right.
Basically,
we
want
to
take
this
computation
of
you
know
a
million
different
signature
verifications,
throw
it
into
a
snark.
That
can
say
yes,
all
one
million
of
these
are
valid.
Total
value
adds
up
to
the
claim
total
value.
B
B
Another
really
interesting
thing
about
this
primitive
is
we're
trying
to
use
a
snark
as
a
black
box,
so
really
we're
just
trying
to
get
incorporated
into
this
payment
Channel
protocol,
and
we
don't
really
want
to
have
this
snark-
impose
any
extra
requirements
on
the
protocol
itself
right.
We
just
want
this
snark
to
be
this
black
box.
We
plug
in
a
scalar
table.
We
get
out
of
proof
that
proof
goes
Unchained,
you
can
verify
it
and
you
don't
really
impact
the
security
of
the
system
in
any
way
based
off
of
your
snark
and
then
yeah.
B
The
final
thing
here,
the
business
side
of
of
this
oh
yeah:
can
you
make
this
whole
process
of
proving
and
verifying
costs
less
than
thirty
dollars?
Otherwise
it's
not
very
useful
to
the
indexer.
So
thanks
go
all
right.
So
so
now
we're
going.
We
got
our
challenge,
we're
trying
to
prove
this
massive
table
of
data
and
basically
prove
this
massive
table
of
signature
verifications.
How
do
we
know
whenever
we're
done
right?
How
do
we
know
that
we've
succeeded?
There's
a
bunch
of
different
metrics
to
quantify
snark
performance.
B
We
use
prover
time,
prover
memory,
proof,
size
and
verifier
compute,
so
approver
time
is
basically
just
it's
the
amount
of
time
that
the
approver
spends
generating
their
proof
right.
So,
in
this
case,
it's
the
indexer.
The
indexer
has
their
big
table
they're,
going
to
run
this
proving
algorithm,
it's
going
to
take
them
some
amount
of
time
to
generate
that
proof,
prover
memory.
B
This
is
like
an
actual
physical
requirements
of
the
machine
that
they're
using
to
generate
this
proof
right,
so
they
they've
got
if
they
got
a
laptop
with
16
gigs
of
memory,
you're,
not
gonna.
The
algorithm
requires
more
than
16
gigs
of
memory.
You're
gonna
run
into
issues.
You're
not
gonna,
be
able
to
generate
a
proof
proof
size.
This
is
the
size
of
that
proof
that
could
spit
out
of
the
snark.
This
is
what
gets
sent
on
chain,
so
this
is
obviously
important
right.
B
B
Whenever
we
talk
about
the
verified
compute,
we're
really
going
to
just
highlight
the
most
expensive
operations
that
the
verifier
is
going
to
run,
and
so
this
gives
us
kind
of
like
a
quick
way
to
filter
out
techniques
and
estimate
gas
costes,
and
all
that
just
another
thing
on
this
on
these
figures
right,
we'll
see
them
repeatedly
this
x-axis.
Basically,
this
is
showing
our
statement
size
as
it's
growing
right.
So
we
said
we
want
to
prove
this
big
table
of
signature
verifications.
B
The
goal
is
to
get
to
this
kind
of
size
2
to
the
28
instance,
and
then,
by
seeing
you
know
how
this,
how
these
these
metrics
Trend,
we
can
kind
of
get
an
idea
for
like
engineering
Solutions
right
and
we
get
an
idea
how
our
problems
are
growing
and
stuff
like
that.
So
those
are
our
plots
and
now
we
start
our
story
and
I
like
maps
and
I
like
stories
with
maps
and
so
we're
going
to
have
a
map.
B
But
a
quick
caveat
about
Maps
is
this:
is
a
map
of
the
world
in
450
BC,
it's
accurate,
but
we
can
tell
it's
not
the
full
truth
right,
there's
a
whole
lot
to
be
discovered
still
so
here's
our
map.
This
is
cryptography
land,
as
we
saw
it
at
the
start
of
this
program
and
especially
in
particular
when
we're
looking
at
snarks.
So
we've
got
kind
of
two
major
continents
of
snarks:
we've
got
transparent,
snarks
and
we've
got
these
non-transparent,
Starks
and
so
non-transparency
arcs.
These
are
snacks
that
require
some
sort
of
trusted
setup
right.
B
So
we
saw
yesterday
when
we're
talking
about
dank
sharding
and
we're
going
to
have.
You
know
this
kcg
trusted
setup
ceremony.
That
ceremony
is
what
is
required
for
these
non-transparent
snarks,
transparent
snarks.
The
idea
is,
they
don't
require
this
kind
of
trusted
set
up
ceremony.
You
can
kind
of
run
them
out
of
the
box.
B
B
It's
a
black
box
like
we
said
we
don't
want
the
snark
to
impose
any
security
requirements
on
top
of
the
system
that
we're
using,
and
so
when
we
think
about
this
trusted
setup,
we
can
debate
how,
like
the
Practical
implementation,
the
Practical
implications
of
this
trusted
setup
right
like
if
you
only
have
two
people
running
the
trust,
a
set
of
ceremony.
You
have
to
trust
that
both
of
them
are
honest.
B
You
know,
as
you
increase
the
number
of
participants,
you
know
that
level
of
Trust
might
change,
but
the
point
is
you're
still
making
an
argument
right,
there's
still
some
other
additional
argument
that
goes
on
top
of
the
math
of
your
proving
system,
and
so
initially
we
said
we
want
this
thing
to
be
as
black
box
as
possible.
We
don't
want
to
have
to
deal
with
those
extra
arguments,
so
we
want
to
start
with
the
transparent
snark
all
right
so
now,
knowing
that
we're
going
to
be
using
a
transparent
snark.
Where
do
we
go
from
here?
B
And
so
we
start
by
looking
at
our
problem
statement
and
we
start
trying
to
find
you
know,
what's
the
the
next
best
snark
to
use
the
thing,
that's
unique
about
this
problem
statement
right
is
it's
highly
structured,
so
basically
we're
kind
of
proving
the
same
function.
You
know
a
million
times,
so
if
we
could,
basically,
if
we
could
kind
of
reuse
these
circuits
right,
maybe
we
could
significantly
reduce
costs
either
proof
size,
verification
time
that
type
of
thing,
and
so
in
particular,
what
we're
curious
about
is.
We
could
come
up
with
one
circuit.
B
This
is
some
f
circuit
that
can
be
used
to
prove
all
of
these
snark
things
for
a
single
row,
and
so
then,
if
we
could,
if
we
could
do
that,
then
could
we,
you
know,
generate
proofs
for
each
individual
row
and
then
somehow,
like
aggregate
them
all
together,
and
then
we
get
some
aggregate
proof
and
the
hope
is
that
aggregate
proof
will
cost
only
about
the
same
to
to
verify
as
verifying
this
single
small
proof.
So
people
have
been
looking
in
stocks.
You
can
see
where
we're
kind
of
going
with
this.
B
But
at
a
very
high
level,
recursive
snarks,
it's
kind
of
like
what
I
was
saying
right.
We
we
have
the
idea
is
we
have
a
circuit,
we
want
to
repeat
the
computations
on
that
circuit
and
then
kind
of
like
aggregate
these
proofs
together
and
the
way
that
recursive
Stars
tend
to
get
around
this
in
practice.
Is
you
take
your
original
circuit?
B
You
can
like
augment
it
with
some
snark
verify
circuit,
so
it
runs
the
verify
algorithm
of
the
of
your
proving
system,
and
then
you
have
some
resulted
F
Prime
circuit,
and
then
this
F
Prime
circuit
is
kind
of
what
you
start
chaining
together
to
prove
all
of
your
rows
in
our
case,
privilege
rows
with
a
Scala
table
and
the
the
really
important
thing
here
is
the
cost
to
verify
and
like
the
cost
improved
size
is
really
only
tied
to
the
cost
for
proving
and
verifying
this
this
one
F
Prime
circuit.
So
that's
really
encouraging.
B
Maybe
you
know
we
could
significantly
reduce
our
problem.
Using
this
we
use
a
primitive
called
Nova,
so
it
hasn't
seen
too
much
Traction
in
this
community
that
I've
seen
yet.
But
it's
a
it's
a
newer,
primitive.
It
was
presented
at
crypto
this
year,
the
it's
what
it
really
has
going
for
it
is.
It
can
do
kind
of
what
Halo
does,
but
it
has
like
the
smallest,
constant
size,
verifier
circuit.
So
we
remember
that
F
Prime
we
have
that
little
verify
circuit.
B
The
Nova
is,
is
the
smallest
that
exists
in
the
current
literature
and
it's
constant
size,
so
it
doesn't
depend
on
the
size
of
your
original
F
circuit
yeah.
Just
a
note
for
in
our
case
this,
this
F
Prime
circuit
ends
up
being
about
size
2
to
the
15,
and
so
this
is
this
constant
proof
size
and
the
the
verifier
work
is
tied
directly
to
this
kind
of
two
to
the
15..
B
You
have
something
like
kind
of
unique
mathematical
Primitives
that
you
got
to
use,
and
so
in
that
particular
is
called
these
cycles
of
elliptic
curves
and
nobody
uses
the
same
thing.
That
pasta
does
and
it
actually
worked
together
on
this,
so
I
think
too
surprising
there.
What
gets
surprising
now
is
whenever
we
actually
start
looking
at
our
costs.
B
The
first
thing
that
we
notice
is
these
constant
size
here
right,
so
the
proof
size
is
constant.
This
verify
is
compute
is
constant.
So
basically,
what
we're
saying
is,
as
we
increase
on
our
x-axis
here,
we're
basically
proving
more
and
more
rows
in
our
scalar
table
and
this
proof
size
in
this
verifier
compute
stay
constant
because
again,
the
proof
and
the
the
proof
size
in
the
verifier
compute
are
tied
only
to
that
F
Prime
circuit.
So
we
get
this
nice
kind
of
constant
proof,
size
verify
compute.
B
That
doesn't
depend
on
the
the
number
of
rows
that
we're
trying
to
prove
the
prover
time
here.
This
is
pretty
much
linear,
in
the
instance
size
that
we're
trying
to
prove
so
linear
in
the
number
of
rows
that
we're
trying
to
prove
because,
basically
like
the
prover,
has
to
do
the
work
right
so
in
in
this
particular
instantiation.
The
prover
is
just
kind
of
going
row
by
row,
kind
of
proving
and
accumulating
so
you
kind
of
just
see
this
linear
growth
here
and
so
I
mean
based
off
the
implementation
that
we
have
available.
B
You
know
we
would
estimate
you
know
51
hours
to
prove
using
Nova
for
a
an
instance
as
as
big
as
we
want
to
get
that
may
or
may
not
be
a
a
fundamental
limiter,
but
really
what
we
see
the
big
limiter.
Is
this
verify
compute?
So,
even
though
verify
compute
is
constant,
it
still
is
a
very
expensive
operation
that
needs
to
run,
and
so
in
particular
it's
part
of
this
bulletproof's
polynomial
commitment
scheme.
B
You
have
to
run
this
elliptic
curve,
multi-exponentiation
and
it's
you
know
size
2
to
the
15.,
so
32
000,
basically
up
to
the
curve
multiplications,
and
so
the
problem
really
is
nobody's
going
to
work
with
pasta.
Curves
ethereum
only
has
pre-compile
support
for
one
curve
all
to
be
in
128,
and
so
this
is
kind
of
a
famously
known
problem
at
this
point.
B
So
if
we
wanted
to
run
this
verify
algorithm,
we
would
have
to
implement
smart
contracts
for
pasta
curves,
so
that
in
itself
is
a
cost
that
we
would
have
to
absorb.
And
then,
if
we
did,
we
would
see
you
know
based
off
of
some
people
have
done
a
similar
work.
A
scalar
amount
would
still
cost
about
350
000
gas,
and
so,
if
we
could
use
you
know
some
algorithms
for
speeding
up
this
multi-exponentiation,
we
could
get
these.
B
These
total
costs
down
to
you
know
764
million
gas,
or
you
know
seventy
six
thousand
dollars
off
of
some
estimate
of
gas
to
dollar
ratio.
So
clearly
this
isn't
the
solution
that
we're
looking
for.
Maybe
there's
some
engineering
things
we
could
do.
We
could
take
advantage
of
all
bn128.
It
also
has
a
cycle,
but
for
now
we'll
table
this
and
we'll
go
look
elsewhere.
B
So
where
do
we
go
from
here
again
we
want
a
transparent
snark
and
we
would
really
like
to
use
Primitives
that
can
take
advantage
of
you
know
things
that
are
supported
by
ethereum.
So
we
look
for
Primitives
that
use
Albion
128
Albion
128
is
a
pairing
friendly
curve,
so
we're
going
to
look
for
transparent
stock
Primitives
that
use
pairings
and
we
don't
really
have
to
look
too
far
so
Nova
the
same
authors
who
wrote
Nova.
B
They
also
authored
something
called
quarks,
and
so
this
is
a
another
transparent,
snark,
primitive
and
in
particular,
what's
unique
about
it.
Is
they
invent
some
pretty
unique,
polynomial
commitment
schemes
that
use
pairings,
but
they
don't
require
trusted
setup,
and
so
they
can
get
some
significantly
better
performance
than
say
bulletproofs
from
a
verifier
from
a
verifier
standpoint.
So
it's
pretty
unique
again
similar
to
how
Nova
was
written
they're
using
Spartan
as
their
IOP.
B
So
basically
they
take
one
of
their
polynomial
commitment
schemes,
either
Copus
or
Dory
pair
it
with
Spartan,
and
then
now
they
have
a
snark.
The
nice
thing
about
them.
They've
got
fast
and
spaces
fast
and
space
efficient,
provers,
that's
a
property
of
both
polynomial
commitment
schemes
and
the
Spartan
primitive.
The
proofs
are
they're
a
little
bit
bigger
than
what
you
would
get
out
of
something
like
bulletproofs,
but
they
could
be
manageable
and
then
the
nice
thing
about
them
too.
They
have
relatively
cheap
verifiers.
B
Oh
yeah,
then
just
another
comment:
there's
actually
some
more
research
by
the
same
kind
of
group
of
authors
about
Spartan
that
is
used
to
prove
kind
of
like
simdi
computations
right.
So
you
have
basically
our
scalar
table
right.
We
have
one
circuit,
we
have
multiple
inputs,
single
input,
multiple
data
and
so
they've
got
some
stuff
off
the
shelf
that
can
seemingly
help
us
with
our
problem.
B
So
we
get
really
excited
about
this,
so
let
me
start
digging
in
to
quarks
and
we
want
to
use
it
and
we
want
to
try
to
try
to
build
snacks
with
it.
The
first
problem
that
we
run
into
is
there's
no
open
source
implementation,
so
that
in
itself
makes
things
pretty
challenging.
There's
no
copis,
nor
is
there
a
Dory
PC.
Although
I
was
talking,
it
sounds
like
there
might
be
a
door
implementation
available
somewhere
as
of
a
couple
days
ago,
but
I
haven't
seen
it
yet.
B
So,
knowing
that
this
polynomial
commitment
scheme
is
kind
of
like
the
primary
cost
driver
for
these
snarks,
we
implemented
the
Copus
PC
using
the
rust,
Arc
Works
libraries,
and
then
we
ran
it
to
get
some
some
benchmarks
right
and
kind
of
get
some
estimated
costs,
and
so
these
are
the
the
results
for
Copus
PC.
The
one
thing
that
we
see
in
approver
time
now
is
is
pretty
nice
right,
that's
565
seconds
for
the
biggest
incidence
size
that
we'd
want
to
prove
so
yeah,
that's
nice,
the
prover
memory
requirements.
B
You
know
the.
If
you
have
a
machine
that
has
four
gigs
of
memory,
you
should
be
able
to
run
this
again.
This
is
our
proof
size,
so
we're
in
the
orders
of
kilobytes
here
right,
so
the
small
basically
at
the
biggest
InstaSize,
we
got
a
proof
of
about
nine
kilobytes
and
then
this
verify
compute.
This
is
again
the
we'll
see
this.
This
becomes
the
big
problem,
we're
talking
about
doing
electric
curve,
arithmetic
again,
sometimes
how
bulletproofs
was
doing.
The
instant
sizes
are
significantly
smaller,
but
there's
still
significant
work
to
be
done
there.
B
To
contrast,
copis
with
you
know,
Dory,
which
is
the
other
polynomial
commitment
scheme.
Dory
takes
advantage
of
some
pre-computation
to
reduce
this
verifier
time,
or
this
verify
compute
work
even
further
and
as
a
consequence,
like
their
proofs,
are
about
three
times
bigger.
So
just
take
these
proof
sizes
multiply
by
three
and
then
the
verify
compute
is
significantly
less
like
we'll
see
on
the
next
slide,
so
Quark
slick
promising
at
least
the
polynomial
schemes
look
promising
on
paper.
B
There
is
no
GT
exponentiation
support,
so
yeah,
and
so
yes,
that's
that's
a
significant
problem
and
basically
we
simulated,
we
implemented
some
GT
arithmetic,
we
simulated
the
total
cost
and
we
got
down
to
about
4
million
gas
to
do
one
exponentiation
and
so
a
whole
Dory
verify
would
cost
about
125
million
guests,
or
you
know
12
000,
so
smaller,
but
we're
still
not
there
yet,
and
so
now
we
start
asking
questions
you
know:
where
do
we
go
is?
Do
we
really
want
to
use
a
transparent
snark?
B
Let's
go
see
what
this
plonk
is
all
about
that
everybody's
using
so
you
know,
plot's
very
popular,
it's
got
a
ton
of
support.
Proofs
are
small
verification,
is
the
cost
is
known
and
really?
What
we'll
see
really
importantly,
is
plunk
is
supported.
The
verifier
is
supported
by
pre-compose
in
ethereum,
so
all
of
the
the
heavy
arithmetic
is
cheap,
so
we
dig
into
Planck.
Fortunately,
like
I,
said:
Planck
is
so
popular
there's
a
lot
of
high
quality,
open
source
implementations.
B
B
Is
this
prover
time
improver
memory
is
expensive,
so
Planck
needs
to
run
ffts
ffts
require
you
know,
n
log
n
work
and
they
are
also
not
space
friendly,
and
so,
if
we
try
to
prove
just
a
raw
two,
eight
a
two
to
the
28
size
incidents,
we're
looking
at
you
know
that
that's
500
minutes.
So
we're
looking
at
like
about
eight
hours,
and
you
need
about
three
ten
three
terabytes
of
memory
on
your
machine
to
be
able
to
complete
a
proof
of
this
size.
You
could
do
it,
you
could.
B
You
know
go
to
the
cloud
rent
a
gcp
instance
and
you
can
get
it
done
for
about
200,
but
you're
not
gonna,
be
able
to
prove
this
out
of
the
box
all
right.
So
now
we
start
asking
our
questions.
We've,
we
started
getting
introspective
we've
surveyed,
we've
surveyed
some
snarks
we've
flip-flopped
between
transparent
snarks
to
to
trusted
set
of
snarks.
What
are
the
important
questions
here?
So
one
thing
that
really
popped
up
is:
why
is
Planck's
verifier,
so
much
cheaper
than
say,
dory's
verifier?
B
B
In
particular,
there
are
interesting
polynomial
commitment
schemes,
these
Copa
schemes,
Dory
schemes
that
could
be
useful,
but
we're
not
going
to
build
a
room,
we'll
never
be
able
to
run
on
ethereum
being
that
because
things
are
too
expensive
because
they're
not
supported
by
say,
pre-compiles,
and
so
one
of
the
questions-
and
this
is
kind
of
just
like
a
a
thought.
Question
right
is
ethereum
ecosystem
artificially.
Selecting
for
snark
Primitives
with
costly,
don't
reflect
reality.
B
We
say
ethereum
is
driving
snark
research
and
it
is
and
we're
seeing
like
a
flurry
of
development,
especially
for
Primitives
like
Planck,
but
is
I
mean
the
reason.
Is
it's
cheap
to
verify?
And
so
the
question
is
you
know
that
costs
aren't
reflecting
reality.
We
want
to
address
this
question
if
there
are
other
people,
who've
kind
of
run
into
some
other
things
like
come
talk
to
us.
We
have
ideas
of
how
to
address
this
yeah
with
the
last
minute.
Where
do
we
go
next
right?
B
So
we've
gone
all
over
the
place.
We've
surveyed,
a
bunch
of
snarks,
actually
there's
a
ton
of
snarks
in
practice
right
and
we
look
at
all
of
these.
This
is
this.
Is
this
was
our
path,
but
you
know
there's
a
whole
bunch
of
places
we
can
go.
The
other
point
here
is
snarks.
Generally,
we
think
of
them
as
proving
kind
of
arbitrary
programs,
NP
complete
or
mp
NP
statements
that
power
as
a
cost.
There
are
other
proving
systems
that
have
cheaper
costs.
B
So
it's
a
pretty
cool,
primitive
I
haven't
really
seen
it
used
much
in
practice,
but
we
have
a
unique
application
here
on
blockchain,
and
so
we
can
take
advantage
of
that
and
run.
You
know
this.
This
reference
scheme
and
basically
the
the
bottom
line,
is
we
get
small
proofs
small
verify
time
similar
to
plonk?
B
These
costs
are
about
the
same
cost
of
aggregating,
just
regular
signatures,
so
elliptic
curve,
arithmetic
and
we
can
get
something
done
for
you
know
less
than
30
dollars
quote
I
like
it's
worth
thinking
about
again,
this
is.
We
are
Edge
node,
semiotic
labs
for
core
Developers
for
the
graph
I'm
with
semiotic
AI,
we're
looking
for
people
who
are
interested
in
these
type
of
problems,
we're
also
looking
for
people
who
are
interested
in
you
know:
AI
reinforcement,
learning,
all
kinds
of
good
stuff,
we're
looking
for
people
if
this
was
interesting,
Reach
Out.