字幕列表 影片播放 列印英文字幕 The following content is provided under a Creative Commons license. Your support will help MIT Open CourseWare continue to offer high-quality educational resources for free. To make a donation or to view additional materials from hundreds of MIT courses, visit MIT Open CourseWare at ocw.mit.edu. I'm going to talk about alternate consensus mechanisms. And there's a bunch of them. And some of them are variants on proof of work. Some of them are proof of stake-- all these different things. So unique node lists-- this is something that Ripple and Stellar use. I'm not sure if there's others. Proof of stake is this huge research topic that lots of things fall under. There's lots of variance. One of them I'll talk about is delegated proof of stake. Proof of space is an interesting thing that is basically a form of proof of work that doesn't use CPU as much. There's the idea of directed acyclic graphs, which IOTA is a great example of. And then one that I came up with a few years ago and is kind of fun-- proof of idol, which is sort of silly but some of these others are silly, too. OK. And so disclaimer-- I'm OK with proof of work. So I think if you were at the class on Monday, it's a great segue into this, where, clearly, proof of work has, I don't know if you want to call it problems, but it's kind of crazy, right, all the stuff David was saying on Monday. It's not an egalitarian-- and I think in the Satoshi White Paper, he says one CPU, one vote. Well, that's not really how it works. Define CPU. Maybe you have your own CPU. Someone else has a different view. And there's that huge industry of building all these chips. So there's a lot of issues with proof of work. It's certainly not ideal. That's probably not why most people don't like it. So I, generally, in academia, in a lot of business places, people don't like the Bitcoin proof of work mechanism-- not everyone, but it's a pretty widespread. Oh, Bitcoin is bad because it uses as much electricity as Denmark or something. And I think that's a sort of early, I don't like it because it uses electricity. There's other reasons not to like it, which I think you have to go into much more depth. Like with David's talk yesterday, sure, it uses a lot of electricity. But it also uses a lot of fabrication plants, and it uses all these other distribution networks. So anyway, I get that there's a lot of-- one of the first things with Bitcoin is, OK, how can we improve upon this? How can we get rid of this huge energy sink? On the other hand, I'm sort of OK with it, right? The first thing that I thought with Bitcoin is, wow, this is going to be huge. This is going to take a lot of electricity. But it's kind of cool that it works that way. So I'm sort of OK with people-- to me, you can't really get mad at people doing things you think are stupid because you'll just get mad all the time. People mine gold. People spend billions of dollars on diamonds. I think diamonds are really stupid. But hey, if you want to dig up diamonds, oh, whatever. Yeah. There's entire cultural areas that I just have no interest in. But hey. OK. So I'll try to explain these other methods in a neutral way. But I do have my own biases, where I think like, hey, proof of work pretty much works. I think it's a cool system. And I'm somewhat skeptical of various different algorithms and mechanisms here. And also, I'm most familiar with the proof of work system and all the intricacies of it. So like with David's talk yesterday, there was some new stuff, but I sort of knew because I've talked to these people for a long time, and this is how this system works. Proof of stake-- I've seen it implemented in altcoins. But I haven't followed them that closely. So I don't know as intimately what goes wrong and all the weird details. Anyway. OK. So the first one, UNL, or unique node list. This is, essentially, the consensus mechanism used by Ripple and Stellar. For history, Ripple started in 2013? No, 2011. I don't know. It was a while ago. AUDIENCE: [? Dennis ?] says [INAUDIBLE] January 1, 2013. TADGE DRYJA: 2013, OK. So actually, the name Ripple and the idea of these debt obligations through this network actually predates Bitcoin. And then Jed McCaleb started the company. He's also the guy who started Mt. Gox. So he started Mt. Gox, I believe, in 2011 or '10-- late 2010, sold it to the Mark Karpelés, started Ripple, hired a bunch of people, sort of got fired from Ripple. There's a lot of bad-- everyone fighting. Because it was all these people who used to play Magic-- the Gathering and were friends. And now they're not friends anymore. And then, he started Stellar, which he called "Secret Bitcoin Project." And I was thinking of joining it, but he wouldn't tell me what it was. And also, I knew that other people knew what it was, like my friends, and if they weren't telling me because they're not supposed to, it was like, well, it must not be that cool. Because nobody can actually keep a secret if it's really cool. [LAUGHING] So that was my, mm, I'll just go work somewhere else. And Stellar was, more or less, a copy of the Ripple code, which was open source, so it was totally fine to do this. And then it diverged, and they added their own different parts of the consensus algorithm than Ripple did. So it's account-based, somewhat like Ethereum. Transactions have senders, receivers. What's interesting is in the Stellar case, and possibly Ripple, there's a minimum balance. So I actually had some Stellar last year, or up until last year, because I went to the initial release party, and they gave out Stellar. And I had some. And then, it wasn't much. But then, last year, I looked, and it was like, oh, this is like $200 worth. I'll sell it. And I sold it and got some bitcoins. But it was weird because they enforced a minimum balance, which seems weird to me. Because you had to retain some number of stellar units in every account, which, to me, seems sort of weird. Because that means those stellars, they're gone, in a way, in that if you open a new account and it must have 50 stellar in it forever. Well, so Stellar effectively destroyed, it just seemed-- which is a fine thing to do. It's sort of a transaction fee. But from a computer science database standpoint, it's like, why not just have it cost money to create a new account instead of have a minimum balance? So just interacting with it, it was like, huh. So there's no work. But the idea is that nodes sign transactions that they've seen. Everyone makes blocks. And you sign them, so you've got some kind of identity. Your node has a key. When you start a new node, you've got a public key/private key pair. You can sign off on transactions. This is not the case in Bitcoin, right? In Bitcoin, you have a full node. Your full node might have a wallet associated with it with public keys and private keys, but the node itself does not. Possibly in the future, there's BIP 150, I believe, which the idea is to have encrypted communications between nodes, which would have some kind of authentication. There's BIP and BIP 151. I might have them backwards. 151, I believe, is just encryption, so for privacy, confidentiality. And then, BIT 150 is for authenticity. So you connect to a node. You're like, oh, this is the same node at the same IP address that I connected to before. They're not implemented yet that I'm aware of. So right now, in Bitcoin, when you connect to people, you just use their IP address. You don't really know who they are. There's no authentication there. But in these, in Ripple and Stellar, you do know. OK. I'm connecting to this node. It's got a key. It's got an identity. So to sync, instead of verifying all the work, you verify the signatures on blocks. And the question is, whose signatures, right? So if you assume, OK, well, if we have a majority that's honest and is not trying to create transactions that are invalidated or something like that, then it might work. But majority is hard to define when you're subject to civil attacks, right? The obvious attack is I just make thousands of nodes, or maybe these nodes don't even really exist. I just make thousands of key pairs, have them pretend to be nodes in my own subnetwork, and they all endorse blocks that are different than the rest of the network is endorsing. So majority is the tricky part. How do you know who's the majority if you don't know who these people are? You need some kind of way to identify humans or computers, even. And this is a problem akin to certificate authorities. So a lot of the problems that you see in blockchain, bitcoin, these kind of things, are not exactly new problems and have sort of already been, quote unquote, "solved." So does everyone know how CAs work, or do people have some idea? Or who's like, what's a CA? OK. So it's kind of interesting. I can give a little demo. AUDIENCE: Did you say CA stands for certificate authority? TADGE DRYJA: Yes. Uh-oh. This doesn't work. Hold on. OK. So if you have a computer, I don't know where it is in Windows, but I think in Mac and Linux, it's in the same place. You go to etc and then-- shoot, I forget where it is. Yeah. Where's the certificates? Cert-- tru-- AUDIENCE: CA certificates right under the mouse. TADGE DRYJA: There it is. OK. So in your computer, and whether you have Linux or Mac, you've got a folder somewhere, etc/ca-certificates. It's something like that in Mac, as well. And, oh, no, that's not it. Where are they? Shoot. Wait, wait, wait-- what is in update.dn? And there's nothing there. Hold on. I need to find this. Because this is kind of cool. Where are X? Ah, SSL-- is that-- there we go. OK. So sorry. etc/ssl, and then you've got certs. And this folder has a bunch of certs. I trust all of these entities. Well, my computer does and, by extension, my browsers and my computer, which is crazy because I have no idea who these people are. TURKTRUST? I don't really trust Turkey. Swisscom-- Swiss people seem nice, I guess. I don't know. OK. Staat-- they're in Netherlands somewhere. There's a bunch of, just things you've never heard of. Hellenic Academic and Research Institute, Hong Kong Post. Well, Hong Kong Post Office seems trustworthy. Yeah? AUDIENCE: On the TURKTRUST one, you pointed out they have [INAUDIBLE] certificates with google.com when they're not supposed to. [INAUDIBLE]. TADGE DRYJA: And then, CNNIC is one which is like-- is that still in here? Maybe they got rid of it. And then some of them just have these numbers, and you don't even know. You have to go in. AUDIENCE: [INAUDIBLE] TADGE DRYJA: Yeah. China Internet Network Information Center EB certificates root. I actually really don't trust them to endorse-- pseudo arm-- there we go. OK, it's gone-- solved it, solved the distributed internet trust problem. AUDIENCE: Now part of the internet doesn't work for you. TADGE DRYJA: Yeah, well, I might get invalid certificate errors for some Chinese sites now. I don't go to many Chinese sites. Anyway, so that's the basic idea of certificate authorities. And this started in mid-'90s, when they wanted to make public key infrastructure for secure websites. One of the problems is how do you know-- so you've got-- oh, we didn't talk about Diffie-Hellman, or maybe I mentioned it. But you've got public keys, private keys. You've got ways to do signatures. Diffie-Hellman is a way to do key exchange. So if I know you're a public key, and I give you my public key, we can form a third, basically, key that we can then use for encryption and secure messaging. This works, but how do you know, given a key, who is on the other end? So that's the idea of certificate authorities. You have this sort of root of trust. And these certificate authorities sign certificates in websites and let you know, oh, this is the person who you think it is. So for example, Google-- secure connection. Really? How do I know? Verified by Google Trust. Well, Google has verified that Google is trustworthy, which is somewhat circular. But no, that's sort of how it works. Yeah, so Google Trust Services is a certificate authority. And they signed off their own certificate for their own website. That's maybe not the best example. OK, The New York Times, they are certified by Comodo CA, who also has had-- Comodo has gotten in a lot of trouble for signing the wrong things. So yeah. New York Times does not have an EB cert. I think Washington Post does. So there's also EB certs where-- you've got now The Washington Post, WP Company LLC. That's like an extended validation cert, which, then, the CA is saying, we didn't just check that they had an IP address and a domain name. We actually checked that they had some kind of legal corporate entity. And they sent it on their letterhead, and we, I don't know, emailed someone in Delaware to make sure they actually had a company. And this is verified by Entrust. OK. So Entrust, Comodo, those are all going to be in here. Yeah, there's Comodo. So you've got these companies called CAs that have some kind of agreement with each other. There's these standards where you make some kind of standards where, OK, don't sign the wrong thing. If you do, we're going to delete you. And then they all endorse entities' identity, usually for companies. There's also stuff now-- Let's Encrypt, which does it for free and without really endorsing anything. This whole thing, it sort of felt like it was like the big scam of the late '90s because they made billions of dollars. But then again, we got Ubuntu out of it, right? So yeah, Ubuntu was funded by Mark Shuttleworth, who started this one, I believe, and made a couple hundred million, went on the spaceship, went into orbit, had some fun. Eccentric billionaires are what fund a lot of technology development. And this is how we get them. A lot of the people who work on Bitcoin and these systems feel that the current-- it's called X.509 is the name of this whole system with these certificate authorities-- and I also sort of feel that this is a suboptimal solution in that there's a lot of problems with certificates being signed inappropriately. It works, in a way. But it's not great. So this is a problem. So the problem that these systems like Ripple and Stellar have to deal with are, in some ways, similar to the problem that is solved by CAs. So what they do is they say, we have a unique node list. We're not actually endorsing an identity from, here's a public key, here's a human name or a company name or something like that. It's we're just saying that they're unique. So it's more limited than a certificate authority. It's just saying we're certifying that these two keys belong to different people or different companies, which seems easier than the job of a CA, right? The CA has to verify that The Washington Post is actually-- whoever's presenting a public key is actually The Washington Post. So the actual certificate is just, basically, here's a pubkey, here's a name, and then the CA sign. And you can look at those and stuff. OK. So for synchronization, you wait for a majority of nodes in your unique node list to sign and, if they've signed, accept. So there's some recent papers from Ripple. And in order to really get consensus, you need, basically, a 90% overlap in your own unique node list. So if I have a unique node list of Alice and Bob and Carol, and you have a unique node list of Carol and Dave and Edna-- I don't know-- we might diverge. We might not agree on the same chain of transactions because we've got different people that were looking at their signatures. They may all be unique. But if we have different unique people we're looking to, it might not converge. So they have a newer paper that reduces that to 60%-ish, where the overlap of what unique nodes everyone needs to look at is not as large but still quite large. And then, the real question is, OK, well, who provides the unique node list? Because that's not really a job I can do. Maybe it is, in a way. If I know you, and we do some kind of web of trust thing where I'm like, oh, what's your Ripple nodes pubkey? OK. Cool, I know you. And what's your Ripple nodes pubkey? We meet in person. We sign each other's pubkeys. We do the whole PGP kind of thing, which I do. And the Bitcoin people actually do this. So if I go to-- hold on. So I've got a bunch of keys, and everyone signed them. And there's Andrew Chow and Suhas and [INAUDIBLE] and all these Bitcoin people. And I've signed their keys and they've signed my keys because we meet in person and do that kind of thing. So we've established not just a unique node list, but we've done a CA-free validation of each other's keys. We just meet in person, read each other's keys off. So you can do that, in practice. It's really nerdy, and no one does that. And it would be cool if we could get it to be easier and maybe cooler somehow. But it's been an uphill battle. So who provides the UNL? It's probably kind of obvious. Well, the Ripple company provides the UNL, right? So when you download Ripple, it has a list of unique nodes. Those are essentially de facto, the nodes that run Ripple.