WEBVTT

00:00:00.950 --> 00:00:03.320
The following content is
provided under a Creative

00:00:03.320 --> 00:00:04.710
Commons license.

00:00:04.710 --> 00:00:06.920
Your support will help
MIT OpenCourseWare

00:00:06.920 --> 00:00:11.010
continue to offer high quality
educational resources for free.

00:00:11.010 --> 00:00:13.580
To make a donation or to
view additional materials

00:00:13.580 --> 00:00:17.540
from hundreds of MIT courses,
visit MIT OpenCourseWare

00:00:17.540 --> 00:00:18.426
at ocw.mit.edu.

00:00:23.950 --> 00:00:26.750
NEHA NARULA: OK, let's
go ahead and get started.

00:00:26.750 --> 00:00:30.520
So Tadge is in
California today, so he

00:00:30.520 --> 00:00:33.220
asked me to give
today's lecture, which

00:00:33.220 --> 00:00:34.750
will be based on
a research project

00:00:34.750 --> 00:00:37.630
that we're working
on at the DCI.

00:00:37.630 --> 00:00:39.430
This is actually
really connected

00:00:39.430 --> 00:00:42.610
to confidential transactions
and confidential assets,

00:00:42.610 --> 00:00:45.760
which I think that you guys
covered in a previous class.

00:00:45.760 --> 00:00:48.970
So Pedersen commitments will
play a very important role

00:00:48.970 --> 00:00:50.560
in the work I'm
about to present.

00:00:50.560 --> 00:00:54.280
I want to present this
work that we've been doing.

00:00:54.280 --> 00:00:58.630
This is joint work with Willy
Vasquez, who was an MIT M.Eng.

00:00:58.630 --> 00:01:01.700
He graduated and moved
to UT-Austin, and Madars

00:01:01.700 --> 00:01:04.420
Virza, who is a research
scientist with the DCI.

00:01:04.420 --> 00:01:06.640
And this project
is called zkLedger.

00:01:06.640 --> 00:01:09.460
It's about
privacy-preserving auditing

00:01:09.460 --> 00:01:11.470
for distributed ledgers.

00:01:11.470 --> 00:01:14.980
So to start with, I
am not sure how much

00:01:14.980 --> 00:01:17.710
work you guys have done on
permissioned blockchains

00:01:17.710 --> 00:01:18.557
so far.

00:01:18.557 --> 00:01:20.140
How much have you
covered with respect

00:01:20.140 --> 00:01:21.340
to permissioned blockchains?

00:01:21.340 --> 00:01:22.520
Nothing at all?

00:01:22.520 --> 00:01:23.020
OK.

00:01:25.408 --> 00:01:27.700
Should we start with what is
a permissioned blockchain,

00:01:27.700 --> 00:01:30.100
or do you guys feel like
you have a handle on what

00:01:30.100 --> 00:01:31.400
that means or what that is?

00:01:31.400 --> 00:01:34.010
In its most generic,
abstract sense?

00:01:34.010 --> 00:01:34.780
Yes?

00:01:34.780 --> 00:01:37.600
AUDIENCE: Does it just mean that
different people have access

00:01:37.600 --> 00:01:39.040
to see parts of the chain?

00:01:39.040 --> 00:01:39.790
NEHA NARULA: Yeah.

00:01:39.790 --> 00:01:41.230
So, good question.

00:01:41.230 --> 00:01:44.620
OK, so these words that we
use-- permissioned versus

00:01:44.620 --> 00:01:47.170
permissionless--
usually refer to who

00:01:47.170 --> 00:01:49.780
has right access to the chain.

00:01:49.780 --> 00:01:53.560
So in cryptocurrencies
like Bitcoin and Ethereum,

00:01:53.560 --> 00:01:57.490
theoretically, any one of us
could spin up our own ASIC,

00:01:57.490 --> 00:02:01.270
get really lucky, mine a
block, and put the transactions

00:02:01.270 --> 00:02:04.060
that we are interested
in into the chain.

00:02:04.060 --> 00:02:07.510
Now of course, no one's
going to accept that block

00:02:07.510 --> 00:02:11.260
if it violates the majority
consensus rules of the chain.

00:02:11.260 --> 00:02:14.710
But assuming that it follows
the rules, it's well formatted,

00:02:14.710 --> 00:02:18.220
it has the appropriate proof of
work, et cetera, any one of us

00:02:18.220 --> 00:02:20.480
could submit a block to
the Bitcoin blockchain.

00:02:20.480 --> 00:02:21.310
Right?

00:02:21.310 --> 00:02:25.180
There's no permissions
on who is allowed

00:02:25.180 --> 00:02:29.096
and who isn't allowed to write
to the Bitcoin blockchain.

00:02:31.720 --> 00:02:34.640
Permissioned blockchains
are a different story.

00:02:34.640 --> 00:02:37.210
These are more like
distributed databases.

00:02:37.210 --> 00:02:39.490
The idea behind
permissioned blockchains

00:02:39.490 --> 00:02:42.670
is that you choose a set
of actors ahead of time,

00:02:42.670 --> 00:02:45.430
and only those
actors are allowed

00:02:45.430 --> 00:02:47.590
to write to the blockchain.

00:02:47.590 --> 00:02:49.870
So you can't just have
anyone willy-nilly

00:02:49.870 --> 00:02:52.060
spinning up a mining
node, or spinning up

00:02:52.060 --> 00:02:55.090
a node in the system, and
submitting transactions

00:02:55.090 --> 00:02:56.530
and things to the blockchain.

00:02:56.530 --> 00:02:58.450
Usually, permissioned
versus permissionless

00:02:58.450 --> 00:02:59.950
doesn't say anything
about reads,

00:02:59.950 --> 00:03:01.283
and who can read the blockchain.

00:03:01.283 --> 00:03:03.400
We're really just
talking about rights.

00:03:03.400 --> 00:03:05.470
So an important use--

00:03:05.470 --> 00:03:07.060
permissioned
blockchains, I think,

00:03:07.060 --> 00:03:10.780
are not really the focus
of this course, in part

00:03:10.780 --> 00:03:16.410
because we take the position
that the technology behind them

00:03:16.410 --> 00:03:18.490
is essentially
distributed databases.

00:03:18.490 --> 00:03:21.640
And there's lovely courses out
there on distributed databases.

00:03:21.640 --> 00:03:23.260
And there's a lot
to learn about them,

00:03:23.260 --> 00:03:26.800
and they're very interesting,
but they're not necessarily

00:03:26.800 --> 00:03:29.200
very closely related
to cryptocurrencies

00:03:29.200 --> 00:03:33.040
and the designs of
the past decade.

00:03:33.040 --> 00:03:35.200
So that's the idea behind
permissioned blockchains.

00:03:35.200 --> 00:03:37.660
Now, as I was saying,
I think that there's

00:03:37.660 --> 00:03:39.950
a lot of use cases for
permissioned blockchains.

00:03:39.950 --> 00:03:41.140
They're very useful.

00:03:41.140 --> 00:03:43.450
Distributed databases, in
general, are very useful.

00:03:43.450 --> 00:03:45.190
And so let's talk
about one of them.

00:03:45.190 --> 00:03:48.460
And I'm going to interchangeably
use permissioned blockchain

00:03:48.460 --> 00:03:50.470
and distributed ledger, here.

00:03:50.470 --> 00:03:52.540
Distributed ledger,
permissioned blockchain,

00:03:52.540 --> 00:03:56.317
I'm sort of saying
the same thing.

00:03:56.317 --> 00:03:58.150
So permissioned
blockchains-- any questions,

00:03:58.150 --> 00:04:01.720
before we dive into the
use case in zkLedger,

00:04:01.720 --> 00:04:04.610
about permissioned blockchains?

00:04:04.610 --> 00:04:05.195
Get the idea?

00:04:05.195 --> 00:04:07.070
It's a whole bunch of
people working together

00:04:07.070 --> 00:04:09.560
to construct a ledger.

00:04:09.560 --> 00:04:11.180
So let's start
with the structure

00:04:11.180 --> 00:04:12.750
of the financial system.

00:04:12.750 --> 00:04:15.285
And this is setting the
use case for zkLedger,

00:04:15.285 --> 00:04:16.910
and what we were
trying to do, and what

00:04:16.910 --> 00:04:18.390
we were trying to address.

00:04:18.390 --> 00:04:21.860
So to start with, there are
dozens of very large investment

00:04:21.860 --> 00:04:25.670
banks that are trading
securities, currencies,

00:04:25.670 --> 00:04:27.770
commodities, derivatives.

00:04:27.770 --> 00:04:30.470
Many of these things
are traded on exchanges,

00:04:30.470 --> 00:04:34.100
regulated exchanges like NASDAQ
or the New York Stock Exchange.

00:04:34.100 --> 00:04:38.870
But up to 40% are actually
traded in unregulated fashion.

00:04:38.870 --> 00:04:41.690
They're done in a way that's
called over-the-counter,

00:04:41.690 --> 00:04:44.690
meaning that there is no
regulated exchange sitting

00:04:44.690 --> 00:04:47.090
in the middle
facilitating these trades.

00:04:47.090 --> 00:04:49.850
Instead, the banks,
the entities,

00:04:49.850 --> 00:04:54.260
trade amongst themselves in a
slightly more ad hoc fashion.

00:04:54.260 --> 00:04:57.920
This represents trillions
of dollars of the economy.

00:04:57.920 --> 00:05:00.087
And just to give you
a sense of scale,

00:05:00.087 --> 00:05:02.420
the time frequency we're
dealing, with we're not talking

00:05:02.420 --> 00:05:03.800
about high-frequency trading.

00:05:03.800 --> 00:05:06.960
That's not the use case
that zkLedger is targeting.

00:05:06.960 --> 00:05:08.780
We're thinking like
10s of trades a minute.

00:05:08.780 --> 00:05:11.690
These are things that
are done electronically.

00:05:11.690 --> 00:05:12.788
It's not like people are--

00:05:12.788 --> 00:05:14.330
people might be
calling each other up

00:05:14.330 --> 00:05:16.288
to arrange these trades,
but oftentimes they're

00:05:16.288 --> 00:05:17.250
done electronically.

00:05:17.250 --> 00:05:20.540
But we're not considering
high-frequency trading.

00:05:20.540 --> 00:05:25.190
So a useful abstraction
for thinking

00:05:25.190 --> 00:05:29.510
about a table of these trades
is a transaction ledger.

00:05:29.510 --> 00:05:33.170
So each row in the
ledger is a transaction,

00:05:33.170 --> 00:05:35.690
transferring assets from
one bank to another.

00:05:35.690 --> 00:05:37.970
So this should be very
familiar to everyone.

00:05:37.970 --> 00:05:40.640
It looks a little bit different
than things like Bitcoin,

00:05:40.640 --> 00:05:47.420
because since this is a ledger
designed for the existing

00:05:47.420 --> 00:05:50.510
financial system, we know
who the entities are.

00:05:50.510 --> 00:05:51.530
They have names.

00:05:51.530 --> 00:05:53.165
They're regulated.

00:05:53.165 --> 00:05:54.740
They have companies behind them.

00:05:54.740 --> 00:05:59.180
We're not talking just
about arbitrary public keys.

00:05:59.180 --> 00:06:01.190
So each row in the
ledger is a transaction.

00:06:01.190 --> 00:06:04.412
So here, Citibank is
transferring a million dollars.

00:06:04.412 --> 00:06:05.870
So that's another
thing that's very

00:06:05.870 --> 00:06:07.203
different than cryptocurrencies.

00:06:07.203 --> 00:06:09.020
Here we have multiple
different assets

00:06:09.020 --> 00:06:10.530
being recorded in the ledger.

00:06:10.530 --> 00:06:14.480
So we're not talking about a
ledger with a native asset,

00:06:14.480 --> 00:06:15.042
necessarily.

00:06:15.042 --> 00:06:16.250
This is not a cryptocurrency.

00:06:16.250 --> 00:06:19.370
Really think about this
like a table in a database

00:06:19.370 --> 00:06:20.720
recording transactions.

00:06:20.720 --> 00:06:23.780
Those transactions might
be in dollars, or euros,

00:06:23.780 --> 00:06:27.690
or municipal bonds, or
securities, or shares--

00:06:27.690 --> 00:06:28.940
they could be anything, right?

00:06:28.940 --> 00:06:31.445
So we're just
recording transactions.

00:06:31.445 --> 00:06:33.320
So Citibank is transferring
a million dollars

00:06:33.320 --> 00:06:34.550
to Goldman Sachs.

00:06:34.550 --> 00:06:39.590
JP Morgan is transferring
money to UBS and to Barclays.

00:06:39.590 --> 00:06:40.970
OK?

00:06:40.970 --> 00:06:44.810
So as with
cryptocurrencies, I think,

00:06:44.810 --> 00:06:47.900
cryptocurrencies
have inspired people

00:06:47.900 --> 00:06:51.080
to reconsider the
case of a distributed

00:06:51.080 --> 00:06:54.410
database as a ledger that
multiple entities can write to.

00:06:54.410 --> 00:06:57.560
And part of that consideration
involves thinking

00:06:57.560 --> 00:06:59.330
about digital signatures.

00:06:59.330 --> 00:07:04.400
So maybe these banks have
public, private key pairs.

00:07:04.400 --> 00:07:08.720
And perhaps they use their
keys to indicate consent

00:07:08.720 --> 00:07:10.400
on the transaction, right?

00:07:10.400 --> 00:07:12.380
This is something that's
done under the hood

00:07:12.380 --> 00:07:14.720
right now, when you think
about the protocols we

00:07:14.720 --> 00:07:15.760
use to exchange data.

00:07:15.760 --> 00:07:18.100
But it's not necessarily
done explicitly

00:07:18.100 --> 00:07:19.850
when creating these
distributed databases.

00:07:19.850 --> 00:07:24.680
So they can use their
keys to attach signatures

00:07:24.680 --> 00:07:27.020
to the transaction
to indicate a consent

00:07:27.020 --> 00:07:29.150
to transfer for security.

00:07:29.150 --> 00:07:33.380
Now, this ledger might be
maintained by a third party,

00:07:33.380 --> 00:07:35.690
or it could be a
distributed database,

00:07:35.690 --> 00:07:38.060
a permissioned
blockchain that is

00:07:38.060 --> 00:07:39.780
run by the transacting parties.

00:07:42.800 --> 00:07:45.830
So there are some important
financial invariants

00:07:45.830 --> 00:07:48.890
that you want to maintain here
to verify that transactions are

00:07:48.890 --> 00:07:53.500
happening correctly, that
they're valid, that assets

00:07:53.500 --> 00:07:55.030
aren't created out of nowhere.

00:07:55.030 --> 00:07:58.610
So one of them is
consent to transfer.

00:07:58.610 --> 00:08:01.070
And we use these
signatures for that.

00:08:01.070 --> 00:08:02.982
Another important
thing to verify,

00:08:02.982 --> 00:08:04.940
another important invariant,
is that the person

00:08:04.940 --> 00:08:08.450
doing the transacting actually
has the assets to transfer.

00:08:08.450 --> 00:08:10.950
That they're not making
up assets out of nowhere,

00:08:10.950 --> 00:08:12.992
or they're not double-spending--
that there isn't

00:08:12.992 --> 00:08:15.440
something incorrect happening.

00:08:15.440 --> 00:08:17.860
And then, that assets are
neither created nor destroyed.

00:08:17.860 --> 00:08:19.360
That we have
conservation of assets.

00:08:19.360 --> 00:08:22.580
So these are important financial
invariants to maintain.

00:08:22.580 --> 00:08:25.765
This looks a lot like what
the invariants are that we're

00:08:25.765 --> 00:08:27.890
trying to maintain in a
cryptocurrency like Bitcoin

