1 00:00:00,950 --> 00:00:03,320 The following content is provided under a Creative 2 00:00:03,320 --> 00:00:04,710 Commons license. 3 00:00:04,710 --> 00:00:06,920 Your support will help MIT OpenCourseWare 4 00:00:06,920 --> 00:00:11,010 continue to offer high quality educational resources for free. 5 00:00:11,010 --> 00:00:13,580 To make a donation or to view additional materials 6 00:00:13,580 --> 00:00:17,540 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,540 --> 00:00:18,426 at ocw.mit.edu. 8 00:00:23,950 --> 00:00:26,750 NEHA NARULA: OK, let's go ahead and get started. 9 00:00:26,750 --> 00:00:30,520 So Tadge is in California today, so he 10 00:00:30,520 --> 00:00:33,220 asked me to give today's lecture, which 11 00:00:33,220 --> 00:00:34,750 will be based on a research project 12 00:00:34,750 --> 00:00:37,630 that we're working on at the DCI. 13 00:00:37,630 --> 00:00:39,430 This is actually really connected 14 00:00:39,430 --> 00:00:42,610 to confidential transactions and confidential assets, 15 00:00:42,610 --> 00:00:45,760 which I think that you guys covered in a previous class. 16 00:00:45,760 --> 00:00:48,970 So Pedersen commitments will play a very important role 17 00:00:48,970 --> 00:00:50,560 in the work I'm about to present. 18 00:00:50,560 --> 00:00:54,280 I want to present this work that we've been doing. 19 00:00:54,280 --> 00:00:58,630 This is joint work with Willy Vasquez, who was an MIT M.Eng. 20 00:00:58,630 --> 00:01:01,700 He graduated and moved to UT-Austin, and Madars 21 00:01:01,700 --> 00:01:04,420 Virza, who is a research scientist with the DCI. 22 00:01:04,420 --> 00:01:06,640 And this project is called zkLedger. 23 00:01:06,640 --> 00:01:09,460 It's about privacy-preserving auditing 24 00:01:09,460 --> 00:01:11,470 for distributed ledgers. 25 00:01:11,470 --> 00:01:14,980 So to start with, I am not sure how much 26 00:01:14,980 --> 00:01:17,710 work you guys have done on permissioned blockchains 27 00:01:17,710 --> 00:01:18,557 so far. 28 00:01:18,557 --> 00:01:20,140 How much have you covered with respect 29 00:01:20,140 --> 00:01:21,340 to permissioned blockchains? 30 00:01:21,340 --> 00:01:22,520 Nothing at all? 31 00:01:22,520 --> 00:01:23,020 OK. 32 00:01:25,408 --> 00:01:27,700 Should we start with what is a permissioned blockchain, 33 00:01:27,700 --> 00:01:30,100 or do you guys feel like you have a handle on what 34 00:01:30,100 --> 00:01:31,400 that means or what that is? 35 00:01:31,400 --> 00:01:34,010 In its most generic, abstract sense? 36 00:01:34,010 --> 00:01:34,780 Yes? 37 00:01:34,780 --> 00:01:37,600 AUDIENCE: Does it just mean that different people have access 38 00:01:37,600 --> 00:01:39,040 to see parts of the chain? 39 00:01:39,040 --> 00:01:39,790 NEHA NARULA: Yeah. 40 00:01:39,790 --> 00:01:41,230 So, good question. 41 00:01:41,230 --> 00:01:44,620 OK, so these words that we use-- permissioned versus 42 00:01:44,620 --> 00:01:47,170 permissionless-- usually refer to who 43 00:01:47,170 --> 00:01:49,780 has right access to the chain. 44 00:01:49,780 --> 00:01:53,560 So in cryptocurrencies like Bitcoin and Ethereum, 45 00:01:53,560 --> 00:01:57,490 theoretically, any one of us could spin up our own ASIC, 46 00:01:57,490 --> 00:02:01,270 get really lucky, mine a block, and put the transactions 47 00:02:01,270 --> 00:02:04,060 that we are interested in into the chain. 48 00:02:04,060 --> 00:02:07,510 Now of course, no one's going to accept that block 49 00:02:07,510 --> 00:02:11,260 if it violates the majority consensus rules of the chain. 50 00:02:11,260 --> 00:02:14,710 But assuming that it follows the rules, it's well formatted, 51 00:02:14,710 --> 00:02:18,220 it has the appropriate proof of work, et cetera, any one of us 52 00:02:18,220 --> 00:02:20,480 could submit a block to the Bitcoin blockchain. 53 00:02:20,480 --> 00:02:21,310 Right? 54 00:02:21,310 --> 00:02:25,180 There's no permissions on who is allowed 55 00:02:25,180 --> 00:02:29,096 and who isn't allowed to write to the Bitcoin blockchain. 56 00:02:31,720 --> 00:02:34,640 Permissioned blockchains are a different story. 57 00:02:34,640 --> 00:02:37,210 These are more like distributed databases. 58 00:02:37,210 --> 00:02:39,490 The idea behind permissioned blockchains 59 00:02:39,490 --> 00:02:42,670 is that you choose a set of actors ahead of time, 60 00:02:42,670 --> 00:02:45,430 and only those actors are allowed 61 00:02:45,430 --> 00:02:47,590 to write to the blockchain. 62 00:02:47,590 --> 00:02:49,870 So you can't just have anyone willy-nilly 63 00:02:49,870 --> 00:02:52,060 spinning up a mining node, or spinning up 64 00:02:52,060 --> 00:02:55,090 a node in the system, and submitting transactions 65 00:02:55,090 --> 00:02:56,530 and things to the blockchain. 66 00:02:56,530 --> 00:02:58,450 Usually, permissioned versus permissionless 67 00:02:58,450 --> 00:02:59,950 doesn't say anything about reads, 68 00:02:59,950 --> 00:03:01,283 and who can read the blockchain. 69 00:03:01,283 --> 00:03:03,400 We're really just talking about rights. 70 00:03:03,400 --> 00:03:05,470 So an important use-- 71 00:03:05,470 --> 00:03:07,060 permissioned blockchains, I think, 72 00:03:07,060 --> 00:03:10,780 are not really the focus of this course, in part 73 00:03:10,780 --> 00:03:16,410 because we take the position that the technology behind them 74 00:03:16,410 --> 00:03:18,490 is essentially distributed databases. 75 00:03:18,490 --> 00:03:21,640 And there's lovely courses out there on distributed databases. 76 00:03:21,640 --> 00:03:23,260 And there's a lot to learn about them, 77 00:03:23,260 --> 00:03:26,800 and they're very interesting, but they're not necessarily 78 00:03:26,800 --> 00:03:29,200 very closely related to cryptocurrencies 79 00:03:29,200 --> 00:03:33,040 and the designs of the past decade. 80 00:03:33,040 --> 00:03:35,200 So that's the idea behind permissioned blockchains. 81 00:03:35,200 --> 00:03:37,660 Now, as I was saying, I think that there's 82 00:03:37,660 --> 00:03:39,950 a lot of use cases for permissioned blockchains. 83 00:03:39,950 --> 00:03:41,140 They're very useful. 84 00:03:41,140 --> 00:03:43,450 Distributed databases, in general, are very useful. 85 00:03:43,450 --> 00:03:45,190 And so let's talk about one of them. 86 00:03:45,190 --> 00:03:48,460 And I'm going to interchangeably use permissioned blockchain 87 00:03:48,460 --> 00:03:50,470 and distributed ledger, here. 88 00:03:50,470 --> 00:03:52,540 Distributed ledger, permissioned blockchain, 89 00:03:52,540 --> 00:03:56,317 I'm sort of saying the same thing. 90 00:03:56,317 --> 00:03:58,150 So permissioned blockchains-- any questions, 91 00:03:58,150 --> 00:04:01,720 before we dive into the use case in zkLedger, 92 00:04:01,720 --> 00:04:04,610 about permissioned blockchains? 93 00:04:04,610 --> 00:04:05,195 Get the idea? 94 00:04:05,195 --> 00:04:07,070 It's a whole bunch of people working together 95 00:04:07,070 --> 00:04:09,560 to construct a ledger. 96 00:04:09,560 --> 00:04:11,180 So let's start with the structure 97 00:04:11,180 --> 00:04:12,750 of the financial system. 98 00:04:12,750 --> 00:04:15,285 And this is setting the use case for zkLedger, 99 00:04:15,285 --> 00:04:16,910 and what we were trying to do, and what 100 00:04:16,910 --> 00:04:18,390 we were trying to address. 101 00:04:18,390 --> 00:04:21,860 So to start with, there are dozens of very large investment 102 00:04:21,860 --> 00:04:25,670 banks that are trading securities, currencies, 103 00:04:25,670 --> 00:04:27,770 commodities, derivatives. 104 00:04:27,770 --> 00:04:30,470 Many of these things are traded on exchanges, 105 00:04:30,470 --> 00:04:34,100 regulated exchanges like NASDAQ or the New York Stock Exchange. 106 00:04:34,100 --> 00:04:38,870 But up to 40% are actually traded in unregulated fashion. 107 00:04:38,870 --> 00:04:41,690 They're done in a way that's called over-the-counter, 108 00:04:41,690 --> 00:04:44,690 meaning that there is no regulated exchange sitting 109 00:04:44,690 --> 00:04:47,090 in the middle facilitating these trades. 110 00:04:47,090 --> 00:04:49,850 Instead, the banks, the entities, 111 00:04:49,850 --> 00:04:54,260 trade amongst themselves in a slightly more ad hoc fashion. 112 00:04:54,260 --> 00:04:57,920 This represents trillions of dollars of the economy. 113 00:04:57,920 --> 00:05:00,087 And just to give you a sense of scale, 114 00:05:00,087 --> 00:05:02,420 the time frequency we're dealing, with we're not talking 115 00:05:02,420 --> 00:05:03,800 about high-frequency trading. 116 00:05:03,800 --> 00:05:06,960 That's not the use case that zkLedger is targeting. 117 00:05:06,960 --> 00:05:08,780 We're thinking like 10s of trades a minute. 118 00:05:08,780 --> 00:05:11,690 These are things that are done electronically. 119 00:05:11,690 --> 00:05:12,788 It's not like people are-- 120 00:05:12,788 --> 00:05:14,330 people might be calling each other up 121 00:05:14,330 --> 00:05:16,288 to arrange these trades, but oftentimes they're 122 00:05:16,288 --> 00:05:17,250 done electronically. 123 00:05:17,250 --> 00:05:20,540 But we're not considering high-frequency trading. 124 00:05:20,540 --> 00:05:25,190 So a useful abstraction for thinking 125 00:05:25,190 --> 00:05:29,510 about a table of these trades is a transaction ledger. 126 00:05:29,510 --> 00:05:33,170 So each row in the ledger is a transaction, 127 00:05:33,170 --> 00:05:35,690 transferring assets from one bank to another. 128 00:05:35,690 --> 00:05:37,970 So this should be very familiar to everyone. 129 00:05:37,970 --> 00:05:40,640 It looks a little bit different than things like Bitcoin, 130 00:05:40,640 --> 00:05:47,420 because since this is a ledger designed for the existing 131 00:05:47,420 --> 00:05:50,510 financial system, we know who the entities are. 132 00:05:50,510 --> 00:05:51,530 They have names. 133 00:05:51,530 --> 00:05:53,165 They're regulated. 134 00:05:53,165 --> 00:05:54,740 They have companies behind them. 135 00:05:54,740 --> 00:05:59,180 We're not talking just about arbitrary public keys. 136 00:05:59,180 --> 00:06:01,190 So each row in the ledger is a transaction. 137 00:06:01,190 --> 00:06:04,412 So here, Citibank is transferring a million dollars. 138 00:06:04,412 --> 00:06:05,870 So that's another thing that's very 139 00:06:05,870 --> 00:06:07,203 different than cryptocurrencies. 140 00:06:07,203 --> 00:06:09,020 Here we have multiple different assets 141 00:06:09,020 --> 00:06:10,530 being recorded in the ledger. 142 00:06:10,530 --> 00:06:14,480 So we're not talking about a ledger with a native asset, 143 00:06:14,480 --> 00:06:15,042 necessarily. 144 00:06:15,042 --> 00:06:16,250 This is not a cryptocurrency. 145 00:06:16,250 --> 00:06:19,370 Really think about this like a table in a database 146 00:06:19,370 --> 00:06:20,720 recording transactions. 147 00:06:20,720 --> 00:06:23,780 Those transactions might be in dollars, or euros, 148 00:06:23,780 --> 00:06:27,690 or municipal bonds, or securities, or shares-- 149 00:06:27,690 --> 00:06:28,940 they could be anything, right? 150 00:06:28,940 --> 00:06:31,445 So we're just recording transactions. 151 00:06:31,445 --> 00:06:33,320 So Citibank is transferring a million dollars 152 00:06:33,320 --> 00:06:34,550 to Goldman Sachs. 153 00:06:34,550 --> 00:06:39,590 JP Morgan is transferring money to UBS and to Barclays. 154 00:06:39,590 --> 00:06:40,970 OK? 155 00:06:40,970 --> 00:06:44,810 So as with cryptocurrencies, I think, 156 00:06:44,810 --> 00:06:47,900 cryptocurrencies have inspired people 157 00:06:47,900 --> 00:06:51,080 to reconsider the case of a distributed 158 00:06:51,080 --> 00:06:54,410 database as a ledger that multiple entities can write to. 159 00:06:54,410 --> 00:06:57,560 And part of that consideration involves thinking 160 00:06:57,560 --> 00:06:59,330 about digital signatures. 161 00:06:59,330 --> 00:07:04,400 So maybe these banks have public, private key pairs. 162 00:07:04,400 --> 00:07:08,720 And perhaps they use their keys to indicate consent 163 00:07:08,720 --> 00:07:10,400 on the transaction, right? 164 00:07:10,400 --> 00:07:12,380 This is something that's done under the hood 165 00:07:12,380 --> 00:07:14,720 right now, when you think about the protocols we 166 00:07:14,720 --> 00:07:15,760 use to exchange data. 167 00:07:15,760 --> 00:07:18,100 But it's not necessarily done explicitly 168 00:07:18,100 --> 00:07:19,850 when creating these distributed databases. 169 00:07:19,850 --> 00:07:24,680 So they can use their keys to attach signatures 170 00:07:24,680 --> 00:07:27,020 to the transaction to indicate a consent 171 00:07:27,020 --> 00:07:29,150 to transfer for security. 172 00:07:29,150 --> 00:07:33,380 Now, this ledger might be maintained by a third party, 173 00:07:33,380 --> 00:07:35,690 or it could be a distributed database, 174 00:07:35,690 --> 00:07:38,060 a permissioned blockchain that is 175 00:07:38,060 --> 00:07:39,780 run by the transacting parties. 176 00:07:42,800 --> 00:07:45,830 So there are some important financial invariants 177 00:07:45,830 --> 00:07:48,890 that you want to maintain here to verify that transactions are 178 00:07:48,890 --> 00:07:53,500 happening correctly, that they're valid, that assets 179 00:07:53,500 --> 00:07:55,030 aren't created out of nowhere. 180 00:07:55,030 --> 00:07:58,610 So one of them is consent to transfer. 181 00:07:58,610 --> 00:08:01,070 And we use these signatures for that. 182 00:08:01,070 --> 00:08:02,982 Another important thing to verify, 183 00:08:02,982 --> 00:08:04,940 another important invariant, is that the person 184 00:08:04,940 --> 00:08:08,450 doing the transacting actually has the assets to transfer. 185 00:08:08,450 --> 00:08:10,950 That they're not making up assets out of nowhere, 186 00:08:10,950 --> 00:08:12,992 or they're not double-spending-- that there isn't 187 00:08:12,992 --> 00:08:15,440 something incorrect happening. 188 00:08:15,440 --> 00:08:17,860 And then, that assets are neither created nor destroyed. 189 00:08:17,860 --> 00:08:19,360 That we have conservation of assets. 190 00:08:19,360 --> 00:08:22,580 So these are important financial invariants to maintain. 191 00:08:22,580 --> 00:08:25,765 This looks a lot like what the invariants are that we're 192 00:08:25,765 --> 00:08:27,890 trying to maintain in a cryptocurrency like Bitcoin 193 00:08:27,890 --> 00:08:30,830 or Ethereum, except this was with multiple assets, 194 00:08:30,830 --> 00:08:34,350 and we know who the people are involved. 195 00:08:34,350 --> 00:08:41,429 Now, if this ledger were being maintained by an exchange, 196 00:08:41,429 --> 00:08:45,050 then the exchange would be responsible for verifying 197 00:08:45,050 --> 00:08:47,810 and validating that all of these transactions are correct. 198 00:08:47,810 --> 00:08:50,960 If this ledger is being maintained by the participants, 199 00:08:50,960 --> 00:08:53,360 it's a permissioned blockchain, then 200 00:08:53,360 --> 00:08:56,480 everyone can verify and validate that these invariants are being 201 00:08:56,480 --> 00:08:58,940 maintained by looking at the blockchain, 202 00:08:58,940 --> 00:09:02,210 by checking the signatures, right? 203 00:09:02,210 --> 00:09:08,470 So that's great, except for the fact that privacy 204 00:09:08,470 --> 00:09:10,480 is really, really important. 205 00:09:10,480 --> 00:09:13,210 And quite a bit of data, and quite 206 00:09:13,210 --> 00:09:15,070 a bit of sensitive information, is actually 207 00:09:15,070 --> 00:09:17,320 leaked by looking at these transactions. 208 00:09:17,320 --> 00:09:20,350 So if we want to be able to maintain financial invariants, 209 00:09:20,350 --> 00:09:22,223 if we want to be able to check and make sure 210 00:09:22,223 --> 00:09:23,390 that the ledger is correct-- 211 00:09:23,390 --> 00:09:25,550 and I mean, this is the whole point of blockchains, 212 00:09:25,550 --> 00:09:29,920 is that everyone can verify, and validate, and reconcile 213 00:09:29,920 --> 00:09:31,030 real time. 214 00:09:31,030 --> 00:09:35,020 Then in the act of looking at those transactions, 215 00:09:35,020 --> 00:09:38,320 you're actually finding out really sensitive information 216 00:09:38,320 --> 00:09:39,970 about banks' trading strategy-- about 217 00:09:39,970 --> 00:09:41,340 their intellectual property. 218 00:09:41,340 --> 00:09:42,910 OK? 219 00:09:42,910 --> 00:09:45,280 For example, a large trade might indicate 220 00:09:45,280 --> 00:09:49,450 that a bank has decided to get out of a position. 221 00:09:49,450 --> 00:09:50,917 Other banks could learn about this, 222 00:09:50,917 --> 00:09:52,500 notice it on the blockchain as they're 223 00:09:52,500 --> 00:09:55,750 validating transactions, and try to follow suit, 224 00:09:55,750 --> 00:09:57,280 driving down the price. 225 00:09:57,280 --> 00:09:59,897 So privacy, especially in this type of context, 226 00:09:59,897 --> 00:10:00,730 is really important. 227 00:10:00,730 --> 00:10:04,240 And I'm sure you can imagine a lot of other different types 228 00:10:04,240 --> 00:10:08,380 of context in which privacy is important as well, right? 229 00:10:08,380 --> 00:10:11,650 So we don't want to be in this situation 230 00:10:11,650 --> 00:10:16,000 where we have to choose between privacy 231 00:10:16,000 --> 00:10:19,100 and being able to validate what's going on. 232 00:10:19,100 --> 00:10:19,720 Right? 233 00:10:19,720 --> 00:10:22,870 So even if we were to use a trusted third party 234 00:10:22,870 --> 00:10:25,090 like an exchange, we still wouldn't 235 00:10:25,090 --> 00:10:27,730 have privacy, necessarily, because the exchange would 236 00:10:27,730 --> 00:10:29,660 be looking at everything in the ledger. 237 00:10:29,660 --> 00:10:32,960 So that's the goal here that we're trying to achieve. 238 00:10:32,960 --> 00:10:34,630 We're trying to achieve this goal where 239 00:10:34,630 --> 00:10:37,510 we want to be able to publicly verify and validate 240 00:10:37,510 --> 00:10:41,350 what's happening in the ledger, and at the same time, 241 00:10:41,350 --> 00:10:43,840 obtain some amount of privacy for transactions. 242 00:10:43,840 --> 00:10:45,340 We don't want all transactions to be 243 00:10:45,340 --> 00:10:47,590 public to whoever is maintaining the ledger, 244 00:10:47,590 --> 00:10:51,880 be that a third party exchange or a set of banks. 245 00:10:51,880 --> 00:10:53,815 So I'm just going to pause right there and-- 246 00:10:56,911 --> 00:10:58,710 do we get the setup, here? 247 00:10:58,710 --> 00:11:03,030 Privacy versus verification-- we want both. 248 00:11:03,030 --> 00:11:05,220 Any questions about that? 249 00:11:05,220 --> 00:11:05,940 Yes? 250 00:11:05,940 --> 00:11:07,357 AUDIENCE: I was confused as to how 251 00:11:07,357 --> 00:11:09,893 you verify that people-- transactions are 252 00:11:09,893 --> 00:11:11,310 correct in their account balances? 253 00:11:11,310 --> 00:11:13,090 It's like there's no native assets supplied. 254 00:11:13,090 --> 00:11:14,882 NEHA NARULA: Yeah, that's a great question. 255 00:11:14,882 --> 00:11:18,160 So I have dollars and euros here, right? 256 00:11:18,160 --> 00:11:20,830 How do you know that Citibank actually has those dollars 257 00:11:20,830 --> 00:11:22,820 to transfer to Goldman Sachs? 258 00:11:22,820 --> 00:11:23,320 Right? 259 00:11:23,320 --> 00:11:24,910 Where does that come from? 260 00:11:24,910 --> 00:11:28,090 Notice how this is transaction number 90. 261 00:11:28,090 --> 00:11:30,340 I'm assuming that there's a transaction up here-- 262 00:11:30,340 --> 00:11:32,080 this is just a subset of the ledger. 263 00:11:32,080 --> 00:11:35,260 But as you'll see in a moment, we 264 00:11:35,260 --> 00:11:38,920 think about this role of depositors 265 00:11:38,920 --> 00:11:41,860 who are allowed to deposit assets into the ledger. 266 00:11:41,860 --> 00:11:45,070 And so I'm assuming there's a transaction up here somewhere 267 00:11:45,070 --> 00:11:49,240 which in a provable way shows that someone 268 00:11:49,240 --> 00:11:52,260 we trust to deposit assets into the ledger 269 00:11:52,260 --> 00:11:55,240 gave Citibank the dollars necessary for them 270 00:11:55,240 --> 00:11:56,710 to give to Goldman Sachs. 271 00:11:56,710 --> 00:11:58,070 But you're absolutely right. 272 00:11:58,070 --> 00:12:01,000 If the asset isn't native to the ledger, 273 00:12:01,000 --> 00:12:03,722 then you do have that connection to the real world, 274 00:12:03,722 --> 00:12:05,680 where you do need to apply some level of trust. 275 00:12:05,680 --> 00:12:07,450 The question, is it auditable? 276 00:12:07,450 --> 00:12:11,440 Can you at least track it back up to that point? 277 00:12:11,440 --> 00:12:14,620 Any other questions? 278 00:12:14,620 --> 00:12:17,575 OK, great. 279 00:12:17,575 --> 00:12:19,800 So we want to do the following. 280 00:12:19,800 --> 00:12:22,915 We want to be able to verify that financial invariants are 281 00:12:22,915 --> 00:12:25,040 maintained, that things are correct while achieving 282 00:12:25,040 --> 00:12:26,180 privacy. 283 00:12:26,180 --> 00:12:29,210 So one good technique for achieving privacy 284 00:12:29,210 --> 00:12:35,250 is simply to encrypt or hide the transactions in the ledger, OK? 285 00:12:35,250 --> 00:12:41,780 So surprisingly, maybe, we actually know how to do this. 286 00:12:41,780 --> 00:12:46,160 And to, at the same time, still achieve 287 00:12:46,160 --> 00:12:48,590 checking of the financial invariants. 288 00:12:48,590 --> 00:12:51,150 Here are two systems that actually achieve this. 289 00:12:51,150 --> 00:12:55,820 The first is Zerocash, which was implemented inside of Zcash, 290 00:12:55,820 --> 00:12:57,650 an anonymous cryptocurrency. 291 00:12:57,650 --> 00:13:02,175 In Zcash, transactions are completely hidden. 292 00:13:02,175 --> 00:13:04,550 They're completely opaque shielded transactions in Zcash. 293 00:13:04,550 --> 00:13:07,190 Zcash has two transactions. 294 00:13:07,190 --> 00:13:08,960 Once set is public, like in Bitcoin. 295 00:13:08,960 --> 00:13:11,870 The other set are called shielded transactions. 296 00:13:11,870 --> 00:13:13,970 And in a shielded transaction, you 297 00:13:13,970 --> 00:13:16,730 don't know who the parties are who are involved. 298 00:13:16,730 --> 00:13:20,630 You don't know the amount of the asset that's transferred. 299 00:13:20,630 --> 00:13:23,990 But you can validate that this was correct, 300 00:13:23,990 --> 00:13:27,020 that financial invariants were maintained. 301 00:13:27,020 --> 00:13:31,610 Zerocash and Zcash use a primitive called zero-knowledge 302 00:13:31,610 --> 00:13:34,250 proofs, and in particular, zk-SNARKS-- 303 00:13:34,250 --> 00:13:37,520 zero knowledge succinct arguments of knowledge. 304 00:13:37,520 --> 00:13:42,830 Those were actually developed in part here at MIT. 305 00:13:42,830 --> 00:13:46,310 So using these really interesting cryptographic 306 00:13:46,310 --> 00:13:49,850 primitives, we're able to maintain financial invariance 307 00:13:49,850 --> 00:13:50,750 in Zcash. 308 00:13:50,750 --> 00:13:52,940 There's another system called Solidus, 309 00:13:52,940 --> 00:13:56,750 which is out of Cornell, which also achieves this. 310 00:13:56,750 --> 00:13:59,150 You can't tell who the participants are. 311 00:13:59,150 --> 00:14:03,360 And you can still maintain financial invariants. 312 00:14:03,360 --> 00:14:05,570 Solidus uses a completely different cryptographic 313 00:14:05,570 --> 00:14:09,412 primitive called PVORM. 314 00:14:09,412 --> 00:14:11,120 So you should check out both these papers 315 00:14:11,120 --> 00:14:12,830 if you're interested. 316 00:14:12,830 --> 00:14:17,690 It's definitely still possible to accomplish this, right? 317 00:14:17,690 --> 00:14:21,300 However, there's still a problem here. 318 00:14:21,300 --> 00:14:24,890 Both of these systems hide everything. 319 00:14:24,890 --> 00:14:29,420 You get no insight into the economy, into the blockchain, 320 00:14:29,420 --> 00:14:34,250 into what's actually happening in the system. 321 00:14:34,250 --> 00:14:38,360 Regulators, in particular, need insight into markets 322 00:14:38,360 --> 00:14:40,610 in order to maintain financial stability 323 00:14:40,610 --> 00:14:43,430 and in order to protect investors. 324 00:14:43,430 --> 00:14:46,520 Even considering non-financial use cases, 325 00:14:46,520 --> 00:14:48,770 it's oftentimes the case that people 326 00:14:48,770 --> 00:14:52,010 who might be using a blockchain, or distributed 327 00:14:52,010 --> 00:14:53,930 ledger, or distributed database want 328 00:14:53,930 --> 00:14:59,210 to be able to maintain that certain things are true 329 00:14:59,210 --> 00:15:04,290 and to get some insight into the system that they're a part of. 330 00:15:07,510 --> 00:15:11,140 Lack of insight can actually have devastating effects, 331 00:15:11,140 --> 00:15:14,140 as we saw with toxic assets in 2008. 332 00:15:14,140 --> 00:15:19,000 One part of the problem, one contributor to the crisis, 333 00:15:19,000 --> 00:15:21,340 was the issue that people didn't really 334 00:15:21,340 --> 00:15:26,560 have confidence or insight into exactly what assets banks had 335 00:15:26,560 --> 00:15:27,430 on their books. 336 00:15:27,430 --> 00:15:29,410 It was a bit confusing. 337 00:15:29,410 --> 00:15:32,500 And surprisingly, this happens to this day 338 00:15:32,500 --> 00:15:37,840 I think there was a case with Dow Chemical where they didn't 339 00:15:37,840 --> 00:15:39,640 actually know how many outstanding 340 00:15:39,640 --> 00:15:41,200 shares that they had issued. 341 00:15:41,200 --> 00:15:42,160 They just didn't know. 342 00:15:42,160 --> 00:15:45,040 And they had to give out a dividend, 343 00:15:45,040 --> 00:15:48,070 and they gave out too much money or too 344 00:15:48,070 --> 00:15:51,160 little money or something like that. 345 00:15:51,160 --> 00:15:54,790 So here are some examples of things that we might 346 00:15:54,790 --> 00:15:56,890 want to measure and understand. 347 00:15:56,890 --> 00:15:59,630 We might want to get a sense of leverage in the system. 348 00:15:59,630 --> 00:16:03,580 So, the participants who are holding assets, 349 00:16:03,580 --> 00:16:06,100 how much do they have en masse? 350 00:16:06,100 --> 00:16:07,990 We want to understand exposure. 351 00:16:07,990 --> 00:16:11,350 We might want to get a sense of market concentration. 352 00:16:11,350 --> 00:16:15,220 It's pretty useful to know things like, OK, this bank, 353 00:16:15,220 --> 00:16:18,190 this asset in particular is very highly concentrated. 354 00:16:18,190 --> 00:16:19,840 Or this asset is more distributed 355 00:16:19,840 --> 00:16:22,210 amongst the participants of the system. 356 00:16:22,210 --> 00:16:24,400 So there are things that we might 357 00:16:24,400 --> 00:16:27,280 want to learn about the economy represented 358 00:16:27,280 --> 00:16:29,550 by the assets in the blockchain. 359 00:16:29,550 --> 00:16:33,880 And that if the entire thing is encrypted or completely opaque, 360 00:16:33,880 --> 00:16:37,040 we're not going to be able to really gain this insight. 361 00:16:37,040 --> 00:16:39,180 And toxic assets, like I said. 362 00:16:39,180 --> 00:16:41,370 So here's a specific example of something 363 00:16:41,370 --> 00:16:44,550 we might want to learn. 364 00:16:44,550 --> 00:16:45,600 Here's a bank. 365 00:16:45,600 --> 00:16:46,740 Here's an auditor. 366 00:16:46,740 --> 00:16:48,330 And the auditor might want to-- 367 00:16:48,330 --> 00:16:50,850 let's assume the bank is using a system like zkLedger, 368 00:16:50,850 --> 00:16:53,160 a permissioned blockchain. 369 00:16:53,160 --> 00:16:54,690 An auditor might want to know how 370 00:16:54,690 --> 00:16:58,200 exposed is this bank to a drop in the euro? 371 00:16:58,200 --> 00:17:01,770 So if the euro versus the dollar changes dramatically, 372 00:17:01,770 --> 00:17:04,530 what's going to happen to this bank's balance sheet? 373 00:17:04,530 --> 00:17:07,410 So in zkLedger, the auditor can ask a question 374 00:17:07,410 --> 00:17:10,980 like what fraction of your assets are in euros? 375 00:17:10,980 --> 00:17:15,680 And the bank might respond, 3 million out of 100 million. 376 00:17:15,680 --> 00:17:17,940 So, 3 million euros, 100 million dollars. 377 00:17:17,940 --> 00:17:19,740 Something like that. 378 00:17:19,740 --> 00:17:21,960 But just simply asking this question, 379 00:17:21,960 --> 00:17:25,500 the auditor doesn't really get any assurance 380 00:17:25,500 --> 00:17:27,310 that this answer is correct. 381 00:17:27,310 --> 00:17:29,550 And so this is the nugget of the problem 382 00:17:29,550 --> 00:17:32,700 that we are trying to solve and achieve. 383 00:17:32,700 --> 00:17:34,890 So this talk presents zkLedger. 384 00:17:34,890 --> 00:17:38,610 And it's a private, auditable transaction ledger. 385 00:17:38,610 --> 00:17:42,330 The idea behind zkLedger is like other systems. 386 00:17:42,330 --> 00:17:48,360 We also hide the transacting banks and the amounts involved. 387 00:17:48,360 --> 00:17:51,360 We provide integrity with public verification. 388 00:17:51,360 --> 00:17:53,100 So despite the fact that you can't really 389 00:17:53,100 --> 00:17:55,110 see the details of the transaction, 390 00:17:55,110 --> 00:17:56,790 anyone, not just the participants, 391 00:17:56,790 --> 00:17:59,310 but anyone you want to show this to, 392 00:17:59,310 --> 00:18:02,430 can publicly verify and convince themselves 393 00:18:02,430 --> 00:18:04,680 that transactions are well-formed 394 00:18:04,680 --> 00:18:07,200 and financial invariants are maintained. 395 00:18:07,200 --> 00:18:10,800 And an auditor can interactively compute 396 00:18:10,800 --> 00:18:13,380 provably correct linear functions 397 00:18:13,380 --> 00:18:14,820 over the transactions. 398 00:18:14,820 --> 00:18:16,290 So things like trying to understand 399 00:18:16,290 --> 00:18:19,450 market concentration, or leverage, or exposure-- 400 00:18:19,450 --> 00:18:21,480 they can compute a set of queries 401 00:18:21,480 --> 00:18:26,390 over the contents of the transactions in the ledger. 402 00:18:26,390 --> 00:18:29,860 OK, so I'm going to describe to you how zkLedger works. 403 00:18:29,860 --> 00:18:32,655 I'm going to give you a brief overview of the system model. 404 00:18:32,655 --> 00:18:34,030 And then I'm going to start to go 405 00:18:34,030 --> 00:18:37,060 into some of the more interesting pieces 406 00:18:37,060 --> 00:18:38,380 inside zkLedger. 407 00:18:38,380 --> 00:18:40,750 So the commitments that we use to hide 408 00:18:40,750 --> 00:18:44,390 things, the way the ledger is constructed. 409 00:18:44,390 --> 00:18:46,270 And I'm going to tell you a little bit 410 00:18:46,270 --> 00:18:48,140 about the primitives that we use, 411 00:18:48,140 --> 00:18:49,482 which are zero-knowledge proofs. 412 00:18:49,482 --> 00:18:51,940 Not SNARKs, which I talked about earlier-- a different type 413 00:18:51,940 --> 00:18:52,940 of zero-knowledge proof. 414 00:18:52,940 --> 00:18:54,970 But I'll give you a little bit of a flavor 415 00:18:54,970 --> 00:18:57,290 of what those things look like. 416 00:18:57,290 --> 00:19:00,890 And then I'll show you the performance of zkLedger. 417 00:19:00,890 --> 00:19:04,090 So whether you buy this use case or not, 418 00:19:04,090 --> 00:19:06,850 I think that you will see these topics come 419 00:19:06,850 --> 00:19:10,293 up over and over again as you're looking at cryptocurrencies. 420 00:19:10,293 --> 00:19:12,460 People are quite interested in zero-knowledge proofs 421 00:19:12,460 --> 00:19:15,970 and how they can use them to provide privacy 422 00:19:15,970 --> 00:19:19,720 inside of cryptocurrencies. 423 00:19:19,720 --> 00:19:23,355 OK, before we jump into the system model, any questions? 424 00:19:26,540 --> 00:19:27,740 OK, let's go. 425 00:19:27,740 --> 00:19:30,650 So let's start with the system model. 426 00:19:30,650 --> 00:19:31,970 So here's the system model. 427 00:19:31,970 --> 00:19:33,170 We have a set of banks. 428 00:19:33,170 --> 00:19:37,400 These banks have generated public keys and secret keys, 429 00:19:37,400 --> 00:19:38,360 which they have. 430 00:19:38,360 --> 00:19:42,530 And these banks are working together to construct a ledger. 431 00:19:42,530 --> 00:19:44,030 And the way that this ledger works 432 00:19:44,030 --> 00:19:45,650 is that they are determining transactions 433 00:19:45,650 --> 00:19:46,442 amongst themselves. 434 00:19:46,442 --> 00:19:49,370 So they're deciding, OK, I'm going to transfer this amount 435 00:19:49,370 --> 00:19:50,210 to that bank. 436 00:19:50,210 --> 00:19:53,270 And then once they've decided on a transaction, 437 00:19:53,270 --> 00:19:55,797 they append that transaction to the ledger. 438 00:19:55,797 --> 00:19:57,380 And again, remember, this ledger could 439 00:19:57,380 --> 00:19:59,633 be maintained by a third party. 440 00:19:59,633 --> 00:20:01,550 It could be maintained by the banks themselves 441 00:20:01,550 --> 00:20:02,570 on a blockchain. 442 00:20:02,570 --> 00:20:04,670 They could be using a public bulletin board. 443 00:20:04,670 --> 00:20:06,320 They could be posting transactions to Twitter. 444 00:20:06,320 --> 00:20:06,960 It doesn't matter. 445 00:20:06,960 --> 00:20:08,960 We're not really concerned about that right now. 446 00:20:08,960 --> 00:20:13,400 The point is that there is an append-only ledger that's 447 00:20:13,400 --> 00:20:17,107 orthogonal to our techniques-- how exactly it's maintained. 448 00:20:19,910 --> 00:20:22,010 An auditor, a third party auditor, 449 00:20:22,010 --> 00:20:24,830 can obtain correct answers to questions 450 00:20:24,830 --> 00:20:26,030 based on ledger contents. 451 00:20:26,030 --> 00:20:28,550 So note that auditing is interactive. 452 00:20:28,550 --> 00:20:31,790 It's not the case that someone can just take this ledger 453 00:20:31,790 --> 00:20:33,560 and compute things over it. 454 00:20:33,560 --> 00:20:35,012 They can't do that. 455 00:20:35,012 --> 00:20:36,470 There's not enough information here 456 00:20:36,470 --> 00:20:38,090 to reveal the answers to queries. 457 00:20:38,090 --> 00:20:42,110 The auditor has to actually talk to the participants 458 00:20:42,110 --> 00:20:43,110 in the ledger. 459 00:20:43,110 --> 00:20:44,720 So you might say, well, we didn't 460 00:20:44,720 --> 00:20:48,140 trust the participants to give the auditor the right answer. 461 00:20:48,140 --> 00:20:51,158 Why would we trust them to answer the auditor at all? 462 00:20:51,158 --> 00:20:52,700 Well in the setting that we've set up 463 00:20:52,700 --> 00:20:54,700 for ourselves, if they don't answer the auditor, 464 00:20:54,700 --> 00:20:55,670 they can go to jail. 465 00:20:55,670 --> 00:20:56,240 OK? 466 00:20:56,240 --> 00:20:58,740 So at least you can tell whether the bank is answering you 467 00:20:58,740 --> 00:20:59,240 or not. 468 00:20:59,240 --> 00:21:01,782 If the bank were to lie to you, you might not be able to tell 469 00:21:01,782 --> 00:21:04,400 whether-- this allows you to be able to-- 470 00:21:04,400 --> 00:21:08,580 if you get an answer, you know that that answer is correct. 471 00:21:08,580 --> 00:21:10,410 So the auditor will query the bank 472 00:21:10,410 --> 00:21:11,970 and ask a question similar to what 473 00:21:11,970 --> 00:21:14,137 we were asking before-- what fraction of your assets 474 00:21:14,137 --> 00:21:14,880 are in euros? 475 00:21:14,880 --> 00:21:16,140 The bank can respond. 476 00:21:16,140 --> 00:21:19,050 But this time, instead of just getting an answer, 477 00:21:19,050 --> 00:21:24,030 the auditor also gets a small part of a proof from the bank 478 00:21:24,030 --> 00:21:27,810 and can confirm that that proof is correct 479 00:21:27,810 --> 00:21:30,030 based on these opaque transaction 480 00:21:30,030 --> 00:21:31,860 details in the ledger. 481 00:21:31,860 --> 00:21:38,040 So the auditor still needs to talk to the bank, 482 00:21:38,040 --> 00:21:40,830 but using the bank's response, they 483 00:21:40,830 --> 00:21:43,020 can compute a proof that shows that this answer must 484 00:21:43,020 --> 00:21:43,770 be correct. 485 00:21:43,770 --> 00:21:44,940 OK? 486 00:21:44,940 --> 00:21:46,200 So auditing is interactive. 487 00:21:46,200 --> 00:21:47,580 Like I said, it's possible a bank 488 00:21:47,580 --> 00:21:49,110 might choose not to respond. 489 00:21:49,110 --> 00:21:50,580 That could happen. 490 00:21:50,580 --> 00:21:53,970 Also I want to point out that if the auditor is constantly 491 00:21:53,970 --> 00:21:55,580 auditing this ledger-- 492 00:21:55,580 --> 00:21:57,675 is constantly asking how many euros do you have? 493 00:21:57,675 --> 00:21:58,800 How many euros do you have? 494 00:21:58,800 --> 00:22:00,090 How many euros do you have? 495 00:22:00,090 --> 00:22:02,910 Then if that number changes, it's 496 00:22:02,910 --> 00:22:05,220 reasonable to assume that that change happened 497 00:22:05,220 --> 00:22:07,230 in the last transaction appended to the ledger. 498 00:22:07,230 --> 00:22:07,800 Right? 499 00:22:07,800 --> 00:22:12,270 So if the bank continually answers 500 00:22:12,270 --> 00:22:15,480 the auditor's questions, this will leak transaction contents. 501 00:22:15,480 --> 00:22:18,480 This doesn't provide what's known as differential privacy. 502 00:22:18,480 --> 00:22:19,170 OK? 503 00:22:19,170 --> 00:22:22,950 And so the setup here is that the auditor and the bank 504 00:22:22,950 --> 00:22:25,560 should come to some agreement about the appropriate level 505 00:22:25,560 --> 00:22:29,730 of frequency of auditing such that both the auditor gets 506 00:22:29,730 --> 00:22:32,550 the data that they need, and the bank maintains the privacy 507 00:22:32,550 --> 00:22:35,300 that it needs to maintain. 508 00:22:35,300 --> 00:22:38,130 OK, so as I said before, zkLedger 509 00:22:38,130 --> 00:22:42,310 supports any linear function over transaction values. 510 00:22:42,310 --> 00:22:45,990 So we can do ratios, sums, averages, variance, 511 00:22:45,990 --> 00:22:48,600 skews outliers. 512 00:22:48,600 --> 00:22:53,880 By outliers, I mean give me all the transactions that have 513 00:22:53,880 --> 00:22:55,963 amounts outside of this range. 514 00:22:55,963 --> 00:22:58,380 So you want all high-value transactions, you can provably, 515 00:22:58,380 --> 00:23:00,560 correctly give that. 516 00:23:00,560 --> 00:23:03,720 Approximation-- so orders of magnitude of my trades, 517 00:23:03,720 --> 00:23:06,090 without revealing the precise number. 518 00:23:06,090 --> 00:23:09,900 Changes over time, and also well-known financial risk 519 00:23:09,900 --> 00:23:12,870 measurements like the Herfindahl-Hirschman Index. 520 00:23:12,870 --> 00:23:14,230 So in this talk-- 521 00:23:14,230 --> 00:23:14,850 oh, sorry. 522 00:23:14,850 --> 00:23:18,390 Yes, there are small amounts of well-defined leakage 523 00:23:18,390 --> 00:23:21,660 for some of these measurements. 524 00:23:21,660 --> 00:23:24,750 So for example, in order to compute the average, 525 00:23:24,750 --> 00:23:28,330 we actually compute the sum and the number of transactions. 526 00:23:28,330 --> 00:23:30,600 So we leak a little bit more information 527 00:23:30,600 --> 00:23:35,070 than just the average, but it's very well-defined. 528 00:23:35,070 --> 00:23:36,720 And in this talk, I'm only really going 529 00:23:36,720 --> 00:23:39,150 to talk about sums. 530 00:23:39,150 --> 00:23:44,040 But our paper, which I'll put a point or two on the website, 531 00:23:44,040 --> 00:23:46,430 explains how to do more complex things. 532 00:23:46,430 --> 00:23:51,960 And everything's built on the sums primitive. 533 00:23:51,960 --> 00:23:54,540 So let's talk about the security goals. 534 00:23:54,540 --> 00:23:57,910 So what are we trying to achieve with the system? 535 00:23:57,910 --> 00:24:00,810 So first of all, we're trying to achieve privacy. 536 00:24:00,810 --> 00:24:03,270 We want to make sure that the auditor and non-involved 537 00:24:03,270 --> 00:24:06,990 parties cannot see transaction participants or amounts. 538 00:24:06,990 --> 00:24:10,470 So I don't know if I made this clear before, 539 00:24:10,470 --> 00:24:12,960 but it's not just the case that this third-party auditor 540 00:24:12,960 --> 00:24:18,270 can't see who's in transactions or what they're transacting. 541 00:24:18,270 --> 00:24:20,280 Anyone who's not actually involved 542 00:24:20,280 --> 00:24:22,290 in the transaction, receiving or sending assets, 543 00:24:22,290 --> 00:24:26,310 also can't see inside of a transaction. 544 00:24:26,310 --> 00:24:27,102 Completeness. 545 00:24:27,102 --> 00:24:28,560 So what do we mean by completeness? 546 00:24:28,560 --> 00:24:33,770 What we mean by that is that banks can't lie to the auditor. 547 00:24:33,770 --> 00:24:36,297 They can't say that they have 5 million euros when actually 548 00:24:36,297 --> 00:24:37,380 they have 3 million euros. 549 00:24:37,380 --> 00:24:42,460 But also, the bank can't selectively leave out things. 550 00:24:42,460 --> 00:24:42,960 OK? 551 00:24:42,960 --> 00:24:44,970 So you could imagine some ways of constructing 552 00:24:44,970 --> 00:24:47,700 this in which, if a bank was really clever, 553 00:24:47,700 --> 00:24:51,630 they could just not include some of the transactions 554 00:24:51,630 --> 00:24:53,850 that they had received, and thus change 555 00:24:53,850 --> 00:24:55,110 their answers to the auditor. 556 00:24:55,110 --> 00:24:57,900 But one of our security goals that we achieve 557 00:24:57,900 --> 00:25:01,320 is that it's impossible for a bank to omit transactions 558 00:25:01,320 --> 00:25:03,930 when responding to the auditor. 559 00:25:03,930 --> 00:25:06,360 We also are looking to achieve integrity, 560 00:25:06,360 --> 00:25:09,060 so banks can't violate financial invariants. 561 00:25:09,060 --> 00:25:12,300 We assume that banks are malicious. 562 00:25:12,300 --> 00:25:15,060 But honest banks should always be 563 00:25:15,060 --> 00:25:17,870 able to convince the auditor of a correct answer. 564 00:25:17,870 --> 00:25:19,620 So we don't want to have a situation where 565 00:25:19,620 --> 00:25:22,230 a malicious bank screws up the ledger such 566 00:25:22,230 --> 00:25:25,290 that an honest bank can't respond to the auditor 567 00:25:25,290 --> 00:25:27,090 because the ledger doesn't make sense. 568 00:25:27,090 --> 00:25:30,050 So we also want to maintain that. 569 00:25:30,050 --> 00:25:32,100 And then progress. 570 00:25:32,100 --> 00:25:35,630 We also want to make sure that a malicious bank can't block 571 00:25:35,630 --> 00:25:38,570 other banks from transacting-- that they can't hold up 572 00:25:38,570 --> 00:25:39,740 the entire ledger. 573 00:25:39,740 --> 00:25:41,990 And I think as I describe the design, 574 00:25:41,990 --> 00:25:44,615 it'll become clearer why these things were issues 575 00:25:44,615 --> 00:25:45,740 that we were worried about. 576 00:25:45,740 --> 00:25:48,500 And it's part of how we designed the system 577 00:25:48,500 --> 00:25:51,470 to address these problems. 578 00:25:51,470 --> 00:25:53,080 So, the threat model. 579 00:25:53,080 --> 00:25:56,350 And the threat model describes what kind 580 00:25:56,350 --> 00:25:58,750 of attacks that we are trying to protect against 581 00:25:58,750 --> 00:26:02,230 and what kind of attacks we don't protect against. 582 00:26:02,230 --> 00:26:06,040 So banks might attempt to steal or hide 583 00:26:06,040 --> 00:26:10,570 assets, manipulate balances, or lie to the auditor. 584 00:26:10,570 --> 00:26:12,700 Banks can arbitrarily collude, so they 585 00:26:12,700 --> 00:26:15,730 can try to work together to do these things. 586 00:26:15,730 --> 00:26:17,590 And banks or the auditor might try 587 00:26:17,590 --> 00:26:19,060 to learn transaction contents. 588 00:26:19,060 --> 00:26:21,220 So it's not that they're passive. 589 00:26:21,220 --> 00:26:23,710 They might actually be trying to actively learn 590 00:26:23,710 --> 00:26:25,840 what's happening in the ledger. 591 00:26:25,840 --> 00:26:27,970 What's out of scope for this work 592 00:26:27,970 --> 00:26:31,390 is a ledger that omits transactions or is unavailable. 593 00:26:31,390 --> 00:26:34,990 As I said, we're agnostic to the ledger implementation 594 00:26:34,990 --> 00:26:38,920 as long as it's available so it accepts transactions. 595 00:26:38,920 --> 00:26:41,410 If the ledger doesn't accept transactions, 596 00:26:41,410 --> 00:26:44,240 we can't provide our goals. 597 00:26:44,240 --> 00:26:47,530 We also don't protect against an adversary who might 598 00:26:47,530 --> 00:26:49,220 be watching network traffic. 599 00:26:49,220 --> 00:26:53,500 So if there's an adversary who's snooping on the network 600 00:26:53,500 --> 00:26:55,720 and sees that two banks are communicating a lot, 601 00:26:55,720 --> 00:26:58,178 it's reasonable to assume that those two banks are involved 602 00:26:58,178 --> 00:26:59,320 in all the transactions. 603 00:26:59,320 --> 00:27:02,780 There are other techniques to deal with these problems. 604 00:27:02,780 --> 00:27:04,270 And then also what's out of scope 605 00:27:04,270 --> 00:27:06,275 is banks leaking their own transactions. 606 00:27:06,275 --> 00:27:07,900 If a bank leaks their own transactions, 607 00:27:07,900 --> 00:27:09,070 we throw up our hands. 608 00:27:09,070 --> 00:27:10,570 Sorry, we tried to give you privacy. 609 00:27:15,570 --> 00:27:17,663 So that's the system model for zkLedger. 610 00:27:17,663 --> 00:27:19,830 That's the threat model, those are our goals, that's 611 00:27:19,830 --> 00:27:21,660 what we're trying to achieve. 612 00:27:21,660 --> 00:27:25,260 Now, let's get into the design a little bit. 613 00:27:25,260 --> 00:27:28,930 So we're going to build up the design based on this example. 614 00:27:28,930 --> 00:27:33,510 So here is an example of a public transaction ledger. 615 00:27:33,510 --> 00:27:36,810 And we're going to slowly start to mask things in this ledger 616 00:27:36,810 --> 00:27:39,840 until we end up with zkLedger's design. 617 00:27:39,840 --> 00:27:42,900 So we have four transactions here. 618 00:27:42,900 --> 00:27:45,750 I'm only using one asset, euros. 619 00:27:45,750 --> 00:27:48,447 You'll notice that the first transaction addresses 620 00:27:48,447 --> 00:27:50,280 the question that you asked, which is, well, 621 00:27:50,280 --> 00:27:51,450 where do funds come from? 622 00:27:51,450 --> 00:27:54,180 And here we have a special depositor, 623 00:27:54,180 --> 00:27:57,240 who is injecting assets into the system. 624 00:27:57,240 --> 00:28:00,040 This depositor might be the central bank, for example. 625 00:28:00,040 --> 00:28:02,040 A lot of systems are actually designed this way. 626 00:28:02,040 --> 00:28:09,690 So Stellar, I think Chains, Blockchain, Ripple-- 627 00:28:09,690 --> 00:28:12,330 these systems are all designed with the idea 628 00:28:12,330 --> 00:28:15,240 of a special depositor who's allowed 629 00:28:15,240 --> 00:28:19,210 to create their own asset and insert it into the system. 630 00:28:19,210 --> 00:28:23,460 So here, maybe the depositor is the European Central Bank. 631 00:28:23,460 --> 00:28:26,010 Maybe it's some other bank, who provably has 632 00:28:26,010 --> 00:28:30,070 a lot of euros in their account and puts them onto the ledger. 633 00:28:30,070 --> 00:28:32,640 So there's a depositor who's granting 30 million euros 634 00:28:32,640 --> 00:28:34,230 to Goldman Sachs. 635 00:28:34,230 --> 00:28:36,690 And then there are three transactions. 636 00:28:36,690 --> 00:28:38,912 And I think it's important to get a sense of what 637 00:28:38,912 --> 00:28:39,870 these transactions are. 638 00:28:39,870 --> 00:28:43,770 So Goldman Sachs is transferring 10 million to JP Morgan. 639 00:28:43,770 --> 00:28:48,680 And then JP Morgan, in two different transactions, 640 00:28:48,680 --> 00:28:50,610 is transferring money to Barclays. 641 00:28:50,610 --> 00:28:51,550 OK? 642 00:28:51,550 --> 00:28:56,150 So let's move on from here. 643 00:28:56,150 --> 00:28:59,350 So like I said, the depositor injects assets to ledger, 644 00:28:59,350 --> 00:29:01,780 and that's the way of entering transactions. 645 00:29:01,780 --> 00:29:04,750 That's the depositor, right there. 646 00:29:04,750 --> 00:29:08,200 Now our goals are to achieve auditing and privacy. 647 00:29:08,200 --> 00:29:09,470 What do we mean by that? 648 00:29:09,470 --> 00:29:13,570 Well, we shouldn't-- someone looking at the ledger 649 00:29:13,570 --> 00:29:16,750 shouldn't be able to tell these amounts except 650 00:29:16,750 --> 00:29:19,360 for the depositor transaction, which is always public. 651 00:29:19,360 --> 00:29:22,070 In zkLedger, the depositor transactions are public. 652 00:29:22,070 --> 00:29:25,110 But they shouldn't be able to tell after that 653 00:29:25,110 --> 00:29:27,065 that Goldman Sachs gave money to JP Morgan, 654 00:29:27,065 --> 00:29:28,690 and that JP Morgan gave it to Barclays, 655 00:29:28,690 --> 00:29:29,773 and what the amounts were. 656 00:29:29,773 --> 00:29:32,480 OK? 657 00:29:32,480 --> 00:29:37,690 So in this example, we're going to try to provably audit 658 00:29:37,690 --> 00:29:42,382 Barclays to figure out how many euros Barclays is holding. 659 00:29:42,382 --> 00:29:44,590 And again, we want to hide the participants, amounts, 660 00:29:44,590 --> 00:29:46,000 and the transaction graph. 661 00:29:46,000 --> 00:29:49,930 So what do I mean when I say transaction graph? 662 00:29:49,930 --> 00:29:52,210 I think you guys learned a little bit about a system 663 00:29:52,210 --> 00:29:55,180 called confidential transactions a few weeks ago. 664 00:29:55,180 --> 00:29:59,140 Confidential transactions does not hide the transaction graph. 665 00:29:59,140 --> 00:30:02,290 It hides the amounts, but you can 666 00:30:02,290 --> 00:30:05,350 tell the source of the funds. 667 00:30:05,350 --> 00:30:08,970 So here, the money that Barclays got-- 668 00:30:08,970 --> 00:30:13,690 so if we were trying to attain privacy in the system, the fact 669 00:30:13,690 --> 00:30:16,578 that Goldman Sachs got euros, and Goldman Sachs is 670 00:30:16,578 --> 00:30:18,370 the only company that got euros, is public, 671 00:30:18,370 --> 00:30:20,720 because depositor transactions are public. 672 00:30:20,720 --> 00:30:24,280 But we shouldn't be able to tell that the euros 673 00:30:24,280 --> 00:30:26,770 that Barclays got-- obviously they must have been 674 00:30:26,770 --> 00:30:28,060 sourced through Goldman Sachs. 675 00:30:28,060 --> 00:30:32,020 We shouldn't be able to tell they went through anyone, 676 00:30:32,020 --> 00:30:33,820 or how many people they went through, 677 00:30:33,820 --> 00:30:35,710 or that it was JP Morgan. 678 00:30:35,710 --> 00:30:38,620 So if we leaked the transaction graph, 679 00:30:38,620 --> 00:30:40,630 you might be able to tell that there 680 00:30:40,630 --> 00:30:43,360 was an entity that the money went through 681 00:30:43,360 --> 00:30:44,662 before it got to Barclays. 682 00:30:44,662 --> 00:30:46,870 So when we say we want to hide the transaction graph, 683 00:30:46,870 --> 00:30:47,703 that's what we mean. 684 00:30:47,703 --> 00:30:50,740 We want to be able to hide the flow of funds, how 685 00:30:50,740 --> 00:30:52,330 they move through the system. 686 00:30:56,660 --> 00:31:01,070 We hide the amounts by using a cryptographic primitive called 687 00:31:01,070 --> 00:31:03,650 Pedersen commitments. 688 00:31:03,650 --> 00:31:06,050 So Pedersen commitments, as you learned, 689 00:31:06,050 --> 00:31:10,080 are binding and hiding commitments to a value. 690 00:31:10,080 --> 00:31:11,800 And the way that they work-- 691 00:31:11,800 --> 00:31:14,780 and I'm terribly sorry, but I use slightly different notation 692 00:31:14,780 --> 00:31:15,800 than Tadge. 693 00:31:15,800 --> 00:31:20,870 So Tadge uses additive notation-- 694 00:31:20,870 --> 00:31:23,700 multiplicative notation, and I use exponential notation. 695 00:31:23,700 --> 00:31:25,370 These mean exactly the same thing. 696 00:31:25,370 --> 00:31:28,970 I will very quickly write down what they are. 697 00:31:28,970 --> 00:31:35,820 So in Tadge's notation, G and H are generators in some group. 698 00:31:35,820 --> 00:31:39,290 And if you have some value and some randomness, 699 00:31:39,290 --> 00:31:47,110 then you would write a Pedersen commitment as that, OK? 700 00:31:47,110 --> 00:31:50,930 Now, whether it's r times G, or v times H isn't important. 701 00:31:50,930 --> 00:31:55,420 The point is these are two generators of a group, 702 00:31:55,420 --> 00:31:57,430 in this case, an elliptical curve group. 703 00:31:57,430 --> 00:32:00,140 And in Bitcoin, secp256k1. 704 00:32:00,140 --> 00:32:02,530 It doesn't really matter what those generators are. 705 00:32:02,530 --> 00:32:04,750 You just pick any two. 706 00:32:04,750 --> 00:32:07,390 You could call this G1 and G2, if you wanted to. 707 00:32:07,390 --> 00:32:10,270 And so this is the way that Tadge would write it. 708 00:32:10,270 --> 00:32:12,005 The way that I write it-- 709 00:32:12,005 --> 00:32:13,630 and I'm sorry about this, but it's good 710 00:32:13,630 --> 00:32:15,610 that you guys get exposed to both ways, 711 00:32:15,610 --> 00:32:18,160 because you'll find both ways in the literature-- 712 00:32:18,160 --> 00:32:19,990 is in exponential notation. 713 00:32:19,990 --> 00:32:25,340 So I would write g to the v, h to the r. 714 00:32:25,340 --> 00:32:30,510 And they're multiplied together instead of added together. 715 00:32:30,510 --> 00:32:31,610 OK? 716 00:32:31,610 --> 00:32:36,460 So this is just purely a notational thing. 717 00:32:36,460 --> 00:32:39,980 It's just, instead of the multiply operator here, 718 00:32:39,980 --> 00:32:41,270 we're doing exponentiation. 719 00:32:41,270 --> 00:32:42,687 Instead of the plus operator here, 720 00:32:42,687 --> 00:32:43,846 we're doing multiplication. 721 00:32:47,040 --> 00:32:49,520 So, Pedersen commitment. 722 00:32:49,520 --> 00:32:52,100 The way that you commit to a value v 723 00:32:52,100 --> 00:32:55,190 is everyone has chosen these generators. 724 00:32:55,190 --> 00:32:56,885 The generator choice is system-wide. 725 00:32:56,885 --> 00:32:58,760 This isn't something you pick at the time you 726 00:32:58,760 --> 00:32:59,552 make a transaction. 727 00:32:59,552 --> 00:33:01,160 The generator choice is system-wide. 728 00:33:01,160 --> 00:33:06,200 However, the r, the randomness, you do choose fresh each time. 729 00:33:06,200 --> 00:33:07,880 You pick any randomness each time. 730 00:33:07,880 --> 00:33:10,130 And the way that you commit to a value 731 00:33:10,130 --> 00:33:14,490 is by producing this value right here, 732 00:33:14,490 --> 00:33:17,300 which is the generator raised to the value 733 00:33:17,300 --> 00:33:20,900 times the second generator raised to the randomness. 734 00:33:20,900 --> 00:33:26,570 And what this serves to do is it's binding. 735 00:33:26,570 --> 00:33:29,930 It's very difficult to come up with, later, 736 00:33:29,930 --> 00:33:32,540 a different and a different r that ends up 737 00:33:32,540 --> 00:33:34,790 equaling the same commitment. 738 00:33:34,790 --> 00:33:36,620 And part of that is based on an assumption 739 00:33:36,620 --> 00:33:38,780 called the discrete logarithm-- the hardness 740 00:33:38,780 --> 00:33:42,230 of the discrete logarithm problem. 741 00:33:42,230 --> 00:33:44,780 And also, importantly, these things 742 00:33:44,780 --> 00:33:47,610 can be homomorphically combined. 743 00:33:47,610 --> 00:33:51,600 So if we have these commitments to these different values, 744 00:33:51,600 --> 00:33:53,700 and we multiply them together, well, 745 00:33:53,700 --> 00:33:58,010 when you multiply things that are raised to an exponent, 746 00:33:58,010 --> 00:34:01,100 you end up adding the exponent, right? 747 00:34:01,100 --> 00:34:03,990 So by multiplying these things together, 748 00:34:03,990 --> 00:34:07,430 we end up with a valid commitment 749 00:34:07,430 --> 00:34:11,719 to the sum of the values in the individual commitments 750 00:34:11,719 --> 00:34:13,670 that we multiplied together. 751 00:34:13,670 --> 00:34:17,750 So we can homomorphically combine the commitments. 752 00:34:17,750 --> 00:34:21,780 It ends up summing in the exponent. 753 00:34:21,780 --> 00:34:25,010 And we end up with a valid commitment 754 00:34:25,010 --> 00:34:26,225 to the sum of the values. 755 00:34:28,770 --> 00:34:31,489 Another nice property of Pedersen commitments 756 00:34:31,489 --> 00:34:36,290 is that they are very fast to create, combine, and verify. 757 00:34:36,290 --> 00:34:38,420 And perhaps surprisingly, we can actually 758 00:34:38,420 --> 00:34:40,310 achieve all of the auditing functions 759 00:34:40,310 --> 00:34:44,690 that I showed you earlier just using Pedersen commitments. 760 00:34:44,690 --> 00:34:47,590 So before we move on, questions on Pedersen commitments? 761 00:34:47,590 --> 00:34:50,090 I know that you guys learned about this in a previous class, 762 00:34:50,090 --> 00:34:52,805 but they're pretty important. 763 00:34:55,940 --> 00:34:58,070 They're used in confidential transactions 764 00:34:58,070 --> 00:35:00,800 as well to prove that the sum of the outputs 765 00:35:00,800 --> 00:35:04,010 is less than or equal to the sum of the inputs, 766 00:35:04,010 --> 00:35:05,890 if you guys recall that. 767 00:35:05,890 --> 00:35:08,423 So any questions? 768 00:35:08,423 --> 00:35:10,340 AUDIENCE: When are you making this commitment? 769 00:35:10,340 --> 00:35:12,120 NEHA NARULA: Ah, great question. 770 00:35:12,120 --> 00:35:14,640 You're making this commitment at the time 771 00:35:14,640 --> 00:35:16,590 that the transaction is created. 772 00:35:16,590 --> 00:35:19,770 And I'll get into the details of who creates the transaction, 773 00:35:19,770 --> 00:35:21,940 and what do they choose, and how does that happen, 774 00:35:21,940 --> 00:35:23,520 and how do we make sure they don't screw it up. 775 00:35:23,520 --> 00:35:26,030 AUDIENCE: So when you add a measurement to this ledger, 776 00:35:26,030 --> 00:35:29,270 it might add a number of commitments that people make... 777 00:35:29,270 --> 00:35:30,840 NEHA NARULA: Well, so measurements 778 00:35:30,840 --> 00:35:32,500 happen on top of the ledger. 779 00:35:32,500 --> 00:35:35,730 So we can actually do all of our measurements 780 00:35:35,730 --> 00:35:37,230 basically just on those commitments. 781 00:35:37,230 --> 00:35:40,510 We don't have to add anything to ledger. 782 00:35:40,510 --> 00:35:41,310 OK. 783 00:35:41,310 --> 00:35:44,130 So, yes, like I said, we can achieve all the auditing 784 00:35:44,130 --> 00:35:45,630 functions with Pedersen commitments. 785 00:35:45,630 --> 00:35:47,770 And I'll go into a little bit of detail. 786 00:35:47,770 --> 00:35:48,270 OK, great. 787 00:35:48,270 --> 00:35:51,420 So we can use Pearson commitments to hide the value. 788 00:35:51,420 --> 00:35:55,260 So again, by using these commitments, you can't-- 789 00:35:55,260 --> 00:35:58,890 looking at this right here, if you don't know r, 790 00:35:58,890 --> 00:36:00,300 you can't guess-- 791 00:36:00,300 --> 00:36:02,250 if you don't know v and r, you can't-- 792 00:36:02,250 --> 00:36:04,350 if you don't know r, you can't guess what v is. 793 00:36:04,350 --> 00:36:05,750 It could be anything. 794 00:36:05,750 --> 00:36:10,650 So that's what we mean when we say that these commitments are 795 00:36:10,650 --> 00:36:13,530 perfectly hiding. 796 00:36:13,530 --> 00:36:15,300 So we also want to hide the participants 797 00:36:15,300 --> 00:36:16,560 in the transaction, obviously. 798 00:36:16,560 --> 00:36:18,643 And we're going to do that using other techniques. 799 00:36:18,643 --> 00:36:20,670 Just hold that in your head for a moment. 800 00:36:20,670 --> 00:36:22,690 We're going to jump to that. 801 00:36:22,690 --> 00:36:25,050 But first, quickly, let's take a look 802 00:36:25,050 --> 00:36:28,740 at how auditing might work given that we're using these Pedersen 803 00:36:28,740 --> 00:36:30,120 commitments, OK? 804 00:36:30,120 --> 00:36:35,340 So assume that we have hidden who the participants are 805 00:36:35,340 --> 00:36:37,870 in this ledger through a technique 806 00:36:37,870 --> 00:36:40,180 that I'm not telling you about, yet. 807 00:36:40,180 --> 00:36:44,407 We're hiding the values in the transactions that are not 808 00:36:44,407 --> 00:36:46,240 inject-- not these special transactions that 809 00:36:46,240 --> 00:36:49,210 are injecting assets or removing assets, but just the transfers. 810 00:36:49,210 --> 00:36:52,330 We're hiding the values using Pedersen commitments, OK? 811 00:36:52,330 --> 00:36:54,610 So let's look at how auditing might work. 812 00:36:54,610 --> 00:36:57,100 So an auditor will ask the bank-- 813 00:36:57,100 --> 00:36:58,390 in this case, it's Barclays. 814 00:36:58,390 --> 00:37:02,140 So remember, Barclays received euros 815 00:37:02,140 --> 00:37:04,180 in two different transactions, and should 816 00:37:04,180 --> 00:37:06,640 tell the auditor 3 million. 817 00:37:06,640 --> 00:37:09,160 The auditor asks Barclays, how many euros do you hold? 818 00:37:09,160 --> 00:37:13,810 Barclays can convince the auditor that 3 million 819 00:37:13,810 --> 00:37:17,110 is the right answer by doing the following. 820 00:37:17,110 --> 00:37:18,550 OK? 821 00:37:18,550 --> 00:37:22,420 Barclays can say, hey, auditor, it's 3 million. 822 00:37:22,420 --> 00:37:23,200 OK. 823 00:37:23,200 --> 00:37:25,600 And what I'm going to do is I'm going 824 00:37:25,600 --> 00:37:31,690 to actually open up the combined commitments 825 00:37:31,690 --> 00:37:33,070 for my transactions. 826 00:37:33,070 --> 00:37:35,350 So I don't actually have this on a slide here, 827 00:37:35,350 --> 00:37:38,270 but I will write out what this means. 828 00:37:38,270 --> 00:37:38,770 OK? 829 00:37:47,030 --> 00:37:50,990 So we have two transactions here and two commitments. 830 00:37:50,990 --> 00:37:54,680 And one of them is g to the 1 million, 831 00:37:54,680 --> 00:37:57,140 h to-- the let's just r1. 832 00:37:57,140 --> 00:38:04,820 And then the other is g to the 2 million, h to the r2. 833 00:38:04,820 --> 00:38:05,450 OK? 834 00:38:05,450 --> 00:38:07,760 These are the commitments in the ledger. 835 00:38:07,760 --> 00:38:10,310 Barclays wants to convince the auditor 836 00:38:10,310 --> 00:38:12,260 that it has 3 million euros. 837 00:38:12,260 --> 00:38:15,560 It does so by-- when you multiply these two things 838 00:38:15,560 --> 00:38:19,640 together, and the auditor can't see what these two things are, 839 00:38:19,640 --> 00:38:20,720 but this is-- 840 00:38:24,790 --> 00:38:27,970 or actually, I think it's comm 2-- 841 00:38:27,970 --> 00:38:28,620 3. 842 00:38:28,620 --> 00:38:33,290 OK, comm 3 times comm 4. 843 00:38:33,290 --> 00:38:36,000 Then when you multiply these two things together, 844 00:38:36,000 --> 00:38:42,890 you get g to the 1 million plus 2 million h to the r1 plus r2, 845 00:38:42,890 --> 00:38:45,180 OK? 846 00:38:45,180 --> 00:38:47,210 This is 3 million. 847 00:38:47,210 --> 00:38:57,410 If Barclays gives the auditor 3 million and r1 plus r2, 848 00:38:57,410 --> 00:39:02,150 the sum, than the auditor can confirm 849 00:39:02,150 --> 00:39:07,100 that if they raise g to this and h to this, that it's 850 00:39:07,100 --> 00:39:09,710 equal to the multiplication of the two 851 00:39:09,710 --> 00:39:10,820 commitments on the ledger. 852 00:39:15,420 --> 00:39:18,420 And the auditor can-- 853 00:39:18,420 --> 00:39:20,980 given that these two things are equal, 854 00:39:20,980 --> 00:39:25,050 then the auditor knows that the bank in fact 855 00:39:25,050 --> 00:39:29,520 did commit to two commitments that sum to $3 million. 856 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, 857 00:39:35,850 --> 00:39:37,500 999-- 858 00:39:37,500 --> 00:39:41,400 it doesn't know what those individual values were. 859 00:39:41,400 --> 00:39:43,920 It just knows that the sum is correct. 860 00:39:47,860 --> 00:39:50,810 So, questions about opening commitments? 861 00:39:50,810 --> 00:39:51,375 Yes? 862 00:39:51,375 --> 00:39:54,200 AUDIENCE: The sub-3, sub-4-- those are the IDs? 863 00:39:54,200 --> 00:39:56,110 NEHA NARULA: Yeah, those are 3 and 4. 864 00:39:56,110 --> 00:39:57,610 Sorry, I'm using different numbers. 865 00:39:57,610 --> 00:39:58,450 They're r1 and r2. 866 00:39:58,450 --> 00:40:01,270 But the comm 3 and comm 4 are-- 867 00:40:01,270 --> 00:40:05,080 this is literally a elliptic curve point. 868 00:40:05,080 --> 00:40:09,960 So the point is posted to the ledger. 869 00:40:09,960 --> 00:40:10,460 Yes? 870 00:40:10,460 --> 00:40:13,985 AUDIENCE: Wouldn't 4 million and minus 1 million also do that? 871 00:40:13,985 --> 00:40:15,110 NEHA NARULA: It would, yes. 872 00:40:15,110 --> 00:40:17,630 And we'll talk about how we address that. 873 00:40:17,630 --> 00:40:19,320 AUDIENCE: So just to confirm, the bank 874 00:40:19,320 --> 00:40:21,880 provides both the 3 million number and-- 875 00:40:21,880 --> 00:40:23,430 NEHA NARULA: And r1 plus r2. 876 00:40:23,430 --> 00:40:24,090 Yes. 877 00:40:24,090 --> 00:40:26,370 And those two pieces of information 878 00:40:26,370 --> 00:40:28,620 are enough to convince the auditor that 3 million 879 00:40:28,620 --> 00:40:31,250 does in fact correspond to the commitments on the ledger. 880 00:40:31,250 --> 00:40:31,750 Yes? 881 00:40:31,750 --> 00:40:34,530 AUDIENCE: [INAUDIBLE] so you will always 882 00:40:34,530 --> 00:40:38,268 get the sum and the number of transactions? 883 00:40:38,268 --> 00:40:39,060 NEHA NARULA: Sorry? 884 00:40:39,060 --> 00:40:40,200 AUDIENCE: You will get the number of transactions? 885 00:40:40,200 --> 00:40:41,158 NEHA NARULA: Who's you? 886 00:40:41,158 --> 00:40:43,790 AUDIENCE: Oh, [INAUDIBLE] as in the auditor. 887 00:40:43,790 --> 00:40:45,460 NEHA NARULA: The auditor will get-- 888 00:40:45,460 --> 00:40:48,110 AUDIENCE: They will know the number of transactions? 889 00:40:48,110 --> 00:40:50,990 NEHA NARULA: In the straw man example that I've done, 890 00:40:50,990 --> 00:40:52,585 it does look that way, yes. 891 00:40:52,585 --> 00:40:54,710 I'm going to build up to how the auditor won't know 892 00:40:54,710 --> 00:40:56,330 the number of transactions. 893 00:40:56,330 --> 00:40:59,430 Did you have a question? 894 00:40:59,430 --> 00:41:01,610 AUDIENCE: So as a user, you are recording 895 00:41:01,610 --> 00:41:02,610 all of your randomness? 896 00:41:02,610 --> 00:41:04,310 You're responsible for tracking all of your randomness? 897 00:41:04,310 --> 00:41:06,852 NEHA NARULA: You're responsible for tracking your randomness. 898 00:41:06,852 --> 00:41:08,720 And you're responsible for tracking 899 00:41:08,720 --> 00:41:10,487 your own individual details. 900 00:41:10,487 --> 00:41:12,320 You have to keep that in your own databases. 901 00:41:12,320 --> 00:41:13,462 Yes? 902 00:41:13,462 --> 00:41:16,910 AUDIENCE: If somebody found your randomness-- 903 00:41:16,910 --> 00:41:18,980 NEHA NARULA: If someone found your randomnesses, 904 00:41:18,980 --> 00:41:21,110 then they could guess-- 905 00:41:21,110 --> 00:41:24,030 they could backwards-compute the values of your transactions. 906 00:41:24,030 --> 00:41:24,530 Yes. 907 00:41:27,150 --> 00:41:27,650 OK. 908 00:41:27,650 --> 00:41:29,530 AUDIENCE: How do you define the timing? 909 00:41:29,530 --> 00:41:30,730 NEHA NARULA: The time-- 910 00:41:30,730 --> 00:41:31,980 getting to that. 911 00:41:31,980 --> 00:41:34,360 So we'll get to that. 912 00:41:34,360 --> 00:41:37,630 So just in figures, showing what we did there. 913 00:41:37,630 --> 00:41:40,060 The auditor can look at those two commitments, 914 00:41:40,060 --> 00:41:42,070 compute the product for themselves, 915 00:41:42,070 --> 00:41:45,910 and confirm that this 3 million lines up with what they see. 916 00:41:45,910 --> 00:41:48,670 However, this has the problem that it 917 00:41:48,670 --> 00:41:51,220 reveals the transactions in which Barclays 918 00:41:51,220 --> 00:41:53,020 was involved, right? 919 00:41:53,020 --> 00:41:55,300 Barclays is saying, hey, multiply these two things 920 00:41:55,300 --> 00:41:56,560 together, right? 921 00:41:56,560 --> 00:41:59,930 And not only that, Barclays could lie. 922 00:41:59,930 --> 00:42:00,430 OK? 923 00:42:00,430 --> 00:42:03,670 Barclays could say, oh, actually, 924 00:42:03,670 --> 00:42:05,700 I only have 1 million euros. 925 00:42:05,700 --> 00:42:07,600 Here's the transaction that proves 926 00:42:07,600 --> 00:42:09,040 that I have 1 million euros. 927 00:42:09,040 --> 00:42:10,870 I will just give you our one. 928 00:42:10,870 --> 00:42:12,702 I will just point to this transaction. 929 00:42:12,702 --> 00:42:14,410 Don't worry about the other transactions. 930 00:42:14,410 --> 00:42:16,010 I'm not involved in them. 931 00:42:16,010 --> 00:42:19,510 The bank, Barclays, could leave out 932 00:42:19,510 --> 00:42:24,040 relevant important transactions in this straw man design. 933 00:42:24,040 --> 00:42:26,660 OK? 934 00:42:26,660 --> 00:42:29,740 And importantly, this would match up, right? 935 00:42:29,740 --> 00:42:33,430 The auditor would say, OK, you've given me-- 936 00:42:33,430 --> 00:42:34,900 Barclays could just give-- 937 00:42:38,572 --> 00:42:40,030 could leave this part out entirely. 938 00:42:40,030 --> 00:42:45,490 Could just give 1 million and r1, 939 00:42:45,490 --> 00:42:47,950 and the auditor would say, why, yes, 940 00:42:47,950 --> 00:42:49,970 that does match up to commitment three. 941 00:42:49,970 --> 00:42:50,470 Great. 942 00:42:50,470 --> 00:42:51,100 Good work. 943 00:42:51,100 --> 00:42:52,420 And they wouldn't even know that there 944 00:42:52,420 --> 00:42:54,170 was another commitment out there that they 945 00:42:54,170 --> 00:42:56,500 should be concerned about. 946 00:42:56,500 --> 00:42:59,700 So how do we address this problem? 947 00:43:03,300 --> 00:43:05,340 And this, I think, was the key insight 948 00:43:05,340 --> 00:43:08,510 in the design of our system. 949 00:43:08,510 --> 00:43:12,290 In zkLedger, a transaction actually 950 00:43:12,290 --> 00:43:16,970 has a commitment for every participant in the system. 951 00:43:16,970 --> 00:43:20,210 So let's talk about that for a second. 952 00:43:20,210 --> 00:43:24,070 So depositor transactions still basically look the way 953 00:43:24,070 --> 00:43:26,050 that they did before they're public. 954 00:43:26,050 --> 00:43:30,110 But transfer transactions now look quite different. 955 00:43:30,110 --> 00:43:35,140 We don't actually have the names of the participant 956 00:43:35,140 --> 00:43:36,460 in the transaction. 957 00:43:36,460 --> 00:43:40,840 The names are implied by the values of the commitments 958 00:43:40,840 --> 00:43:43,310 in that participants column. 959 00:43:43,310 --> 00:43:45,850 So now we're looking at a transaction 960 00:43:45,850 --> 00:43:48,910 as a row with multiple columns. 961 00:43:48,910 --> 00:43:53,860 And there's a column per participant in the system. 962 00:43:53,860 --> 00:43:57,790 If a bank is not involved in the transaction at all, 963 00:43:57,790 --> 00:44:00,640 then their commitment is to the value 0. 964 00:44:00,640 --> 00:44:03,400 If the bank is involved in a transaction, 965 00:44:03,400 --> 00:44:07,300 and it's doing the spending, then its value-- 966 00:44:07,300 --> 00:44:08,590 sorry, depositor transactions. 967 00:44:08,590 --> 00:44:09,580 Yes. 968 00:44:09,580 --> 00:44:12,430 If a bank is involved in the transaction, 969 00:44:12,430 --> 00:44:15,940 it's doing the spending, it commits to a negative value. 970 00:44:15,940 --> 00:44:18,920 And if it's doing the receiving, it commits-- 971 00:44:18,920 --> 00:44:21,010 sorry, not it, but the creator of the transaction, 972 00:44:21,010 --> 00:44:22,810 commits to a positive value. 973 00:44:22,810 --> 00:44:25,930 So the way that you transfer $1 million from one bank 974 00:44:25,930 --> 00:44:29,170 to another is committing to a negative value in the spenders 975 00:44:29,170 --> 00:44:30,840 column-- here, JP Morgan-- 976 00:44:30,840 --> 00:44:33,570 and committing to a positive value in the receivers column-- 977 00:44:33,570 --> 00:44:34,300 here, Barclays. 978 00:44:41,760 --> 00:44:45,570 And again for non-involved banks, entries commit to 0. 979 00:44:45,570 --> 00:44:47,820 But one thing I want to stress-- 980 00:44:47,820 --> 00:44:51,840 commitments to 0 are completely indistinguishable from 981 00:44:51,840 --> 00:44:54,060 commitments to any other value. 982 00:44:54,060 --> 00:44:55,530 And commitments to negative values 983 00:44:55,530 --> 00:44:58,770 are indistinguishable from commitments to positive values. 984 00:44:58,770 --> 00:45:03,050 So someone looking at this, just looking at these commitments 985 00:45:03,050 --> 00:45:05,870 posted to the ledger, has no idea which ones are 0s, 986 00:45:05,870 --> 00:45:09,240 and which ones are negative, and which ones are positive. 987 00:45:09,240 --> 00:45:09,740 Yes? 988 00:45:09,740 --> 00:45:11,655 AUDIENCE: Does this mean that each bank has 989 00:45:11,655 --> 00:45:13,280 to keep track of every transaction that 990 00:45:13,280 --> 00:45:16,848 is done in the ledger, and produce the random numbers, 991 00:45:16,848 --> 00:45:18,390 and keep track of those numbers, too? 992 00:45:18,390 --> 00:45:19,920 NEHA NARULA: Great question. 993 00:45:19,920 --> 00:45:23,840 So, yeah, one design might have it be the case 994 00:45:23,840 --> 00:45:25,760 that every bank actually has to be 995 00:45:25,760 --> 00:45:27,590 involved in every transaction. 996 00:45:27,590 --> 00:45:32,240 We managed to design zkLedger so that the spending bank can 997 00:45:32,240 --> 00:45:34,820 produce one of these without actually involving 998 00:45:34,820 --> 00:45:37,558 any of the other banks. 999 00:45:37,558 --> 00:45:39,100 And I will describe how that happens. 1000 00:45:44,810 --> 00:45:49,420 OK, and so, given now that we've said, 1001 00:45:49,420 --> 00:45:52,450 essentially, every bank is involved in every transaction, 1002 00:45:52,450 --> 00:45:54,730 this actually makes life easier for the auditor. 1003 00:45:54,730 --> 00:45:56,620 Because now when the auditor audits a bank, 1004 00:45:56,620 --> 00:45:59,630 they audit every transaction. 1005 00:45:59,630 --> 00:46:03,400 So they audit the entire column for a bank. 1006 00:46:03,400 --> 00:46:06,190 So here, when the auditor is auditing Barclays, 1007 00:46:06,190 --> 00:46:09,250 they won't just look at whatever transactions Barclays tells 1008 00:46:09,250 --> 00:46:10,210 them to look at. 1009 00:46:10,210 --> 00:46:12,770 They will look at every transaction. 1010 00:46:12,770 --> 00:46:13,390 OK? 1011 00:46:13,390 --> 00:46:14,650 And this is where-- 1012 00:46:14,650 --> 00:46:16,300 I think someone asked about timing, 1013 00:46:16,300 --> 00:46:20,500 or how do you audit a range of transactions? 1014 00:46:20,500 --> 00:46:23,020 The auditor can actually tell the bank, oh, I just 1015 00:46:23,020 --> 00:46:25,680 want to audit from this point onwards. 1016 00:46:25,680 --> 00:46:27,220 Or it can say, I just want to audit 1017 00:46:27,220 --> 00:46:31,030 your transactions for the past month, if it wants to. 1018 00:46:31,030 --> 00:46:33,790 That doesn't mean that Barclays can leave out transactions, 1019 00:46:33,790 --> 00:46:37,590 because there's supposed to be a time stamp column in here 1020 00:46:37,590 --> 00:46:38,090 as well. 1021 00:46:38,090 --> 00:46:39,820 So you can see when transactions happen. 1022 00:46:39,820 --> 00:46:41,440 That's public. 1023 00:46:41,440 --> 00:46:43,260 So what happens here is the auditor 1024 00:46:43,260 --> 00:46:44,950 is going to look at everything. 1025 00:46:44,950 --> 00:46:48,970 They're actually going to multiply three commitments 1026 00:46:48,970 --> 00:46:52,387 together, because there's three commitments in that column. 1027 00:46:52,387 --> 00:46:54,970 And it doesn't know which ones are 0 and which ones are not 0. 1028 00:46:54,970 --> 00:46:56,940 But the 0 doesn't contribute to the sum. 1029 00:47:00,350 --> 00:47:05,620 And so a malicious bank can't actually lie to the auditor, 1030 00:47:05,620 --> 00:47:12,780 because in this case, the bank is not 1031 00:47:12,780 --> 00:47:15,560 going to leave out commitment four. 1032 00:47:15,560 --> 00:47:19,260 And in fact, it's also going to include commitment two. 1033 00:47:29,740 --> 00:47:37,390 So the bank is going to have to include the r primes in here 1034 00:47:37,390 --> 00:47:39,160 to get all of this to work out correctly. 1035 00:47:39,160 --> 00:47:40,868 It's going to have to include everything. 1036 00:47:49,000 --> 00:47:51,980 So this next-- 1037 00:47:51,980 --> 00:47:56,040 I'm actually going to skip a little bit of this, 1038 00:47:56,040 --> 00:47:58,313 because I think we're running a bit low on time. 1039 00:47:58,313 --> 00:48:00,480 And I do want to get into what the proofs look like. 1040 00:48:00,480 --> 00:48:05,370 So I'm going to skip this averages part. 1041 00:48:05,370 --> 00:48:09,165 I'm going to go back to our security goals. 1042 00:48:11,790 --> 00:48:15,360 What I just described to you, the ledger table construction, 1043 00:48:15,360 --> 00:48:19,590 allows us to achieve our first two security goals. 1044 00:48:19,590 --> 00:48:21,810 Privacy-- because these commitments are perfectly 1045 00:48:21,810 --> 00:48:25,380 hiding, no one can see transaction participants. 1046 00:48:25,380 --> 00:48:27,120 They can't tell who's committing to 0, 1047 00:48:27,120 --> 00:48:29,310 and who's not committing to 0. 1048 00:48:29,310 --> 00:48:31,890 Banks can't lie to the auditor, because the auditor audits 1049 00:48:31,890 --> 00:48:33,760 every transaction for a bank. 1050 00:48:33,760 --> 00:48:36,120 But what I haven't figured out yet 1051 00:48:36,120 --> 00:48:39,730 is, well, how do we maintain financial invariants 1052 00:48:39,730 --> 00:48:40,440 in this scheme? 1053 00:48:40,440 --> 00:48:42,815 How do we make sure assets aren't created out of nowhere? 1054 00:48:42,815 --> 00:48:45,540 How do we make sure that whoever is spending actually 1055 00:48:45,540 --> 00:48:47,160 consented to the spend? 1056 00:48:47,160 --> 00:48:50,100 And how do we construct this transaction 1057 00:48:50,100 --> 00:48:54,840 that involves every bank when we assume banks are malicious, 1058 00:48:54,840 --> 00:48:57,660 and we don't want one bank to be able to hold up everyone 1059 00:48:57,660 --> 00:48:58,912 from transacting? 1060 00:49:03,160 --> 00:49:06,580 So our solution to do that is to use a set 1061 00:49:06,580 --> 00:49:08,080 of what are called NIZKs-- 1062 00:49:08,080 --> 00:49:11,890 non-interactive zero-knowledge proofs. 1063 00:49:11,890 --> 00:49:13,720 So what are NIZKs? 1064 00:49:13,720 --> 00:49:17,670 NIZKs are short binary strings. 1065 00:49:17,670 --> 00:49:21,060 True statements have proofs. 1066 00:49:21,060 --> 00:49:24,410 So, if a statement is true, it should have a proof 1067 00:49:24,410 --> 00:49:26,000 indicating that it's true. 1068 00:49:26,000 --> 00:49:29,270 False statements only have proofs 1069 00:49:29,270 --> 00:49:33,450 with negligible probability. 1070 00:49:33,450 --> 00:49:38,580 And proofs don't reveal why they are true. 1071 00:49:38,580 --> 00:49:41,730 So we're going to use NIZKs to prove things 1072 00:49:41,730 --> 00:49:47,410 like the person who knows the secret key for this public key 1073 00:49:47,410 --> 00:49:52,480 consented to this transfer, without indicating which 1074 00:49:52,480 --> 00:49:56,543 bank it was that consented to the transfer. 1075 00:49:56,543 --> 00:49:58,210 We're going to use NIZKs to prove things 1076 00:49:58,210 --> 00:50:05,500 like this bank has the assets to spend, 1077 00:50:05,500 --> 00:50:09,590 without revealing how many assets that bank actually has. 1078 00:50:12,750 --> 00:50:16,980 So zkLedger uses a set of carefully crafted NIZKs. 1079 00:50:16,980 --> 00:50:19,270 And to be clear, NIZKs are pretty old. 1080 00:50:19,270 --> 00:50:22,470 They were invented in the '80s and the '90s. 1081 00:50:22,470 --> 00:50:24,240 And most of them are based on the hardness 1082 00:50:24,240 --> 00:50:26,940 of the discrete log problem in elliptic curve cryptography, 1083 00:50:26,940 --> 00:50:28,230 again. 1084 00:50:28,230 --> 00:50:30,480 So here are the properties we want 1085 00:50:30,480 --> 00:50:31,800 to achieve with transactions. 1086 00:50:31,800 --> 00:50:33,510 We want transaction validity. 1087 00:50:33,510 --> 00:50:37,417 We want to make sure whoever is the spender, whoever 1088 00:50:37,417 --> 00:50:39,000 has a negative amount in their column, 1089 00:50:39,000 --> 00:50:41,070 actually consented to the transfer. 1090 00:50:41,070 --> 00:50:43,453 And again, remember, in cryptocurrencies and things 1091 00:50:43,453 --> 00:50:45,870 like that, where it's OK to reveal who the person is who's 1092 00:50:45,870 --> 00:50:47,710 spending, we use a signature. 1093 00:50:47,710 --> 00:50:51,720 In this case, we'll use proof of knowledge of secret key. 1094 00:50:51,720 --> 00:50:53,978 So there's a consent NIZK. 1095 00:50:53,978 --> 00:50:56,520 We want to be able to prove that whoever is spending actually 1096 00:50:56,520 --> 00:50:58,470 has the assets to transfer-- that they're not 1097 00:50:58,470 --> 00:50:59,640 going negative. 1098 00:50:59,640 --> 00:51:02,070 And we use an assets NIZK. 1099 00:51:02,070 --> 00:51:06,210 And we want to make sure that assets are neither created 1100 00:51:06,210 --> 00:51:08,580 nor destroyed, so for that we use a balance NIZK. 1101 00:51:08,580 --> 00:51:10,470 We want to show that things work out, 1102 00:51:10,470 --> 00:51:14,550 and you didn't create more euros than you were supposed to. 1103 00:51:14,550 --> 00:51:16,050 The only place where you can do that 1104 00:51:16,050 --> 00:51:17,760 is in the depositor transactions, 1105 00:51:17,760 --> 00:51:20,130 the public depositor transactions. 1106 00:51:20,130 --> 00:51:24,570 We also want to make sure that honest banks can make progress. 1107 00:51:24,570 --> 00:51:28,140 And in order to do that, creating a transaction 1108 00:51:28,140 --> 00:51:30,240 in zkLedger is non-interactive. 1109 00:51:30,240 --> 00:51:33,790 The banks don't have to interact to create a transaction. 1110 00:51:33,790 --> 00:51:37,380 This is exactly how systems like Ethereum and Bitcoin work, 1111 00:51:37,380 --> 00:51:38,530 if you think about it. 1112 00:51:38,530 --> 00:51:41,940 I can't stop you from sending me Bitcoin, right? 1113 00:51:41,940 --> 00:51:43,530 If you want to send me Bitcoin, you 1114 00:51:43,530 --> 00:51:45,570 construct a transaction that sends me Bitcoin. 1115 00:51:45,570 --> 00:51:46,903 You submit it to the blockchain. 1116 00:51:46,903 --> 00:51:48,270 I have nothing to do with that. 1117 00:51:48,270 --> 00:51:51,000 Offline, we might have agreed that the reason you're 1118 00:51:51,000 --> 00:51:53,490 sending me Bitcoin is because I'm selling you 1119 00:51:53,490 --> 00:51:55,410 my car or something like that. 1120 00:51:55,410 --> 00:51:59,340 But to actually create the transaction that spends, 1121 00:51:59,340 --> 00:52:01,800 you don't have to talk to the other participants. 1122 00:52:01,800 --> 00:52:08,760 And we use a consistency NIZK so that the person creating 1123 00:52:08,760 --> 00:52:13,530 the transaction can prove in a publicly verifiable way 1124 00:52:13,530 --> 00:52:16,110 that everything matches up correctly, 1125 00:52:16,110 --> 00:52:18,210 that all of these proofs are correct, 1126 00:52:18,210 --> 00:52:21,690 and that all of the banks are going to be able to later 1127 00:52:21,690 --> 00:52:22,980 respond to the auditor-- 1128 00:52:22,980 --> 00:52:25,450 be able to respond to the auditor as necessary. 1129 00:52:25,450 --> 00:52:27,600 So to give you a little bit of insight 1130 00:52:27,600 --> 00:52:32,370 into why this consistency NIZK is necessary, 1131 00:52:32,370 --> 00:52:36,630 over here, I was speaking as though the bank knew 1132 00:52:36,630 --> 00:52:41,190 all of the r values, right? 1133 00:52:41,190 --> 00:52:43,740 Actually, in zkLedger, if a bank is not 1134 00:52:43,740 --> 00:52:46,530 involved in a transaction, if their commitment's to 0, 1135 00:52:46,530 --> 00:52:48,510 they don't know their own r value, 1136 00:52:48,510 --> 00:52:50,910 because some other bank has created that. 1137 00:52:50,910 --> 00:53:01,180 So if we go backwards a little bit to here, 1138 00:53:01,180 --> 00:53:04,390 Barclays wasn't involved in this transaction at all. 1139 00:53:04,390 --> 00:53:07,660 And in fact, Barclays-- so Goldman Sachs 1140 00:53:07,660 --> 00:53:09,830 created this transaction. 1141 00:53:09,830 --> 00:53:13,190 JP Morgan created this one and this one. 1142 00:53:13,190 --> 00:53:15,030 Barclays had nothing to do with them. 1143 00:53:15,030 --> 00:53:16,850 They weren't involved at all. 1144 00:53:16,850 --> 00:53:19,490 And we can't assume that Barclays knows 1145 00:53:19,490 --> 00:53:22,780 what the rs are in its column. 1146 00:53:22,780 --> 00:53:25,100 Yet the way that I told you that Barclays' 1147 00:53:25,100 --> 00:53:28,880 response to the auditor is by revealing the sum of the rs. 1148 00:53:28,880 --> 00:53:31,580 So that's actually not how zkLedger works. 1149 00:53:31,580 --> 00:53:33,530 They don't actually reveal the sum of the rs. 1150 00:53:33,530 --> 00:53:38,720 The proof is a little bit more complicated. 1151 00:53:38,720 --> 00:53:42,110 The rs are encoded for Barclays in a way 1152 00:53:42,110 --> 00:53:45,590 that it can't see what they are, but it can use them. 1153 00:53:45,590 --> 00:53:50,120 And the consistency proof is to prove that that encoding was 1154 00:53:50,120 --> 00:53:51,260 done correctly. 1155 00:53:55,707 --> 00:53:57,540 So again, you can see the paper for details, 1156 00:53:57,540 --> 00:53:58,957 but I'm actually going to tell you 1157 00:53:58,957 --> 00:54:03,450 a little bit about these proofs and what they look like, OK? 1158 00:54:03,450 --> 00:54:05,580 So, consent. 1159 00:54:05,580 --> 00:54:11,160 The consent proof is proof of knowledge of secret key, sk. 1160 00:54:11,160 --> 00:54:16,260 So what this means is that if the value in the commitment 1161 00:54:16,260 --> 00:54:21,210 in this entry is negative, then there 1162 00:54:21,210 --> 00:54:24,240 should be a proof of knowledge of secret key 1163 00:54:24,240 --> 00:54:28,455 to indicate that this bank has consented to subtracting 1164 00:54:28,455 --> 00:54:29,205 from their assets. 1165 00:54:32,720 --> 00:54:35,840 Also, if the value is negative, you 1166 00:54:35,840 --> 00:54:38,900 need to create a proof of assets. 1167 00:54:38,900 --> 00:54:40,940 Technically, you don't need a proof of assets 1168 00:54:40,940 --> 00:54:43,220 if the value is not negative, but we're 1169 00:54:43,220 --> 00:54:46,400 trying not to reveal, remember, which bank is 1170 00:54:46,400 --> 00:54:48,230 involved in which transaction. 1171 00:54:48,230 --> 00:54:51,560 So I'm going to draw a transaction up 1172 00:54:51,560 --> 00:54:55,880 here and explain a little bit about where 1173 00:54:55,880 --> 00:54:57,030 these proofs actually go. 1174 00:55:04,930 --> 00:55:07,730 A transaction is a row. 1175 00:55:14,180 --> 00:55:25,252 And there is an entry for each bank in the transaction. 1176 00:55:30,080 --> 00:55:32,900 So there is a commitment. 1177 00:55:32,900 --> 00:55:38,510 So let's-- negative 1 million. 1178 00:55:43,190 --> 00:55:45,680 And then there is also these sets of proofs. 1179 00:55:45,680 --> 00:55:52,730 So, proof of assets, in particular. 1180 00:55:52,730 --> 00:55:56,780 And every single entry has a proof of assets, 1181 00:55:56,780 --> 00:55:59,060 even though, really, this is the only bank that's 1182 00:55:59,060 --> 00:56:01,535 spending and needs to prove that it has assets. 1183 00:56:04,190 --> 00:56:10,110 The proof of assets is constructed to look like this. 1184 00:56:10,110 --> 00:56:13,700 It's a new commitment, either to the sum 1185 00:56:13,700 --> 00:56:16,850 of the values in the column, or, if you're not 1186 00:56:16,850 --> 00:56:19,790 the spending bank, a commitment to the value. 1187 00:56:19,790 --> 00:56:24,500 And it also includes a proof that the value 1188 00:56:24,500 --> 00:56:27,500 in this auxiliary commitment is in range. 1189 00:56:27,500 --> 00:56:29,690 So what do I mean by that? 1190 00:56:29,690 --> 00:56:32,210 I think you guys should have covered this in the Pedersen 1191 00:56:32,210 --> 00:56:34,460 commitment lecture with confidential transactions, 1192 00:56:34,460 --> 00:56:36,770 but when you're dealing with cyclic groups, 1193 00:56:36,770 --> 00:56:39,020 you can wrap around the end of the group. 1194 00:56:39,020 --> 00:56:42,770 And that's the same as if you hadn't wrapped around. 1195 00:56:42,770 --> 00:56:44,600 There are many different things that 1196 00:56:44,600 --> 00:56:48,020 can occupy one point in the space of a cyclic group. 1197 00:56:48,020 --> 00:56:52,490 So we need to include proofs that your value is 1198 00:56:52,490 --> 00:56:54,290 in a range that's expected. 1199 00:56:54,290 --> 00:56:56,330 And in the case of zkLedger, we need 1200 00:56:56,330 --> 00:56:58,730 to prove that the value is between 0 1201 00:56:58,730 --> 00:57:01,520 and a certain upper limit that is less 1202 00:57:01,520 --> 00:57:03,650 than the order of the group. 1203 00:57:03,650 --> 00:57:06,950 And we use the exact same technique 1204 00:57:06,950 --> 00:57:09,560 that they use in confidential transactions to do this-- 1205 00:57:09,560 --> 00:57:12,320 borromean ring signatures. 1206 00:57:12,320 --> 00:57:16,430 What's kind of exciting is that, a few months ago, there 1207 00:57:16,430 --> 00:57:21,830 was some work done on a faster, smaller, more aggregatable 1208 00:57:21,830 --> 00:57:25,910 version of range proofs using a system called bullet proofs. 1209 00:57:25,910 --> 00:57:31,250 So as you'll see in the evaluation, 1210 00:57:31,250 --> 00:57:33,230 this sounds like such a silly little thing. 1211 00:57:33,230 --> 00:57:35,630 Oh, yeah, also prove that the value is in range. 1212 00:57:35,630 --> 00:57:39,920 This is like 90% of all of the space and work in zkLedger. 1213 00:57:39,920 --> 00:57:43,140 These range proofs are the bane of our existence. 1214 00:57:43,140 --> 00:57:44,930 They take up a lot of space. 1215 00:57:44,930 --> 00:57:49,130 They're very slow to create and verify, but they're necessary. 1216 00:57:49,130 --> 00:57:54,620 So making them faster is a really amazing thing. 1217 00:57:54,620 --> 00:57:57,740 Then the next thing is balance. 1218 00:57:57,740 --> 00:57:59,810 And I think this one is illustrative, 1219 00:57:59,810 --> 00:58:02,730 because it shows that a proof-- 1220 00:58:02,730 --> 00:58:04,760 sometimes you have a proof not by creating 1221 00:58:04,760 --> 00:58:07,580 an additional binary string, but by the way you choose 1222 00:58:07,580 --> 00:58:10,190 things in your transaction. 1223 00:58:10,190 --> 00:58:12,500 So the way that you prove that no funds are created 1224 00:58:12,500 --> 00:58:14,820 or destroyed is as follows. 1225 00:58:14,820 --> 00:58:19,030 So these are-- remember these commitments are g to the 0. 1226 00:58:19,030 --> 00:58:23,360 Let's say h the r1, g to the negative 1 million, 1227 00:58:23,360 --> 00:58:28,440 h to the r2, and g to the 1 million, h to the r3. 1228 00:58:28,440 --> 00:58:31,460 Now, given that we have these commitments, 1229 00:58:31,460 --> 00:58:35,420 how can we prove to someone that no assets 1230 00:58:35,420 --> 00:58:36,830 were created or destroyed? 1231 00:58:36,830 --> 00:58:38,780 Well, what does it mean for no assets 1232 00:58:38,780 --> 00:58:40,200 to be created or destroyed? 1233 00:58:40,200 --> 00:58:46,723 It means that the sum of the vs is equal to 0, right? 1234 00:58:46,723 --> 00:58:48,140 That's what it means for no assets 1235 00:58:48,140 --> 00:58:49,400 to be created or destroyed. 1236 00:58:49,400 --> 00:58:53,210 How can we prove to someone that, given that all they're 1237 00:58:53,210 --> 00:58:57,050 seeing are these commitments, that the sum of the vs 1238 00:58:57,050 --> 00:58:58,700 commit to 0? 1239 00:58:58,700 --> 00:59:04,610 Well, let's just make the sum of the rs also commit to 0. 1240 00:59:04,610 --> 00:59:09,560 So if the sum of the rs also commits to 0, then 1241 00:59:09,560 --> 00:59:12,180 when you multiply these things together, 1242 00:59:12,180 --> 00:59:15,380 you're going to get g to the sum of the vs, h 1243 00:59:15,380 --> 00:59:17,540 to the sum of the rs. 1244 00:59:17,540 --> 00:59:21,770 And if both of these things are 0, you get g to the 0, 1245 00:59:21,770 --> 00:59:25,080 h to the 0, which should equal what? 1246 00:59:25,080 --> 00:59:27,470 One, exactly. 1247 00:59:27,470 --> 00:59:31,040 So we choose our rs very carefully, 1248 00:59:31,040 --> 00:59:34,190 so that the auditor, or whoever is verifying this, 1249 00:59:34,190 --> 00:59:37,430 can just multiply all the commitments together and verify 1250 00:59:37,430 --> 00:59:38,480 that they equal 1. 1251 00:59:38,480 --> 00:59:40,940 And if it equals 1, that means it 1252 00:59:40,940 --> 00:59:45,640 would have been very difficult to choose vs such that you 1253 00:59:45,640 --> 00:59:48,810 could make this come out to 1 without it actually coming out 1254 00:59:48,810 --> 00:59:50,300 to 1. 1255 00:59:50,300 --> 00:59:52,970 So that's the proof of balance. 1256 00:59:52,970 --> 00:59:54,860 It's not an actual proof. 1257 00:59:54,860 --> 00:59:56,690 It's not a short binary string. 1258 00:59:56,690 --> 00:59:59,540 It's literally choosing the exponents in a clever way 1259 00:59:59,540 --> 01:00:02,675 to show that we can maintain the invariant that we want. 1260 01:00:02,675 --> 01:00:03,550 Does that make sense? 1261 01:00:08,220 --> 01:00:10,420 Questions about these proofs? 1262 01:00:10,420 --> 01:00:13,150 And I didn't go into proof of assets very much. 1263 01:00:13,150 --> 01:00:14,400 It's the most complicated one. 1264 01:00:14,400 --> 01:00:15,733 But you can check out the paper. 1265 01:00:18,730 --> 01:00:20,535 I see some confused faces. 1266 01:00:20,535 --> 01:00:22,160 You don't have to ask about the proofs. 1267 01:00:22,160 --> 01:00:26,020 AUDIENCE: Couldn't you just choose both of the exponents? 1268 01:00:26,020 --> 01:00:28,240 So if you're choosing rs in a certain way, 1269 01:00:28,240 --> 01:00:31,140 can't you choose them in a certain way 1270 01:00:31,140 --> 01:00:36,103 and then choose payments so that they sum to 0? 1271 01:00:36,103 --> 01:00:37,770 NEHA NARULA: Well, we're trying to prove 1272 01:00:37,770 --> 01:00:38,895 that the payments sum to 0. 1273 01:00:38,895 --> 01:00:40,140 That's what we want. 1274 01:00:40,140 --> 01:00:43,950 Because that means that assets weren't created or destroyed. 1275 01:00:43,950 --> 01:00:45,040 And remember-- 1276 01:00:45,040 --> 01:00:46,540 AUDIENCE: You're generating-- you're 1277 01:00:46,540 --> 01:00:51,120 creating those random numbers in a way that they sum to zero. 1278 01:00:51,120 --> 01:00:53,600 So if you create them in a way that doesn't sum to 0? 1279 01:00:53,600 --> 01:00:55,110 NEHA NARULA: Then every-- ah, OK. 1280 01:00:55,110 --> 01:00:56,442 So this is an important-- 1281 01:00:56,442 --> 01:00:57,900 AUDIENCE: Change the transaction so 1282 01:00:57,900 --> 01:01:02,062 that the sum of the rs and the sum of the values sum to 0? 1283 01:01:02,062 --> 01:01:04,020 NEHA NARULA: So basically, what you're saying-- 1284 01:01:04,020 --> 01:01:04,640 I think what you're say-- 1285 01:01:04,640 --> 01:01:06,390 OK, you could be saying one of two things. 1286 01:01:06,390 --> 01:01:10,590 Number one, what if you choose your vs and rs such 1287 01:01:10,590 --> 01:01:12,270 that it doesn't sum to 0, right? 1288 01:01:12,270 --> 01:01:14,760 What if you produce an invalid transaction? 1289 01:01:14,760 --> 01:01:18,060 And the answer is that everyone will reject it. 1290 01:01:18,060 --> 01:01:19,500 Sort of similar to Bitcoin, if you 1291 01:01:19,500 --> 01:01:21,690 don't have a valid transaction, good for you. 1292 01:01:21,690 --> 01:01:23,940 But it's going to be considered invalid by everyone 1293 01:01:23,940 --> 01:01:24,360 in the system. 1294 01:01:24,360 --> 01:01:26,160 And everyone's going to skip it and ignore it. 1295 01:01:26,160 --> 01:01:28,140 It's not going to be part of what happens, right? 1296 01:01:28,140 --> 01:01:29,807 So this is part of the proof of validity 1297 01:01:29,807 --> 01:01:31,800 that all of the participants have consented to. 1298 01:01:31,800 --> 01:01:33,425 The second question you might be asking 1299 01:01:33,425 --> 01:01:39,180 is, what if these don't sum to 0, 1300 01:01:39,180 --> 01:01:42,120 but I still manage to figure out how 1301 01:01:42,120 --> 01:01:43,800 to make this equal 1, right? 1302 01:01:43,800 --> 01:01:47,280 That's what you-- OK, so that's the question you're asking. 1303 01:01:47,280 --> 01:01:50,250 Based on the assumption that the discrete logarithm problem 1304 01:01:50,250 --> 01:01:52,978 is hard-- 1305 01:01:52,978 --> 01:01:54,270 this is too hard to figure out. 1306 01:01:54,270 --> 01:01:56,160 You literally cannot find-- 1307 01:01:58,780 --> 01:02:00,800 there is an assumption here. 1308 01:02:00,800 --> 01:02:03,380 These are two generators of the group, right? 1309 01:02:03,380 --> 01:02:07,280 So that means the g is equal to h to the x, 1310 01:02:07,280 --> 01:02:09,200 that there's some way to produce one generator 1311 01:02:09,200 --> 01:02:11,060 from the other generator. 1312 01:02:11,060 --> 01:02:14,420 There is an assumption here that figuring out what that x is 1313 01:02:14,420 --> 01:02:16,590 is nearly impossible. 1314 01:02:16,590 --> 01:02:20,510 So you don't know what g is in terms of h. 1315 01:02:20,510 --> 01:02:23,180 And given that you don't know this relationship between g 1316 01:02:23,180 --> 01:02:27,800 and h, you can't figure out how to produce 1317 01:02:27,800 --> 01:02:32,750 two exponents that sum to what you want them to sum to. 1318 01:02:32,750 --> 01:02:40,700 So is the hardness problem that these systems are based on. 1319 01:02:40,700 --> 01:02:43,310 If you could do that, if you could figure out 1320 01:02:43,310 --> 01:02:47,528 a sum of rs such that it gave you a 1 with the vs 1321 01:02:47,528 --> 01:02:49,820 you wanted, then you would have broken the discrete log 1322 01:02:49,820 --> 01:02:51,550 problem. 1323 01:02:51,550 --> 01:02:52,050 Yes? 1324 01:02:52,050 --> 01:02:54,405 AUDIENCE: So who chooses the [INAUDIBLE] 1325 01:02:54,405 --> 01:02:57,140 we know that they don't know the relationship [INAUDIBLE] they 1326 01:02:57,140 --> 01:02:58,265 maliciously gave those two? 1327 01:02:58,265 --> 01:02:59,710 NEHA NARULA: Great question. 1328 01:02:59,710 --> 01:03:02,550 So the answer is that in our system, 1329 01:03:02,550 --> 01:03:06,480 the way that we choose g and h is by taking the SHA-256 1330 01:03:06,480 --> 01:03:08,220 hash of 0 and 1. 1331 01:03:11,310 --> 01:03:12,900 Those are numbers such that-- 1332 01:03:12,900 --> 01:03:15,870 they're sufficiently random, and they 1333 01:03:15,870 --> 01:03:22,050 show that if you took a hash of 0 and 1, 1334 01:03:22,050 --> 01:03:25,370 you would have no relationship between those two. 1335 01:03:25,370 --> 01:03:29,167 And everyone uses the same g and h, right, from the beginning. 1336 01:03:35,240 --> 01:03:37,830 Any other questions? 1337 01:03:37,830 --> 01:03:41,490 OK, so we're running low on time, 1338 01:03:41,490 --> 01:03:43,710 but I do want to go through the evaluation really 1339 01:03:43,710 --> 01:03:45,210 quickly, because-- 1340 01:03:45,210 --> 01:03:48,870 so this system, this paper, was presented at NSDI 1341 01:03:48,870 --> 01:03:50,700 in April, which is a systems conference. 1342 01:03:50,700 --> 01:03:53,340 And I think part of the reason that the systems community 1343 01:03:53,340 --> 01:03:56,340 liked it was because it's surprisingly fast. 1344 01:03:56,340 --> 01:03:58,740 You might have heard that computing unencrypted data is 1345 01:03:58,740 --> 01:03:59,820 too slow. 1346 01:03:59,820 --> 01:04:00,720 It's infeasible. 1347 01:04:00,720 --> 01:04:01,470 You can't do it. 1348 01:04:01,470 --> 01:04:03,780 Well, the answer is, actually, if you understand 1349 01:04:03,780 --> 01:04:07,590 the set of computations you want to do really well, 1350 01:04:07,590 --> 01:04:10,160 you can structure things using things like these NIZKs 1351 01:04:10,160 --> 01:04:11,910 and the discrete log problem in such a way 1352 01:04:11,910 --> 01:04:16,550 that you can do that computation actually pretty fast. 1353 01:04:16,550 --> 01:04:19,680 So zkLedger is written in Go. 1354 01:04:19,680 --> 01:04:22,045 It uses an elliptic curve as the group-- 1355 01:04:22,045 --> 01:04:24,990 secp256k1, which is the same elliptic curve 1356 01:04:24,990 --> 01:04:26,970 that Bitcoin uses. 1357 01:04:26,970 --> 01:04:30,060 We use range proofs to prevent overflow, like I said. 1358 01:04:30,060 --> 01:04:32,850 We use the same ones as in confidential transactions 1359 01:04:32,850 --> 01:04:34,290 and confidential assets. 1360 01:04:34,290 --> 01:04:36,510 And it's around 4,000 lines of code. 1361 01:04:36,510 --> 01:04:39,390 It's mostly cryptography functions. 1362 01:04:39,390 --> 01:04:41,580 We don't actually implement our own ledger, 1363 01:04:41,580 --> 01:04:44,150 because we're ledger agnostic. 1364 01:04:44,150 --> 01:04:47,390 So in the evaluation we want to understand how fast 1365 01:04:47,390 --> 01:04:49,700 is auditing, first of all? 1366 01:04:49,700 --> 01:04:50,390 Right? 1367 01:04:50,390 --> 01:04:52,520 And then second, the construction 1368 01:04:52,520 --> 01:04:54,020 I described to you, you might think 1369 01:04:54,020 --> 01:04:56,480 is very slow, because every bank has 1370 01:04:56,480 --> 01:04:58,260 an entry in every transaction. 1371 01:04:58,260 --> 01:05:00,710 So how does this actually work in practice? 1372 01:05:00,710 --> 01:05:04,100 Can we get away with such a construction? 1373 01:05:04,100 --> 01:05:07,130 So first, let's talk about the auditing. 1374 01:05:07,130 --> 01:05:08,210 Auditing is really fast. 1375 01:05:08,210 --> 01:05:09,980 So here, we are auditing four banks, 1376 01:05:09,980 --> 01:05:11,780 and we're doing a measurement called 1377 01:05:11,780 --> 01:05:13,447 the Herfindahl-Hirschman Index, so we're 1378 01:05:13,447 --> 01:05:16,250 trying to understand market concentration for a given 1379 01:05:16,250 --> 01:05:17,120 asset. 1380 01:05:17,120 --> 01:05:19,700 And what's happening here is the auditor 1381 01:05:19,700 --> 01:05:23,270 is keeping up with the ledger and keeping these things 1382 01:05:23,270 --> 01:05:25,040 that we call commitment caches. 1383 01:05:25,040 --> 01:05:29,690 So because of the design of our system 1384 01:05:29,690 --> 01:05:33,320 and the fact that we're using these Pedersen commitments-- 1385 01:05:33,320 --> 01:05:37,670 which, we can actually maintain rolling sums 1386 01:05:37,670 --> 01:05:42,020 going down of these commitments and use them 1387 01:05:42,020 --> 01:05:43,910 when needing to answer the auditor 1388 01:05:43,910 --> 01:05:46,370 or confirm that a bank has the correct answer. 1389 01:05:46,370 --> 01:05:49,130 And so this means that auditing for banks is milliseconds. 1390 01:05:49,130 --> 01:05:52,130 It's a few milliseconds to audit the banks. 1391 01:05:52,130 --> 01:05:56,270 And we see here on the x-axis we have the number of transactions 1392 01:05:56,270 --> 01:05:57,080 in the ledger. 1393 01:05:57,080 --> 01:05:59,570 The reason that auditing a bank is 1394 01:05:59,570 --> 01:06:02,030 independent of the number of transactions in the ledger 1395 01:06:02,030 --> 01:06:03,860 is because of these commitment caches. 1396 01:06:03,860 --> 01:06:06,350 We can do it really fast, assuming an online auditor 1397 01:06:06,350 --> 01:06:07,670 who's keeping up with things. 1398 01:06:10,695 --> 01:06:13,070 And part of the reason for that is because of our design. 1399 01:06:13,070 --> 01:06:14,510 It's very amenable to caching. 1400 01:06:14,510 --> 01:06:18,380 Now, if the auditor is not online and hasn't 1401 01:06:18,380 --> 01:06:20,090 been maintaining commitment caches, 1402 01:06:20,090 --> 01:06:23,930 then auditing is order the number of things in the ledger. 1403 01:06:23,930 --> 01:06:26,420 Here, we have a ledger with 100,000 entries. 1404 01:06:26,420 --> 01:06:29,650 It takes about 3.5 seconds to audit that. 1405 01:06:29,650 --> 01:06:31,760 Still not so bad, really. 1406 01:06:31,760 --> 01:06:34,430 And it's pretty linear, so you could imagine, well, 1407 01:06:34,430 --> 01:06:36,830 if you had a million entries, it would be 10 times that. 1408 01:06:36,830 --> 01:06:38,480 It would be about 30 seconds. 1409 01:06:38,480 --> 01:06:42,510 Still pretty reasonable, actually. 1410 01:06:42,510 --> 01:06:44,540 A question some people ask is, well, 1411 01:06:44,540 --> 01:06:46,760 do we have to maintain this ledger forever? 1412 01:06:46,760 --> 01:06:48,680 How do you clean up the ledger? 1413 01:06:48,680 --> 01:06:53,510 You can create a snapshot of the state in the ledger 1414 01:06:53,510 --> 01:06:55,040 and get rid of the past, assuming 1415 01:06:55,040 --> 01:06:56,320 you know the set of auditing queries 1416 01:06:56,320 --> 01:06:57,945 that you're going to do moving forward. 1417 01:06:57,945 --> 01:07:01,920 We don't implement this, but this should be possible. 1418 01:07:01,920 --> 01:07:04,470 Right, so if you wanted to do 100 million rows, 1419 01:07:04,470 --> 01:07:08,190 it would work out to be about an hour. 1420 01:07:08,190 --> 01:07:12,780 So here is a graph which shows how long it 1421 01:07:12,780 --> 01:07:16,463 takes to create and verify transactions in zkLedger. 1422 01:07:16,463 --> 01:07:18,130 And this is varying the number of banks. 1423 01:07:18,130 --> 01:07:19,505 And again, we see this is linear. 1424 01:07:19,505 --> 01:07:23,010 The more banks, the more entries per transaction, 1425 01:07:23,010 --> 01:07:25,770 the more of these commitments, the more range proofs, 1426 01:07:25,770 --> 01:07:27,270 quite honestly, is the problem. 1427 01:07:27,270 --> 01:07:29,700 Because there's a range proof per entry. 1428 01:07:29,700 --> 01:07:32,010 And what we see here is that with 10 banks, 1429 01:07:32,010 --> 01:07:36,090 it's about a second or 800 milliseconds 1430 01:07:36,090 --> 01:07:39,570 to create a transaction, which is not unreasonable. 1431 01:07:39,570 --> 01:07:44,070 Again, this achieves the multiple per second things 1432 01:07:44,070 --> 01:07:46,320 we were looking for, depending on the number of banks. 1433 01:07:46,320 --> 01:07:48,270 However, it is linear in the number 1434 01:07:48,270 --> 01:07:49,990 of participants in the system. 1435 01:07:49,990 --> 01:07:54,570 So something like this is not really suitable for a setting 1436 01:07:54,570 --> 01:07:58,560 like Bitcoin, where there are thousands, if not millions, 1437 01:07:58,560 --> 01:08:01,670 of participants in the system. 1438 01:08:01,670 --> 01:08:05,800 This graph gives you an idea of how all of that cost 1439 01:08:05,800 --> 01:08:07,280 breaks down. 1440 01:08:07,280 --> 01:08:13,240 So these are the components in the proofs. 1441 01:08:13,240 --> 01:08:16,630 And again, I think the thing to get from here 1442 01:08:16,630 --> 01:08:22,000 is that range proofs are the entirety of the problem. 1443 01:08:22,000 --> 01:08:25,390 So this is the number in a transaction for k participants. 1444 01:08:25,390 --> 01:08:28,779 So this is each slot. 1445 01:08:28,779 --> 01:08:30,430 There are two different commitments. 1446 01:08:30,430 --> 01:08:32,470 The first commitment, and then the auxiliary commitment. 1447 01:08:32,470 --> 01:08:34,178 There's two different consistency proofs. 1448 01:08:34,178 --> 01:08:37,010 There's a disjunctive proof, and there's a range proof. 1449 01:08:37,010 --> 01:08:42,279 And yeah, the commitment is one elliptic curve point, 1450 01:08:42,279 --> 01:08:44,850 which in Go is a big int-- 1451 01:08:44,850 --> 01:08:46,630 two big ints. 1452 01:08:46,630 --> 01:08:48,430 And so that's 64 bytes. 1453 01:08:48,430 --> 01:08:52,880 This is something that is actually highly compressable. 1454 01:08:52,880 --> 01:08:56,380 We didn't actually-- oh, OK. 1455 01:08:56,380 --> 01:08:58,200 Yeah, I'll get to that point in a moment. 1456 01:08:58,200 --> 01:09:04,109 But note here that the range proofs are slower and larger 1457 01:09:04,109 --> 01:09:05,490 than everything else combined. 1458 01:09:05,490 --> 01:09:07,979 They are the entirety of the cost of the system. 1459 01:09:07,979 --> 01:09:11,700 So a faster way of doing range proofs would really help a lot. 1460 01:09:11,700 --> 01:09:15,090 It would make us be able to handle many, many more banks. 1461 01:09:17,840 --> 01:09:20,380 So this is the cost in a transaction 1462 01:09:20,380 --> 01:09:22,029 per participant in the system. 1463 01:09:22,029 --> 01:09:29,310 [AUDIO OUT] One thing that I want to point out 1464 01:09:29,310 --> 01:09:34,410 is that this is all very highly parallelizable. 1465 01:09:34,410 --> 01:09:38,580 And like I said, we're using Go's big int construction, 1466 01:09:38,580 --> 01:09:41,800 which is not really very optimized at all. 1467 01:09:41,800 --> 01:09:44,069 So I think that there are a lot of opportunities 1468 01:09:44,069 --> 01:09:45,270 to make this faster. 1469 01:09:45,270 --> 01:09:50,189 So I think if we put in some engineering legwork, 1470 01:09:50,189 --> 01:09:53,040 we could create a system that was maybe 1471 01:09:53,040 --> 01:09:57,330 twice as fast as what we have now, and could handle maybe 100 1472 01:09:57,330 --> 01:10:00,090 banks. 1473 01:10:00,090 --> 01:10:03,240 So really quickly to wrap up, related work. 1474 01:10:03,240 --> 01:10:04,870 If you're interested in this topic, 1475 01:10:04,870 --> 01:10:08,280 there's a lot of different papers to read about and study. 1476 01:10:08,280 --> 01:10:10,770 This is all-- confidential assets kicked off 1477 01:10:10,770 --> 01:10:13,500 this line of using Pedersen commitments for privacy 1478 01:10:13,500 --> 01:10:14,760 in cryptocurrencies. 1479 01:10:14,760 --> 01:10:19,680 Zerocash was the origin of using zk-SNARKs. 1480 01:10:19,680 --> 01:10:23,640 They don't really support auditing in any fashion. 1481 01:10:23,640 --> 01:10:26,820 Then there's a couple papers that are really interesting, 1482 01:10:26,820 --> 01:10:29,760 one from Andrew Lowe, actually, who's 1483 01:10:29,760 --> 01:10:32,010 in the economics department here at MIT, 1484 01:10:32,010 --> 01:10:35,220 on using secure multi-party computation 1485 01:10:35,220 --> 01:10:38,210 to attack this problem. 1486 01:10:38,210 --> 01:10:41,760 The issue with that sort of design 1487 01:10:41,760 --> 01:10:44,520 is that it doesn't actually have the completeness guarantee 1488 01:10:44,520 --> 01:10:45,640 that we have. 1489 01:10:45,640 --> 01:10:47,970 So if the ledger really represents the assets 1490 01:10:47,970 --> 01:10:50,778 in the system, and the assets that you're trying to audit, 1491 01:10:50,778 --> 01:10:52,320 then there's no way for a participant 1492 01:10:52,320 --> 01:10:54,160 to lie in a multi-party computation. 1493 01:10:54,160 --> 01:10:55,680 They can use the wrong inputs. 1494 01:10:55,680 --> 01:10:57,720 So those systems provide secrecy, 1495 01:10:57,720 --> 01:10:59,640 but they don't provide completeness. 1496 01:10:59,640 --> 01:11:02,370 And then I mentioned Solidus before, 1497 01:11:02,370 --> 01:11:05,610 which I think our techniques would apply to really nicely. 1498 01:11:05,610 --> 01:11:09,720 And then there's a paper, a design 1499 01:11:09,720 --> 01:11:12,300 for doing some other sorts of accountability stuff 1500 01:11:12,300 --> 01:11:15,120 with cryptocurrencies, like proving you paid your taxes, 1501 01:11:15,120 --> 01:11:20,310 or proving that money didn't go through some blacklisted thing 1502 01:11:20,310 --> 01:11:22,083 using zk-SNARKs. 1503 01:11:22,083 --> 01:11:24,000 But that's not really a system, it's a design. 1504 01:11:24,000 --> 01:11:28,170 But I think that's also a really promising area to consider. 1505 01:11:28,170 --> 01:11:32,310 So, future work. 1506 01:11:32,310 --> 01:11:35,550 We want to consider more applications besides just 1507 01:11:35,550 --> 01:11:38,520 large investment banks trading securities and assets. 1508 01:11:38,520 --> 01:11:42,690 Can we do something with clinical trials? 1509 01:11:42,690 --> 01:11:45,390 Can we do something with supply chains? 1510 01:11:45,390 --> 01:11:46,800 I think that these techniques can 1511 01:11:46,800 --> 01:11:48,923 be applied to a lot more areas. 1512 01:11:48,923 --> 01:11:50,340 And I'd love to hear from you guys 1513 01:11:50,340 --> 01:11:52,882 if you have ideas on that, or if you're interested in working 1514 01:11:52,882 --> 01:11:55,590 on that and want to do a UROP, or maybe even 1515 01:11:55,590 --> 01:11:58,680 an M.Eng., that's definitely something that's on the table. 1516 01:11:58,680 --> 01:12:02,280 We get surprisingly far with Pedersen commitments, 1517 01:12:02,280 --> 01:12:05,283 but if we included more interesting types 1518 01:12:05,283 --> 01:12:07,200 of cryptographic primitives, we could probably 1519 01:12:07,200 --> 01:12:08,460 get more functionality. 1520 01:12:08,460 --> 01:12:10,440 So what's the type-- we know, given 1521 01:12:10,440 --> 01:12:13,980 that we might want to apply this to different use cases, what 1522 01:12:13,980 --> 01:12:16,368 types of functionality might we need? 1523 01:12:16,368 --> 01:12:17,910 There's someone at the Media Lab here 1524 01:12:17,910 --> 01:12:22,470 who is interested in running algorithms on research trials. 1525 01:12:22,470 --> 01:12:26,377 And secrecy and privacy is really important. 1526 01:12:26,377 --> 01:12:28,710 I haven't even looked at his machine-learning algorithms 1527 01:12:28,710 --> 01:12:30,990 yet, but can we run machine-learning algorithms 1528 01:12:30,990 --> 01:12:36,090 on Pedersen commitments, or do we need something else? 1529 01:12:36,090 --> 01:12:38,193 Also, another really important area of future work 1530 01:12:38,193 --> 01:12:39,610 is to optimize the implementation. 1531 01:12:39,610 --> 01:12:42,060 Like I said, I think we get at least twice as fast, if not 1532 01:12:42,060 --> 01:12:43,500 more. 1533 01:12:43,500 --> 01:12:46,050 And in conclusion, yeah, if you want 1534 01:12:46,050 --> 01:12:48,300 to work on any of these things, please let me know. 1535 01:12:48,300 --> 01:12:51,210 If you're interested in using cryptographic primitives 1536 01:12:51,210 --> 01:12:53,250 to achieve privacy with interesting functions, 1537 01:12:53,250 --> 01:12:55,705 let me know. 1538 01:12:55,705 --> 01:12:58,080 And this is the website for zkLedger, which at the moment 1539 01:12:58,080 --> 01:13:00,300 is really just the paper. 1540 01:13:00,300 --> 01:13:04,500 We have a code base which is too embarrassing to be released out 1541 01:13:04,500 --> 01:13:07,050 into the real world, but we'll get there shortly, 1542 01:13:07,050 --> 01:13:08,250 once we clean it up. 1543 01:13:08,250 --> 01:13:09,590 So that's it. 1544 01:13:09,590 --> 01:13:10,787 So thanks for listening. 1545 01:13:10,787 --> 01:13:12,120 I hope you found it interesting. 1546 01:13:12,120 --> 01:13:15,170 [APPLAUSE]