00:00: Anna Rose:


Before we start, we want to say thank you to our listeners for coming along with us all the way to this special 100th episode. In general, we really do like to hear from you. So please get in touch with us and let us know what kind of topics you want us to cover for the next 100 eps. You can find us on Telegram, on Twitter, on YouTube, or you can email us. If you want to support the podcast, you can donate to the show either on Patreon, Gitcoin or directly. All of this info is in the show notes. And if you're new to the Zero Knowledge podcast, then I want to say welcome. Please do subscribe where you get your podcasts. We share new episodes every week and we would love to have you join us. So thanks again for coming along with us on this journey. For the last two years, we've been learning about blockchain tech, the decentralized web and the awesome emerging field of zero knowledge proof systems. It's been a wild ride, and at the same time feels like it's just getting started. So I would say stay tuned. So now on to our interview with Dan Boneh.


01:06:


Welcome to Zero Knowledge, a podcast where we explore the latest in blockchain technology and the decentralized web. The show is hosted by me, Anna.


01:16: Fredrik:


And me, Fredrik. All right. So I'm here with Anna and Dan Boneh, and this is a very special episode because it's our 100th episode. And I can't imagine a better person to have our 100th episode with, because we're sitting with someone who has invented much of what we're talking about and much of what the entire blockchain space is built on. So I think this is great. To many of our listeners, you're someone who doesn't really need an introduction, but perhaps it's best to lay some background work here. So Dan, who are you? How long have you been working in crypto and whatever related fields?


02:00: Dan Boneh:


So first, Hi everyone. It's great to be here and congratulations on 100 episodes. I'm really, really happy to be here. So let's see, so for background. So I've been working in cryptography now for a long time. I'm almost embarrassed to say it's almost, what is it? Over 25 years or so. It's a wonderful, wonderful, wonderful area. I really, really enjoy it. I've kind of... I got hooked on cryptography already when I was in high school. It was kind of clear to me, this is what I want to do with my life.


02:29: Anna Rose:


Ah, cool.


02:30: Dan Boneh:


It's a beautiful combination of very deep mathematics and real world problems. And people really care. So I'm a professor here at Stanford. I primarily focus on cryptography, computer security, and in the last five years or so on blockchains. Again, blockchains are such an exciting area for a cryptographer that it's been a lot of fun and I guess that's what we'll explore in the coming hour.


02:55: Anna Rose:


You say that cryptography was always this exciting field, but early on, what was the exciting parts and was it different parts? Do you feel like there's more and more industry involvement as time has passed? I'm just trying to picture what it was like then and what it's like now.


03:12: Dan Boneh:


Oh, absolutely. It's changed a lot over the years. So I guess when I started out, the field was mostly... Well, the field was kind of divided into two parts. There were the people who were trying to build secure systems and using cryptography for that. And there was a lot of kind of ad hoc experiments going on at the time. And then there was the theoretical community who was kind of laying the groundworks for what is a secure system. It turns out even just defining what is secure encryption, that actually turned out to be quite a difficult thing. And surprisingly, even for something as simple as symmetric encryption, right? So Alice and Bob have a shared key. Alice wants to send a message to Bob. How does she do that?


03:53:


Even for something as simple as symmetric encryption, it's only in the year 2000 that we had our correct definition for what is the right thing to do. What is it that we're actually trying to achieve? And for your listeners, I hope everybody knows this. This is called authenticated encryption, which is kind of the correct way to implement symmetric encryption today. So that was kind of being developed by more of the theory community. And what happened over the years, which I thought was really exciting, is this really thick bridge emerged between theory and practice, primarily because the ad hoc experiments that were kind of developed over the years, in many ways turned out to be, let me just say, kind of more exciting than we want them to be. So excitement is when things break, it's very exciting and we have a version, a crypto library now called Boring TLS, which the whole point there is to say cryptography is supposed to be boring. You implement it, it just works, it never breaks, and you never hear about it again.


04:48:


And in the old days, in some sense, cryptography was exciting, which is kind of experimental cryptography. I mean, it was a little too... Had a little too many attacks on it. And so there was a very thick bridge that was constructed between the theory community and the applied community. And now, for example, it's pretty much accepted that authenticated encryption is the only way you should be implementing symmetric encryption. There are very robust models for key exchange. And in fact, the development of the very recent development of TLS 1.3, I'm sure all your audience has heard about this. This is a huge development in the world of security and cryptography. That is an amazing success in that that whole protocol was designed using rigorous definitions and formal verifications of all the protocol steps, and it's a major, major advance. So TLS 1.3 is a much better protocol than the TLS versions that came before it, specifically, especially thanks to this thick bridge between the theory and the experimental community.


05:48: Fredrik:


Given this long history, at what point did you start seeing blockchain as being a part of cryptography? And what was your entry point into blockchain tech?


06:01: Dan Boneh:


Oh, yeah, that's a great question. So, blockchain is not just about cryptography, blockchain is kind of a combination of multiple areas. One of the things that's so fascinating to me is that it really is such an interdisciplinary field of research or more than research, I guess, interdisciplinary field. So obviously it involves cryptography, but it's not just cryptography. It's also distributed systems, economics, legal aspects and so on. So to me, I guess, boy, I don't remember the exact dates, but I guess, we kind of... Well, I guess we taught our first course on blockchains back in 2015, I believe. So that was kind of a while ago, and we have been teaching this course now annually. So I think right now we're teaching it for the fourth time.


06:53:


I have to say it's one of the hardest courses I teach. And the reason is, it's almost the exact opposite of teaching calculus. So when you teach calculus, well, I don't teach calculus, but if you teach calculus, the material doesn't change. That's material that was invented 200 years ago and that's basically what you teach. And blockchains, literally, literally, every year that we teach the course, it's a brand new course. It's remarkable that we have to kind of redo 75% of the course every year. And I'd love to talk a little bit more once we dive into education, I'd love to talk about the changes we made this year. So the attendance in the course is actually fairly robust. It's like over 100 students every time, although it does fluctuate. So it's kind of interesting that I'd say that enrollments kind of fluctuate with the price of Bitcoin. If we see over the summer Bitcoin goes up, attendance goes up. If we see over the summer the Bitcoins goes down, attendance goes down.


07:51: Anna Rose:


I was just thinking it must have been very... There must have been a huge wait list in 2017, late 2017.


07:57: Dan Boneh:


Oh my god, yeah, then we had over 150 students. Yeah, that was actually quite a large course.


08:03: Anna Rose:


Do you limit it, actually?


08:04: Dan Boneh:


No, no, no, no, no, no, no. None of our courses are limited. We have courses that don't. We have very, very large courses.


08:09: Anna Rose:


And then you also have Coursera, you have an online course.


08:12: Dan Boneh:


Oh, yeah, yeah. So actually, maybe it's worth talking about, as you can tell, I'm very passionate about education, particularly cryptography education. So maybe I can talk a little bit about what are resources that people can kind of use. In addition to the blockchain course, we also have courses that focus specifically on cryptography and computer security. So a cryptography course basically is just an introduction to cryptography. So actually we have courses at many different levels that I teach. So at the freshman level, these are students who are just coming in, starting...  And these are like 19 year old students just starting in and I'm trying to get them excited about computer security and cryptography. So we have a course, it's called 10 Ideas in Computer Security. It's half about security, half about cryptography. We have our introductory course to cryptography and then we have our graduate course in crypto.


09:00: 


Although I got to tell you, I have to tell you this funny story that happened to me a while ago. So I get this call from a reporter and she's telling me that she's writing a story about crypto education. So I say, great, that's what I do. Let's talk about it. And then she says, well, so how long have you been teaching crypto? So I say, well, I've been teaching crypto for over 22 years. And then the reporter is a little puzzled. Yeah, so then she asks...


09:26: Anna Rose:


Please Satoshi.


09:27: Dan Boneh:


But wait a minute, before 2009, there was nothing to teach. What did you teach before 2009? Yeah. So then that was, I was a little shocked. Yes, so then I had to kind of stop and say, wait a minute, cryptography, this is like an area that's like over 2000 years old. You know, the ancient Babylonians were already encrypting things. Yeah, so it was not invented in 2009. There was a lot to teach beforehand. And so, yeah, so... 


09:52: Anna Rose:


So this goes back to the crypto means cryptography, not cryptocurrency.


09:56: Dan Boneh:


Ah, well, yeah, that's true. That's true.


09:58: Anna Rose:


Or do you think...


09:58: Dan Boneh:


But actually, the word crypto, honestly, it's kind of now become, has two different meanings, right? I mean, it does mean cryptography to some people and it does mean cryptocurrencies to some other people.


10:08: Anna Rose:


Does that bother you? There's other people we've interviewed who are really bothered by this.


10:12: Dan Boneh:


Who are really bothered by that? You know, at the end of the day, a lot of this is applications of cryptography. So I don't mean to be... You know, what is it? There are enough battles to fight out there, I don't need to be fighting with mills. So if people want to use crypto for cryptography and cryptocurrencies, fine. I think it's better, of course, if crypto continues to mean cryptography, because that's the original use of the term. But if people are happy in expanding what it means, fine.


10:42: Anna Rose:


Do you also... I mean, do you consider what you're working on also cryptology? I heard that there was a distinction there. So cryptography, meaning the ability to encrypt and cryptology, encrypt and attack.


10:54: Dan Boneh:


Yeah. So I don't like those distinctions. So there's cryptography, which is sort of encryption and cryptanalysis, which is the attack, attacking crypto systems. And then cryptology is sort of the combination of cryptography and cryptanalysis. I think those distinctions are somewhat artificial in that the way we work is we try to construct a system and then we try to prove that it's secure. If we fail to prove that it's secure, we try to attack it. If we fail to attack it, we go back to try to prove that it's secure and we bounce back and forth and sometimes modifying the system as we go along. And so really to design... You can't design a cryptosystem without also knowing how to attack it.