00:08:27.890 --> 00:08:30.830
or Ethereum, except this
was with multiple assets,

00:08:30.830 --> 00:08:34.350
and we know who the
people are involved.

00:08:34.350 --> 00:08:41.429
Now, if this ledger were being
maintained by an exchange,

00:08:41.429 --> 00:08:45.050
then the exchange would be
responsible for verifying

00:08:45.050 --> 00:08:47.810
and validating that all of
these transactions are correct.

00:08:47.810 --> 00:08:50.960
If this ledger is being
maintained by the participants,

00:08:50.960 --> 00:08:53.360
it's a permissioned
blockchain, then

00:08:53.360 --> 00:08:56.480
everyone can verify and validate
that these invariants are being

00:08:56.480 --> 00:08:58.940
maintained by looking
at the blockchain,

00:08:58.940 --> 00:09:02.210
by checking the
signatures, right?

00:09:02.210 --> 00:09:08.470
So that's great, except
for the fact that privacy

00:09:08.470 --> 00:09:10.480
is really, really important.

00:09:10.480 --> 00:09:13.210
And quite a bit
of data, and quite

00:09:13.210 --> 00:09:15.070
a bit of sensitive
information, is actually

00:09:15.070 --> 00:09:17.320
leaked by looking at
these transactions.

00:09:17.320 --> 00:09:20.350
So if we want to be able to
maintain financial invariants,

00:09:20.350 --> 00:09:22.223
if we want to be able
to check and make sure

00:09:22.223 --> 00:09:23.390
that the ledger is correct--

00:09:23.390 --> 00:09:25.550
and I mean, this is the
whole point of blockchains,

00:09:25.550 --> 00:09:29.920
is that everyone can verify,
and validate, and reconcile

00:09:29.920 --> 00:09:31.030
real time.

00:09:31.030 --> 00:09:35.020
Then in the act of looking
at those transactions,

00:09:35.020 --> 00:09:38.320
you're actually finding out
really sensitive information

00:09:38.320 --> 00:09:39.970
about banks' trading
strategy-- about

00:09:39.970 --> 00:09:41.340
their intellectual property.

00:09:41.340 --> 00:09:42.910
OK?

00:09:42.910 --> 00:09:45.280
For example, a large
trade might indicate

00:09:45.280 --> 00:09:49.450
that a bank has decided
to get out of a position.

00:09:49.450 --> 00:09:50.917
Other banks could
learn about this,

00:09:50.917 --> 00:09:52.500
notice it on the
blockchain as they're

00:09:52.500 --> 00:09:55.750
validating transactions,
and try to follow suit,

00:09:55.750 --> 00:09:57.280
driving down the price.

00:09:57.280 --> 00:09:59.897
So privacy, especially
in this type of context,

00:09:59.897 --> 00:10:00.730
is really important.

00:10:00.730 --> 00:10:04.240
And I'm sure you can imagine
a lot of other different types

00:10:04.240 --> 00:10:08.380
of context in which privacy
is important as well, right?

00:10:08.380 --> 00:10:11.650
So we don't want to
be in this situation

00:10:11.650 --> 00:10:16.000
where we have to
choose between privacy

00:10:16.000 --> 00:10:19.100
and being able to
validate what's going on.

00:10:19.100 --> 00:10:19.720
Right?

00:10:19.720 --> 00:10:22.870
So even if we were to
use a trusted third party

00:10:22.870 --> 00:10:25.090
like an exchange,
we still wouldn't

00:10:25.090 --> 00:10:27.730
have privacy, necessarily,
because the exchange would

00:10:27.730 --> 00:10:29.660
be looking at everything
in the ledger.

00:10:29.660 --> 00:10:32.960
So that's the goal here that
we're trying to achieve.

00:10:32.960 --> 00:10:34.630
We're trying to
achieve this goal where

00:10:34.630 --> 00:10:37.510
we want to be able to
publicly verify and validate

00:10:37.510 --> 00:10:41.350
what's happening in the
ledger, and at the same time,

00:10:41.350 --> 00:10:43.840
obtain some amount of
privacy for transactions.

00:10:43.840 --> 00:10:45.340
We don't want all
transactions to be

00:10:45.340 --> 00:10:47.590
public to whoever is
maintaining the ledger,

00:10:47.590 --> 00:10:51.880
be that a third party
exchange or a set of banks.

00:10:51.880 --> 00:10:53.815
So I'm just going to
pause right there and--

00:10:56.911 --> 00:10:58.710
do we get the setup, here?

00:10:58.710 --> 00:11:03.030
Privacy versus
verification-- we want both.

00:11:03.030 --> 00:11:05.220
Any questions about that?

00:11:05.220 --> 00:11:05.940
Yes?

00:11:05.940 --> 00:11:07.357
AUDIENCE: I was
confused as to how

00:11:07.357 --> 00:11:09.893
you verify that people--
transactions are

00:11:09.893 --> 00:11:11.310
correct in their
account balances?

00:11:11.310 --> 00:11:13.090
It's like there's no
native assets supplied.

00:11:13.090 --> 00:11:14.882
NEHA NARULA: Yeah,
that's a great question.

00:11:14.882 --> 00:11:18.160
So I have dollars and
euros here, right?

00:11:18.160 --> 00:11:20.830
How do you know that Citibank
actually has those dollars

00:11:20.830 --> 00:11:22.820
to transfer to Goldman Sachs?

00:11:22.820 --> 00:11:23.320
Right?

00:11:23.320 --> 00:11:24.910
Where does that come from?

00:11:24.910 --> 00:11:28.090
Notice how this is
transaction number 90.

00:11:28.090 --> 00:11:30.340
I'm assuming that there's
a transaction up here--

00:11:30.340 --> 00:11:32.080
this is just a
subset of the ledger.

00:11:32.080 --> 00:11:35.260
But as you'll see
in a moment, we

00:11:35.260 --> 00:11:38.920
think about this
role of depositors

00:11:38.920 --> 00:11:41.860
who are allowed to deposit
assets into the ledger.

00:11:41.860 --> 00:11:45.070
And so I'm assuming there's a
transaction up here somewhere

00:11:45.070 --> 00:11:49.240
which in a provable
way shows that someone

00:11:49.240 --> 00:11:52.260
we trust to deposit
assets into the ledger

00:11:52.260 --> 00:11:55.240
gave Citibank the dollars
necessary for them

00:11:55.240 --> 00:11:56.710
to give to Goldman Sachs.

00:11:56.710 --> 00:11:58.070
But you're absolutely right.

00:11:58.070 --> 00:12:01.000
If the asset isn't
native to the ledger,

00:12:01.000 --> 00:12:03.722
then you do have that
connection to the real world,

00:12:03.722 --> 00:12:05.680
where you do need to
apply some level of trust.

00:12:05.680 --> 00:12:07.450
The question, is it auditable?

00:12:07.450 --> 00:12:11.440
Can you at least track
it back up to that point?

00:12:11.440 --> 00:12:14.620
Any other questions?

00:12:14.620 --> 00:12:17.575
OK, great.

00:12:17.575 --> 00:12:19.800
So we want to do the following.

00:12:19.800 --> 00:12:22.915
We want to be able to verify
that financial invariants are

00:12:22.915 --> 00:12:25.040
maintained, that things
are correct while achieving

00:12:25.040 --> 00:12:26.180
privacy.

00:12:26.180 --> 00:12:29.210
So one good technique
for achieving privacy

00:12:29.210 --> 00:12:35.250
is simply to encrypt or hide the
transactions in the ledger, OK?

00:12:35.250 --> 00:12:41.780
So surprisingly, maybe, we
actually know how to do this.

00:12:41.780 --> 00:12:46.160
And to, at the same
time, still achieve

00:12:46.160 --> 00:12:48.590
checking of the
financial invariants.

00:12:48.590 --> 00:12:51.150
Here are two systems that
actually achieve this.

00:12:51.150 --> 00:12:55.820
The first is Zerocash, which
was implemented inside of Zcash,

00:12:55.820 --> 00:12:57.650
an anonymous cryptocurrency.

00:12:57.650 --> 00:13:02.175
In Zcash, transactions
are completely hidden.

00:13:02.175 --> 00:13:04.550
They're completely opaque
shielded transactions in Zcash.

00:13:04.550 --> 00:13:07.190
Zcash has two transactions.

00:13:07.190 --> 00:13:08.960
Once set is public,
like in Bitcoin.

00:13:08.960 --> 00:13:11.870
The other set are called
shielded transactions.

00:13:11.870 --> 00:13:13.970
And in a shielded
transaction, you

00:13:13.970 --> 00:13:16.730
don't know who the parties
are who are involved.

00:13:16.730 --> 00:13:20.630
You don't know the amount of
the asset that's transferred.

00:13:20.630 --> 00:13:23.990
But you can validate
that this was correct,

00:13:23.990 --> 00:13:27.020
that financial invariants
were maintained.

00:13:27.020 --> 00:13:31.610
Zerocash and Zcash use a
primitive called zero-knowledge

00:13:31.610 --> 00:13:34.250
proofs, and in
particular, zk-SNARKS--

00:13:34.250 --> 00:13:37.520
zero knowledge succinct
arguments of knowledge.

00:13:37.520 --> 00:13:42.830
Those were actually developed
in part here at MIT.

00:13:42.830 --> 00:13:46.310
So using these really
interesting cryptographic

00:13:46.310 --> 00:13:49.850
primitives, we're able to
maintain financial invariance

00:13:49.850 --> 00:13:50.750
in Zcash.

00:13:50.750 --> 00:13:52.940
There's another
system called Solidus,

00:13:52.940 --> 00:13:56.750
which is out of Cornell,
which also achieves this.

00:13:56.750 --> 00:13:59.150
You can't tell who
the participants are.

00:13:59.150 --> 00:14:03.360
And you can still maintain
financial invariants.

00:14:03.360 --> 00:14:05.570
Solidus uses a completely
different cryptographic

00:14:05.570 --> 00:14:09.412
primitive called PVORM.

00:14:09.412 --> 00:14:11.120
So you should check
out both these papers

00:14:11.120 --> 00:14:12.830
if you're interested.

00:14:12.830 --> 00:14:17.690
It's definitely still possible
to accomplish this, right?

00:14:17.690 --> 00:14:21.300
However, there's
still a problem here.

00:14:21.300 --> 00:14:24.890
Both of these systems
hide everything.

00:14:24.890 --> 00:14:29.420
You get no insight into the
economy, into the blockchain,

00:14:29.420 --> 00:14:34.250
into what's actually
happening in the system.

00:14:34.250 --> 00:14:38.360
Regulators, in particular,
need insight into markets

00:14:38.360 --> 00:14:40.610
in order to maintain
financial stability

00:14:40.610 --> 00:14:43.430
and in order to
protect investors.

00:14:43.430 --> 00:14:46.520
Even considering
non-financial use cases,

00:14:46.520 --> 00:14:48.770
it's oftentimes the
case that people

00:14:48.770 --> 00:14:52.010
who might be using a
blockchain, or distributed

00:14:52.010 --> 00:14:53.930
ledger, or distributed
database want

00:14:53.930 --> 00:14:59.210
to be able to maintain that
certain things are true

00:14:59.210 --> 00:15:04.290
and to get some insight into the
system that they're a part of.

00:15:07.510 --> 00:15:11.140
Lack of insight can actually
have devastating effects,

00:15:11.140 --> 00:15:14.140
as we saw with toxic
assets in 2008.

00:15:14.140 --> 00:15:19.000
One part of the problem, one
contributor to the crisis,

00:15:19.000 --> 00:15:21.340
was the issue that
people didn't really

00:15:21.340 --> 00:15:26.560
have confidence or insight into
exactly what assets banks had

00:15:26.560 --> 00:15:27.430
on their books.

00:15:27.430 --> 00:15:29.410
It was a bit confusing.

00:15:29.410 --> 00:15:32.500
And surprisingly, this
happens to this day

00:15:32.500 --> 00:15:37.840
I think there was a case with
Dow Chemical where they didn't

00:15:37.840 --> 00:15:39.640
actually know how
many outstanding

00:15:39.640 --> 00:15:41.200
shares that they had issued.

00:15:41.200 --> 00:15:42.160
They just didn't know.

00:15:42.160 --> 00:15:45.040
And they had to
give out a dividend,

00:15:45.040 --> 00:15:48.070
and they gave out
too much money or too

00:15:48.070 --> 00:15:51.160
little money or
something like that.

00:15:51.160 --> 00:15:54.790
So here are some examples
of things that we might

00:15:54.790 --> 00:15:56.890
want to measure and understand.

00:15:56.890 --> 00:15:59.630
We might want to get a sense
of leverage in the system.

00:15:59.630 --> 00:16:03.580
So, the participants
who are holding assets,

00:16:03.580 --> 00:16:06.100
how much do they have en masse?

00:16:06.100 --> 00:16:07.990
We want to understand exposure.

00:16:07.990 --> 00:16:11.350
We might want to get a sense
of market concentration.

00:16:11.350 --> 00:16:15.220
It's pretty useful to know
things like, OK, this bank,

00:16:15.220 --> 00:16:18.190
this asset in particular is
very highly concentrated.

00:16:18.190 --> 00:16:19.840
Or this asset is
more distributed

00:16:19.840 --> 00:16:22.210
amongst the participants
of the system.

00:16:22.210 --> 00:16:24.400
So there are things
that we might

00:16:24.400 --> 00:16:27.280
want to learn about
the economy represented

00:16:27.280 --> 00:16:29.550
by the assets in the blockchain.

00:16:29.550 --> 00:16:33.880
And that if the entire thing is
encrypted or completely opaque,

00:16:33.880 --> 00:16:37.040
we're not going to be able
to really gain this insight.

00:16:37.040 --> 00:16:39.180
And toxic assets, like I said.

00:16:39.180 --> 00:16:41.370
So here's a specific
example of something

00:16:41.370 --> 00:16:44.550
we might want to learn.

00:16:44.550 --> 00:16:45.600
Here's a bank.

00:16:45.600 --> 00:16:46.740
Here's an auditor.

00:16:46.740 --> 00:16:48.330
And the auditor might want to--

00:16:48.330 --> 00:16:50.850
let's assume the bank is
using a system like zkLedger,

00:16:50.850 --> 00:16:53.160
a permissioned blockchain.

00:16:53.160 --> 00:16:54.690
An auditor might
want to know how

00:16:54.690 --> 00:16:58.200
exposed is this bank
to a drop in the euro?

00:16:58.200 --> 00:17:01.770
So if the euro versus the
dollar changes dramatically,

00:17:01.770 --> 00:17:04.530
what's going to happen to
this bank's balance sheet?

00:17:04.530 --> 00:17:07.410
So in zkLedger, the
auditor can ask a question

00:17:07.410 --> 00:17:10.980
like what fraction of
your assets are in euros?

00:17:10.980 --> 00:17:15.680
And the bank might respond,
3 million out of 100 million.

00:17:15.680 --> 00:17:17.940
So, 3 million euros,
100 million dollars.

00:17:17.940 --> 00:17:19.740
Something like that.

00:17:19.740 --> 00:17:21.960
But just simply
asking this question,

00:17:21.960 --> 00:17:25.500
the auditor doesn't
really get any assurance

00:17:25.500 --> 00:17:27.310
that this answer is correct.

00:17:27.310 --> 00:17:29.550
And so this is the
nugget of the problem

00:17:29.550 --> 00:17:32.700
that we are trying
to solve and achieve.

00:17:32.700 --> 00:17:34.890
So this talk presents zkLedger.

00:17:34.890 --> 00:17:38.610
And it's a private,
auditable transaction ledger.

00:17:38.610 --> 00:17:42.330
The idea behind zkLedger
is like other systems.

