Placeholder Image

字幕列表 影片播放

  • 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.