11:34: Anna Rose:


Fair enough.


11:34: Dan Boneh:


So the distinction between the two fields is not that meaningful. A cryptographer needs to do both.


11:43: Fredrik:


So yeah, I want to jump back into this point on education, because I would want to make a part of this podcast about education, actually. I think it's a fascinating topic. But I would want to take a step back from where we were just talking and ask, what do you think the current state of both cryptography and blockchain education is today? Like, cryptography education is obviously widespread and exists in all universities across the world. Blockchain education, not at all. Like I think Stanford is in the forefront here.


12:15: Dan Boneh:


Oh yeah, for sure. Right, so like you said, cryptography education is actually fairly widespread. Maybe I should mention that, in fact, we have even this massive open online course. This is what's called a MOOC on cryptography, that in fact, a lot of universities adapted the material for the MOOC for their own local courses, which is everybody's... Material is public, everybody's welcome to learn from the course and also use it to design their own courses. So that's on the cryptography side. On the blockchain side, there are still a lot of... There aren't that many, like you said, there aren't that many universities that offer courses. And I think that's kind of unfortunate.


13:06:


Yeah, I think it's such an exciting area to teach that I would really encourage many, many more professors to actually offer those courses at their universities. One thing I would say is education has kind of changed a little bit over the past couple of years in that, first of all, all of our materials are available online. So anyone who wants to design a blockchain course, they're very welcome to come to our... to look at what we teach, they can steal all the materials, they can steal all our projects, our exams, our lecture notes, and are very welcome to just use it to design local courses at their universities. And I would say even everything that we do is recorded and made available. So if anybody, if a student wants to actually take a Stanford course on blockchains or on cryptography, go ahead, you can just sign up remotely. And we have students from all over the world who take our courses on, so everything is recorded and available for folks to attend.


14:06:


And so why do I find this...Why do I find blockchain so much fun to teach? Like I said, it's a hard course to teach. It's a hard course to teach because it changes from year to year. But what it does... Let's talk a little bit about what goes into a blockchain course. So I viewed a sort of a mix of a distributed systems class plus a cryptography class. So I kind of like to think of blockchains as a system that has four layers. Yeah, so the bottom layer is what I call the consensus layer. This is basically how do we take a sequence of transactions from the public or a set of transactions from the public and make it into an ordered sequence that all the participants in the systems agree on. That's what the consensus layer does. That's what layer... That's layer 1.


14:52:


The second layer, unfortunately, I have to call layer 1.5, which you'll see why in a second. So that's the second layer. It's layer 1.5 is what I call the compute layer. Sometimes this is called a blockchain computer. So here in layer 1.5, we can kind of assume that transactions have already been ordered sequentially and now we can build a computing environment on top of these transactions. So, Bitcoin has Bitcoin script as the computing layer. Ethereum has the EVM as the computing layer. You know, many other blockchains have their own computing layer. So that's kind of like... I kind of think this is kind of the equivalent of an operating system for a blockchain. We... I kind of like the name blockchain computer. So that's what I tend to use.


15:33:


Layer 2 is basically the applications that are built on top of the blockchain computer. Right? So these are all the stablecoins and lending platforms and all the DeFi that's been developed out there. And then layer 3 is basically all the user facing applications. So these would be like wallets and custody services and things like that. Right? So I kind of think of these as these four layers. And you notice that it has many, it spans many areas of computer science and beyond. So the consensus layer, of course, are distributed systems. The application layer has... The compute and application layer has a lot of cryptography that's built into it, including, by the way, zero knowledge and SNARKs, which is, I guess, what we'll talk about in just a minute. And then, obviously, the user-facing layer that has a lot of legal and business aspects associated with it.


16:20:


So in fact, every year... Obviously I'm not a lawyer, so every year I ask a lawyer to come in and talk about the regulatory environment for blockchains. So just a shout out, I guess this year we have the Chief Counsel of Anchorage coming to speak at our class about the regulatory environment. And of course the regulatory environment, that's like a fascinating area in its own right, especially what's happening in the world today, with Libra and now the Fed saying that they're gonna get into cryptocurrencies. So that's kind of a whole... That's like a whole class on its own.


16:48: 


Which, by the way, I should say, my class is designed for a computer scientist. So we focus on A, how the different layers work, but the students actually go ahead and build decentralized applications all the way from writing solidity contract, including the Web3 interface and so on. So all the way to the user facing parts of it. So, but it's designed for a computer scientist. There are also parallel courses being taught in the law school and in the business school that focus on completely different aspects of blockchain. Yeah. So, if your listeners happen to be faculty at other universities, this is an amazing opportunity for interdisciplinary collaboration. Like kind of creating a sequence of courses across the university is really, really rewarding. And we all get exposed to a set of topics that we're not really... That's kind of a little bit outside of our daily week.


17:39: Anna Rose:


Is there any other topic in cryptography where you've seen something similar? Where you've actually seen courses... I realize that these are related courses and they don't need to be taken in tandem, but it helps to know something about law and it helps to know something maybe on the business side or the token economic side. When it comes to other cryptographic concepts, have you seen anything like that?


18:02: Dan Boneh:


Well, that's the beauty of computer security. A lot of computer security is interdisciplinary. Right? So computer security obviously has a huge legal aspect around it. In fact, one of the courses we teach is legal aspects of computer security. It's computer security for lawyers. Yeah.


18:18: Anna Rose:


Oh, wow.


18:18: Dan Boneh:


Basically how the legal system... How the US legal system interacts with the technical computer security world. So that's kind of a...  So, you see that a lot in general computer security. But computer security, so it has obviously legal ramifications, there's a lot of psychology that goes into computer security. How do you get people to do things that harm their computing environment? So no, so a lot of this... Look, this is why I love this area. A lot of it really goes beyond computer science to other parts of academia, that's psychology, economics, and so on. So it's not unique to blockchains, but blockchains really amplify it.


18:52: Anna Rose:


What are those categories? So for blockchain, we've sort of mentioned there's computer science, there's legal, there's business...


18:58: Dan Boneh:


The business school, and economics.


18:59: Anna Rose:


And economics.


19:00: Dan Boneh:


Yeah.


19:01: Anna Rose:
Okay.


19:02: Dan Boneh:


Yeah. So right. So those are kind of the major parts.


19:05: Anna Rose:


Psychology is not included yet?


19:07: Dan Boneh:


Yeah, that's a good question. I'm sure that in time, psychology will be included as well. I guess there's a lot of... In computer security, there are the types of attacks that we call social engineering attacks, where I try to kind of... An attacker would try to make a user harm their computer by calling them up, and that's called social engineering, and convincing them to do things that they shouldn't, like telling your password, right? You shouldn't, but I can... Attackers can convince you to do it. So I don't know that we're seeing as much of it in the blockchain. So we see much more of it in computer security, but I'm sure in the long run psychology... Psychology rules everywhere. I'm sure in the long run, we'll see more interactions.


19:50: Anna Rose:


When you're teaching these students, do you feel like there's some students who are just so good on the engineering side, but maybe less talented on the theoretic side, on the math side? Are you trying to find students who have this perfect balance? What are you looking for when you're teaching these people?


20:09: Dan Boneh:


Oh, what a great question. Yeah. So even though our students are amazing, I kind of always impressed with what they're able to do. Obviously, there are some students who are more interested in coding and engineering, and there are some students who are more interested in doing proofs and focusing on math. This is why cryptography is such a wonderful area. It literally brings the two things together, right? So, well, if you're gonna be using cryptography, implementing cryptography, doing research in cryptography, there is nowhere around it. You gotta be able to do... Understand deep math, you gotta be able to do proofs. These days, a crypto system that does not have an associated proof of security is not a crypto system that we pay attention to, yeah? And so you have to learn how to do proofs.


20:54:


At the same time, I view crypto...Our introduction to crypto course, that's an applied course in that yes, you have to do proofs, but you also have to write code that implements everything that we learned. So I think it's one of the... I can't think of any other course where students literally, they have to deal with group theory and proving that certain things are correct. And at the same time, they have to implement and show that what they did works. I think this is unique. I don't know that that happens in a lot of different courses. And honestly, this is what attracted me to the field. I love both the system side of things, and I love both the mathematics of it. So this is what I do, why I do it, and this is why I view it as an applied course.


21:36:


So how do we deal with this dichotomy, right? It kind of takes the two sides of your brain, well, I don't know. It takes two parts of your brain to kind of do this. Well, the truth is that it's not that hard, right? I mean, if you... I'm a believer that if students are excited by a topic, they'll devote energy to understanding it and then they will understand how to do both math and implementation at the same time. So the goal is just to make people excited about the topic and understand that this is something that they need in the real world. When they graduate, these kids are going to be the ones building the computer systems that we are going to be using in the future. It is absolutely guaranteed that they're going to rely on cryptography... They're going to need cryptography no matter where they go, even if they go into blockchains for sure. But even if they go into building web systems and storage systems and such, they're going to have to use cryptography to protect the information.


22:34:


Yeah, so they're going to have to understand how to use it correctly, and they're going to have to understand how to implement it correctly. And so I think it's kind of easy to motivate students to actually get excited about the area, and also honestly, it's something that they haven't really seen before. And most of them haven't really seen a lot of this before. The kind of the types of proofs that are involved, the types of attacks that are involved. The amazing thing is, I can show them like here's how RSA signatures work. Looks perfectly reasonable to you, seems like it makes sense and it should work. And yet if you start thinking about it, you realize that if you implement it with one tiny bug, the whole thing is just completely insecure. It's just trivial to forge signatures.


23:12:


Yeah, there's this attack called the Bleichenbacher's attack on RSA signatures, which is a lot of fun to teach because you see this you literally see this thing works, right? You can sign, you can verify, everything works. It looks like it should be secure, and if there's this one check that you forget to implement, the whole thing falls apart, right? It just shows you how subtle and difficult it is to get it right. Yeah.