00:17:42.330 --> 00:17:48.360
We also hide the transacting
banks and the amounts involved.

00:17:48.360 --> 00:17:51.360
We provide integrity
with public verification.

00:17:51.360 --> 00:17:53.100
So despite the fact
that you can't really

00:17:53.100 --> 00:17:55.110
see the details of
the transaction,

00:17:55.110 --> 00:17:56.790
anyone, not just
the participants,

00:17:56.790 --> 00:17:59.310
but anyone you want
to show this to,

00:17:59.310 --> 00:18:02.430
can publicly verify
and convince themselves

00:18:02.430 --> 00:18:04.680
that transactions
are well-formed

00:18:04.680 --> 00:18:07.200
and financial invariants
are maintained.

00:18:07.200 --> 00:18:10.800
And an auditor can
interactively compute

00:18:10.800 --> 00:18:13.380
provably correct
linear functions

00:18:13.380 --> 00:18:14.820
over the transactions.

00:18:14.820 --> 00:18:16.290
So things like
trying to understand

00:18:16.290 --> 00:18:19.450
market concentration, or
leverage, or exposure--

00:18:19.450 --> 00:18:21.480
they can compute
a set of queries

00:18:21.480 --> 00:18:26.390
over the contents of the
transactions in the ledger.

00:18:26.390 --> 00:18:29.860
OK, so I'm going to describe
to you how zkLedger works.

00:18:29.860 --> 00:18:32.655
I'm going to give you a brief
overview of the system model.

00:18:32.655 --> 00:18:34.030
And then I'm going
to start to go

00:18:34.030 --> 00:18:37.060
into some of the more
interesting pieces

00:18:37.060 --> 00:18:38.380
inside zkLedger.

00:18:38.380 --> 00:18:40.750
So the commitments
that we use to hide

00:18:40.750 --> 00:18:44.390
things, the way the
ledger is constructed.

00:18:44.390 --> 00:18:46.270
And I'm going to
tell you a little bit

00:18:46.270 --> 00:18:48.140
about the primitives
that we use,

00:18:48.140 --> 00:18:49.482
which are zero-knowledge proofs.

00:18:49.482 --> 00:18:51.940
Not SNARKs, which I talked
about earlier-- a different type

00:18:51.940 --> 00:18:52.940
of zero-knowledge proof.

00:18:52.940 --> 00:18:54.970
But I'll give you a
little bit of a flavor

00:18:54.970 --> 00:18:57.290
of what those things look like.

00:18:57.290 --> 00:19:00.890
And then I'll show you the
performance of zkLedger.

00:19:00.890 --> 00:19:04.090
So whether you buy
this use case or not,

00:19:04.090 --> 00:19:06.850
I think that you will
see these topics come

00:19:06.850 --> 00:19:10.293
up over and over again as you're
looking at cryptocurrencies.

00:19:10.293 --> 00:19:12.460
People are quite interested
in zero-knowledge proofs

00:19:12.460 --> 00:19:15.970
and how they can use
them to provide privacy

00:19:15.970 --> 00:19:19.720
inside of cryptocurrencies.

00:19:19.720 --> 00:19:23.355
OK, before we jump into the
system model, any questions?

00:19:26.540 --> 00:19:27.740
OK, let's go.

00:19:27.740 --> 00:19:30.650
So let's start with
the system model.

00:19:30.650 --> 00:19:31.970
So here's the system model.

00:19:31.970 --> 00:19:33.170
We have a set of banks.

00:19:33.170 --> 00:19:37.400
These banks have generated
public keys and secret keys,

00:19:37.400 --> 00:19:38.360
which they have.

00:19:38.360 --> 00:19:42.530
And these banks are working
together to construct a ledger.

00:19:42.530 --> 00:19:44.030
And the way that
this ledger works

00:19:44.030 --> 00:19:45.650
is that they are
determining transactions

00:19:45.650 --> 00:19:46.442
amongst themselves.

00:19:46.442 --> 00:19:49.370
So they're deciding, OK, I'm
going to transfer this amount

00:19:49.370 --> 00:19:50.210
to that bank.

00:19:50.210 --> 00:19:53.270
And then once they've
decided on a transaction,

00:19:53.270 --> 00:19:55.797
they append that
transaction to the ledger.

00:19:55.797 --> 00:19:57.380
And again, remember,
this ledger could

00:19:57.380 --> 00:19:59.633
be maintained by a third party.

00:19:59.633 --> 00:20:01.550
It could be maintained
by the banks themselves

00:20:01.550 --> 00:20:02.570
on a blockchain.

00:20:02.570 --> 00:20:04.670
They could be using a
public bulletin board.

00:20:04.670 --> 00:20:06.320
They could be posting
transactions to Twitter.

00:20:06.320 --> 00:20:06.960
It doesn't matter.

00:20:06.960 --> 00:20:08.960
We're not really concerned
about that right now.

00:20:08.960 --> 00:20:13.400
The point is that there is
an append-only ledger that's

00:20:13.400 --> 00:20:17.107
orthogonal to our techniques--
how exactly it's maintained.

00:20:19.910 --> 00:20:22.010
An auditor, a third
party auditor,

00:20:22.010 --> 00:20:24.830
can obtain correct
answers to questions

00:20:24.830 --> 00:20:26.030
based on ledger contents.

00:20:26.030 --> 00:20:28.550
So note that auditing
is interactive.

00:20:28.550 --> 00:20:31.790
It's not the case that someone
can just take this ledger

00:20:31.790 --> 00:20:33.560
and compute things over it.

00:20:33.560 --> 00:20:35.012
They can't do that.

00:20:35.012 --> 00:20:36.470
There's not enough
information here

00:20:36.470 --> 00:20:38.090
to reveal the
answers to queries.

00:20:38.090 --> 00:20:42.110
The auditor has to actually
talk to the participants

00:20:42.110 --> 00:20:43.110
in the ledger.

00:20:43.110 --> 00:20:44.720
So you might say,
well, we didn't

00:20:44.720 --> 00:20:48.140
trust the participants to give
the auditor the right answer.

00:20:48.140 --> 00:20:51.158
Why would we trust them to
answer the auditor at all?

00:20:51.158 --> 00:20:52.700
Well in the setting
that we've set up

00:20:52.700 --> 00:20:54.700
for ourselves, if they
don't answer the auditor,

00:20:54.700 --> 00:20:55.670
they can go to jail.

00:20:55.670 --> 00:20:56.240
OK?

00:20:56.240 --> 00:20:58.740
So at least you can tell whether
the bank is answering you

00:20:58.740 --> 00:20:59.240
or not.

00:20:59.240 --> 00:21:01.782
If the bank were to lie to you,
you might not be able to tell

00:21:01.782 --> 00:21:04.400
whether-- this allows
you to be able to--

00:21:04.400 --> 00:21:08.580
if you get an answer, you know
that that answer is correct.

00:21:08.580 --> 00:21:10.410
So the auditor
will query the bank

00:21:10.410 --> 00:21:11.970
and ask a question
similar to what

00:21:11.970 --> 00:21:14.137
we were asking before--
what fraction of your assets

00:21:14.137 --> 00:21:14.880
are in euros?

00:21:14.880 --> 00:21:16.140
The bank can respond.

00:21:16.140 --> 00:21:19.050
But this time, instead of
just getting an answer,

00:21:19.050 --> 00:21:24.030
the auditor also gets a small
part of a proof from the bank

00:21:24.030 --> 00:21:27.810
and can confirm that
that proof is correct

00:21:27.810 --> 00:21:30.030
based on these
opaque transaction

00:21:30.030 --> 00:21:31.860
details in the ledger.

00:21:31.860 --> 00:21:38.040
So the auditor still
needs to talk to the bank,

00:21:38.040 --> 00:21:40.830
but using the bank's
response, they

00:21:40.830 --> 00:21:43.020
can compute a proof that
shows that this answer must

00:21:43.020 --> 00:21:43.770
be correct.

00:21:43.770 --> 00:21:44.940
OK?

00:21:44.940 --> 00:21:46.200
So auditing is interactive.

00:21:46.200 --> 00:21:47.580
Like I said, it's
possible a bank

00:21:47.580 --> 00:21:49.110
might choose not to respond.

00:21:49.110 --> 00:21:50.580
That could happen.

00:21:50.580 --> 00:21:53.970
Also I want to point out that
if the auditor is constantly

00:21:53.970 --> 00:21:55.580
auditing this ledger--

00:21:55.580 --> 00:21:57.675
is constantly asking how
many euros do you have?

00:21:57.675 --> 00:21:58.800
How many euros do you have?

00:21:58.800 --> 00:22:00.090
How many euros do you have?

00:22:00.090 --> 00:22:02.910
Then if that number
changes, it's

00:22:02.910 --> 00:22:05.220
reasonable to assume
that that change happened

00:22:05.220 --> 00:22:07.230
in the last transaction
appended to the ledger.

00:22:07.230 --> 00:22:07.800
Right?

00:22:07.800 --> 00:22:12.270
So if the bank
continually answers

00:22:12.270 --> 00:22:15.480
the auditor's questions, this
will leak transaction contents.

00:22:15.480 --> 00:22:18.480
This doesn't provide what's
known as differential privacy.

00:22:18.480 --> 00:22:19.170
OK?

00:22:19.170 --> 00:22:22.950
And so the setup here is
that the auditor and the bank

00:22:22.950 --> 00:22:25.560
should come to some agreement
about the appropriate level

00:22:25.560 --> 00:22:29.730
of frequency of auditing such
that both the auditor gets

00:22:29.730 --> 00:22:32.550
the data that they need, and
the bank maintains the privacy

00:22:32.550 --> 00:22:35.300
that it needs to maintain.

00:22:35.300 --> 00:22:38.130
OK, so as I said
before, zkLedger

00:22:38.130 --> 00:22:42.310
supports any linear function
over transaction values.

00:22:42.310 --> 00:22:45.990
So we can do ratios,
sums, averages, variance,

00:22:45.990 --> 00:22:48.600
skews outliers.

00:22:48.600 --> 00:22:53.880
By outliers, I mean give me
all the transactions that have

00:22:53.880 --> 00:22:55.963
amounts outside of this range.

00:22:55.963 --> 00:22:58.380
So you want all high-value
transactions, you can provably,

00:22:58.380 --> 00:23:00.560
correctly give that.

00:23:00.560 --> 00:23:03.720
Approximation-- so orders
of magnitude of my trades,

00:23:03.720 --> 00:23:06.090
without revealing
the precise number.

00:23:06.090 --> 00:23:09.900
Changes over time, and also
well-known financial risk

00:23:09.900 --> 00:23:12.870
measurements like the
Herfindahl-Hirschman Index.

00:23:12.870 --> 00:23:14.230
So in this talk--

00:23:14.230 --> 00:23:14.850
oh, sorry.

00:23:14.850 --> 00:23:18.390
Yes, there are small amounts
of well-defined leakage

00:23:18.390 --> 00:23:21.660
for some of these measurements.

00:23:21.660 --> 00:23:24.750
So for example, in order
to compute the average,

00:23:24.750 --> 00:23:28.330
we actually compute the sum
and the number of transactions.

00:23:28.330 --> 00:23:30.600
So we leak a little
bit more information

00:23:30.600 --> 00:23:35.070
than just the average, but
it's very well-defined.

00:23:35.070 --> 00:23:36.720
And in this talk,
I'm only really going

00:23:36.720 --> 00:23:39.150
to talk about sums.

00:23:39.150 --> 00:23:44.040
But our paper, which I'll put
a point or two on the website,

00:23:44.040 --> 00:23:46.430
explains how to do
more complex things.

00:23:46.430 --> 00:23:51.960
And everything's built
on the sums primitive.

00:23:51.960 --> 00:23:54.540
So let's talk about
the security goals.

00:23:54.540 --> 00:23:57.910
So what are we trying to
achieve with the system?

00:23:57.910 --> 00:24:00.810
So first of all, we're
trying to achieve privacy.

00:24:00.810 --> 00:24:03.270
We want to make sure that
the auditor and non-involved

00:24:03.270 --> 00:24:06.990
parties cannot see transaction
participants or amounts.

00:24:06.990 --> 00:24:10.470
So I don't know if I
made this clear before,

00:24:10.470 --> 00:24:12.960
but it's not just the case
that this third-party auditor

00:24:12.960 --> 00:24:18.270
can't see who's in transactions
or what they're transacting.

00:24:18.270 --> 00:24:20.280
Anyone who's not
actually involved

00:24:20.280 --> 00:24:22.290
in the transaction,
receiving or sending assets,

00:24:22.290 --> 00:24:26.310
also can't see inside
of a transaction.

00:24:26.310 --> 00:24:27.102
Completeness.

00:24:27.102 --> 00:24:28.560
So what do we mean
by completeness?

00:24:28.560 --> 00:24:33.770
What we mean by that is that
banks can't lie to the auditor.

00:24:33.770 --> 00:24:36.297
They can't say that they have
5 million euros when actually

00:24:36.297 --> 00:24:37.380
they have 3 million euros.

00:24:37.380 --> 00:24:42.460
But also, the bank can't
selectively leave out things.

00:24:42.460 --> 00:24:42.960
OK?

00:24:42.960 --> 00:24:44.970
So you could imagine
some ways of constructing

00:24:44.970 --> 00:24:47.700
this in which, if a
bank was really clever,

00:24:47.700 --> 00:24:51.630
they could just not include
some of the transactions

00:24:51.630 --> 00:24:53.850
that they had received,
and thus change

00:24:53.850 --> 00:24:55.110
their answers to the auditor.

00:24:55.110 --> 00:24:57.900
But one of our security
goals that we achieve

00:24:57.900 --> 00:25:01.320
is that it's impossible for
a bank to omit transactions

00:25:01.320 --> 00:25:03.930
when responding to the auditor.

00:25:03.930 --> 00:25:06.360
We also are looking
to achieve integrity,

00:25:06.360 --> 00:25:09.060
so banks can't violate
financial invariants.

00:25:09.060 --> 00:25:12.300
We assume that
banks are malicious.

00:25:12.300 --> 00:25:15.060
But honest banks
should always be

00:25:15.060 --> 00:25:17.870
able to convince the
auditor of a correct answer.

00:25:17.870 --> 00:25:19.620
So we don't want to
have a situation where

00:25:19.620 --> 00:25:22.230
a malicious bank screws
up the ledger such

00:25:22.230 --> 00:25:25.290
that an honest bank can't
respond to the auditor

00:25:25.290 --> 00:25:27.090
because the ledger
doesn't make sense.

00:25:27.090 --> 00:25:30.050
So we also want
to maintain that.

00:25:30.050 --> 00:25:32.100
And then progress.

00:25:32.100 --> 00:25:35.630
We also want to make sure that
a malicious bank can't block

00:25:35.630 --> 00:25:38.570
other banks from transacting--
that they can't hold up

00:25:38.570 --> 00:25:39.740
the entire ledger.

00:25:39.740 --> 00:25:41.990
And I think as I
describe the design,

00:25:41.990 --> 00:25:44.615
it'll become clearer why
these things were issues

00:25:44.615 --> 00:25:45.740
that we were worried about.

00:25:45.740 --> 00:25:48.500
And it's part of how
we designed the system

00:25:48.500 --> 00:25:51.470
to address these problems.

00:25:51.470 --> 00:25:53.080
So, the threat model.

00:25:53.080 --> 00:25:56.350
And the threat model
describes what kind

00:25:56.350 --> 00:25:58.750
of attacks that we are
trying to protect against

00:25:58.750 --> 00:26:02.230
and what kind of attacks
we don't protect against.

00:26:02.230 --> 00:26:06.040
So banks might attempt
to steal or hide

