Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/730 Thanks!
So our last speaker for tonight
is Sven Salberg,
and he's going to talk about the
cash anonymous cryptocurrency.
The subtitle of this stock is Zero
Knowledge, Succinct, Non Interactive
Arguments of Knowledge for White People.
If there are people who could memorize
that and can repeat, you get karma
points.
Sven is a mathematician,
a coder, a cryptographer.
He also does functional programing
in C, which probably
makes him the person you might want to
listen to.
Plays a round of applause
for.
Thank you. Thanks for the introduction.
Um, yeah, thank you all for coming.
So the short version of the subtitle
is A Zik Snarks for the Interested
Layperson.
Quick check. Has anybody from the
audience heard the term XXX snark before?
Oh, that's more than I expected.
OK, um,
so at the end of this talk, hopefully
you will know how these things can
be used to build a cryptocurrency
that which is kind of like bitcoin
but has better privacy
and anonymity properties.
Um, little
disclaimer. I won't be able to explain to
you how the XXX snarks work,
so please don't
be too disappointed by that.
That will be another talk for next year
maybe.
All right.
So let's start.
Right.
Um, zie cash
is like I said, it's a cryptocurrency,
uh, magic Internet money.
Um, kind of like Bitcoin
is, in fact based on the Bitcoin
code base.
So it's kind of like an old coin
that you may have known.
But other than a lot of other
coins, it actually adds
a substantial new
feature to the protocol.
And that is mainly a new type of
transaction that is
capable of shielding
the sender, the receiver
and the amount of money being
transferred.
Um, now this type
of transaction leaves next to
the regular Bitcoin type
transaction. So you actually have two
types of addresses, uh,
ones. It's called a transparent address.
It starts with a T and a new
type of address that starts with a Z
or Z, um,
which gets used by the new type
of transactions.
And yes, like I already said, it uses
these so-called Zeca snarks, which
are relatively recent
kind of mathematical magic.
As I like to say.
I think the earliest 2010 is the
earliest citation
from the Z cache spec.
Um, yeah.
Uh, for a little bit of history, the
cache is a is an evolution basically of
two academic proposals, one called
zero coin, which was still
pretty different from Z cache
and the other is called zero cache.
And that is already almost
like C cache.
Um, so you could consider
Z cache a um, an
implementation of zero cache with
some refinements and improvements.
Um, now, uh,
the or a number of
the inventors of zero cache and
a number of other people have formed a
company in order to
actually um.
Yeah. Get this, get the system off the
ground as its own
alt coin.
And I'm told they are also
in the process of forming a nonprofit
foundation to govern, uh,
the future development or something.
Um, a little disclaimer.
I am not affiliated with any of these
entities.
I'm just interested bystander who happens
to think you can explain
this stuff a little bit.
Uh.
So
because we don't have so much time,
this talk is going to focus entirely
on the technical aspects, um,
there are also other interesting
questions, but I just want to explain,
how does the system work in the abstract?
What do the transactions look like?
What exactly is being hidden?
What isn't hidden maybe?
And how can you how can you verify
even the validity of a transaction
if you know almost nothing about it?
Um, yeah.
And lastly, it'll then become
clear whether snarks come in.
So if you know Bitcoin, this is, uh,
just to recap, this is a Bitcoin
transaction.
Um.
Oh, sorry.
So imagine Bitcoin,
I don't want to go into a block chain
or any of that here because we don't need
to please imagine Bitcoin just as
a long list of transactions that is
publicly verified.
That is entirely enough
for this talk because
the Bitcoin system is basically
transferred over for the transparent
world.
Um, we can just focus
on an individual transaction.
OK, so this is one
single Bitcoin transaction of
which you have a long list in
the world, and each such
transaction takes a number of input
amounts from previous transactions
and then declares a number of outputs,
um, amounts to
some receiver addresses.
And in order for this transaction to be
valid, you needs
most of all.
Well, these two things you need
to show that you actually have authority
to spend the inputs and you need to
make sure that, well, the input
amounts balance with the output amounts
right now.
Uh, like I've already alluded to with
that, the picture looks almost exactly
the same, except there is a new block at
the end of the transaction that adds
some, um, things called joint
splits.
And, um, yeah.
What these are and how you can
verify and prove their validity
is the main topic.
So let's jump right in.
What does a joint split, a joint split
look like?
So as a as
a major difference from Bitcoin
value in these new cash transactions,
it's actually transferred in the form of
virtual coins.
That's kind of ironic because Bitcoin,
despite the name, doesn't actually
contain any sort of coin concept
anywhere.
Um, here we
have that.
And you can see from the picture
the, uh, that each joint split
takes two coins as inputs and
it generates two coins as outputs.
So the input coins are consumed and no
longer valid at the end and two new
coins come into existence.
So why to um, just
really quickly? That's because
that is general enough for any thing.
If you just want to consume one coin, you
said the other two zero.
If you just want to produce one, you said
the other to zero.
And if you want to consume more or create
more, you just combine multiple
of these joint splits in the same
transaction.
OK, um,
and now the important part,
each such virtual coin has a
well, what's called a not plaintext.
That is basically a tuple of values
that contains
the information about that
coin, namely its owner, its
value and some technical
technical values that will get back to
me. And this stuff is
is kept secret.
It is known by the owner of the coin, but
nobody else.
The only things that are published
actually in the block
chain in the as part of the joint split
statement, are these
so-called modifiers on the left here
and commitments on the right.
Don't worry so much about what those are
for the moment, but these
are just numbers that are uniquely
derived from the,
uh, from the coin, from the coin
plaintext.
Um, and yeah, the
fires are always used when spending
the coin and the commitments are always
used to create the to bring
the coin into existence.
Um, so since these numbers
are different and they
are actually derived in such a way that
they cannot be matched to each other,
you can't immediately trace
a transaction, right.
Mm.
And this
is called a nullifier simply because
it's not it is a value that essentially
nullifies the coin, right?
It gets consumed after that.
It is no longer a valid coin.
And the way this works is really simple.
I can explain this on this picture.
Each node in the network
simply keeps a list of all the nullifier
as it has ever seen, and it keeps a list
of all the commitments it has ever seen.
And when a new joint split comes in,
it's simply checks.
The nullifier is against the list.
It is already seen and
only if it is nowhere in there.
This is a coin that's still valid.
So that's really simple.
This is double spending protection.
Very important, obviously,
but that doesn't require any magic yet.
What requires magic is,
well, checking that
I don't pull these numbers out of
thin air, that they actually correspond
to actual coins and that everything
balances out. The values need to balance.
I actually need to be the owner of the
coins and so on.
And explaining how that works
is the rest of the talk.
So this is what the joint split looks
like and less of a picturesque
form, more of a formal form.
This is actually from the paper with
slight adaptations for readability.
You can see there are a number of number
of values. We are not interested in most
of them.
But you can see the two modifiers
here for the input coins
and you see the commitments for the
output coins and then you see a value
called R t.
That's a that
is a number that uniquely identifies
the set of commitments in existence
at that moment.
So it establishes the context
for the nullifier as for instance,
if you know what a Merkle tree is, this
is actually the root of a Merkl hash
tree.
If you don't know what a Mercal tree is,
don't worry.
Simply think of it as a
well, like I said, a unique a number
that uniquely identifies the set of coins
in existence.
And then lastly, the interesting
and most important part away at the end
here, that little PI is a so-called proof
of validity. And that is just a simple
number that
somehow with some process
is supposed to convince us that this
transaction is valid
and conforms to all the things we,
uh.
Well, we all the
conditions we expect from a
valid transactions
transaction and
to kind of motivate how that could
work without going into too much detail
right now.
Imagine if if I could
convince somebody that I simply
know the note plaintext
for four notes, the two input
notes and the two output notes,
if I can convince somebody that I have
these plain texts and
that these two nullifier
values do correspond to
the two input points, and these
two commitments do correspond to the two
output coins and the values balance
out and the two input coins actually
exist in this country here.
Then this is this is
right. This is already intuitively.
Yeah. This this is convincing of some
sort.
And that is basically the game plan
for us.
And to make
that more more precise
will be the will be will
be our job.
Now, really quickly, the titular
Zik snarks,
it's already been introduced.
What it stands for is a zero knowledge,
succinct, non interactive argument
of knowledge.
So this is the black this black
box lets us do what
I just alluded to,
perform that proof that we know
these are not plain texts
and that they
also
satisfy our requirements.
And this is the abstract API, really
simplified of a Zik Snarks
system.
And maybe a little caveat.
There are multiple constructions of Zucca
snarks, not a single single one,
but so we're talking about
the one that is used in Zeca as cash.
So at first there is a one time set up
procedure. This is, by the way,
a concept for the of some interest,
but we also don't have time for that
one. This was actually done
a week prior to the launch of the
cache, this set up procedure.
And it's a very interesting story, if
you want to read it.
There are several people involved in
there and they have written accounts on
how it all went.
So that's really that's really
interesting. But we have to skip it,
unfortunately.
And then we have this proof procedure
that we give some some
inputs in our case, the note plaintext,
and it generates this little PPI value
that we can put into the verify
procedure, notably
without the inputs.
And if that returns
true, we should be
convinced that
the approver knows
this inputs such that it satisfies
the statement that we set the whole
thing up for and that you just
put into a lip snark.
It is literally on GitHub
and
and your system works,
hopefully. All right.
So to make
this all concrete, the so-called
joint split statement, this is the
the collection of the collection
of conditions for validity
of a transaction.
So it is actually basically what I
already said, the approver
knows for notes
that satisfy these things.
Each note consists of four values.
That is the address of the owner, the
value of the node pseudo
random number called row.
Another random number called are these
are of technical interest will kind of
gloss over that.
And these should satisfy
the statement that the input nodes appear
somewhere in our Merkl tree of
existing notes.
The of the modifiers
correspond to the inputs, the,
the commitments correspond to the
outputs, the values ballons.
And we also have spend authority for
the inputs and then non malleability
and uniqueness of role are
more technical, not malleability
means that this disjoined
split, this proof is uniquely
tied to this particular joint split and
uniqueness of role is similar
for the for the pseudo
random number that has to be actually
pseudo random.
All right, so sorry,
let's go back for one second,
how do we encode this in a form that the
Zech Snarks system can actually
make sense of it?
So if any if there are any programmers in
the audience, you
know how to encode lots of things in
some sorts of code
in this picture on the next slide should
probably look familiar to many.
This is a boolean logic
or a circuit diagram of a boolean
circuit and that computes
some logical function.
This is just a stupid toy example,
of course, that takes some inputs on the
left. Then these boolean values
run along. These wires are combined by
these gates here and you get some output
value to the right.
Um, now,
you know, this is this is enough to do
all the things in your computer.
So this could be intuitive as a way
of encoding things.
However, it turns out booleans are
mathematically not that nice because
everything immediately collapses to zero
or one. So what does snarks
and Zarkasih actually use is a
variant call, an arithmetic circuit
where the values along the
wires are actual
football numbers and
the gates perform the
arithmetic, basic operations of addition
or multiplication.
So this is another toy example
as a circuit for adding two numbers
and squaring them and then multiplying
by a certain number.
And as it turns out, we can use these
arithmetic circuits also to represent
boolean operations.
This is just this this is multiplication.
And if you consider the inputs
restricted simply to the set of values,
zero or one, the output is also
zero or one. And it this one, if and only
if both inputs are
one.
So that's that's Boolean and
here's Boolean not that's the function
one minus X
that is zero if X is one and it's one
zero.
So we can, we can do a lot with these
circuits. We can encode all kinds of
well. Expressions or functions in
them. But what we
have in our joint split statement
are actually conditions.
Right. Things like this value has to
equal that value, although some of that
value ourselves.
How do we get there?
And for that, we need to introduce the
concept of satisfy ability.
So, again,
this arithmetic circuit
we call it satisfies liable if we can
find an assignment for the input values
here such that the output becomes
zero y zero,
because that immediately
leads us to satisfy ability of
equations.
So consider maybe
this equation at the top here.
If we want to know whether
this is satisfied by some assignment to
X, Y and Z.
Well, to your high school math,
instead of talking about equality, talk
about the two sides being equal.
Talk about the difference between the two
sides being zero.
So just transform it like this.
Build an arithmetic circuit to represent
the left side and then
talk about satisfy the ability of that
circuit so that this
left hand side becomes zero.
And then you know that these
values
satisfy that equation.
And Zeca snarks,
not just allow you to prove, well,
satisfy ability itself, and that is
existence of any
of any assignment that satisfies it.
But it allows
us to prove knowledge of the part
of the actual assignment.
Right.
So our note plaintext.
So this is kind of our game plan.
You can you can you probably have a
picture.
Now, our plan is
to encode the joint split statement that
you've seen in
formal equations and
such, then turn all those into
an arithmetic circuit, plug that into
our lips, snark,
and use it to prove knowledge of the
notes such that the circuit is satisfied.
Now, if we want to
think back, what
what is it actually that we have to
encode and the joints.
But what are the ingredients?
I said something about a hash stream,
the these commitments involved,
and I mentioned the pseudo random
function.
And finally, for the balance, we need to
regular arithmetic.
So the first three of these
are actually all instantiated with
a hash function that, you know, Shahd,
two, five, six.
So we basically just need to build an
arithmetic circuit for Shata five, six
and then the rest. As variations of that
shot, five, six, if you've ever seen
a description of it, contains
lots of binary operations, arithmetic
on binary numbers, and
so the Z cache implementation
or zero cache actually chooses
the route of representing all the
numbers natively as binary.
So if you have, say, a thirty two bit
number, you take thirty two wires, each
of them carrying only a zero or one.
And only if you need the actual direct
representation, let's say for your
balance arithmetic, you convert that
with an automatic circuit that simply
computes the value of
the binary representation
with the regular formula there.
You can also go back with
us with a little trick that I don't
want to get into.
So not so as not to confuse.
And you can also do a thing like, well,
bit shifting or other permutations
of the bits simply by, well,
commuting, the wiring and the
correct way.
So this will be a big shift by two
and you get the get the values in
at the bottom and then.
Yeah, reroute everything to
places to the right.
And so this should already give you
a good idea of what to do.
Right. You just need to look up, try to
forsakes, take all the pieces,
transform them all into these, into these
arithmetic circles, just combine
everything together.
And when you're done, it looks
something like this.
Um, so this is from the zero
cache paper.
They have this wonderful salad in there,
which is basically just boil it all down.
So the H here that shanteau five
six.
Um, you see that a lot,
but actually not that much more.
There's a concatenation, right.
This, this bar, there are some constants
and there's regular arithmetic on
numbers. So this, this down here
is the is the balancing and
some values plus some other values have
to equal some values.
Uh, here's here's here's a check for
overflow. That's also easy to represent.
If you think about it.
Here is the condition that the
commitments are formed correctly.
Here's the nullifier being formed
correctly.
And the only thing that's missing from
this picture is the the Merkle
tree look up because that didn't fit
on a single line.
So they don't have it in the paper.
Too bad.
Yeah, but
that's basically it.
So I think
we have like seven minutes for questions.
A short Q&A right now.
Please come up to the microphones.
Number four,
assuming that
there is a bug and that someone
can create
money out of thin air
using this anonymous.
Is there a way that
that the community can at some point
see that there is much more
coin then? Then there should be.
Yeah.
So
not immediately.
And this is actually one of the big
dangers.
So it's a very good question.
One thing that you can see, if you
remember the slide
with the joint split statement, you can
see when when coins are created
and you can see when they are spent.
So at any time the
system has a picture of how many coins
have been created so far and how many
points have already been spent.
But it's not that, of
course, doesn't give you exactly what you
want. And there has actually
been talk about
extending the system in the future to
include a sort of
regular account
where they where every node is
required to regularly
transfer all their money into the
transparent world and
then at their leisure, transfer them
back. So it doesn't it wouldn't actually
hurt your anonymity, but that's not in
there yet.
Thank you. OK, one question from the
Internet.
Is a split in the of
the chain's cash possible,
a fork? You mean?
Yes, that
would work exactly as in Bitcoin.
So, yeah, the all
the all the conditions
and everything are enforced by the same
sort of consensus mechanism as in
Bitcoin.
And the last one, microphone number
eight.
Yes,
I was wondering if you've
kind of looked at the funding aspect
and the ethical aspects and the
algorithm of of Zied Cash, and
I was wondering what you think about
those, because when I looked
at how they're funded and
what the algorithm,
how the algorithm is collecting
money for the developers and for the
investors, I found that in the
first four years, 20 percent of
all the coins will go to the
developers and
the investors.
And after that, it stops.
And the total amount that will ever
be made of coins,
10 percent of those will then be
for the developers and the investors.
What do you think ethically
about the choice they make there?
Because they are kind of
algorithmically programing
the inequality?
Well, OK, um.
So.
I can, of course, only speak from my
own interpretation of this,
and I will admit I didn't look at it
too closely because I was mostly
interested in the technical side.
But the way I interpret it is that I
think they did this
this way, that
in order to, um.
Have an alternative that's better than
than than a pre
mine.
I think they didn't want to do the pre
mining thing that some currencies do
where the where the initial developers
just just generate a bunch of coins
and then they own.
And they also have the slow start mining,
which I couldn't mention.
That means that the first
time, the first few blocks,
I don't know how many the
the mining reward is lower
and it slowly ramps up.
And I think they did those
things in order to avoid
a situation where the developers have
a lot of power concentrated in
the beginning. And I think this phoners
reward that you mentioned where it is
put into the algorithm, that for the
first four years they get a percentage of
all the mined coins is basically to just
balance that out, to do that in a fashion
that's transparent.
I think that's the intention.
Um, apart from that, you
said about
basically algorithmically making this
choice.
So how do I interpret
that ethically?
I would say, well.
It is put by them into the algorithm,
but it's still the the network consensus
that confirms it.
So there's absolutely not nothing
stopping the the network
to democratically decide.
We want only half the share
for the founders or no share at all.
And there is actually there's an
basically or an alternative Vikash.
I don't know if it took off or not that
that just simply rips out the founder's
award.
And there's also another one that simply
that replaces it with something else
entirely. So there's a big discussion
to be had about that.
And I think it's pretty interesting, but
that's basically my interpretation.
Thank you.
One more question, Mike
seven.
Yes, you already went into this a little
bit, but I wonder what
alternative zero cash
solutions you have looked into because,
for example, there exists Monero
money, which is
based on a different hashing algorithm, I
guess, but I don't really know what the
difference is. Yeah.
Um, I have to admit, I am not
familiar with Monero.
I know only that Monero uses
something called ring signatures.
So there's some some math magic in there
as well. But I haven't looked at the
differences to that.
I yeah, I'm I'm
guessing that the privacy guarantees that
they can make are less strong than
the ones in cash.
But, um, I yeah.
I don't know the details.
And this is it for tonight,
please. A round of applause for
our lost.