23:35: Anna Rose:


Cool.


23:35: Dan Boneh:


And students need to understand that.


23:37: Fredrik:


This is something that sort of actually kind of kept me out of crypto when I was in college because there's like, I had worked in engineering for a long time before college as well. And when you're talking to programmers and talking in engineering, there's this mantra of don't roll your own crypto. Everyone says don't roll your own crypto all the time everywhere. And I think it's sound advice.


24:00: Dan Boneh:


Oh, I'm gonna go, I'm gonna take it a step further. So don't roll your own crypto typically refers to don't invent your own crypto, which is absolutely right. You should use standards. You should use the things that the community has vetted. Absolutely right. There's another step to that, which is typically don't even try to implement your own crypto. Because it's...


24:19: Fredrik:
Yeah, that's what I take it to.


24:21: Dan Boneh:


That's right, that's right. It's one of those things where, if you're at a company and somebody comes to you and says, ooh, I made our crypto library 20% faster. This is great. The answer should be no, you probably made it vulnerable to a timing attack, right? There's a reason why these things are implemented the way they are. And so even when implementing crypto correctly is counterintuitive, and typically you should be using standard libraries that a lot of people have vetted, looked at, and tried to break and couldn't. And that's what should actually get deployed.


24:55: Fredrik:


But how do you then balance that with getting people into the field if you're always telling everyone to not do anything in the field?


25:03: Dan Boneh: 


Well, I mean... No, that's a very fair question. But the fact is that to know how to use a library correctly, you have to understand what the primitives are and how they're supposed to be used. The typical example is, actually this is something that just came out in iOS 13, right? So Apple has this, what is it called? The crypto object that's supposed to be used by applications to encrypt. And before iOS 13, their interface was fairly complex. Yeah, you have to specify the initialization vector, the IV, you have to specify the mode of operation for your encryption scheme. And most developers just didn't know what to write there. So they just ended up Googling and went to Stack Overflow, found some sample code and just pasted that into their application. And it turned out that sample code was just incorrect. Yeah, it told them to use ECB mode for encryption and to set the IV to null and that's just incorrect.


25:58:


So unless you understand what the parameters are, it's very likely you're gonna use the library incorrectly. Which by the way, is kind of interesting. This also goes to API design, which is in crypto, one of the... That's also been my mantra in that we should keep our APIs boring as well, right? It should be like literally encrypt key and message. It shouldn't be, the API should... The basic API should not have all these bells and whistles where you can specify the mode and the IV and so on and so forth, right? So one of the things that happened in iOS 13 is Apple greatly simplified the crypto API. So now it's a lot harder to get it wrong. Yeah, so we definitely should see more of this. But my point is, no matter what library you're using, you need to understand what the primitives do so that you can use the library correctly.


26:43: Fredrik:


Yeah, moving on to zero knowledge stuff, which we've already touched on a little bit. You know, I think zero knowledge crypto has become a really hot topic over the past year, two years. Maybe there's also been a ton of development happening recently also in your own work and what your group is doing. How does zero knowledge fit into the field of cryptography? And why does zero knowledge tech seem so important, especially to blockchains?


27:12: Dan Boneh:


Oh, fantastic. Yeah, so I'm really excited about all the developments that are happening in zero knowledge. So by the way, one thing that I promised to come back to earlier, so let me do that now, is one of the new things we're doing in our blockchain course this year is I just believe because SNARKs have become such a vital component of blockchains, that we're now developing... Devoting three weeks of the course just explaining how SNARKs work...


27:37: Anna Rose:


Amazing.


27:38: Dan Boneh:


And how to use them in blockchains. Yeah, so we've made space, we've had to kind of compress other things specifically to make much more room for SNARKs. And by the way, we're gonna make all that content available on the internet for free. So if anybody wants to learn about SNARKs, come back in a few weeks and all this information will be available on the web.


27:55: Anna Rose:


Will this SNARKs course be specifically for computer science students?


27:58: Dan Boneh:


Yes, yes, absolutely.


27:59: Anna Rose:


Okay. Because I've always understood you can teach SNARKs for computer science, you can teach SNARKs for cryptography.


28:05: Dan Boneh:


You can. I tend to teach computer scientists. For sure, there's room to do a blockchain class for non-computer scientists. Actually, you're making me think that this is maybe a good idea for me to do in the future. So, but right now, the course is designed for computer scientists.


28:21: Anna Rose:


Got it.


28:21: Dan Boneh:


So the plan is we're gonna dive exactly into how SNARKs work. And by the way, this has become such a fast-moving area. There's so many new ideas coming up that we could actually teach a whole course just on SNARKs. But this year, we're just gonna focus on kind of the main techniques. So why do I think that SNARKs are so important for blockchains? Well, there are two killer apps that make them really important. So the first one is a blockchain... All the data on the blockchain is public. Yeah, if it's a public blockchain, the whole world sees it, but even if it's not a public blockchain, the participants in the network see all the data on the blockchain. Often that means that businesses cannot use it, right?


29:05: Anna Rose:


Totally.


29:05: Dan Boneh:


So you cannot have your private confidential business data stored in a public blockchain. The typical example I like to give is if Ford wants to pay their tire suppliers using a cryptocurrency and how much they pay is written on the blockchain, that just means that Ford can't use it.


29:25: Anna Rose:


Because anyone who they pay could then see what else they've paid in general...


29:30: Dan Boneh:


For sure.


29:30: Anna Rose:


And what they're going to be paying in the future to other suppliers or to other... 


29:33: Dan Boneh:


For sure. Or in fact, all of Ford's competitors will see exactly, I'm just speaking on Ford at random, will see exactly how much Ford is paying for their tyres. 


29:40: Anna Rose:


Totally.


29:41: Dan Boneh:


Which is not something that people want to make public.


29:43: Anna Rose:


But at the same time, this transparency, this is a topic by the way that I find super fascinating, this balance of transparency and privacy. But transparency is a good thing as well. Like the fact that you can see this ledger is actually the benefit of a blockchain.


29:57: Dan Boneh:


I'm so happy you said that. I'm so happy you said that. So the properties of a ledger is A, you have public verifiability and transparency, right? Public verifiability. Everybody can tell all the transactions are correct. At the same time, public verifiability and transparency make it so that businesses simply can't use it. The other example is if a business wants to pay its employees in a cryptocurrency, their salaries would all be public to the world, which is not workable.


30:22: Anna Rose:


Totally. And even like what they do after with those tokens could somehow be traced.


30:27: Dan Boneh:


By the way, I was always thinking there's a kind of an interesting sci-fi novel to write, which is how would a society function if literally all transactions were public to the whole world? What would happen? And I guarantee you the first thing that society will do is it will create human mixnets, right? So if you want to buy potatoes and I want to buy tomatoes, we'll kind of... I'll buy your tomatoes and now you'll buy my potatoes. We'll kind of mix the coins ourselves. Yeah.


30:52: Anna Rose:


Interesting.


30:52: Dan Boneh:


Because humans just fundamentally don't... There's kind of a need for privacy in our financial transactions.


30:59: Anna Rose:


I almost feel like with the advent of social media, there was this moment where it was almost like an experiment or a belief that actually we don't need privacy anymore. All of a sudden people felt I can share everything with everyone. And I feel that now we're seeing the repercussions of that.


31:15: Dan Boneh:


Backlash.


31:16: Anna Rose:


And basically things that previous generations learned also firsthand, this generation is now learning, oh wait, sharing everything. There are problems with that. There are unforeseen consequences of having all of your information out there.


31:31: Dan Boneh:


Very interesting. Actually, I think it's an interesting thought experiment. I would really encourage your listeners, just think, what would a society... How would you function in a society where literally all transactions are public? Yeah, it's an interesting thought experiment. But anyhow, so there's this conflict. There's a need for transparency and verifiability on the one hand, and there's a need for privacy on the other hand. This type of conflict is exactly the type of conflict that cryptography can help resolve. And the tool to do it is zero knowledge and SNARKs. And this is why it's such an important tool. So what it allows you to do is effectively people can post commitments to the blockchain rather than posting the data in the clear. And then if they want to prove that transactions are valid, they just attach a zero knowledge proof to say yes, this transaction is valid. And anyone can check the zero knowledge proof, convince themselves that the committed data actually corresponds to a valid transaction without learning what the committed data is. 


32:26:


Yeah. And the same thing for transparency. If you want to prove that you followed certain rules, you can just attach a zero knowledge proof to your... Not just to all your transactions. And by the way, this is not just payment transactions, this could apply to dApps as well, you can just prove that you're following the protocol and do that all in zero knowledge. So SNARKs, I believe they are such an important tool because they help resolve this fundamental conflict in blockchains. They help us move from a totally public blockchain to a private blockchain while preserving all the properties of transparency and public verifiability.


33:02:


So, definitely zero knowledge proofs can provide privacy for transactions, but it goes much beyond that in that they can provide also privacy for dApps, right? So that whenever you post data to a dApp, you don't have to actually reveal what the data is. You can post commitments and just prove that the dApp processed that data correctly. So there's a lot of potential. It's not just about privacy. It's about... I would say it more generally, it's about resolving the conflict between public verifiability and privacy. That's what they do. So that's one thing. So that's a huge, huge deal on its own. And that's why I think SNARKs are so important. But SNARKs actually let you go... Those are, by the way, zk-SNARKs, the ones that are zero knowledge. SNARKs by themselves don't have to be zero knowledge. 


33:44:


And the other... So that's the other aspect that they provide, which is scalability. So there are beautiful projects like rollup, and I guess you already covered Coda in a previous session.


33:55: Anna Rose:


Totally.


33:55: Dan Boneh:


But I don't know if you talked about rollup in a previous session.


33:58: Anna Rose:


Well, just recently we had an episode with Georgios, Tarun, and James Prestwich, and there we touched on rollups, but I'd actually like to do an episode just outlining the different kinds of rollups.