00:26:06.040 --> 00:26:10.570
assets, manipulate balances,
or lie to the auditor.

00:26:10.570 --> 00:26:12.700
Banks can arbitrarily
collude, so they

00:26:12.700 --> 00:26:15.730
can try to work together
to do these things.

00:26:15.730 --> 00:26:17.590
And banks or the
auditor might try

00:26:17.590 --> 00:26:19.060
to learn transaction contents.

00:26:19.060 --> 00:26:21.220
So it's not that
they're passive.

00:26:21.220 --> 00:26:23.710
They might actually be
trying to actively learn

00:26:23.710 --> 00:26:25.840
what's happening in the ledger.

00:26:25.840 --> 00:26:27.970
What's out of
scope for this work

00:26:27.970 --> 00:26:31.390
is a ledger that omits
transactions or is unavailable.

00:26:31.390 --> 00:26:34.990
As I said, we're agnostic
to the ledger implementation

00:26:34.990 --> 00:26:38.920
as long as it's available
so it accepts transactions.

00:26:38.920 --> 00:26:41.410
If the ledger doesn't
accept transactions,

00:26:41.410 --> 00:26:44.240
we can't provide our goals.

00:26:44.240 --> 00:26:47.530
We also don't protect against
an adversary who might

00:26:47.530 --> 00:26:49.220
be watching network traffic.

00:26:49.220 --> 00:26:53.500
So if there's an adversary
who's snooping on the network

00:26:53.500 --> 00:26:55.720
and sees that two banks
are communicating a lot,

00:26:55.720 --> 00:26:58.178
it's reasonable to assume that
those two banks are involved

00:26:58.178 --> 00:26:59.320
in all the transactions.

00:26:59.320 --> 00:27:02.780
There are other techniques
to deal with these problems.

00:27:02.780 --> 00:27:04.270
And then also
what's out of scope

00:27:04.270 --> 00:27:06.275
is banks leaking their
own transactions.

00:27:06.275 --> 00:27:07.900
If a bank leaks their
own transactions,

00:27:07.900 --> 00:27:09.070
we throw up our hands.

00:27:09.070 --> 00:27:10.570
Sorry, we tried to
give you privacy.

00:27:15.570 --> 00:27:17.663
So that's the system
model for zkLedger.

00:27:17.663 --> 00:27:19.830
That's the threat model,
those are our goals, that's

00:27:19.830 --> 00:27:21.660
what we're trying to achieve.

00:27:21.660 --> 00:27:25.260
Now, let's get into the
design a little bit.

00:27:25.260 --> 00:27:28.930
So we're going to build up the
design based on this example.

00:27:28.930 --> 00:27:33.510
So here is an example of a
public transaction ledger.

00:27:33.510 --> 00:27:36.810
And we're going to slowly start
to mask things in this ledger

00:27:36.810 --> 00:27:39.840
until we end up with
zkLedger's design.

00:27:39.840 --> 00:27:42.900
So we have four
transactions here.

00:27:42.900 --> 00:27:45.750
I'm only using one asset, euros.

00:27:45.750 --> 00:27:48.447
You'll notice that the
first transaction addresses

00:27:48.447 --> 00:27:50.280
the question that you
asked, which is, well,

00:27:50.280 --> 00:27:51.450
where do funds come from?

00:27:51.450 --> 00:27:54.180
And here we have a
special depositor,

00:27:54.180 --> 00:27:57.240
who is injecting
assets into the system.

00:27:57.240 --> 00:28:00.040
This depositor might be the
central bank, for example.

00:28:00.040 --> 00:28:02.040
A lot of systems are
actually designed this way.

00:28:02.040 --> 00:28:09.690
So Stellar, I think Chains,
Blockchain, Ripple--

00:28:09.690 --> 00:28:12.330
these systems are all
designed with the idea

00:28:12.330 --> 00:28:15.240
of a special depositor
who's allowed

00:28:15.240 --> 00:28:19.210
to create their own asset and
insert it into the system.

00:28:19.210 --> 00:28:23.460
So here, maybe the depositor
is the European Central Bank.

00:28:23.460 --> 00:28:26.010
Maybe it's some other
bank, who provably has

00:28:26.010 --> 00:28:30.070
a lot of euros in their account
and puts them onto the ledger.

00:28:30.070 --> 00:28:32.640
So there's a depositor who's
granting 30 million euros

00:28:32.640 --> 00:28:34.230
to Goldman Sachs.

00:28:34.230 --> 00:28:36.690
And then there are
three transactions.

00:28:36.690 --> 00:28:38.912
And I think it's important
to get a sense of what

00:28:38.912 --> 00:28:39.870
these transactions are.

00:28:39.870 --> 00:28:43.770
So Goldman Sachs is transferring
10 million to JP Morgan.

00:28:43.770 --> 00:28:48.680
And then JP Morgan, in two
different transactions,

00:28:48.680 --> 00:28:50.610
is transferring
money to Barclays.

00:28:50.610 --> 00:28:51.550
OK?

00:28:51.550 --> 00:28:56.150
So let's move on from here.

00:28:56.150 --> 00:28:59.350
So like I said, the depositor
injects assets to ledger,

00:28:59.350 --> 00:29:01.780
and that's the way of
entering transactions.

00:29:01.780 --> 00:29:04.750
That's the depositor,
right there.

00:29:04.750 --> 00:29:08.200
Now our goals are to achieve
auditing and privacy.

00:29:08.200 --> 00:29:09.470
What do we mean by that?

00:29:09.470 --> 00:29:13.570
Well, we shouldn't-- someone
looking at the ledger

00:29:13.570 --> 00:29:16.750
shouldn't be able to
tell these amounts except

00:29:16.750 --> 00:29:19.360
for the depositor transaction,
which is always public.

00:29:19.360 --> 00:29:22.070
In zkLedger, the depositor
transactions are public.

00:29:22.070 --> 00:29:25.110
But they shouldn't be
able to tell after that

00:29:25.110 --> 00:29:27.065
that Goldman Sachs gave
money to JP Morgan,

00:29:27.065 --> 00:29:28.690
and that JP Morgan
gave it to Barclays,

00:29:28.690 --> 00:29:29.773
and what the amounts were.

00:29:29.773 --> 00:29:32.480
OK?

00:29:32.480 --> 00:29:37.690
So in this example, we're
going to try to provably audit

00:29:37.690 --> 00:29:42.382
Barclays to figure out how
many euros Barclays is holding.

00:29:42.382 --> 00:29:44.590
And again, we want to hide
the participants, amounts,

00:29:44.590 --> 00:29:46.000
and the transaction graph.

00:29:46.000 --> 00:29:49.930
So what do I mean when
I say transaction graph?

00:29:49.930 --> 00:29:52.210
I think you guys learned a
little bit about a system

00:29:52.210 --> 00:29:55.180
called confidential
transactions a few weeks ago.

00:29:55.180 --> 00:29:59.140
Confidential transactions does
not hide the transaction graph.

00:29:59.140 --> 00:30:02.290
It hides the
amounts, but you can

00:30:02.290 --> 00:30:05.350
tell the source of the funds.

00:30:05.350 --> 00:30:08.970
So here, the money
that Barclays got--

00:30:08.970 --> 00:30:13.690
so if we were trying to attain
privacy in the system, the fact

00:30:13.690 --> 00:30:16.578
that Goldman Sachs got
euros, and Goldman Sachs is

00:30:16.578 --> 00:30:18.370
the only company that
got euros, is public,

00:30:18.370 --> 00:30:20.720
because depositor
transactions are public.

00:30:20.720 --> 00:30:24.280
But we shouldn't be able
to tell that the euros

00:30:24.280 --> 00:30:26.770
that Barclays got--
obviously they must have been

00:30:26.770 --> 00:30:28.060
sourced through Goldman Sachs.

00:30:28.060 --> 00:30:32.020
We shouldn't be able to tell
they went through anyone,

00:30:32.020 --> 00:30:33.820
or how many people
they went through,

00:30:33.820 --> 00:30:35.710
or that it was JP Morgan.

00:30:35.710 --> 00:30:38.620
So if we leaked the
transaction graph,

00:30:38.620 --> 00:30:40.630
you might be able
to tell that there

00:30:40.630 --> 00:30:43.360
was an entity that
the money went through

00:30:43.360 --> 00:30:44.662
before it got to Barclays.

00:30:44.662 --> 00:30:46.870
So when we say we want to
hide the transaction graph,

00:30:46.870 --> 00:30:47.703
that's what we mean.

00:30:47.703 --> 00:30:50.740
We want to be able to hide
the flow of funds, how

00:30:50.740 --> 00:30:52.330
they move through the system.

00:30:56.660 --> 00:31:01.070
We hide the amounts by using a
cryptographic primitive called

00:31:01.070 --> 00:31:03.650
Pedersen commitments.

00:31:03.650 --> 00:31:06.050
So Pedersen commitments,
as you learned,

00:31:06.050 --> 00:31:10.080
are binding and hiding
commitments to a value.

00:31:10.080 --> 00:31:11.800
And the way that they work--

00:31:11.800 --> 00:31:14.780
and I'm terribly sorry, but I
use slightly different notation

00:31:14.780 --> 00:31:15.800
than Tadge.

00:31:15.800 --> 00:31:20.870
So Tadge uses
additive notation--

00:31:20.870 --> 00:31:23.700
multiplicative notation, and
I use exponential notation.

00:31:23.700 --> 00:31:25.370
These mean exactly
the same thing.

00:31:25.370 --> 00:31:28.970
I will very quickly
write down what they are.

00:31:28.970 --> 00:31:35.820
So in Tadge's notation, G and
H are generators in some group.

00:31:35.820 --> 00:31:39.290
And if you have some
value and some randomness,

00:31:39.290 --> 00:31:47.110
then you would write a Pedersen
commitment as that, OK?

00:31:47.110 --> 00:31:50.930
Now, whether it's r times G,
or v times H isn't important.

00:31:50.930 --> 00:31:55.420
The point is these are
two generators of a group,

00:31:55.420 --> 00:31:57.430
in this case, an
elliptical curve group.

00:31:57.430 --> 00:32:00.140
And in Bitcoin, secp256k1.

00:32:00.140 --> 00:32:02.530
It doesn't really matter
what those generators are.

00:32:02.530 --> 00:32:04.750
You just pick any two.

00:32:04.750 --> 00:32:07.390
You could call this G1
and G2, if you wanted to.

00:32:07.390 --> 00:32:10.270
And so this is the way
that Tadge would write it.

00:32:10.270 --> 00:32:12.005
The way that I write it--

00:32:12.005 --> 00:32:13.630
and I'm sorry about
this, but it's good

00:32:13.630 --> 00:32:15.610
that you guys get
exposed to both ways,

00:32:15.610 --> 00:32:18.160
because you'll find both
ways in the literature--

00:32:18.160 --> 00:32:19.990
is in exponential notation.

00:32:19.990 --> 00:32:25.340
So I would write g
to the v, h to the r.

00:32:25.340 --> 00:32:30.510
And they're multiplied together
instead of added together.

00:32:30.510 --> 00:32:31.610
OK?

00:32:31.610 --> 00:32:36.460
So this is just purely
a notational thing.

00:32:36.460 --> 00:32:39.980
It's just, instead of the
multiply operator here,

00:32:39.980 --> 00:32:41.270
we're doing exponentiation.

00:32:41.270 --> 00:32:42.687
Instead of the
plus operator here,

00:32:42.687 --> 00:32:43.846
we're doing multiplication.

00:32:47.040 --> 00:32:49.520
So, Pedersen commitment.

00:32:49.520 --> 00:32:52.100
The way that you
commit to a value v

00:32:52.100 --> 00:32:55.190
is everyone has chosen
these generators.

00:32:55.190 --> 00:32:56.885
The generator choice
is system-wide.

00:32:56.885 --> 00:32:58.760
This isn't something
you pick at the time you

00:32:58.760 --> 00:32:59.552
make a transaction.

00:32:59.552 --> 00:33:01.160
The generator choice
is system-wide.

00:33:01.160 --> 00:33:06.200
However, the r, the randomness,
you do choose fresh each time.

00:33:06.200 --> 00:33:07.880
You pick any
randomness each time.

00:33:07.880 --> 00:33:10.130
And the way that you
commit to a value

00:33:10.130 --> 00:33:14.490
is by producing this
value right here,

00:33:14.490 --> 00:33:17.300
which is the generator
raised to the value

00:33:17.300 --> 00:33:20.900
times the second generator
raised to the randomness.

00:33:20.900 --> 00:33:26.570
And what this serves
to do is it's binding.

00:33:26.570 --> 00:33:29.930
It's very difficult to
come up with, later,

00:33:29.930 --> 00:33:32.540
a different and a
different r that ends up

00:33:32.540 --> 00:33:34.790
equaling the same commitment.

00:33:34.790 --> 00:33:36.620
And part of that is
based on an assumption

00:33:36.620 --> 00:33:38.780
called the discrete
logarithm-- the hardness

00:33:38.780 --> 00:33:42.230
of the discrete
logarithm problem.

00:33:42.230 --> 00:33:44.780
And also, importantly,
these things

00:33:44.780 --> 00:33:47.610
can be homomorphically combined.

00:33:47.610 --> 00:33:51.600
So if we have these commitments
to these different values,

00:33:51.600 --> 00:33:53.700
and we multiply
them together, well,

00:33:53.700 --> 00:33:58.010
when you multiply things that
are raised to an exponent,

00:33:58.010 --> 00:34:01.100
you end up adding
the exponent, right?

00:34:01.100 --> 00:34:03.990
So by multiplying
these things together,

00:34:03.990 --> 00:34:07.430
we end up with a
valid commitment

00:34:07.430 --> 00:34:11.719
to the sum of the values in
the individual commitments

00:34:11.719 --> 00:34:13.670
that we multiplied together.

00:34:13.670 --> 00:34:17.750
So we can homomorphically
combine the commitments.

00:34:17.750 --> 00:34:21.780
It ends up summing
in the exponent.

00:34:21.780 --> 00:34:25.010
And we end up with
a valid commitment

00:34:25.010 --> 00:34:26.225
to the sum of the values.

00:34:28.770 --> 00:34:31.489
Another nice property
of Pedersen commitments

00:34:31.489 --> 00:34:36.290
is that they are very fast to
create, combine, and verify.

00:34:36.290 --> 00:34:38.420
And perhaps surprisingly,
we can actually

00:34:38.420 --> 00:34:40.310
achieve all of the
auditing functions

00:34:40.310 --> 00:34:44.690
that I showed you earlier just
using Pedersen commitments.

00:34:44.690 --> 00:34:47.590
So before we move on, questions
on Pedersen commitments?

00:34:47.590 --> 00:34:50.090
I know that you guys learned
about this in a previous class,

00:34:50.090 --> 00:34:52.805
but they're pretty important.

00:34:55.940 --> 00:34:58.070
They're used in
confidential transactions

00:34:58.070 --> 00:35:00.800
as well to prove that
the sum of the outputs

00:35:00.800 --> 00:35:04.010
is less than or equal to
the sum of the inputs,

00:35:04.010 --> 00:35:05.890
if you guys recall that.

00:35:05.890 --> 00:35:08.423
So any questions?

00:35:08.423 --> 00:35:10.340
AUDIENCE: When are you
making this commitment?

00:35:10.340 --> 00:35:12.120
NEHA NARULA: Ah, great question.

00:35:12.120 --> 00:35:14.640
You're making this
commitment at the time

00:35:14.640 --> 00:35:16.590
that the transaction is created.

00:35:16.590 --> 00:35:19.770
And I'll get into the details
of who creates the transaction,

00:35:19.770 --> 00:35:21.940
and what do they choose,
and how does that happen,

00:35:21.940 --> 00:35:23.520
and how do we make sure
they don't screw it up.

00:35:23.520 --> 00:35:26.030
AUDIENCE: So when you add a
measurement to this ledger,

00:35:26.030 --> 00:35:29.270
it might add a number of
commitments that people make...

00:35:29.270 --> 00:35:30.840
NEHA NARULA: Well,
so measurements

00:35:30.840 --> 00:35:32.500
happen on top of the ledger.

00:35:32.500 --> 00:35:35.730
So we can actually do
all of our measurements

00:35:35.730 --> 00:35:37.230
basically just on
those commitments.

00:35:37.230 --> 00:35:40.510
We don't have to add
anything to ledger.

00:35:40.510 --> 00:35:41.310
OK.

00:35:41.310 --> 00:35:44.130
So, yes, like I said, we
can achieve all the auditing

00:35:44.130 --> 00:35:45.630
functions with
Pedersen commitments.

00:35:45.630 --> 00:35:47.770
And I'll go into a
little bit of detail.

00:35:47.770 --> 00:35:48.270
OK, great.

00:35:48.270 --> 00:35:51.420
So we can use Pearson
commitments to hide the value.

00:35:51.420 --> 00:35:55.260
So again, by using these
commitments, you can't--

00:35:55.260 --> 00:35:58.890
looking at this right
here, if you don't know r,

00:35:58.890 --> 00:36:00.300
you can't guess--

00:36:00.300 --> 00:36:02.250
if you don't know v
and r, you can't--

00:36:02.250 --> 00:36:04.350
if you don't know r, you
can't guess what v is.

00:36:04.350 --> 00:36:05.750
It could be anything.

00:36:05.750 --> 00:36:10.650
So that's what we mean when we
say that these commitments are

00:36:10.650 --> 00:36:13.530
perfectly hiding.

00:36:13.530 --> 00:36:15.300
So we also want to
hide the participants

00:36:15.300 --> 00:36:16.560
in the transaction, obviously.

00:36:16.560 --> 00:36:18.643
And we're going to do that
using other techniques.

00:36:18.643 --> 00:36:20.670
Just hold that in your
head for a moment.

00:36:20.670 --> 00:36:22.690
We're going to jump to that.

00:36:22.690 --> 00:36:25.050
But first, quickly,
let's take a look

00:36:25.050 --> 00:36:28.740
at how auditing might work given
that we're using these Pedersen

00:36:28.740 --> 00:36:30.120
commitments, OK?

00:36:30.120 --> 00:36:35.340
So assume that we have hidden
who the participants are

00:36:35.340 --> 00:36:37.870
in this ledger
through a technique

00:36:37.870 --> 00:36:40.180
that I'm not telling
you about, yet.

00:36:40.180 --> 00:36:44.407
We're hiding the values in
the transactions that are not

00:36:44.407 --> 00:36:46.240
inject-- not these
special transactions that

00:36:46.240 --> 00:36:49.210
are injecting assets or removing
assets, but just the transfers.

00:36:49.210 --> 00:36:52.330
We're hiding the values using
Pedersen commitments, OK?

00:36:52.330 --> 00:36:54.610
So let's look at how
auditing might work.

00:36:54.610 --> 00:36:57.100
So an auditor will
ask the bank--

00:36:57.100 --> 00:36:58.390
in this case, it's Barclays.

00:36:58.390 --> 00:37:02.140
So remember, Barclays
received euros

00:37:02.140 --> 00:37:04.180
in two different
transactions, and should

00:37:04.180 --> 00:37:06.640
tell the auditor 3 million.

00:37:06.640 --> 00:37:09.160
The auditor asks Barclays,
how many euros do you hold?

00:37:09.160 --> 00:37:13.810
Barclays can convince the
auditor that 3 million

00:37:13.810 --> 00:37:17.110
is the right answer by
doing the following.

00:37:17.110 --> 00:37:18.550
OK?

00:37:18.550 --> 00:37:22.420
Barclays can say, hey,
auditor, it's 3 million.

00:37:22.420 --> 00:37:23.200
OK.

00:37:23.200 --> 00:37:25.600
And what I'm going
to do is I'm going

00:37:25.600 --> 00:37:31.690
to actually open up the
combined commitments

00:37:31.690 --> 00:37:33.070
for my transactions.

00:37:33.070 --> 00:37:35.350
So I don't actually have
this on a slide here,

00:37:35.350 --> 00:37:38.270
but I will write
out what this means.

00:37:38.270 --> 00:37:38.770
OK?

00:37:47.030 --> 00:37:50.990
So we have two transactions
here and two commitments.

00:37:50.990 --> 00:37:54.680
And one of them is
g to the 1 million,

00:37:54.680 --> 00:37:57.140
h to-- the let's just r1.

00:37:57.140 --> 00:38:04.820
And then the other is g to
the 2 million, h to the r2.

00:38:04.820 --> 00:38:05.450
OK?

00:38:05.450 --> 00:38:07.760
These are the commitments
in the ledger.

00:38:07.760 --> 00:38:10.310
Barclays wants to
convince the auditor

00:38:10.310 --> 00:38:12.260
that it has 3 million euros.

00:38:12.260 --> 00:38:15.560
It does so by-- when you
multiply these two things

00:38:15.560 --> 00:38:19.640
together, and the auditor can't
see what these two things are,

00:38:19.640 --> 00:38:20.720
but this is--

00:38:24.790 --> 00:38:27.970
or actually, I
think it's comm 2--

00:38:27.970 --> 00:38:28.620
3.

00:38:28.620 --> 00:38:33.290
OK, comm 3 times comm 4.

00:38:33.290 --> 00:38:36.000
Then when you multiply
these two things together,

00:38:36.000 --> 00:38:42.890
you get g to the 1 million plus
2 million h to the r1 plus r2,

00:38:42.890 --> 00:38:45.180
OK?

00:38:45.180 --> 00:38:47.210
This is 3 million.

00:38:47.210 --> 00:38:57.410
If Barclays gives the auditor
3 million and r1 plus r2,

00:38:57.410 --> 00:39:02.150
the sum, than the
auditor can confirm

00:39:02.150 --> 00:39:07.100
that if they raise g to this
and h to this, that it's

00:39:07.100 --> 00:39:09.710
equal to the
multiplication of the two

00:39:09.710 --> 00:39:10.820
commitments on the ledger.

00:39:15.420 --> 00:39:18.420
And the auditor can--

00:39:18.420 --> 00:39:20.980
given that these two
things are equal,

00:39:20.980 --> 00:39:25.050
then the auditor knows
that the bank in fact

00:39:25.050 --> 00:39:29.520
did commit to two commitments
that sum to $3 million.

00:39:29.520 --> 00:39:35.850
It doesn't know if that was 1.5
and 1.5, or 1 and 2 million,

00:39:35.850 --> 00:39:37.500
999--

00:39:37.500 --> 00:39:41.400
it doesn't know what those
individual values were.

00:39:41.400 --> 00:39:43.920
It just knows that
the sum is correct.

00:39:47.860 --> 00:39:50.810
So, questions about
opening commitments?

00:39:50.810 --> 00:39:51.375
Yes?

00:39:51.375 --> 00:39:54.200
AUDIENCE: The sub-3,
sub-4-- those are the IDs?

00:39:54.200 --> 00:39:56.110
NEHA NARULA: Yeah,
those are 3 and 4.

00:39:56.110 --> 00:39:57.610
Sorry, I'm using
different numbers.

00:39:57.610 --> 00:39:58.450
They're r1 and r2.

00:39:58.450 --> 00:40:01.270
But the comm 3 and comm 4 are--

00:40:01.270 --> 00:40:05.080
this is literally a
elliptic curve point.

00:40:05.080 --> 00:40:09.960
So the point is
posted to the ledger.

00:40:09.960 --> 00:40:10.460
Yes?

00:40:10.460 --> 00:40:13.985
AUDIENCE: Wouldn't 4 million and
minus 1 million also do that?

00:40:13.985 --> 00:40:15.110
NEHA NARULA: It would, yes.

00:40:15.110 --> 00:40:17.630
And we'll talk about
how we address that.

00:40:17.630 --> 00:40:19.320
AUDIENCE: So just
to confirm, the bank

00:40:19.320 --> 00:40:21.880
provides both the 3
million number and--

00:40:21.880 --> 00:40:23.430
NEHA NARULA: And r1 plus r2.

00:40:23.430 --> 00:40:24.090
Yes.

00:40:24.090 --> 00:40:26.370
And those two pieces
of information

00:40:26.370 --> 00:40:28.620
are enough to convince
the auditor that 3 million

00:40:28.620 --> 00:40:31.250
does in fact correspond to
the commitments on the ledger.

00:40:31.250 --> 00:40:31.750
Yes?

00:40:31.750 --> 00:40:34.530
AUDIENCE: [INAUDIBLE]
so you will always

00:40:34.530 --> 00:40:38.268
get the sum and the
number of transactions?

00:40:38.268 --> 00:40:39.060
NEHA NARULA: Sorry?

00:40:39.060 --> 00:40:40.200
AUDIENCE: You will get the
number of transactions?

00:40:40.200 --> 00:40:41.158
NEHA NARULA: Who's you?

00:40:41.158 --> 00:40:43.790
AUDIENCE: Oh, [INAUDIBLE]
as in the auditor.

00:40:43.790 --> 00:40:45.460
NEHA NARULA: The
auditor will get--

00:40:45.460 --> 00:40:48.110
AUDIENCE: They will know
the number of transactions?

00:40:48.110 --> 00:40:50.990
NEHA NARULA: In the straw
man example that I've done,

00:40:50.990 --> 00:40:52.585
it does look that way, yes.

00:40:52.585 --> 00:40:54.710
I'm going to build up to
how the auditor won't know

00:40:54.710 --> 00:40:56.330
the number of transactions.

00:40:56.330 --> 00:40:59.430
Did you have a question?

00:40:59.430 --> 00:41:01.610
AUDIENCE: So as a
user, you are recording

00:41:01.610 --> 00:41:02.610
all of your randomness?

00:41:02.610 --> 00:41:04.310
You're responsible for tracking
all of your randomness?

00:41:04.310 --> 00:41:06.852
NEHA NARULA: You're responsible
for tracking your randomness.

00:41:06.852 --> 00:41:08.720
And you're responsible
for tracking

00:41:08.720 --> 00:41:10.487
your own individual details.

00:41:10.487 --> 00:41:12.320
You have to keep that
in your own databases.

00:41:12.320 --> 00:41:13.462
Yes?

00:41:13.462 --> 00:41:16.910
AUDIENCE: If somebody
found your randomness--

00:41:16.910 --> 00:41:18.980
NEHA NARULA: If someone
found your randomnesses,

00:41:18.980 --> 00:41:21.110
then they could guess--

00:41:21.110 --> 00:41:24.030
they could backwards-compute
the values of your transactions.

00:41:24.030 --> 00:41:24.530
Yes.

00:41:27.150 --> 00:41:27.650
OK.

00:41:27.650 --> 00:41:29.530
AUDIENCE: How do you
define the timing?

00:41:29.530 --> 00:41:30.730
NEHA NARULA: The time--

00:41:30.730 --> 00:41:31.980
getting to that.

00:41:31.980 --> 00:41:34.360
So we'll get to that.

00:41:34.360 --> 00:41:37.630
So just in figures,
showing what we did there.

00:41:37.630 --> 00:41:40.060
The auditor can look at
those two commitments,

00:41:40.060 --> 00:41:42.070
compute the product
for themselves,

00:41:42.070 --> 00:41:45.910
and confirm that this 3 million
lines up with what they see.

00:41:45.910 --> 00:41:48.670
However, this has
the problem that it

00:41:48.670 --> 00:41:51.220
reveals the transactions
in which Barclays

00:41:51.220 --> 00:41:53.020
was involved, right?

00:41:53.020 --> 00:41:55.300
Barclays is saying, hey,
multiply these two things

00:41:55.300 --> 00:41:56.560
together, right?

00:41:56.560 --> 00:41:59.930
And not only that,
Barclays could lie.

00:41:59.930 --> 00:42:00.430
OK?

00:42:00.430 --> 00:42:03.670
Barclays could
say, oh, actually,

00:42:03.670 --> 00:42:05.700
I only have 1 million euros.

00:42:05.700 --> 00:42:07.600
Here's the transaction
that proves

00:42:07.600 --> 00:42:09.040
that I have 1 million euros.

00:42:09.040 --> 00:42:10.870
I will just give you our one.

00:42:10.870 --> 00:42:12.702
I will just point
to this transaction.

00:42:12.702 --> 00:42:14.410
Don't worry about the
other transactions.

00:42:14.410 --> 00:42:16.010
I'm not involved in them.

00:42:16.010 --> 00:42:19.510
The bank, Barclays,
could leave out

00:42:19.510 --> 00:42:24.040
relevant important transactions
in this straw man design.

00:42:24.040 --> 00:42:26.660
OK?

00:42:26.660 --> 00:42:29.740
And importantly, this
would match up, right?

00:42:29.740 --> 00:42:33.430
The auditor would say,
OK, you've given me--

00:42:33.430 --> 00:42:34.900
Barclays could just give--

00:42:38.572 --> 00:42:40.030
could leave this
part out entirely.

00:42:40.030 --> 00:42:45.490
Could just give
1 million and r1,

00:42:45.490 --> 00:42:47.950
and the auditor
would say, why, yes,

00:42:47.950 --> 00:42:49.970
that does match up
to commitment three.

00:42:49.970 --> 00:42:50.470
Great.

00:42:50.470 --> 00:42:51.100
Good work.

00:42:51.100 --> 00:42:52.420
And they wouldn't
even know that there

00:42:52.420 --> 00:42:54.170
was another commitment
out there that they

00:42:54.170 --> 00:42:56.500
should be concerned about.

00:42:56.500 --> 00:42:59.700
So how do we address
this problem?

00:43:03.300 --> 00:43:05.340
And this, I think,
was the key insight

00:43:05.340 --> 00:43:08.510
in the design of our system.

00:43:08.510 --> 00:43:12.290
In zkLedger, a
transaction actually

00:43:12.290 --> 00:43:16.970
has a commitment for every
participant in the system.

00:43:16.970 --> 00:43:20.210
So let's talk about
that for a second.

00:43:20.210 --> 00:43:24.070
So depositor transactions
still basically look the way

00:43:24.070 --> 00:43:26.050
that they did before
they're public.

00:43:26.050 --> 00:43:30.110
But transfer transactions
now look quite different.

00:43:30.110 --> 00:43:35.140
We don't actually have the
names of the participant

00:43:35.140 --> 00:43:36.460
in the transaction.

00:43:36.460 --> 00:43:40.840
The names are implied by the
values of the commitments

00:43:40.840 --> 00:43:43.310
in that participants column.

00:43:43.310 --> 00:43:45.850
So now we're looking
at a transaction

00:43:45.850 --> 00:43:48.910
as a row with multiple columns.

00:43:48.910 --> 00:43:53.860
And there's a column per
participant in the system.

00:43:53.860 --> 00:43:57.790
If a bank is not involved
in the transaction at all,

00:43:57.790 --> 00:44:00.640
then their commitment
is to the value 0.

00:44:00.640 --> 00:44:03.400
If the bank is involved
in a transaction,

00:44:03.400 --> 00:44:07.300
and it's doing the
spending, then its value--

00:44:07.300 --> 00:44:08.590
sorry, depositor transactions.

00:44:08.590 --> 00:44:09.580
Yes.

00:44:09.580 --> 00:44:12.430
If a bank is involved
in the transaction,

00:44:12.430 --> 00:44:15.940
it's doing the spending, it
commits to a negative value.

00:44:15.940 --> 00:44:18.920
And if it's doing the
receiving, it commits--