34:10: Fredrik:


Yeah, we've already... We've also talked to Matter Labs, who's doing a version of rollup.


34:15: Dan Boneh:


Oh, right, right. Yeah, yeah, we're working with them too. So rollup is, maybe I could just summarize it quickly.


34:20: Anna Rose:


Sure.


34:21: Dan Boneh:


So rollup is a way to scale up the blockchain where instead of sending transactions directly to the blockchain, you send transactions to the rollup server. The rollup server aggregates thousands of transactions, verifies that they're all correct and then posts that up to the blockchain. And I guess you mentioned there are now multiple types of rollup services. So there's optimistic rollup where security is enforced by staking. And then there's a zero knowledge rollup, actually not the zero knowledge, the SNARK rollup, where security is maintained by crypto. So I want to focus on the SNARK version of rollup. 


34:55:


Yeah, so there the idea is that these thousands of transactions are submitted to the rollup server. The rollup server will verify all the signatures, will verify that the transactions are valid relative to current account balances, and then just post a proof, a short proof, that those transactions are all valid and all the contract on the blockchain needs to do is just verify this one simple short proof and you verify thousands of transactions at once. Yeah, so this is pretty cool. This is really, really cool. Very beautiful application of SNARKs. And actually it takes us into something that we've been working on.


35:30:


So right now they are limited to, because of the time to produce these proofs, they are somewhat limited in the number of transactions that you can handle per block. So one of the things that we're working on, this is with two of my students, Riad Wahby and Alex Ozdemir. We are working on basically improving the proof generation time, so that we can dramatically scale up the number of transactions per block. We can get, and already our system shows that you can go up by an order of magnitude beyond what's available today. Yeah, so same proof generation time, just handling an order of magnitude more transactions per block. Again, this is an amazing application of SNARKs in that you kind of outsource the job of verifying transactions away from the expensive blockchain into an offline service and the service can then prove to the blockchain that things were done correctly.


36:25: Fredrik:


A thing that really scares me about zero knowledge tech actually is going back to what you were talking about before with crypto is supposed to be boring. It's not supposed to be exciting. And we're talking about SNARKs, which have been around for a while and kind of battle tested on Zcash and other things. But then like this year we've had Sonics and then we had Halo and now we have Supersonics and it's just like project after project and it's moving so quickly. How do you actually ensure that these things are correct, that they're reviewed, battle tested, that it's actually ready for adoption into a critical system?


37:04: Dan Boneh:


You know, so the state of SNARKs today is not exactly where we want to be. So there are


like five or six different directions for building SNARKs. Maybe just to mention them, there's like MPC in the head, there's like GKR like systems, there's the GGPR methods, STARKs, Bulletproofs, there's like different, I kind of think of them as like different trains for building for building SNARKs. Yeah, and each one follows a very different technique. And the problem that we're having is each one is good in its own way. Yeah, so just to give an example, Bulletproofs, for example, gives the shortest proofs without trusted setup. The GGPR methods give the shortest proofs with trusted setup, right? So if you don't like trusted setup, you have to use Bulletproofs. If you're okay with trusted setup, you can use the GGPR methods or Groth16 methods.


38:05:


And so like every... And the same is true for the other methods, right? Some of them have better prover time, some of them have better verifier time. So every method kind of shines in its own dimension. What we would love to have, yeah, and I hope we'll get there. What we would love to have is like, one SNARK to rule them all. Yeah, just like in Lord of the Rings. Yeah. We'd love to have one SNARK that's better, that's like best in all dimensions. That's the one SNARK that we would teach, that's the one SNARK that we would implement, and that's the one SNARK that we would all use and make sure the implementation is robust. We're not there yet. Yeah, different SNARKs are good in different dimensions. And so I hope... This is an open problem, I hope your listeners can help us solve this. And so today, basically, it's a very, very exciting area of research, right? So like every week there's new ideas, new results.


38:57:


As you mentioned, I mean, even my students put out Supersonic just last week. Actually, this week, I think. They're posting the paper. So very, very, very exciting area. I think if we wait just a few years, I think we will get to this one SNARK to rule them all. And that's the one we will focus on. Right now, the one that's being most widely deployed are the Groth16 methods. So this is in the Bellman Library, in the Circom and so on. Which by the way, in our course, we're also going to be doing like a hands-on Bellman project. So our students are going to have to learn how to write R1CS code so they can actually implement SNARKs themselves for Bellman.


39:39: Fredrik:


Nice.


39:40: Dan Boneh:


So if people are looking for projects to do, just go to our website and do the project yourself and you can learn how to write R1CS code yourself. And so, right now those are kind of the...  That implementation of Groth16-like methods. That's kind of the, as you said, battle tested implementation. That's what many of the projects actually use. But in the long run, things could be a little different. Right now, it's an active area of research. And by the way, that happens all the time. That happens in a fast-moving field. There are new ideas coming up, and it takes a while for the implementers and developers to actually go ahead and write battle tested implementations. It's just early in the development of this applied field.


40:28:


Even though I have to say, one of the fascinating things is zero knowledge is not a new concept. Zero knowledge dates back to the 80s, right? It's just for many years, it was considered this theoretical application. There hasn't been... It was a little bit of a struggle to kind of find a real world application for zero knowledge and then blockchain is kind of burst on the scene and they're like the perfect application.


40:50: Anna Rose:


Totally.


40:51: Dan Boneh:


Perfect, right? This is the perfect match. And because it's such a perfect match, all of a sudden, everybody's interested in building the best one and making it work in practice. And the minute you have a real world application, that's where all these beautiful ideas and people's focus comes up, and that's why we're seeing so much development now. But it's a lot of fun. I mean, that's kind of what makes this exciting, right?


41:12: Anna Rose:


What would you say, though, to a team? Because I've actually met a few blockchain company teams who are looking to implement zero knowledge proofs, but they don't know where to start. They're kind of like exactly what you're saying with this boom of new concepts coming out. They don't know which one to kind of latch onto. So would you give them the advice to wait?


41:32: Dan Boneh:


No, no, no, no, no, no. You don't want to hold up progress just to wait for the community to find the best SNARK. Let's see. So first of all, I should say, come talk to us. We're happy to help. We talk to a lot of projects.


41:49: Anna Rose:


Cool.


41:50: Dan Boneh:


And in fact, a lot of our research is based on problems that projects pose to us. That's one option. The other option is, of course, hire people who can help assess which zero knowledge method is best for you, for your particular project. And if you're kind of a black box user of SNARKs, well, there are already fairly good implementations that they do require trusted setup, that do require, prover time is not ideal and so on. But there are implementations like Bellman and such that a lot of projects actually use. So the implementations are getting more robust, but they're a little bit… They're falling behind the latest developments in the theory of SNARKs. So there's gonna be a little bit of catch up to do. But the other interesting thing is, you could try to use whatever is available today as in your project. And then, if a new SNARK gets developed later, essentially, you can swap it in if you're okay with a hard fork to swap it in. But that's always another option.


43:02: Anna Rose:


Is there any fear, I mean, in these new constructions that have come out, is there ever a fear that like, there isn't enough peer review, that there isn't... There's so few people that actually know how to gauge this stuff that proper peer review isn't necessarily happening and some narratives or some ideas might be taking hold, which are not completely correct.


43:24: Dan Boneh:


You know, the truth of the matter is these are complex systems to implement, right? And so whenever you're dealing with a complex system, you know that there'll be issues down the road. Yeah. And so it's quite possible that your project might use a SNARK implementation today and later on it will turn out that there were bugs in the implementation and the SNARK is not as sound as you would hope, or maybe is not as private as you would hope. In fact, we know that this already happened a couple of times in the real world. And so the best thing to do is just design your project to prepare for that, right? So, a SNARK has two security properties, right? Soundness and zero knowledge, right? So zero knowledge is the privacy property.


44:12:


And your implementation could end up breaking either one. And in fact, we've seen examples in the real world where in one case soundness was broken, in the other case, zero knowledge was broken. Yeah, and so the only thing, the only advice I can give there is, well, these are complex systems, and when you design your project, you should just design in a process to handle those kinds of bugs. So if there's a soundness... But a soundness vulnerability is the more dangerous one, because soundness could actually lead to money being lost or money being created. So that's actually quite a dangerous effect. And so you need to prepare for a hard fork to recover from those kind of soundness bugs. The zero knowledge bug is mostly affecting people's privacy, which of course could be equally devastating. And there, what can I say? You just need to, just your project needs to be prepared to handle those kind of issues.


45:06:


But I can't... It's not exactly, the SNARKs are not the ones that should be taking the brunt of the heat here, in that consensus is also extremely complicated to implement correctly in the real world. If you have consensus bugs, you also have issues with money being lost or created. And many projects are prepared to deal with consensus bugs by hard forking and fixing them. So I don't think it's fair to say that SNARKs are especially vulnerable. I think this whole ecosystem of blockchains, it's just a complex system. And whenever you have complex systems, you have to be prepared for major vulnerabilities that you have to address.


45:45: Anna Rose:


But going back to that question of, but specifically of peer review though, is that, I mean, throughout all of those systems, how does it work right now? Is it just sort of the traditional academic peer review on some of the academic papers? The reason I'm asking is because there's so much work also coming out of industry. It's not necessarily vetted in the same way, I guess. I wonder what you think of that.


46:07: Dan Boneh:


Yeah, this... I know, it's a bit of a... Because it's a young area, it's a bit of a problematic topic to end... Question to answer in that, in the traditional computer security world, there are companies whose whole business model is just to help other companies assess the security of their software. Right, so there are lots of companies who will do security reviews for you. In the world of blockchains, some of these computer security review companies have also morphed into doing blockchain reviews. So they will review your Solidity Code and review your consensus protocol. In the area of SNARKs, it's much harder for them to find people to do reviews because it's such a specialized area. And there are not that many people who are versed in it.