00:44:18.920 --> 00:44:21.010
sorry, not it, but the
creator of the transaction,

00:44:21.010 --> 00:44:22.810
commits to a positive value.

00:44:22.810 --> 00:44:25.930
So the way that you transfer
$1 million from one bank

00:44:25.930 --> 00:44:29.170
to another is committing to a
negative value in the spenders

00:44:29.170 --> 00:44:30.840
column-- here, JP Morgan--

00:44:30.840 --> 00:44:33.570
and committing to a positive
value in the receivers column--

00:44:33.570 --> 00:44:34.300
here, Barclays.

00:44:41.760 --> 00:44:45.570
And again for non-involved
banks, entries commit to 0.

00:44:45.570 --> 00:44:47.820
But one thing I want to stress--

00:44:47.820 --> 00:44:51.840
commitments to 0 are completely
indistinguishable from

00:44:51.840 --> 00:44:54.060
commitments to any other value.

00:44:54.060 --> 00:44:55.530
And commitments
to negative values

00:44:55.530 --> 00:44:58.770
are indistinguishable from
commitments to positive values.

00:44:58.770 --> 00:45:03.050
So someone looking at this, just
looking at these commitments

00:45:03.050 --> 00:45:05.870
posted to the ledger, has
no idea which ones are 0s,

00:45:05.870 --> 00:45:09.240
and which ones are negative,
and which ones are positive.

00:45:09.240 --> 00:45:09.740
Yes?

00:45:09.740 --> 00:45:11.655
AUDIENCE: Does this
mean that each bank has

00:45:11.655 --> 00:45:13.280
to keep track of
every transaction that

00:45:13.280 --> 00:45:16.848
is done in the ledger, and
produce the random numbers,

00:45:16.848 --> 00:45:18.390
and keep track of
those numbers, too?

00:45:18.390 --> 00:45:19.920
NEHA NARULA: Great question.

00:45:19.920 --> 00:45:23.840
So, yeah, one design
might have it be the case

00:45:23.840 --> 00:45:25.760
that every bank
actually has to be

00:45:25.760 --> 00:45:27.590
involved in every transaction.

00:45:27.590 --> 00:45:32.240
We managed to design zkLedger
so that the spending bank can

00:45:32.240 --> 00:45:34.820
produce one of these
without actually involving

00:45:34.820 --> 00:45:37.558
any of the other banks.

00:45:37.558 --> 00:45:39.100
And I will describe
how that happens.

00:45:44.810 --> 00:45:49.420
OK, and so, given
now that we've said,

00:45:49.420 --> 00:45:52.450
essentially, every bank is
involved in every transaction,

00:45:52.450 --> 00:45:54.730
this actually makes life
easier for the auditor.

00:45:54.730 --> 00:45:56.620
Because now when the
auditor audits a bank,

00:45:56.620 --> 00:45:59.630
they audit every transaction.

00:45:59.630 --> 00:46:03.400
So they audit the entire
column for a bank.

00:46:03.400 --> 00:46:06.190
So here, when the auditor
is auditing Barclays,

00:46:06.190 --> 00:46:09.250
they won't just look at whatever
transactions Barclays tells

00:46:09.250 --> 00:46:10.210
them to look at.

00:46:10.210 --> 00:46:12.770
They will look at
every transaction.

00:46:12.770 --> 00:46:13.390
OK?

00:46:13.390 --> 00:46:14.650
And this is where--

00:46:14.650 --> 00:46:16.300
I think someone
asked about timing,

00:46:16.300 --> 00:46:20.500
or how do you audit a
range of transactions?

00:46:20.500 --> 00:46:23.020
The auditor can actually
tell the bank, oh, I just

00:46:23.020 --> 00:46:25.680
want to audit from
this point onwards.

00:46:25.680 --> 00:46:27.220
Or it can say, I
just want to audit

00:46:27.220 --> 00:46:31.030
your transactions for the
past month, if it wants to.

00:46:31.030 --> 00:46:33.790
That doesn't mean that Barclays
can leave out transactions,

00:46:33.790 --> 00:46:37.590
because there's supposed to
be a time stamp column in here

00:46:37.590 --> 00:46:38.090
as well.

00:46:38.090 --> 00:46:39.820
So you can see when
transactions happen.

00:46:39.820 --> 00:46:41.440
That's public.

00:46:41.440 --> 00:46:43.260
So what happens
here is the auditor

00:46:43.260 --> 00:46:44.950
is going to look at everything.

00:46:44.950 --> 00:46:48.970
They're actually going to
multiply three commitments

00:46:48.970 --> 00:46:52.387
together, because there's three
commitments in that column.

00:46:52.387 --> 00:46:54.970
And it doesn't know which ones
are 0 and which ones are not 0.

00:46:54.970 --> 00:46:56.940
But the 0 doesn't
contribute to the sum.

00:47:00.350 --> 00:47:05.620
And so a malicious bank can't
actually lie to the auditor,

00:47:05.620 --> 00:47:12.780
because in this
case, the bank is not

00:47:12.780 --> 00:47:15.560
going to leave out
commitment four.

00:47:15.560 --> 00:47:19.260
And in fact, it's also going
to include commitment two.

00:47:29.740 --> 00:47:37.390
So the bank is going to have
to include the r primes in here

00:47:37.390 --> 00:47:39.160
to get all of this to
work out correctly.

00:47:39.160 --> 00:47:40.868
It's going to have to
include everything.

00:47:49.000 --> 00:47:51.980
So this next--

00:47:51.980 --> 00:47:56.040
I'm actually going to
skip a little bit of this,

00:47:56.040 --> 00:47:58.313
because I think we're
running a bit low on time.

00:47:58.313 --> 00:48:00.480
And I do want to get into
what the proofs look like.

00:48:00.480 --> 00:48:05.370
So I'm going to skip
this averages part.

00:48:05.370 --> 00:48:09.165
I'm going to go back
to our security goals.

00:48:11.790 --> 00:48:15.360
What I just described to you,
the ledger table construction,

00:48:15.360 --> 00:48:19.590
allows us to achieve our
first two security goals.

00:48:19.590 --> 00:48:21.810
Privacy-- because these
commitments are perfectly

00:48:21.810 --> 00:48:25.380
hiding, no one can see
transaction participants.

00:48:25.380 --> 00:48:27.120
They can't tell who's
committing to 0,

00:48:27.120 --> 00:48:29.310
and who's not committing to 0.

00:48:29.310 --> 00:48:31.890
Banks can't lie to the auditor,
because the auditor audits

00:48:31.890 --> 00:48:33.760
every transaction for a bank.

00:48:33.760 --> 00:48:36.120
But what I haven't
figured out yet

00:48:36.120 --> 00:48:39.730
is, well, how do we maintain
financial invariants

00:48:39.730 --> 00:48:40.440
in this scheme?

00:48:40.440 --> 00:48:42.815
How do we make sure assets
aren't created out of nowhere?

00:48:42.815 --> 00:48:45.540
How do we make sure that
whoever is spending actually

00:48:45.540 --> 00:48:47.160
consented to the spend?

00:48:47.160 --> 00:48:50.100
And how do we construct
this transaction

00:48:50.100 --> 00:48:54.840
that involves every bank when
we assume banks are malicious,

00:48:54.840 --> 00:48:57.660
and we don't want one bank to
be able to hold up everyone

00:48:57.660 --> 00:48:58.912
from transacting?

00:49:03.160 --> 00:49:06.580
So our solution to do
that is to use a set

00:49:06.580 --> 00:49:08.080
of what are called NIZKs--

00:49:08.080 --> 00:49:11.890
non-interactive
zero-knowledge proofs.

00:49:11.890 --> 00:49:13.720
So what are NIZKs?

00:49:13.720 --> 00:49:17.670
NIZKs are short binary strings.

00:49:17.670 --> 00:49:21.060
True statements have proofs.

00:49:21.060 --> 00:49:24.410
So, if a statement is true,
it should have a proof

00:49:24.410 --> 00:49:26.000
indicating that it's true.

00:49:26.000 --> 00:49:29.270
False statements
only have proofs

00:49:29.270 --> 00:49:33.450
with negligible probability.

00:49:33.450 --> 00:49:38.580
And proofs don't reveal
why they are true.

00:49:38.580 --> 00:49:41.730
So we're going to use
NIZKs to prove things

00:49:41.730 --> 00:49:47.410
like the person who knows the
secret key for this public key

00:49:47.410 --> 00:49:52.480
consented to this transfer,
without indicating which

00:49:52.480 --> 00:49:56.543
bank it was that
consented to the transfer.

00:49:56.543 --> 00:49:58.210
We're going to use
NIZKs to prove things

00:49:58.210 --> 00:50:05.500
like this bank has
the assets to spend,

00:50:05.500 --> 00:50:09.590
without revealing how many
assets that bank actually has.

00:50:12.750 --> 00:50:16.980
So zkLedger uses a set of
carefully crafted NIZKs.

00:50:16.980 --> 00:50:19.270
And to be clear,
NIZKs are pretty old.

00:50:19.270 --> 00:50:22.470
They were invented in
the '80s and the '90s.

00:50:22.470 --> 00:50:24.240
And most of them are
based on the hardness

00:50:24.240 --> 00:50:26.940
of the discrete log problem in
elliptic curve cryptography,

00:50:26.940 --> 00:50:28.230
again.

00:50:28.230 --> 00:50:30.480
So here are the
properties we want

00:50:30.480 --> 00:50:31.800
to achieve with transactions.

00:50:31.800 --> 00:50:33.510
We want transaction validity.

00:50:33.510 --> 00:50:37.417
We want to make sure whoever
is the spender, whoever

00:50:37.417 --> 00:50:39.000
has a negative amount
in their column,

00:50:39.000 --> 00:50:41.070
actually consented
to the transfer.

00:50:41.070 --> 00:50:43.453
And again, remember, in
cryptocurrencies and things

00:50:43.453 --> 00:50:45.870
like that, where it's OK to
reveal who the person is who's

00:50:45.870 --> 00:50:47.710
spending, we use a signature.

00:50:47.710 --> 00:50:51.720
In this case, we'll use proof
of knowledge of secret key.

00:50:51.720 --> 00:50:53.978
So there's a consent NIZK.

00:50:53.978 --> 00:50:56.520
We want to be able to prove that
whoever is spending actually

00:50:56.520 --> 00:50:58.470
has the assets to
transfer-- that they're not

00:50:58.470 --> 00:50:59.640
going negative.

00:50:59.640 --> 00:51:02.070
And we use an assets NIZK.

00:51:02.070 --> 00:51:06.210
And we want to make sure that
assets are neither created

00:51:06.210 --> 00:51:08.580
nor destroyed, so for that
we use a balance NIZK.

00:51:08.580 --> 00:51:10.470
We want to show that
things work out,

00:51:10.470 --> 00:51:14.550
and you didn't create more
euros than you were supposed to.

00:51:14.550 --> 00:51:16.050
The only place where
you can do that

00:51:16.050 --> 00:51:17.760
is in the depositor
transactions,

00:51:17.760 --> 00:51:20.130
the public depositor
transactions.

00:51:20.130 --> 00:51:24.570
We also want to make sure that
honest banks can make progress.

00:51:24.570 --> 00:51:28.140
And in order to do that,
creating a transaction

00:51:28.140 --> 00:51:30.240
in zkLedger is non-interactive.

00:51:30.240 --> 00:51:33.790
The banks don't have to interact
to create a transaction.

00:51:33.790 --> 00:51:37.380
This is exactly how systems
like Ethereum and Bitcoin work,

00:51:37.380 --> 00:51:38.530
if you think about it.

00:51:38.530 --> 00:51:41.940
I can't stop you from
sending me Bitcoin, right?

00:51:41.940 --> 00:51:43.530
If you want to send
me Bitcoin, you

00:51:43.530 --> 00:51:45.570
construct a transaction
that sends me Bitcoin.

00:51:45.570 --> 00:51:46.903
You submit it to the blockchain.

00:51:46.903 --> 00:51:48.270
I have nothing to do with that.

00:51:48.270 --> 00:51:51.000
Offline, we might have
agreed that the reason you're

00:51:51.000 --> 00:51:53.490
sending me Bitcoin is
because I'm selling you

00:51:53.490 --> 00:51:55.410
my car or something like that.

00:51:55.410 --> 00:51:59.340
But to actually create the
transaction that spends,

00:51:59.340 --> 00:52:01.800
you don't have to talk to
the other participants.

00:52:01.800 --> 00:52:08.760
And we use a consistency NIZK
so that the person creating

00:52:08.760 --> 00:52:13.530
the transaction can prove
in a publicly verifiable way

00:52:13.530 --> 00:52:16.110
that everything
matches up correctly,

00:52:16.110 --> 00:52:18.210
that all of these
proofs are correct,

00:52:18.210 --> 00:52:21.690
and that all of the banks
are going to be able to later

00:52:21.690 --> 00:52:22.980
respond to the auditor--

00:52:22.980 --> 00:52:25.450
be able to respond to
the auditor as necessary.

00:52:25.450 --> 00:52:27.600
So to give you a
little bit of insight

00:52:27.600 --> 00:52:32.370
into why this consistency
NIZK is necessary,

00:52:32.370 --> 00:52:36.630
over here, I was speaking
as though the bank knew

00:52:36.630 --> 00:52:41.190
all of the r values, right?

00:52:41.190 --> 00:52:43.740
Actually, in zkLedger,
if a bank is not

00:52:43.740 --> 00:52:46.530
involved in a transaction,
if their commitment's to 0,

00:52:46.530 --> 00:52:48.510
they don't know
their own r value,

00:52:48.510 --> 00:52:50.910
because some other
bank has created that.

00:52:50.910 --> 00:53:01.180
So if we go backwards
a little bit to here,

00:53:01.180 --> 00:53:04.390
Barclays wasn't involved
in this transaction at all.

00:53:04.390 --> 00:53:07.660
And in fact, Barclays--
so Goldman Sachs

00:53:07.660 --> 00:53:09.830
created this transaction.

00:53:09.830 --> 00:53:13.190
JP Morgan created
this one and this one.

00:53:13.190 --> 00:53:15.030
Barclays had nothing
to do with them.

00:53:15.030 --> 00:53:16.850
They weren't involved at all.

00:53:16.850 --> 00:53:19.490
And we can't assume
that Barclays knows

00:53:19.490 --> 00:53:22.780
what the rs are in its column.

00:53:22.780 --> 00:53:25.100
Yet the way that I
told you that Barclays'

00:53:25.100 --> 00:53:28.880
response to the auditor is by
revealing the sum of the rs.

00:53:28.880 --> 00:53:31.580
So that's actually not
how zkLedger works.

00:53:31.580 --> 00:53:33.530
They don't actually
reveal the sum of the rs.

00:53:33.530 --> 00:53:38.720
The proof is a little
bit more complicated.

00:53:38.720 --> 00:53:42.110
The rs are encoded
for Barclays in a way

00:53:42.110 --> 00:53:45.590
that it can't see what they
are, but it can use them.

00:53:45.590 --> 00:53:50.120
And the consistency proof is
to prove that that encoding was

00:53:50.120 --> 00:53:51.260
done correctly.

00:53:55.707 --> 00:53:57.540
So again, you can see
the paper for details,

00:53:57.540 --> 00:53:58.957
but I'm actually
going to tell you

00:53:58.957 --> 00:54:03.450
a little bit about these proofs
and what they look like, OK?

00:54:03.450 --> 00:54:05.580
So, consent.

00:54:05.580 --> 00:54:11.160
The consent proof is proof of
knowledge of secret key, sk.

00:54:11.160 --> 00:54:16.260
So what this means is that if
the value in the commitment

00:54:16.260 --> 00:54:21.210
in this entry is
negative, then there

00:54:21.210 --> 00:54:24.240
should be a proof of
knowledge of secret key

00:54:24.240 --> 00:54:28.455
to indicate that this bank
has consented to subtracting

00:54:28.455 --> 00:54:29.205
from their assets.

00:54:32.720 --> 00:54:35.840
Also, if the value
is negative, you

00:54:35.840 --> 00:54:38.900
need to create a
proof of assets.

00:54:38.900 --> 00:54:40.940
Technically, you don't
need a proof of assets

00:54:40.940 --> 00:54:43.220
if the value is not
negative, but we're

00:54:43.220 --> 00:54:46.400
trying not to reveal,
remember, which bank is

00:54:46.400 --> 00:54:48.230
involved in which transaction.

00:54:48.230 --> 00:54:51.560
So I'm going to draw
a transaction up

00:54:51.560 --> 00:54:55.880
here and explain a
little bit about where

00:54:55.880 --> 00:54:57.030
these proofs actually go.

00:55:04.930 --> 00:55:07.730
A transaction is a row.

00:55:14.180 --> 00:55:25.252
And there is an entry for
each bank in the transaction.

00:55:30.080 --> 00:55:32.900
So there is a commitment.

00:55:32.900 --> 00:55:38.510
So let's-- negative 1 million.

00:55:43.190 --> 00:55:45.680
And then there is also
these sets of proofs.

00:55:45.680 --> 00:55:52.730
So, proof of assets,
in particular.

00:55:52.730 --> 00:55:56.780
And every single entry
has a proof of assets,

00:55:56.780 --> 00:55:59.060
even though, really, this
is the only bank that's

00:55:59.060 --> 00:56:01.535
spending and needs to
prove that it has assets.

00:56:04.190 --> 00:56:10.110
The proof of assets is
constructed to look like this.

00:56:10.110 --> 00:56:13.700
It's a new commitment,
either to the sum

00:56:13.700 --> 00:56:16.850
of the values in the
column, or, if you're not

00:56:16.850 --> 00:56:19.790
the spending bank, a
commitment to the value.

00:56:19.790 --> 00:56:24.500
And it also includes
a proof that the value

00:56:24.500 --> 00:56:27.500
in this auxiliary
commitment is in range.

00:56:27.500 --> 00:56:29.690
So what do I mean by that?

00:56:29.690 --> 00:56:32.210
I think you guys should have
covered this in the Pedersen

00:56:32.210 --> 00:56:34.460
commitment lecture with
confidential transactions,

00:56:34.460 --> 00:56:36.770
but when you're dealing
with cyclic groups,

00:56:36.770 --> 00:56:39.020
you can wrap around
the end of the group.

00:56:39.020 --> 00:56:42.770
And that's the same as if
you hadn't wrapped around.

00:56:42.770 --> 00:56:44.600
There are many
different things that

00:56:44.600 --> 00:56:48.020
can occupy one point in the
space of a cyclic group.

00:56:48.020 --> 00:56:52.490
So we need to include
proofs that your value is

00:56:52.490 --> 00:56:54.290
in a range that's expected.

00:56:54.290 --> 00:56:56.330
And in the case of
zkLedger, we need

00:56:56.330 --> 00:56:58.730
to prove that the
value is between 0

00:56:58.730 --> 00:57:01.520
and a certain upper
limit that is less

00:57:01.520 --> 00:57:03.650
than the order of the group.

00:57:03.650 --> 00:57:06.950
And we use the
exact same technique

00:57:06.950 --> 00:57:09.560
that they use in confidential
transactions to do this--

00:57:09.560 --> 00:57:12.320
borromean ring signatures.

00:57:12.320 --> 00:57:16.430
What's kind of exciting is
that, a few months ago, there

00:57:16.430 --> 00:57:21.830
was some work done on a faster,
smaller, more aggregatable

00:57:21.830 --> 00:57:25.910
version of range proofs using
a system called bullet proofs.

00:57:25.910 --> 00:57:31.250
So as you'll see
in the evaluation,

00:57:31.250 --> 00:57:33.230
this sounds like such
a silly little thing.

00:57:33.230 --> 00:57:35.630
Oh, yeah, also prove that
the value is in range.

00:57:35.630 --> 00:57:39.920
This is like 90% of all of the
space and work in zkLedger.

00:57:39.920 --> 00:57:43.140
These range proofs are
the bane of our existence.

00:57:43.140 --> 00:57:44.930
They take up a lot of space.

00:57:44.930 --> 00:57:49.130
They're very slow to create and
verify, but they're necessary.

00:57:49.130 --> 00:57:54.620
So making them faster is
a really amazing thing.

00:57:54.620 --> 00:57:57.740
Then the next thing is balance.

00:57:57.740 --> 00:57:59.810
And I think this
one is illustrative,

00:57:59.810 --> 00:58:02.730
because it shows that a proof--

00:58:02.730 --> 00:58:04.760
sometimes you have a
proof not by creating

00:58:04.760 --> 00:58:07.580
an additional binary string,
but by the way you choose

00:58:07.580 --> 00:58:10.190
things in your transaction.

00:58:10.190 --> 00:58:12.500
So the way that you prove
that no funds are created

00:58:12.500 --> 00:58:14.820
or destroyed is as follows.

00:58:14.820 --> 00:58:19.030
So these are-- remember these
commitments are g to the 0.

00:58:19.030 --> 00:58:23.360
Let's say h the r1, g to
the negative 1 million,

00:58:23.360 --> 00:58:28.440
h to the r2, and g to the
1 million, h to the r3.

00:58:28.440 --> 00:58:31.460
Now, given that we
have these commitments,

00:58:31.460 --> 00:58:35.420
how can we prove to
someone that no assets

00:58:35.420 --> 00:58:36.830
were created or destroyed?

00:58:36.830 --> 00:58:38.780
Well, what does it
mean for no assets

00:58:38.780 --> 00:58:40.200
to be created or destroyed?

00:58:40.200 --> 00:58:46.723
It means that the sum of
the vs is equal to 0, right?

00:58:46.723 --> 00:58:48.140
That's what it
means for no assets

00:58:48.140 --> 00:58:49.400
to be created or destroyed.

00:58:49.400 --> 00:58:53.210
How can we prove to someone
that, given that all they're

00:58:53.210 --> 00:58:57.050
seeing are these commitments,
that the sum of the vs

00:58:57.050 --> 00:58:58.700
commit to 0?

00:58:58.700 --> 00:59:04.610
Well, let's just make the sum
of the rs also commit to 0.

00:59:04.610 --> 00:59:09.560
So if the sum of the rs
also commits to 0, then

00:59:09.560 --> 00:59:12.180
when you multiply
these things together,

00:59:12.180 --> 00:59:15.380
you're going to get g
to the sum of the vs, h

00:59:15.380 --> 00:59:17.540
to the sum of the rs.

00:59:17.540 --> 00:59:21.770
And if both of these things
are 0, you get g to the 0,

00:59:21.770 --> 00:59:25.080
h to the 0, which
should equal what?

00:59:25.080 --> 00:59:27.470
One, exactly.

00:59:27.470 --> 00:59:31.040
So we choose our
rs very carefully,

00:59:31.040 --> 00:59:34.190
so that the auditor, or
whoever is verifying this,

00:59:34.190 --> 00:59:37.430
can just multiply all the
commitments together and verify

00:59:37.430 --> 00:59:38.480
that they equal 1.

00:59:38.480 --> 00:59:40.940
And if it equals
1, that means it

00:59:40.940 --> 00:59:45.640
would have been very difficult
to choose vs such that you

00:59:45.640 --> 00:59:48.810
could make this come out to 1
without it actually coming out

00:59:48.810 --> 00:59:50.300
to 1.

00:59:50.300 --> 00:59:52.970
So that's the proof of balance.

00:59:52.970 --> 00:59:54.860
It's not an actual proof.

00:59:54.860 --> 00:59:56.690
It's not a short binary string.

00:59:56.690 --> 00:59:59.540
It's literally choosing the
exponents in a clever way

00:59:59.540 --> 01:00:02.675
to show that we can maintain
the invariant that we want.

01:00:02.675 --> 01:00:03.550
Does that make sense?

01:00:08.220 --> 01:00:10.420
Questions about these proofs?

01:00:10.420 --> 01:00:13.150
And I didn't go into
proof of assets very much.

01:00:13.150 --> 01:00:14.400
It's the most complicated one.

01:00:14.400 --> 01:00:15.733
But you can check out the paper.

01:00:18.730 --> 01:00:20.535
I see some confused faces.

01:00:20.535 --> 01:00:22.160
You don't have to
ask about the proofs.

01:00:22.160 --> 01:00:26.020
AUDIENCE: Couldn't you just
choose both of the exponents?

01:00:26.020 --> 01:00:28.240
So if you're choosing
rs in a certain way,

01:00:28.240 --> 01:00:31.140
can't you choose
them in a certain way

01:00:31.140 --> 01:00:36.103
and then choose payments
so that they sum to 0?

01:00:36.103 --> 01:00:37.770
NEHA NARULA: Well,
we're trying to prove

01:00:37.770 --> 01:00:38.895
that the payments sum to 0.

01:00:38.895 --> 01:00:40.140
That's what we want.

01:00:40.140 --> 01:00:43.950
Because that means that assets
weren't created or destroyed.

01:00:43.950 --> 01:00:45.040
And remember--

01:00:45.040 --> 01:00:46.540
AUDIENCE: You're
generating-- you're

01:00:46.540 --> 01:00:51.120
creating those random numbers
in a way that they sum to zero.

01:00:51.120 --> 01:00:53.600
So if you create them in a
way that doesn't sum to 0?

01:00:53.600 --> 01:00:55.110
NEHA NARULA: Then
every-- ah, OK.

01:00:55.110 --> 01:00:56.442
So this is an important--

01:00:56.442 --> 01:00:57.900
AUDIENCE: Change
the transaction so

01:00:57.900 --> 01:01:02.062
that the sum of the rs and the
sum of the values sum to 0?

01:01:02.062 --> 01:01:04.020
NEHA NARULA: So basically,
what you're saying--

01:01:04.020 --> 01:01:04.640
I think what you're say--

01:01:04.640 --> 01:01:06.390
OK, you could be saying
one of two things.

01:01:06.390 --> 01:01:10.590
Number one, what if you
choose your vs and rs such

01:01:10.590 --> 01:01:12.270
that it doesn't sum to 0, right?

01:01:12.270 --> 01:01:14.760
What if you produce an
invalid transaction?

01:01:14.760 --> 01:01:18.060
And the answer is that
everyone will reject it.

01:01:18.060 --> 01:01:19.500
Sort of similar
to Bitcoin, if you

01:01:19.500 --> 01:01:21.690
don't have a valid
transaction, good for you.

01:01:21.690 --> 01:01:23.940
But it's going to be
considered invalid by everyone

01:01:23.940 --> 01:01:24.360
in the system.

01:01:24.360 --> 01:01:26.160
And everyone's going to
skip it and ignore it.

01:01:26.160 --> 01:01:28.140
It's not going to be part
of what happens, right?

01:01:28.140 --> 01:01:29.807
So this is part of
the proof of validity

01:01:29.807 --> 01:01:31.800
that all of the participants
have consented to.

01:01:31.800 --> 01:01:33.425
The second question
you might be asking

01:01:33.425 --> 01:01:39.180
is, what if these
don't sum to 0,

01:01:39.180 --> 01:01:42.120
but I still manage
to figure out how

01:01:42.120 --> 01:01:43.800
to make this equal 1, right?

01:01:43.800 --> 01:01:47.280
That's what you-- OK, so that's
the question you're asking.

01:01:47.280 --> 01:01:50.250
Based on the assumption that
the discrete logarithm problem

01:01:50.250 --> 01:01:52.978
is hard--

01:01:52.978 --> 01:01:54.270
this is too hard to figure out.

01:01:54.270 --> 01:01:56.160
You literally cannot find--

01:01:58.780 --> 01:02:00.800
there is an assumption here.

01:02:00.800 --> 01:02:03.380
These are two generators
of the group, right?

01:02:03.380 --> 01:02:07.280
So that means the g is
equal to h to the x,

01:02:07.280 --> 01:02:09.200
that there's some way
to produce one generator

01:02:09.200 --> 01:02:11.060
from the other generator.

01:02:11.060 --> 01:02:14.420
There is an assumption here
that figuring out what that x is

01:02:14.420 --> 01:02:16.590
is nearly impossible.

01:02:16.590 --> 01:02:20.510
So you don't know what
g is in terms of h.

01:02:20.510 --> 01:02:23.180
And given that you don't know
this relationship between g

01:02:23.180 --> 01:02:27.800
and h, you can't figure
out how to produce

01:02:27.800 --> 01:02:32.750
two exponents that sum to
what you want them to sum to.

01:02:32.750 --> 01:02:40.700
So is the hardness problem that
these systems are based on.

01:02:40.700 --> 01:02:43.310
If you could do that,
if you could figure out

01:02:43.310 --> 01:02:47.528
a sum of rs such that it
gave you a 1 with the vs

01:02:47.528 --> 01:02:49.820
you wanted, then you would
have broken the discrete log

01:02:49.820 --> 01:02:51.550
problem.

01:02:51.550 --> 01:02:52.050
Yes?

01:02:52.050 --> 01:02:54.405
AUDIENCE: So who
chooses the [INAUDIBLE]

01:02:54.405 --> 01:02:57.140
we know that they don't know the
relationship [INAUDIBLE] they

01:02:57.140 --> 01:02:58.265
maliciously gave those two?

01:02:58.265 --> 01:02:59.710
NEHA NARULA: Great question.

01:02:59.710 --> 01:03:02.550
So the answer is
that in our system,

01:03:02.550 --> 01:03:06.480
the way that we choose g and
h is by taking the SHA-256

01:03:06.480 --> 01:03:08.220
hash of 0 and 1.

01:03:11.310 --> 01:03:12.900
Those are numbers such that--

01:03:12.900 --> 01:03:15.870
they're sufficiently
random, and they

01:03:15.870 --> 01:03:22.050
show that if you took
a hash of 0 and 1,

01:03:22.050 --> 01:03:25.370
you would have no relationship
between those two.

01:03:25.370 --> 01:03:29.167
And everyone uses the same g and
h, right, from the beginning.

01:03:35.240 --> 01:03:37.830
Any other questions?

01:03:37.830 --> 01:03:41.490
OK, so we're
running low on time,

01:03:41.490 --> 01:03:43.710
but I do want to go through
the evaluation really

01:03:43.710 --> 01:03:45.210
quickly, because--

01:03:45.210 --> 01:03:48.870
so this system, this paper,
was presented at NSDI

01:03:48.870 --> 01:03:50.700
in April, which is a
systems conference.

01:03:50.700 --> 01:03:53.340
And I think part of the reason
that the systems community

01:03:53.340 --> 01:03:56.340
liked it was because
it's surprisingly fast.

01:03:56.340 --> 01:03:58.740
You might have heard that
computing unencrypted data is

01:03:58.740 --> 01:03:59.820
too slow.

01:03:59.820 --> 01:04:00.720
It's infeasible.

01:04:00.720 --> 01:04:01.470
You can't do it.

01:04:01.470 --> 01:04:03.780
Well, the answer is,
actually, if you understand

01:04:03.780 --> 01:04:07.590
the set of computations
you want to do really well,

01:04:07.590 --> 01:04:10.160
you can structure things
using things like these NIZKs

01:04:10.160 --> 01:04:11.910
and the discrete log
problem in such a way

01:04:11.910 --> 01:04:16.550
that you can do that computation
actually pretty fast.

01:04:16.550 --> 01:04:19.680
So zkLedger is written in Go.