46:53: Anna Rose:


It's interesting because here the way that we're talking about peer review is like the audits, basically. It's companies auditing rather than sort of that academic. I'm not in academia, but the way I've understood peer review, where you'd actually send papers out to other academics who would basically say, yes, this follows what it needs to in order to be considered acceptable research. Without that, we are more dependent, I guess, on these auditors and firms, the security firms.


47:22: Dan Boneh:


Well, I mean, there are two types of audits, right? Obviously when a new SNARK system is developed, there is a peer review to make sure that the system itself is correct and robust, that the proofs are hold. Otherwise the SNARK would not be published. So that's like a peer review of the paper. But there's a separate audit, which is once the system gets implemented, you wanna audit the code that actually implemented that system... That actually implements that system. And then that is something that is much harder to do. I'll tell you, the reason academics and PhD students don't like to do that as much is it's harder to write papers about that, right? So publish or perish, I mean, students have to write their PhD dissertations. If they can't... If what they do doesn't lead to a publication, it's not worth their time to do. And so I think it's... So security reviews of crypto code is not something that we should rely on PhD students to do because that's not what they're here for. It really should be these professional auditors that do and they, honestly, they just need to build up the expertise to do it.


48:31: Anna Rose:


So we've covered a lot throughout this episode on education. Now we've been talking a little bit about peer review and the zero knowledge space and where's zero knowledge, how's zero knowledge fits into sort of the general cryptography space. But I want... Like, Dan, you've been involved in so many blockchain projects, and what I'd love to hear about are any kind of blockchain projects, zero knowledge projects that you're excited about right now.


48:54: Dan Boneh:


Absolutely. Yeah, I'd love to. First, I should say I'm full-time at Stanford. So what we do... The way we work is projects come to us with interesting research questions and then we help solve those questions. So that's how I love to work. And in fact, many of the papers that we write are motivated and driven by fascinating questions that the projects come and ask us. And I have to say, this is why I love the blockchain space so much, because the questions that it raises, that the projects raise, are questions that have never been asked before. And so for us, it's wonderful, wonderful to work on them. So since we've talked about zero knowledge, maybe I can talk a little bit about projects that we're doing that are related to zero knowledge, and then maybe we can kind of veer off to other directions. 


49:37: Anna Rose:


Sounds good. 


49:37: Dan Boneh:


Yeah, so one project I wanted to mention that we did recently is a system called Prio. This is a system for privately collecting telemetry data. So it has applications in blockchains, but the main applications is a bit outside. And so let me explain what that means.


49:55: Anna Rose:


Actually, yeah, what is telemetry?


49:58: Dan Boneh:


Oh, excellent.


49:59: Anna Rose:


You can start there. Sorry.


50:00: Dan Boneh:


Yeah, yeah, absolutely. Absolutely. I'll explain. So in the past, when a factory made a product like a car or a cell phone or a toothbrush or something, it would roll off the factory floor and then the manufacturer would never ever hear back from the product. Right? So Ford makes a car, they would normally never hear back from the car. That has changed. Today, all products are connected, and as a result, they constantly can send data back to the manufacturer. So cars constantly now connect back to Ford, to the manufacturer and they send data back. Cell phones obviously connect back to the manufacturer. When you run a browser, it connects back to the browser vendor and sends telemetry data back. Telemetry means basically how is the product being used.


50:41: Anna Rose:


Okay.


50:41: Dan Boneh:


Even your toothbrush, right? If you buy an IoT toothbrush, that's gonna send data back to the manufacturer. And the reason the manufacturer wants to collect all this data is so they can make the product better. Right, so for them, it's actually a treasure trove of data that they can use. So you can see again, there's this problem here that the manufacturers wanna collect data on how customers use their product so they can make it better, but at the same time, there's obviously privacy problems here, right? If my car sends data back, all of a sudden the manufacturer knows where I am at any given time and how exactly I use my car. Same thing with cell phones, same thing with browsers. I don't want my browser reporting which websites I go to to the browser vendor. So that's called the telemetry data.


51:27:


So again, there's this conflict, right? They would like to collect aggregate data of how customers use their product. They don't care how you specifically use the product, but they want to know how many people drive with their tires underinflated. They don't care if you drive with your tires underinflated, they just want to know what fraction of the population drives with tires underinflated.


51:47: Fredrik:


By the way, I think this is highly relevant in the blockchain space in the sense that when we are building blockchain clients, we want to know how people use those clients, how many people run an Ethereum node.


52:00: Dan Boneh:


Oh, yeah. For sure.


52:00: Fredrik:


We have no way of finding that out because we have made the decision early on that we are not going to let the client phone home. We don't want people's data. And so we kind of don't know how people use our software and how they run their clients, with what configurations, et cetera. So it's really hard to design a good blockchain client because we don't know how people use them.


52:22: Dan Boneh:


Yep, so you're making the case here. So you're saying layer 4 is basically the client-facing layer and that actually, there's a need for telemetry there as well. But my point is all they care about is aggregate data. You don't care who's using, who's running a full node, you just want to know how many people run a full node and so on. And so that's what the Prio system does. Yeah, so the Prio system is basically a way for companies to collect aggregate information without ever learning anything about the underlying data other than what's revealed by the aggregate collection.


52:59: Anna Rose:


Does this go back to that point we were talking about before where there's the transparency and the privacy? So a certain amount of information is delivered through, but true privacy is still maintained.


53:09: Dan Boneh:


The way I would say it is exactly right. You're right on target in that there's a conflict here between utility and privacy, and crypto is one way to resolve that conflict. There are other ways, by the way. There is something called differential privacy. There are other techniques, but crypto is one way to help resolve that conflict. And so, in just a few sentences, let me explain how the Prio system works. And then I should say that this is actually getting deployed. Yeah, so there is like, by now there are companies out there who are deploying Prio. And I think a lot of your listeners are already using it.


53:48: Anna Rose:


Is Prio a company by the way, or is that a protocol?


53:49: Dan Boneh:


No, no, no, no, no. Prio is a protocol. It's a project that we did here and is available... Everything we do, by the way, is available. Anyone can use it, take our code, run with it. So yeah, all of this is stuff that's available.


54:03: Anna Rose:


Cool.


54:03: Dan Boneh:


There's an implementation available too. Okay, so how does it work? Well, effectively, what happens is whoever's collecting the aggregate data needs to run... It relies on two non-cooperating servers. Yeah, so two or more. So effectively, let's just stick with an example of two. Yeah, so you have to keep... Yeah, so the company would have to partner with someone who basically functions as an auditor and is not gonna share information with the company. Yeah, so that's a strong assumption to make, but that's what the system needs to scale to millions of users. And then what happens is every customer, like if you're talking about a browser, the browser user basically will send encrypted data to the two servers. And once the millions of customers send their data over to these servers, then the aggregate encrypted data can somehow be combined together, so that the aggregate results becomes available in the clear without revealing anything else about the underlying data.


55:13:


It's not quite homomorphic encryption. It's actually based on a.. So homomorphic encryption would not scale to millions of users. This has been the... Let's say, our goal was to support hundreds of millions of users, and as a result, we use an information theoretic mechanism. It's actually based on secret sharing. And I can tell you that the difficult problem to solve was, well, if you're not seeing every individual's contribution, how do you know that people are not sending you junk data and ruining the aggregation process by doing it? For example, if you're trying to count how many people are driving with underinflated tires, well, one person who wants to mess with you can send you instead of saying sending zero or one. Yes, I have underinflated tires or not, they can send you like a million or minus a million. They can send you values that are way out of bound. Yeah. And so the connection to zero knowledge is what we had to do here was effectively have people send secret shared data, but then provide a zero knowledge proof that the data actually is within the allowable range, for example.


56:19: Anna Rose:


Interesting.


56:20: Dan Boneh:


So if a company wants to collect a bunch of traits like this, so every customer sends encrypted vectors of zeros and ones, and then there's a zero knowledge proof that proves, yes, all the values here, you don't know what they are, but you can convince yourself that they really are binary, either zero or one.


56:38: Anna Rose:


That they've acted correctly.


56:39: Dan Boneh:


Exactly. So we had to develop a new zero knowledge mechanism that's specifically designed for proving facts about secret shared data. Yeah, and the mechanism is actually, something that's underlying many, many of the SNARK constructions. So this is something called a Linear PCP. And I don't know if you covered Linear PCPs in previous sessions. 


57:02: Fredrik: 


Not, really.


57:02: Anna Rose:


Don't know that we covered it.


57:03: Dan Boneh:


Oh, really. It's a really, really important term now in the concepts of SNARKs. This is how to understand, actually, it helps you understand how SNARKs work, and it helps you also understand how the Prio system works. It's kind of a very, very powerful, unifying concept. So what's a Linear PCP? It's, by the way, due to Yuval Ishai and his collaborators, very, very powerful concept. So let's see if I can explain it in two sentences. See, that's a challenge for me. So what is a Linear PCP? A Linear PCP is basically a funny type of proof. Yeah, so I can send you a proof. A proof is literally just a string of numbers. Yeah? And the only thing you're allowed to do with that proof is you can specify a vector of the same length as the proof I send you. And what you get to see then is the inner product of those two vectors, the proof vector and the query vector. Yeah, and so the prover submits this proof vector, the verifier submits a number of query vectors, and the verifier then gets to see the inner product of the proof vector and the query vector.


58:11:


And then based on the responses, the verifier says, yes, I believe this proof or no, I don't believe this proof. And the amazing thing is that the proofs don't need to be very large. They're linear in the size of the statement and the verifier doesn't have to issue many queries. In fact, a constant number of queries is sufficient to verify a proof.


58:30 : Anna Rose:


What does the PCP stand for?


58:32: Dan Boneh:


Ah, good. 


58:32: Anna Rose:


Is this proof?


58:33: Dan Boneh:


No, no, no. It's probabilistically checkable proofs because the queries are probabilistic. And this is one of the beautiful applications of probability of randomness that you can verify very complicated statements very efficiently using randomness.


58:48: Anna Rose:


And what is the linear part of that?


58:50: Dan Boneh:


Yeah, the linear is the fact that the queries are linear queries, so that the response to the query is an inner product of the query vector and the proof vector. Yeah, so that's what it stands for, that's what a Linear PCP stands for.


59:00: Anna Rose:


Would there be... What's the opposite of a Linear PCP? Or not opposite, but what's the variation?


59:04: Dan Boneh:


Yeah, so the other type of a PCP is what I would call a Point PCP. So a Point PCP maybe is a more natural one, where I can provide a proof to you, and then you ask me... You're the verifier, so you ask me, open position number 34 on the proof. Yeah, point number 34. Show me what's in position 34. Show me what's in position 217. Yeah, and so those are traditional PCPs, which now I would call point PCPs because you're opening points. So for example, STARKs are based on point PCPs.


59:35: Anna Rose:


That was actually my question, because I know that there's a part of STARK construction where you actually take a sampling.


59:40: Dan Boneh:


That's right. So the whole FRI method, that's all based on looking at particular points inside of the proof. But if you step back, it turns out a lot of these point PCPs are themselves based on Linear PCPs. So yeah, so Linear PCP is actually really quite a powerful concept.


59:56: Anna Rose:


Cool.


59:57: Dan Boneh:


Right, so in a PCP the verifier is random, it's very important that the verifier be random, and let me give you a quick example of the power of randomness. So the typical example would be, if I give you a polynomial of degree 10 in a black box, and the only thing you're allowed to do is evaluate the polynomial at points of your choice. Your job is tell me if this polynomial is identically zero or not. Yeah, that's the only thing you're trying to do. It turns out you can query the polynomial at many points, but if you do it deterministically, it's actually not so easy to determine if it's a zero polynomial or not. You would need at least 10 queries. With randomness, it's quite easy. All you do is you choose one random point, and you ask whether the polynomial in the black box is whether the result is zero or not at the random point. Because you know that a polynomial of degree 10 has at most 10 zeros, the probability that you hit one of those zeros is very small. It's 10 over the size of your field.


1:00:58: Anna Rose:


I get it.


1:00:58: Dan Boneh:


And so if the answer is non-zero, you're guaranteed the polynomial is not the zero polynomial. If the answer is zero, you'll make a mistake with relatively small probability.


1:01:07: Anna Rose:


But it's interesting there, even in that example, because there is a chance you do hit one of the 10.


1:01:12: Dan Boneh:


For sure. Yeah, yeah, yeah. So absolutely. This is why there's always a soundness error. But if we can derive... This is called a soundness error, where you make the wrong determination. But effectively, we can drive the soundness error to be as small as we want by making the field sufficiently big.


1:01:30: Anna Rose:


Got it.


1:01:30: Dan Boneh:


And so you'll see in a lot of these constructions, there's always a trade off between soundness and the size of the field.


1:01:36: Anna Rose:


Cool. And actually, on the topic of randomness, we had Justin Drake from the Ethereum Foundation on the podcast like six months ago or so. And he actually talked about the importance of randomness and how this could be used. If any of our listeners are interested in this topic in particular, I'm going to put the link in the show notes.


1:01:52: Dan Boneh:


Great. And I should say, by the way, that even though now we've made the argument for randomness, it turns out in many situations we can actually remove the randomness using a heuristic called the Fiat-Shamir heuristic, which then lets you basically generate the randomness using a hash function, which makes the protocol non-interactive. So even though randomness is crucial, when you come to actually implement these things, often we can simulate the randomness using a hash function.


1:02:20: Anna Rose:


Nice. Do you have any other examples of projects kind of in the zero knowledge field that you're excited about right now or working on right now?


1:02:27: Dan Boneh:


Yeah, we have a couple also in the blockchain space, but let me give you one that I'm kind of excited about that's relevant to blockchains, although is applicable more widely. So this is a system called True2F. So here we were quite worried about supply chain attacks. So what happens? I'm sure you've heard of this board that ended up in Apple and Amazon that turned out to have an extra rice grain chip, a rice grain processor on it that actually opened up a backdoor. And so that's an example of a supply chain attack. Now whether... So yeah, so you buy a machine, it comes to you from somewhere in the world, and it turns out it's got extra hardware that opens up actually a backdoor on your system. I guess, the application here to blockchains is if you buy any of these Ledger or Trezor, any of these wallet hardware, how do you know that the wallet hardware actually implements what it's supposed to implement? Maybe somebody put some other chip inside of the hardware device that opens it up the backdoor. 


1:03:34: Anna Rose:


This is like supply chain, like a factory somewhere.


1:03:36: Dan Boneh:


Exactly.


1:03:37: Anna Rose:


It's not even the manufacturer themselves, but that someone malicious had access to their supply chain.


1:03:43: Dan Boneh:


Yeah, exactly. So you buy a part from someone. How do you know that that part doesn't have extra chips in it that opens you up to... Opens a backdoor on your system. Right? So we were particularly worried about this for these second factor authentication tokens. So, you know, what are called U2F tokens, Universal 2nd Factor. And so traditionally, I'm sure you're familiar with U2F tokens. I'm sure a lot of your listeners, you use U2F tokens, right? So these are like devices like the Google Titan chip and YubiKey and so on and so forth.


1:04:13: Fredrik:


I hope everyone uses a YubiKey. I'm not sure how many actually does, but yeah.


1:04:18: Dan Boneh:


I hope everybody, it's a wonderful, wonderful product. Yes. By the way, Yubico are right down the street here and I work with them too. So it's a really fun company. So the question is, what happens if one of these 2nd factor comes to you and it's got something that's gonna leak your credentials to the outside world when you use it? Maybe I can step back a second and I can say that these U2F factors, traditionally what they're designed to defend against is a situation where your laptop is infected with malware, but the 2nd factor device is secure. Right? And then the malware can't get the credential because the credential is stored in a 2nd factor. Now we're saying, well, fine, this is a great security model, but maybe we can enhance it a bit. Why don't we also consider the opposite situation? Where your 2nd factor device actually is infected because of the supply chain attacks, but your laptop is secure.


1:05:16: 


Yeah, so maybe the laptop can somehow verify that everything that the U2F device does is according to the protocol. Yeah, and so if the U2F device tries to leak your credentials somehow, it'll get blocked because the laptop is gonna prevent that from happening. So we have these two security models, right? Either your laptop is infected and the U2F token is legit, or vice versa. Of course, if both your U2F token is compromised and your laptop is compromised, then we don't have a root of trust. So then there's nothing much we can do for you.


1:05:48: Anna Rose:


Gotcha. 


1:05:48: Dan Boneh:


So True2F is a system that kind of enhances the traditional U2F model. And so how does this connect to zero knowledge? Well, so the interesting thing is your laptop doesn't contain any secrets. What it does effectively is every time the U2F device produces a signature, say, so you're trying to log in, there's an ECDSA signature that's been generated by the U2F token that's used for logging you in. Every time it does that, it's going to provide a zero knowledge proof that actually it produced that signature correctly. 


1:06:21: Anna Rose:


So it attests to the validity.


1:06:23: Dan Boneh:


Validity, exactly. So the concern is, specifically, an ECDSA signature in principle could leak your secret key. If you were malicious, and you had the secret key, and you wanted to leak it to the outside world, you can produce an ECDSA signature that actually leaks the secret key, right? There's randomness in the ECDSA signature that randomness could be used to leak information about your secret key. Yeah, so what the laptop will do then is it will make sure that the signature produced by the U2F token actually is not doing that. And how you do it is a whole protocol that goes into it. So it's contributing to the randomness that the U2F token is using, and then there's a zero knowledge proof to say, yes, I actually used the randomness you gave me and therefore the signature is properly random and it does not leak your secret key. Yeah, so I wanna encourage people to just think about the supply chain attacks. Whether the event that we heard about last year happened or not, and you can link maybe to that event on the website, whether that event actually happened or not, I think the message to remember is that events, that can happen, that type of supply chain attack is real. And even if it didn't happen last year, it will happen next year.


1:07:38:


So I'd like to encourage your listeners to think about these supply chain attacks. And the point that I'd like to make is that using zero knowledge-like techniques, at least in certain cases, we can help to make sure that whatever hardware you're running, it can prove that it's doing things correctly. So even if the hardware itself has been compromised, it cannot... That compromise cannot be used to leak secrets from the hardware.


1:08:04: Anna Rose:


Cool.


1:08:05: Fredrik:


So that's some of the work that you've done. I know there's like a whole host of other work, both from you and from your group of students and everyone, so we can't really cover everything. But what I'm curious about as well is, what are some of the, like you're talking about solved problems now, what are the unsolved problems? What are you looking forward to work on in the future?


1:08:27: Dan Boneh:


Oh my God, there are many. What a wonderful question. Okay, so one of the problems that's been driving me crazy over the last couple of years, that I would be so happy if somebody solves, so please, I hope one of your listeners solves this, is this long-standing problem of constructing what are called multilinear maps. So let me explain. So I imagine your listeners have heard of bilinear maps. Bilinear maps are the technology that's underlying BLS signatures. It's a technology that's underlying many of the recent SNARKs, Groth16 and so on. So bilinear maps are effectively maps that take two inputs and they're linear in each one of the inputs. It turns out we can do a lot more if we had what's called a cryptographic multilinear map. So a multilinear map is a map that takes multiple inputs and it's linear in each one of those inputs.


1:09:22: 