01:04:19.680 --> 01:04:22.045
It uses an elliptic
curve as the group--

01:04:22.045 --> 01:04:24.990
secp256k1, which is
the same elliptic curve

01:04:24.990 --> 01:04:26.970
that Bitcoin uses.

01:04:26.970 --> 01:04:30.060
We use range proofs to
prevent overflow, like I said.

01:04:30.060 --> 01:04:32.850
We use the same ones as in
confidential transactions

01:04:32.850 --> 01:04:34.290
and confidential assets.

01:04:34.290 --> 01:04:36.510
And it's around
4,000 lines of code.

01:04:36.510 --> 01:04:39.390
It's mostly
cryptography functions.

01:04:39.390 --> 01:04:41.580
We don't actually
implement our own ledger,

01:04:41.580 --> 01:04:44.150
because we're ledger agnostic.

01:04:44.150 --> 01:04:47.390
So in the evaluation we
want to understand how fast

01:04:47.390 --> 01:04:49.700
is auditing, first of all?

01:04:49.700 --> 01:04:50.390
Right?

01:04:50.390 --> 01:04:52.520
And then second,
the construction

01:04:52.520 --> 01:04:54.020
I described to you,
you might think

01:04:54.020 --> 01:04:56.480
is very slow, because
every bank has

01:04:56.480 --> 01:04:58.260
an entry in every transaction.

01:04:58.260 --> 01:05:00.710
So how does this actually
work in practice?

01:05:00.710 --> 01:05:04.100
Can we get away with
such a construction?

01:05:04.100 --> 01:05:07.130
So first, let's talk
about the auditing.

01:05:07.130 --> 01:05:08.210
Auditing is really fast.

01:05:08.210 --> 01:05:09.980
So here, we are
auditing four banks,

01:05:09.980 --> 01:05:11.780
and we're doing a
measurement called

01:05:11.780 --> 01:05:13.447
the Herfindahl-Hirschman
Index, so we're

01:05:13.447 --> 01:05:16.250
trying to understand market
concentration for a given

01:05:16.250 --> 01:05:17.120
asset.

01:05:17.120 --> 01:05:19.700
And what's happening
here is the auditor

01:05:19.700 --> 01:05:23.270
is keeping up with the ledger
and keeping these things

01:05:23.270 --> 01:05:25.040
that we call commitment caches.

01:05:25.040 --> 01:05:29.690
So because of the
design of our system

01:05:29.690 --> 01:05:33.320
and the fact that we're using
these Pedersen commitments--

01:05:33.320 --> 01:05:37.670
which, we can actually
maintain rolling sums

01:05:37.670 --> 01:05:42.020
going down of these
commitments and use them

01:05:42.020 --> 01:05:43.910
when needing to
answer the auditor

01:05:43.910 --> 01:05:46.370
or confirm that a bank
has the correct answer.

01:05:46.370 --> 01:05:49.130
And so this means that auditing
for banks is milliseconds.

01:05:49.130 --> 01:05:52.130
It's a few milliseconds
to audit the banks.

01:05:52.130 --> 01:05:56.270
And we see here on the x-axis we
have the number of transactions

01:05:56.270 --> 01:05:57.080
in the ledger.

01:05:57.080 --> 01:05:59.570
The reason that
auditing a bank is

01:05:59.570 --> 01:06:02.030
independent of the number of
transactions in the ledger

01:06:02.030 --> 01:06:03.860
is because of these
commitment caches.

01:06:03.860 --> 01:06:06.350
We can do it really fast,
assuming an online auditor

01:06:06.350 --> 01:06:07.670
who's keeping up with things.

01:06:10.695 --> 01:06:13.070
And part of the reason for
that is because of our design.

01:06:13.070 --> 01:06:14.510
It's very amenable to caching.

01:06:14.510 --> 01:06:18.380
Now, if the auditor is
not online and hasn't

01:06:18.380 --> 01:06:20.090
been maintaining
commitment caches,

01:06:20.090 --> 01:06:23.930
then auditing is order the
number of things in the ledger.

01:06:23.930 --> 01:06:26.420
Here, we have a ledger
with 100,000 entries.

01:06:26.420 --> 01:06:29.650
It takes about 3.5
seconds to audit that.

01:06:29.650 --> 01:06:31.760
Still not so bad, really.

01:06:31.760 --> 01:06:34.430
And it's pretty linear, so
you could imagine, well,

01:06:34.430 --> 01:06:36.830
if you had a million entries,
it would be 10 times that.

01:06:36.830 --> 01:06:38.480
It would be about 30 seconds.

01:06:38.480 --> 01:06:42.510
Still pretty
reasonable, actually.

01:06:42.510 --> 01:06:44.540
A question some
people ask is, well,

01:06:44.540 --> 01:06:46.760
do we have to maintain
this ledger forever?

01:06:46.760 --> 01:06:48.680
How do you clean up the ledger?

01:06:48.680 --> 01:06:53.510
You can create a snapshot
of the state in the ledger

01:06:53.510 --> 01:06:55.040
and get rid of
the past, assuming

01:06:55.040 --> 01:06:56.320
you know the set
of auditing queries

01:06:56.320 --> 01:06:57.945
that you're going to
do moving forward.

01:06:57.945 --> 01:07:01.920
We don't implement this,
but this should be possible.

01:07:01.920 --> 01:07:04.470
Right, so if you wanted
to do 100 million rows,

01:07:04.470 --> 01:07:08.190
it would work out
to be about an hour.

01:07:08.190 --> 01:07:12.780
So here is a graph
which shows how long it

01:07:12.780 --> 01:07:16.463
takes to create and verify
transactions in zkLedger.

01:07:16.463 --> 01:07:18.130
And this is varying
the number of banks.

01:07:18.130 --> 01:07:19.505
And again, we see
this is linear.

01:07:19.505 --> 01:07:23.010
The more banks, the more
entries per transaction,

01:07:23.010 --> 01:07:25.770
the more of these commitments,
the more range proofs,

01:07:25.770 --> 01:07:27.270
quite honestly, is the problem.

01:07:27.270 --> 01:07:29.700
Because there's a
range proof per entry.

01:07:29.700 --> 01:07:32.010
And what we see here
is that with 10 banks,

01:07:32.010 --> 01:07:36.090
it's about a second
or 800 milliseconds

01:07:36.090 --> 01:07:39.570
to create a transaction,
which is not unreasonable.

01:07:39.570 --> 01:07:44.070
Again, this achieves the
multiple per second things

01:07:44.070 --> 01:07:46.320
we were looking for, depending
on the number of banks.

01:07:46.320 --> 01:07:48.270
However, it is
linear in the number

01:07:48.270 --> 01:07:49.990
of participants in the system.

01:07:49.990 --> 01:07:54.570
So something like this is not
really suitable for a setting

01:07:54.570 --> 01:07:58.560
like Bitcoin, where there are
thousands, if not millions,

01:07:58.560 --> 01:08:01.670
of participants in the system.

01:08:01.670 --> 01:08:05.800
This graph gives you an
idea of how all of that cost

01:08:05.800 --> 01:08:07.280
breaks down.

01:08:07.280 --> 01:08:13.240
So these are the
components in the proofs.

01:08:13.240 --> 01:08:16.630
And again, I think the
thing to get from here

01:08:16.630 --> 01:08:22.000
is that range proofs are
the entirety of the problem.

01:08:22.000 --> 01:08:25.390
So this is the number in a
transaction for k participants.

01:08:25.390 --> 01:08:28.779
So this is each slot.

01:08:28.779 --> 01:08:30.430
There are two
different commitments.

01:08:30.430 --> 01:08:32.470
The first commitment, and
then the auxiliary commitment.

01:08:32.470 --> 01:08:34.178
There's two different
consistency proofs.

01:08:34.178 --> 01:08:37.010
There's a disjunctive proof,
and there's a range proof.

01:08:37.010 --> 01:08:42.279
And yeah, the commitment is
one elliptic curve point,

01:08:42.279 --> 01:08:44.850
which in Go is a big int--

01:08:44.850 --> 01:08:46.630
two big ints.

01:08:46.630 --> 01:08:48.430
And so that's 64 bytes.

01:08:48.430 --> 01:08:52.880
This is something that is
actually highly compressable.

01:08:52.880 --> 01:08:56.380
We didn't actually-- oh, OK.

01:08:56.380 --> 01:08:58.200
Yeah, I'll get to that
point in a moment.

01:08:58.200 --> 01:09:04.109
But note here that the range
proofs are slower and larger

01:09:04.109 --> 01:09:05.490
than everything else combined.

01:09:05.490 --> 01:09:07.979
They are the entirety of
the cost of the system.

01:09:07.979 --> 01:09:11.700
So a faster way of doing range
proofs would really help a lot.

01:09:11.700 --> 01:09:15.090
It would make us be able to
handle many, many more banks.

01:09:17.840 --> 01:09:20.380
So this is the cost
in a transaction

01:09:20.380 --> 01:09:22.029
per participant in the system.

01:09:22.029 --> 01:09:29.310
[AUDIO OUT] One thing
that I want to point out

01:09:29.310 --> 01:09:34.410
is that this is all very
highly parallelizable.

01:09:34.410 --> 01:09:38.580
And like I said, we're using
Go's big int construction,

01:09:38.580 --> 01:09:41.800
which is not really
very optimized at all.

01:09:41.800 --> 01:09:44.069
So I think that there are
a lot of opportunities

01:09:44.069 --> 01:09:45.270
to make this faster.

01:09:45.270 --> 01:09:50.189
So I think if we put in
some engineering legwork,

01:09:50.189 --> 01:09:53.040
we could create a
system that was maybe

01:09:53.040 --> 01:09:57.330
twice as fast as what we have
now, and could handle maybe 100

01:09:57.330 --> 01:10:00.090
banks.

01:10:00.090 --> 01:10:03.240
So really quickly to
wrap up, related work.

01:10:03.240 --> 01:10:04.870
If you're interested
in this topic,

01:10:04.870 --> 01:10:08.280
there's a lot of different
papers to read about and study.

01:10:08.280 --> 01:10:10.770
This is all-- confidential
assets kicked off

01:10:10.770 --> 01:10:13.500
this line of using Pedersen
commitments for privacy

01:10:13.500 --> 01:10:14.760
in cryptocurrencies.

01:10:14.760 --> 01:10:19.680
Zerocash was the origin
of using zk-SNARKs.

01:10:19.680 --> 01:10:23.640
They don't really support
auditing in any fashion.

01:10:23.640 --> 01:10:26.820
Then there's a couple papers
that are really interesting,

01:10:26.820 --> 01:10:29.760
one from Andrew
Lowe, actually, who's

01:10:29.760 --> 01:10:32.010
in the economics
department here at MIT,

01:10:32.010 --> 01:10:35.220
on using secure
multi-party computation

01:10:35.220 --> 01:10:38.210
to attack this problem.

01:10:38.210 --> 01:10:41.760
The issue with
that sort of design

01:10:41.760 --> 01:10:44.520
is that it doesn't actually
have the completeness guarantee

01:10:44.520 --> 01:10:45.640
that we have.

01:10:45.640 --> 01:10:47.970
So if the ledger really
represents the assets

01:10:47.970 --> 01:10:50.778
in the system, and the assets
that you're trying to audit,

01:10:50.778 --> 01:10:52.320
then there's no way
for a participant

01:10:52.320 --> 01:10:54.160
to lie in a multi-party
computation.

01:10:54.160 --> 01:10:55.680
They can use the wrong inputs.

01:10:55.680 --> 01:10:57.720
So those systems
provide secrecy,

01:10:57.720 --> 01:10:59.640
but they don't
provide completeness.

01:10:59.640 --> 01:11:02.370
And then I mentioned
Solidus before,

01:11:02.370 --> 01:11:05.610
which I think our techniques
would apply to really nicely.

01:11:05.610 --> 01:11:09.720
And then there's
a paper, a design

01:11:09.720 --> 01:11:12.300
for doing some other sorts
of accountability stuff

01:11:12.300 --> 01:11:15.120
with cryptocurrencies, like
proving you paid your taxes,

01:11:15.120 --> 01:11:20.310
or proving that money didn't go
through some blacklisted thing

01:11:20.310 --> 01:11:22.083
using zk-SNARKs.

01:11:22.083 --> 01:11:24.000
But that's not really a
system, it's a design.

01:11:24.000 --> 01:11:28.170
But I think that's also a really
promising area to consider.

01:11:28.170 --> 01:11:32.310
So, future work.

01:11:32.310 --> 01:11:35.550
We want to consider more
applications besides just

01:11:35.550 --> 01:11:38.520
large investment banks
trading securities and assets.

01:11:38.520 --> 01:11:42.690
Can we do something
with clinical trials?

01:11:42.690 --> 01:11:45.390
Can we do something
with supply chains?

01:11:45.390 --> 01:11:46.800
I think that these
techniques can

01:11:46.800 --> 01:11:48.923
be applied to a lot more areas.

01:11:48.923 --> 01:11:50.340
And I'd love to
hear from you guys

01:11:50.340 --> 01:11:52.882
if you have ideas on that, or
if you're interested in working

01:11:52.882 --> 01:11:55.590
on that and want to do
a UROP, or maybe even

01:11:55.590 --> 01:11:58.680
an M.Eng., that's definitely
something that's on the table.

01:11:58.680 --> 01:12:02.280
We get surprisingly far
with Pedersen commitments,

01:12:02.280 --> 01:12:05.283
but if we included
more interesting types

01:12:05.283 --> 01:12:07.200
of cryptographic primitives,
we could probably

01:12:07.200 --> 01:12:08.460
get more functionality.

01:12:08.460 --> 01:12:10.440
So what's the type--
we know, given

01:12:10.440 --> 01:12:13.980
that we might want to apply this
to different use cases, what

01:12:13.980 --> 01:12:16.368
types of functionality
might we need?

01:12:16.368 --> 01:12:17.910
There's someone at
the Media Lab here

01:12:17.910 --> 01:12:22.470
who is interested in running
algorithms on research trials.

01:12:22.470 --> 01:12:26.377
And secrecy and privacy
is really important.

01:12:26.377 --> 01:12:28.710
I haven't even looked at his
machine-learning algorithms

01:12:28.710 --> 01:12:30.990
yet, but can we run
machine-learning algorithms

01:12:30.990 --> 01:12:36.090
on Pedersen commitments, or
do we need something else?

01:12:36.090 --> 01:12:38.193
Also, another really
important area of future work

01:12:38.193 --> 01:12:39.610
is to optimize the
implementation.

01:12:39.610 --> 01:12:42.060
Like I said, I think we get
at least twice as fast, if not

01:12:42.060 --> 01:12:43.500
more.

01:12:43.500 --> 01:12:46.050
And in conclusion,
yeah, if you want

01:12:46.050 --> 01:12:48.300
to work on any of these
things, please let me know.

01:12:48.300 --> 01:12:51.210
If you're interested in using
cryptographic primitives

01:12:51.210 --> 01:12:53.250
to achieve privacy with
interesting functions,

01:12:53.250 --> 01:12:55.705
let me know.

01:12:55.705 --> 01:12:58.080
And this is the website for
zkLedger, which at the moment

01:12:58.080 --> 01:13:00.300
is really just the paper.

01:13:00.300 --> 01:13:04.500
We have a code base which is too
embarrassing to be released out

01:13:04.500 --> 01:13:07.050
into the real world, but
we'll get there shortly,

01:13:07.050 --> 01:13:08.250
once we clean it up.

01:13:08.250 --> 01:13:09.590
So that's it.

01:13:09.590 --> 01:13:10.787
So thanks for listening.

01:13:10.787 --> 01:13:12.120
I hope you found it interesting.

01:13:12.120 --> 01:13:15.170
[APPLAUSE]