So what are these things good for? Well, one of the exciting applications for them is they very easily solve the long-standing problem called non-interactive key exchange, non-interactive group key exchange. So what's the problem there? So imagine we have a million users, every user posts their public key to some public forum, say they post on Facebook or something, and now a subgroup of a thousand of them want to create a group key so they can communicate securely with one another. Yeah, so this is what's called the group key exchange question. And we'd like to do that non-attractively. So every user, all they have to do is they have to download the 999 public keys from the remain... From the other users, plus their own secret key. And that lets them generate a group key and all the thousand members of the group do this and they all end up with the same group key. An eavesdropper, all he sees is just a thousand public keys. And as a result, he can't figure out the group, overall the group key.


1:10:27: Anna Rose:


Wow.


1:10:28: Dan Boneh:


Yeah, so this has been an open problem for a long time. The famous Diffie-Hellman protocol lets us solve it for two parties. There's a famous protocol due to Antoine Joux that lets us solve it for three parties. And beyond three, basically, we have theoretical solutions but no practical solutions. Yeah? And so multilinear maps would give you a complete solution to this problem right away, and I'll just say this is quite relevant today because there's now a whole working group called the Messaging Layer Security Working Group, MLS, trying to standardize group key exchange, and this is all relevant because of various chat applications. They all support group key exchange, so Signal and Messenger and so on and so forth. They all support group chats, and so a group key exchange will let them very easily build group chats that are secure. Today they have to go through a much more complicated protocol to generate a group key, so we can do it, and they all do it. And actually the MLS working group is standardizing systems for group key exchange based on two party key exchange. So they can generalize from two party to end party. These multilinear maps will give a very clean solution. So this is actually a good time to solve this problem.


1:11:38:


And by the way, I have to say there are other killer applications for multilinear maps. One of them is what's called code obfuscation. And maybe we can talk about code obfuscation when we talk about future things that crypto can do for us. But we already know that multilinear maps imply code obfuscation. And if we had good multilinear maps, we could actually have decent code obfuscation schemes. So that's an exciting area. So hopefully one of your listeners is interested and can actually come up with a great solution. I would be so happy. Maybe I can mention one more problem.


1:12:10: Anna Rose:


Please. 


1:12:11: Dan Boneh:


Yeah. So this is also a problem that's been on my mind for quite some time. And I would love to see a clean solution. So this is actually a really basic problem that in some sense the crypto community has been failing the blockchain community. So the problem is what I would call short post-quantum signatures. So we have pre-quantum, we have good signatures, Schnorr signatures, BLS signatures and such, that have a short public key, 32 bytes, and a short signature, 48 or 64 bytes and so on. What we'd like to have is a signature scheme that remains secure even if the adversary has a quantum computer, a post-quantum signature.


1:12:54:


Well, today, if you look at the submissions to the NIST competition, these submissions basically either have much, much longer signatures or much longer signatures plus public key lengths. We'd like both the public key and the signature to be short. Yeah, and of course, we'd like it all to be based on assumptions that we all know, trust and believe in. We have faith that they really are post-quantum secure. So this is a problem that I've been kind of bothered with for a long time. Can we actually... Can we construct these short post-quantum signatures? I was hoping we've been working quite hard on trying to get them from these schemes called isogeny-based cryptosystems. So isogenies are kind of an interesting way to build post-quantum security. But somehow everything we try, we're also able to break. So we're not quite there yet. But again, it's a wonderful question and hope some of your listeners will be interested and we'll try to work on it. If you have ideas, please send them. We'd love to collaborate.


1:13:58: Fredrik:


The whole area of isogenies is something I wanna do an episode on in the future because there's so much to talk. Like VDFs have been a hot topic for a while as well. And there's these new isogenies VDFs and yeah, there's a bunch of interesting stuff there, and it's a field that I know very little about.


1:14:15: Dan Boneh:


Yeah, the nice thing about isogenies is that if you understand how Diffie-Hellman works, you can actually, at a high level, you can understand how isogenies work quite easily. Yeah...


1:14:25: Fredrik:


You're right.


1:14:27: Dan Boneh:


So I would love to launch into my quick description of how isogenies work, but I'm not sure given the time we'd have to do. We'll be here until evening if we do that.


1:14:34: Anna Rose:


Maybe that will require a new episode. I wanna ask you about this post-quantum stuff. So this has been brought up a number of times. Is this something that you think the cryptography community is very focused on right now? Are they focused enough on the post-quantum idea?


1:14:48: Dan Boneh:


Oh yeah.


1:14:49: Anna Rose:


The fact that quantum computers are gonna come along and potentially break a lot of the standard cryptography.


1:14:54: Dan Boneh:


Yeah, you know, the way I'd answer this question is, the first question to ask is, why would anyone develop quantum computers? Right? So the answer people give is, oh yeah, we can break RSA, we can break discrete log, we can break Diffie-Hellman. That's not a reason to develop quantum computers. The reason that's not the reason to develop quantum computers is we have good post-quantum crypto today. We have lattice-based crypto, we have isogeny-based crypto. It's all getting standardized by NIST. So by the time somebody actually builds a large enough quantum computer to break these schemes, we will have moved on. We have ways to recover. And so that's not a reason to build a quantum computer. If there's no business reason to build a quantum computer, they will never be built. That's just a fact of nature, law of nature.


1:15:37:


So the first question you have to ask is, why is it that... Why would anyone build a quantum computer? There have to be other applications outside of breaking cryptosystems. And the answer is that these quantum computers are actually... Well, not surprisingly, they're good at simulating physics. And the place where we need to simulate physics is when we do computational chemistry. So when you do drug design, yeah, when you do... I guess, people always give these fertilizers, where you try to actually design molecules with certain properties. Today, if I give you a complicated molecule and I ask you, tell me what its ground states are. Analytically, it's actually quite difficult to do and often people have to go and build a molecule and then do crystallography to actually figure out what its structure is. It'd be much nicer if we can do it all on a computer.


1:16:26: Anna Rose:


And you need quantum computers, post-quantum computers in order to do that. Do you call them post-quantum or quantum?


1:16:30: Dan Boneh:


No, you call them quantum computers. There's post-quantum cryptography and there's quantum computers.


1:16:34: Anna Rose:


So you would need quantum computers in order to do that.


1:16:37: Dan Boneh:


So many of the... This is called, the term for this is called a NISQ. This is what's called a Noisy Intermediate Scale Quantum Computer, NISQ. And the killer application for NISQs is basically computational chemistry, right? So that's kind of the short term application that we're working towards. Now these NISQ applications, they typically require only a couple of hundreds of qubits or maybe thousands of qubits. To break crypto, we need tens of millions of qubits. Yeah, so we're very, very, very far away from that. And by the way, it's not just the number of qubits that we need, it's also the decoherence time. Yeah, so today, if you look at the quantum computers that are being built today by IBM, by Google, by Rigetti, those quantum computers today can only, basically they can maintain coherence so that for a relatively short amount of time, so you can do very shallow computations, right? So you kind of have to do your computation within a thousand steps and then the computation dies. There's too much noise.


1:17:39:


So you can evaluate a wide circuit, but it has to be very shallow so that it's fast to evaluate. Whereas breaking crypto, well, those algorithms are necessarily sequential. So they take quite a while to run. So it'll take the algorithm, the computer actually, a couple of hours to run to break the crypto. So we're not there, we're far from there, A in the number of qubits, and B, in the decoherence time. Now, the interesting thing is that there are improvements, right? So the number of qubits keeps growing, the decoherence time keeps increasing. And so let's just pretend, let's assume things will progress at the rate of Moore's law. That's a big assumption. We don't know if that's true or not, but let's assume things progress at the rate of Moore's law. Well, we need to get to around 100 million qubits to run these factoring and discrete log algorithms. So if you compute log of 100 million based on 1.8 month, right? Moore's law says doubling every 1.8 months, you get about 30 years. Yeah. So we're 30 years away. If Moore's law applies, we're about 30 years away from having a computer that's large enough to actually break a crypto system.  Yeah. So that's kind of the time horizon.


1:18:46: Anna Rose:


It sounds like it's worth keeping an eye on, but it's still a ways off. So a lot of this pre-quantum cryptography is still very, very relevant.


1:18:55: Dan Boneh:


Yes. So in fact, a lot of pre-quantum cryptography is going to be very relevant for a long time to come. We're probably going to have good indication when we need to move away from the pre-quantum crypto. At the same time, I have to say the crypto community is very hard at work on building post-quantum systems so that we are ready. This is what academia is supposed to be working on. Right? We're not supposed to be working on things that are needed next year. We need to be working on things that are also needed 50 to 100 years from now. So there's a massive effort in building post-quantum crypto systems. We are pretty much... We're very well prepared for it. So yeah, so blockchains are safe, no worries. Effectively, for now, it's okay to use pre-quantum crypto.


1:19:38: Fredrik:


Very cool. In the same line, I'm really curious to hear your vision of the future of crypto. We already touched a little bit on various topics here. But where do you see things going, given your decades of experience, are things moving faster, slower? Is it more exciting or less exciting? Or what's going on? What will happen in the future?


1:20:02: Dan Boneh:


Yeah, that's a great question. I have to say there's never a dull moment in crypto. It's like every couple of years, it seems like all the important questions have been solved and then a whole new area gets invented. So there's never ever a dull moment. Maybe if I have to answer... If I need to answer your question, I would kind of answer it like this. I would say, over the past decade, we've kind of seen tools that were considered theoretical tools like zero knowledge and MPC. We've seen them kind of move into practice and actually get deployed in real systems, which is so much fun to see. You know, for a cryptographer, this is amazing, amazing to see these beautiful ideas that we have been developing for 30 years are now actually being put to use. So I'm thrilled that this is happening.


1:20:50:


So you ask about the future. Well, I'm hoping that the same thing will happen in the future. Yeah, so there is this very theoretical concept in cryptography today, which we touched upon, called obfuscation. So maybe for your listeners who are not familiar with obfuscation, I can say what obfuscation is, it's a crypto mechanism that allows you to hide secret keys in code. Yeah, so I can put a secret key like a secret decryption key, a secret signing key in code, I can literally give you the software, you can run the code and do whatever you want with it. Yeah, you can run the software, do whatever you want with that software, but you will not be able to get the key out other than the way that the software was intended to run. Yeah? So that's what obfuscation lets you do. So why is this relevant to blockchains? Well, you can imagine a dApp where I would actually build a program that signs a certain message only if certain conditions exist.


1:21:49:


Yeah. And then today, if I upload that program to the cloud, to the blockchain, everybody can look at the program and say, oh, that's the signing key, I'm just going to extract the signing key and sign things when they're not supposed to be signed. But if the program is obfuscated, really, the only thing you can do is just run the program and it will only sign things for you if the appropriate preconditions are satisfied. Yeah, today, if we wanted to do that, we effectively have to use secure hardware like SGX or other hardware enclaves. But obfuscation basically lets you do things that today requires secure enclaves just using crypto. So what's the problem? The problem is even though obfuscation, software obfuscation solves almost all open problems in crypto, it's like it's amazing. Yeah. It's literally, if we had practical obfuscation, it's like almost everything you want can be done. Yeah, it's remarkable. Yeah.


1:22:43: Anna Rose:


But it's not there yet.


1:22:45: Dan Boneh:


It's far, we know... So that's right. So today we have candidate obfuscation schemes. They're polynomial time, but this is a terrible polynomial. So they're so inefficient that we can't really build real... Anything that's even resembling something that's real world yet. So my hope is just like 10, 20 years ago, everybody was saying, oh, zero knowledge, MPC, it's all theoretical, and it'll get deployed too slow, too inefficient. One could hope that over the next decade or two or three or four, obfuscation will get better and better and better until the point where it can actually be deployed. And again, the amazing thing is, everything that we can do or simple things that we need hardware enclaves for today can then be done without relying on a hardware enclave, but instead relying on crypto. Right? So we remove single points of trust. And instead of security, it's always better to base it on math than to base it on other assumptions. So yeah, so that's kind of, I'm hoping that's one area where things will move in the future.


1:23:50:


And then in the world of post-quantum security, there's still a lot to do. Yeah. They're, like I said, short signatures is an issue, better SNARKs for the post-quantum world. Obviously, STARKs are post-quantum but like I said, there are many different directions to building SNARKs and not all of them are post-quantum. And then even in the world of quantum, there's actually a sequence of papers that we wrote a while ago and something we would call post post-quantum. So post post-quantum, it's a bit of a funny name, but what it is, is the settings where not only does the adversary have a quantum computer, but actually the end users also have a quantum computer. So imagine my laptop is a quantum machine. We are very far away from that. Today quantum computers are huge. They have these fridges that have to cool things down to absolute zero. Long ways off until this is actually running on my laptop. But maybe our great, great, great grandkids will have quantum computers on their laptops.


1:24:54:


And then this opens up like a whole new directions for attacks. Because today, if I want to attack a signature scheme, for example, the security for a signature scheme says, I get to submit a message of my choice, and you give me a signature on that message. And we'd like to make sure that the signature is secure under those settings. But if my laptop is quantum, I get to submit like a... If you like, like a bag of messages, and you give me back a bag of signatures, it gives the attacker more power, and as a result, the question is, how do we design crypto systems that are secure when the attacker can interact with the participants over a quantum channel? Yeah. So even that are things that we're considering. And like I said, there's a lot more to do in that space as well. So the quantum world is like... It's going to keep us busy for many, many years to come.


1:25:43: Anna Rose:


Cool.


1:25:45: Fredrik:


All right. To wrap it up, I want to ask a short question that's a little bit more on your personal feeling because you invented or were part in inventing BLS signatures. And they're now being widely adopted by this relatively large blockchain community. How does it feel to invent something and create something like BLS signatures and see such wide adoption of it?


1:26:15: Dan Boneh:
So honestly, I'm happy whenever new crypto mechanisms get deployed. So for me, it's wonderful to see pairings and BLS signatures being used. Yeah, I love it. I'm actually quite happy that pairings are used in other places too. SNARKs, many of the SNARKs use pairings. But for sure, I mean, I'm thrilled that BLS is useful. Right? So BLS signatures are basically based on bilinear maps. So I'm thrilled to see more applications of bilinear maps being used in the real world. I guess, the primary reason why BLS signatures are kind of a good match for the world of blockchains is that it's very easy to aggregate BLS signatures once they're produced. Yeah, so you can have a million people generate signatures on messages of their choice, and then anyone can come in, take those million signatures, and whoosh, compress them into a single signature that can then be verified.


1:27:13:


So there's one single signature, then basically provides a proof that all million signatures were valid. And it's really simple to aggregate. All you do is you just multiply all the signatures together. That's all it is. Yep, and so if you have a bunch of signatures in a block, all the signatures in a block can be compressed into a single signature. In the proof-of-stake systems, you have to have a lot of the stakers sign the fact that they allow a certain state transition, you can take all those signatures and compress them into a single signature. So the data that's actually stored on the blockchain is much, much, much smaller than it was before. 


1:27:50: Anna Rose:


And yet it still represents all of those signatures somehow.


1:27:53: Dan Boneh:


Exactly. So that one aggregate signature convinces the verifier that all the messages that were signed were actually properly signed. So I like everything in cryptography. It's kind of a tricky situation in that it's always more complicated than it seems. If literally, you implement... If you read kind of the basic schemes for how to do aggregation, you read that, oh, you just take all the signatures and you multiply them together and that's it. That's your aggregate signature. Well, it turns out it's not that simple. Yeah, so that is actually what you do. You just multiply them all together, but it turns out if you just do it naively, you open yourself up to what's called a Rogue Public Key Attack. Yeah, so that's a fascinating attack in its own right, where what I can do is I can look at your public key and I can cook up a public key myself that I wouldn't know what the private key for that public key is. So I cook up a new public key, and now all of a sudden, what I can do is I can create an aggregate signature on a message of my choice that would look like both you and I signed that message.


1:29:04:


Yeah, that's the Rogue Public Key Attack where in effect I can create an aggregate that commits you to a message that you never signed. And so, well, you have to be careful about rogue public keys, and in fact, most of the work on BLS signature deals with how to defend against rogue public keys. And we have multiple methods to defend against that. And all is actually being worked into this standard that's now emerging to provide secure signature aggregation. So the only reason I'm bringing that up is I want your listeners to understand that aggregation is really simple. It can be done securely, however, don't do this at home. Right? If you're going to do a signature aggregation, follow the standards, because if you just do it in the simple, naive way, it'll not be secure.


1:29:55: Anna Rose:


And it's ignoring all of those attack cases.


1:29:57: Dan Boneh:


Exactly. Exactly.


1:29:59: Anna Rose:


That you have thought of in the construction of this.


1:30:01: Dan Boneh:


Yes, exactly. Exactly. So it's kind of... It's a useful mechanism, yeah, that will compress the amount of storage you need to store large numbers of signatures, but you should be using standards. So that's one area where people sometimes can make mistakes. Another area is in the... Again, kind of looking at recent work on BLS, is this question of if you want to sign a message in BLS, the first thing you have to do is you have to map the message to a point in an elliptic curve. And the question is how do you map to a point in an elliptic curve? It turns out there's kind of a naive method. It's called basically guess and try. So you hash to a random place and you hope that it's on the elliptic curve. But it turns out we can do things more efficiently.


1:30:46:


And so actually we have some recent work. This is with my student Riad Wahby, where we give a very efficient way to map onto these pairing-friendly elliptic curves. So again, this is all getting wrapped up in this standard. So if you're going to use BLS signatures, it's probably at this point a good idea to follow the standard that's forming. Don't kind of implement your own library and your own, roll out your own implementation, follow the techniques in the standard, follow the API that the standard provides, and that's probably the best way to do it. I have to say, the cool thing is that it's really getting quite a bit of traction. So, DFINITY, Chia, Ethereum 2.0, all those projects are actually using BLS. And so, yeah, like you said, Fredrik, I'm thrilled that this is actually seeing real use. I hope to see much more crypto get deployed in these projects.


1:31:41: Anna Rose:


When was that actually developed? When was the BLS... Like when was that first proposed?


1:31:45: Dan Boneh:


Oh, it's quite old. It dates back to, I believe, 2001.


1:31:50: Anna Rose:


And so it took, what was it? Like 10 years, 12 years before you got to see it implemented in blockchain? Or was it already...


1:31:58: Dan Boneh:


Well, we implemented it fairly quickly just to experiment with the scheme. But I guess, when did blockchain projects kind of start using?


1:32:08: Anna Rose:


Start using it.


1:32:09: Dan Boneh:


I think, well, that's a good question. I'm actually not sure.


1:32:12: Anna Rose:


I'm just trying to picture what the time frame is.


1:32:13: Fredrik:


I think the first one I remember publicly writing, or maybe it's just the first one that was a large project writing about it, was DFINITY. 


1:32:22: Dan Boneh:


Yeah, I think, Dom was actually kind of needed it for their threshold relay. So what he needed was a signature scheme that's easily supported threshold signatures and easily supported threshold key generation. And so that was a good match in that it easily supports both those operations.


1:32:39: Anna Rose:


Cool. So listen, this has been such a fantastic conversation, wide ranging. I feel like there's so many pieces of this last two hours that we could go very deep on and do full episodes. I want to thank you so much for being on the podcast and for being on our 100th episode.


1:32:57: Dan Boneh:


It's my pleasure. Thank you so much for actually running this podcast. It's a wonderful service to the community.


1:33:02: Fredrik:


Thank you very much. I actually had a piece in the education section that I wanted to ask on what role you think podcasts like these and others play, but I'll leave that for a future conversation as well. So thank you very much. It's been a pleasure. 


1:33:20: Dan Boneh:


Yep. Thank you guys.


1:33:22: Anna Rose:


And to our listeners, thanks for listening. 


1:33:24: Fredrik:


Thanks for listening.