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. And at the current time, those nodes are run by the

  • Ripple corporation, or Ripple apps.

  • Stellar, similarly, it comes with a default UNL. It sort of acts like the CAs, right?

  • It's sort of how when you start your computer, you've got this. This comes with your OS.

  • And you don't really have a choice. I just deleted the CNNIC one. But nobody looks at

  • this stuff. Everyone just goes with the defaults. So that's the problem centralization-wise.

  • Yes?

  • AUDIENCE: You said Ripple or Stellar actually run the nodes? Because I understand that they

  • might sign off on the UNL if you're saying that--

  • TADGE DRYJA: In Ripple's-- at least a year or two ago, and they may have changed that,

  • I think they're trying to-- but in Ripple's case, yeah. They ran their own Ripple nodes.

  • AUDIENCE: So it's not these bank partners or anything?

  • TADGE DRYJA: They may have some. They may now. But I know that two years ago, it was

  • just Ripple, or majority Ripple. Because they also put in things like they can freeze funds.

  • Because Ripple got in trouble with FinCEN. And part of the thing is they modified their

  • code to be able to freeze people's funds if they did something bad.

  • That's definitely not something that the Bitcoin developers, or even the Ethereum Foundation--

  • it's not as direct, anyway. The Ethereum Foundation did freeze funds and move them against the

  • rules of the system in the case of the Dow. But that was, in a lot of ways, with support

  • of a lot of the people running Ethereum. With Ripple, they can do it without much brouhaha.

  • They just freeze these funds.

  • So it's fast. There's no work involved. There's no worry about propagating blocks and miners

  • getting advantages. But there's also known identities, and so it's more susceptible to

  • subpoenas and things like that.

  • In these cases, all the coins existed at the genesis block. So in the case of Ripple, I

  • think it was 100 billion or something. And they just started with all the coins and distributed

  • them as they saw fit.

  • Same with Stellar. Stellar had this thing where they had this party, and they would

  • give them away if you signed up on Facebook. A really interesting article about people

  • in Manila getting thousands of used SIM cards from the US, registering for new Facebook

  • accounts, selling those Facebook accounts to people in China, the people in China then

  • registering with Stellar as unique people to get more stellars.

  • When you incentivize things, weird things happen, be it either giant warehouses full

  • of SHA256 chips or giant warehouses full of 20-year-old girls in Manila putting SIM cards

  • in cell phones all day. Yeah. I should link to that article. It's really interesting.

  • So anyway, this is the Stellar one. And Stellar also had this thing where they were going

  • to give 20% of the stellar to people who held bitcoin, sort of an airdrop. I didn't get

  • any from that. I was sort of hoping. I'm like, hey, cool-- air drop. I have bitcoin. I'll

  • get some stellar. I didn't because you basically had to KYC with them.

  • They said, OK, send in your-- I don't know if it was the social security number-- but

  • send in your documents and prove that you have these bitcoins, and we will credit some

  • stellar to the same keys. And I'm not going to do that. Yeah. Some people did. Some people

  • got some stellar that way. Yeah. So anyway. Yeah?

  • AUDIENCE: If Stellar's just freezing coins--

  • TADGE DRYJA: No. I don't know if Stellar has that capability. Ripple does. Ripple put that

  • in. Stellar is a different-- it's similar software. They certainly argue about how different

  • they are.

  • Stellar had a bug in 2015, I believe, where the consensus broke. And then they said, oh,

  • it's Ripple's code's fault. This is a fault with all this code base. And then Ripple said,

  • no, no, no. It's because you changed it. And you don't know what you're doing.

  • AUDIENCE: I was talking about, I guess, the minimums. You said there was a minimum.

  • TADGE DRYJA: Yeah, there's a minimum account balance.

  • AUDIENCE: And if there's a set number of coins, then eventually, accounts will just get--

  • TADGE DRYJA: Yeah. It's a lot, though. Also, there's enough forever. There's a lot of coins.

  • But yeah. But the idea is not that you have UTXOs, like in Bitcoin, and you make new addresses

  • each time. The idea is you have an address. You keep that forever. So why would you have

  • multiple different addresses, that kind of thing.

  • Anyway. So it's a pretty different system. In some ways, you could argue it's one of

  • the first ICOs-- Ripple-- because it was pretty early. They just came up with all their coins

  • and gave them out and then started selling them. And they continue to do that to this

  • day.

  • Stellar is a nonprofit, which is also sort of weird. Because if you make a billion dollars

  • off of something, is it really a nonprofit? I don't know. The organization didn't directly

  • make the money and then pay it to the employees or anything. But the people who have all the

  • stellar tokens made a lot of money. Interesting sort of ways to do it.

  • So I think both Ripple and Stellar argue that it's decentralized, distributed. But I think

  • a lot of people say, well, maybe to some extent. But on the spectrum of completely decentralized

  • versus one server handles it all, it's a lot further on the centralized side.

  • And Bitcoin is also kind of centralized, too, like we were talking about on Monday. But

  • I would argue these are more so. So anyway. Any questions about Ripple, Stellar? Pretty

  • fun.

  • OK. Next, the big one-- proof of stake. So this we've mentioned a little bit. It's a

  • popular alternative where people really don't like the proof of work stuff. So instead of

  • proving work, have the people who hold coins sign the blocks. So that bootstraps, in a

  • way, your unique node list or your list of who's who.

  • Well, you don't really care who they are. But if they have coins, if you already have

  • a set of who owns what coins, you can use that to say, OK, well, the people who own

  • coins now signed. And they, presumably, have incentives not to destroy the network they

  • have coins in.

  • So if you have a given genesis block with some kind of initial distribution, you can

  • make it deterministic. You can say, I'm just going to go with whatever has the most stake,

  • whoever has the most coins, signing off on the next block. And given two or three different

  • histories, you can see, OK, from the start, which has the most total stakes signing off

  • on these things? So that seems pretty cool.

  • Here's some issues. Stake grinding-- so for example, let's say you have a system where

  • the signer of the next block is determined by the public key nearest to the previous

  • block hash. So for example, OK, I'm looking at the current block hash. Who gets to sign

  • next? Well, whoever's key is closest. Use X or just treat the hash as a number and treat

  • the pubkey as a number and see which is closest.

  • You can do that. But the problem is if the next hash is determined by the current signer,

  • that current signer can make a new signature each time and try to make sure that the block

  • after is also going to be one where they are, again, the next signer. And they can make

  • a couple hundred different accounts with their keys and then keep grinding stake.

  • And this basically means that it turns into proof of work. Because if you can influence

  • who's going to be the next block signer-- yourself-- keep trying different ways to sign,

  • OK, that's basically proof of work, but instead of hashing, you're signing.

  • And this has happened in many altcoins. One that I think was kind of interesting was Nxt,

  • which is the people who later went on to make IOTA. They said, OK, well, we have a deterministic

  • signature scheme, and so this can't happen, right? Given a message and a private key,

  • there's only one signature that can be produced.

  • And this is true. So Bitcoin uses this. It's called rfc6979. Basically, the random nonce

  • can be deterministically created from your private key and message.

  • The problem is-- I don't know if they realized, probably not-- but you can't enforce this.

  • It's a policy that says, OK, I'm going to make a deterministic signature. But given

  • a signature, you can't tell if someone did this or not, right? So it's up to you to obey

  • this rule. But you can't verify that anyone did it.

  • So that one also quickly devolved into proof of work and in a tricky way because a lot

  • of people read the documentation and said, OK, well, there is no way to keep signing.

  • Their function that they wrote, there's only one way to sign. When you sign a message with

  • a public key, you get a single signature.

  • But people who knew how it worked under the hood said, oh, I can change this code. It

  • will still be accepted as a valid signature even though I'm using a different signing

  • scheme. So this is one issue, stake grinding. There's ways to get around it.

  • So let's say you make it deterministic. You have some way to enforce that a signer can

  • only create one message. There are certain signature schemes where you can verifiably

  • make sure that a single key can only make a single signature on a message.

  • Other ways to do it is to, say, have this big lead time, where the people who are signing

  • the next block are determined by entropy created days or weeks ago. So it's hard to know what's

  • going to happen in a week because it's a long period of time's worth of entropy going into

  • it.

  • OK. There's another issue with proof of stake called nothing at stake. So rehash-- rehash--

  • ha ha. So in proof of work, this happens, right? This happens just by accident, where

  • OK, there's a block. And then two people are mining on top of it. Oh, they both got this

  • and then sometimes even this. That almost never happens in Bitcoin, but sometimes, where

  • you just randomly get two split chains coming out at the same time.

  • But then this happens, right? Someone builds on this one. OK, you get rid of those two.

  • And that's just because this is a random process. You can mine on whichever you want. One of

  • them is going to happen first.

  • You can mine on both. You can split your hash bar. If you have a billion hashes per second,

  • you can say, well, I'll do 500 million here and 500 million here. You can equivocate.

  • It's sort of equivocation that way. But one of them will finish first, with very high

  • probability. So eventually, this happens. And then everyone just starts building off

  • this 00a3.

  • Proof of stake-- so this happens. Also, notice that the hashes don't-- they don't start with

  • zeros. So this happens. But then this happens. And then this happens. And then it just keeps

  • going. Because why not sign both, right?

  • I don't know which one's going to win, right? As a proof of stake miner or staker, I don't

  • really know which one's going to win, which is the same case and proof of work. In proof

  • of work, I just flip a coin and pick, right? I don't know what's going to win.

  • I think in bitcoin, the default is go with the one I saw first. Because whatever. It

  • doesn't matter who wins, right? Basically, I win, whichever I pick. If I'm the next one

  • making the block, I win.

  • But what I don't want is I don't want to be this this-- wait a sec. What I don't want

  • to be in proof of work is I don't want to be 008a, right? I don't want to be the last

  • one to make a block, and then something else comes out here.

  • So I'd rather be 00f2. But you don't know here, right? So you just pick one. OK. Well,

  • we lost. In proof of stake, you don't have to worry about that. I'll just build both,

  • right? It takes me no work to sign. So I just sign off on both of them and make parallel

  • chain. And then everyone just keeps doing that. Because if I pick one, I might be wrong.

  • If I pick both, I can't be wrong.

  • So this is a problem called nothing at stake. You have no risk here. You're not actually

  • doing any work. You might as well just keep going. So yeah. Faced with two blocks, why

  • not sign both?

  • So the mitigations-- one of the ideas early in Ethereum was, OK, this thing called Slasher,

  • where if you can prove that a signature from a different chain-- so the idea is on chain

  • 00a3-- oh, wait-- oops. Sorry. On this chain, you say, hey, look. This guy equivocated.

  • He signed off on two blocks, one of which exists in my history that I can point to,

  • one of which doesn't exist in my history, but I can provide that signature. I can say,

  • look, here's two signatures at the same block height from the same person, but they're signing

  • different things. Let's not invalidate this block, but let's take all the rewards from

  • the person who signed.

  • OK. So yeah. This is called Slasher. I believe in Ethereum, like, 2014, they were saying,

  • hey, we're going to do proof of stake. And then they tried all these things and sort

  • of, oh, it's non-trivial. Let's start with proof of work, and then we'll move to proof

  • of stake later. And that's currently their plan. So this was one of their early algorithms,

  • their early ideas.

  • There's also issues with the mitigation because maybe it's hard to get this proof into the

  • blockchain. Because the miners, or the stakers, are the ones who determine what gets in and

  • what doesn't.

  • And so they certainly could say, look, if the person who created this block then sees

  • in this block that there's a Slasher proof where, hey, I just now proved that you equivocated

  • and destroy your account, well, the person who signed this doesn't build on this and

  • instead forks off and builds their own, right? Why would I continue to mine on a chain where

  • I just lost all my money?

  • So there's all sorts of weird-- and there's mitigations for that. So it's a little bit

  • whack-a-mole, where there's all these weird problems, and you have to try to fix them.

  • And then fixing them introduces new weird things. So there's a lot of people working

  • on it.

  • Yeah. Long-range attacks is another big one. Let's say you go back to the genesis block,

  • and you rewrite history. In Bitcoin, you can also do this. It's just really hard, right?

  • You could say, I'm going to get a bunch of miners, rewrite all nine years of Bitcoin's

  • blocks, and we know exactly how long that will take.

  • sipa has a nice graph of it, I think. And sometimes it's not very long. Sometimes it's

  • actually pretty easy to do that. Yeah, that's the other site. Hash rate-- this-- wait--

  • yes. Bitcoin network proof of work equivalent days. That's this year. This is since the

  • beginning.

  • What this means is, OK, given the current hash rate in Bitcoin, how long would it take

  • to rewrite the entire history of Bitcoin? Because the hash rate goes up, right? And

  • sometimes it goes up in-- so this is the all-time hash rate. It basically always looks like

  • this because it's exponential. So if you looked at it three years ago, it would look pretty

  • much the same.

  • And then this is a log chart. So this actually does show some interesting detail, where,

  • OK, this is when the GPUs came out. This is when nothing much happened in 2012. This is

  • when ASICs came out. And then it just keeps going up. And this is log scale, where each

  • number is 100 or 1,000 times. So it's big.

  • So when you have these really sharp upticks, like in mid-2010, the current power of the

  • network is so high-- that probably corresponds to this, the lowest point there, because that's

  • the steepest slope, where I don't know what this is, a week?-- you could rewrite the entire

  • history of Bitcoin in a week and destroy everyone's currency and have all the coins yourself if

  • you had enough power under your control, which you could probably do.

  • And today, it sits at around 200, a little less than 200, so a little over six months

  • where, if you devoted all the current hash power, you could rewrite all the previous

  • history. Still, six months-- it's a lot. And it's interesting how this changes. This is,

  • I guess, when the ASICs first came out, and then the slope [INAUDIBLE].

  • So that is an issue in proof of work that can happen. It's not clear what would happen.

  • The software, at least in theory, the idea is if something like that happens, where there's

  • a reorg that spans nine years, well, extend this out to 500,000 and say, OK, all the stuff

  • you've been dealing with the last nine years, it's out. We've got this new history now with

  • one person owning all the money, presumably.

  • The software will do that, probably, or it'll just crash or something. It's sort of seen

  • as like, well, if there's a reorg that spans weeks or months, the whole system's broken,

  • kind of. But probably.

  • So this is an issue for Bitcoin. But it's a big issue in proof of stake because it seems

  • possibly more feasible, right? In Bitcoin, there have been times when it's like, whoa,

  • a week, yeah, that's feasible, whereas right now, it's like, OK, it would take all the

  • hash power in existence maybe seven or eight months. So that means that Bitcoin would just

  • halt for seven months, and then you'd see this reorg happen. And also, it assumes 51%

  • of the miners are doing this.

  • However, proof of stake, it might not be that expensive, especially if you can get old keys.

  • So if you've got the keys from the genesis block in this proof of stake currency, you

  • can rewrite a history from those with different transactions. So yeah. So a lot of the times,

  • the solution is, OK, well, delete old keys and assume 50% honest.

  • That's tricky. Because old keys can be sold. And I know that people have asked, hey, can

  • I buy your old Ethereum keys? Why do you want these? Well, if proof of stake happens, they

  • might be worth something. Currently, if you have keys that are for addresses or accounts

  • that don't have any money anymore, it's not very useful but possibly can be sold. Yeah?

  • AUDIENCE: Most proof of work schemes that I'm aware of use a [INAUDIBLE].

  • TADGE DRYJA: A proof of stake?

  • AUDIENCE: Yeah.

  • TADGE DRYJA: Yeah. So you checkpoint it. So basically, to prevent long-range attacks,

  • the developers, usually, in GitHub, will just say, OK, well, the block hash here is this.

  • And so you can't reorg before that. But then, what's the mechanism for that? If it's the

  • developers just sticking in a checkpoint, that's not really decentralized.

  • AUDIENCE: In the example of Aircoin, there's actually a checkpointing [? software ?] that,

  • every few hours, forces a [INAUDIBLE].

  • TADGE DRYJA: OK. Well, that's even more not very decentralized. You've now got a pubkey

  • hardcoded into the code, which then calls out to somewhere and says, OK, what's the

  • correct block to be on? And then that key signs something, says, oh, go here. OK. Yeah.

  • That's pretty centralized.

  • So this is one that I think is-- it's hard, right? Because before these things happen,

  • it's easy to dismiss as like, this is crazy. That's never going to happen. Who's going

  • to go back and buy up all these old keys that people were supposed to have deleted? People

  • probably did delete them. You can't assume that they haven't.

  • And even if they did and you made this big reorg, well, everyone would know in practice

  • that that's not the right chain, similar to if there's a nine-year block reorg in Bitcoin,

  • everyone would know, OK, come on. We all knew what the blocks were yesterday. You can't

  • just tell me there's this entirely new history today.

  • And in practice, that's probably true, right? If there was a nine-year block reorg in Bitcoin,

  • probably, people would just ignore it. Similarly, in these systems, probably, they would ignore

  • it. But it's harder to reason about in these systems, I think.

  • But anyway. So proof of stake, there is a bunch of coins that use it. In a lot of cases,

  • they have centralization that's hidden in certain ways. I like the term Greg Maxwell

  • came up called trust laundering. It's not money laundering. It's trust laundering. You

  • sort of move where you're trusting and try to hide it.

  • Yeah. So very common. But this also deals with, OK, who gets the initial coins? Because

  • they have an enormous power over the system. So very common for altcoins-- less so now,

  • I think-- was start with proof of work, then transition to proof of stake. Do they still?

  • Not as much.

  • AUDIENCE: Now you don't need to do that because you [INAUDIBLE].

  • TADGE DRYJA: Right. So you just do ERC-20. Yeah. But it used to be, like 2014, 2015,

  • a lot of the coins would be, OK, proof of work for the first month, two months, whatever

  • it was, with some weird algorithm and Comodo gravity well and all sorts of weird stuff.

  • And then it would switch at a certain point to proof of stake.

  • So that proof of work period builds out the list of who owns what in a sort of provable

  • way. And then, from there, you can use proof of stake. Because you've got a, hopefully,

  • fairly well distributed set of who owns what.

  • Yeah. Some things still do this. And some things have hybrid, where you still have to

  • do work each block. But depending on how much stake you have, depending on how many coins

  • you have, you have to do less work.

  • I think decred is something like that. That actually can make sense. Because you've still

  • got work, and you can mix them in ways that negate some of the downsides of both.

  • Delegated proof of stake. Well, signing requires you to actually do something and be online.

  • So in a lot of proof of stake currencies, very few people actually stake because they

  • don't care. And they leave money on the table, sure. But they don't want to run their own

  • node. They don't want to deal with this stuff. They just buy it, keep it on exchange, or

  • maybe keep it on their own computer.

  • So instead, you can endorse a leader by signing with your coins and saying, hey, I'm not going

  • to actually sign off on blocks, but I'll sign off on a different key, who now can sign on

  • my behalf. And so this can be called supernodes, masternodes. And then is it peer-to-peer,

  • or is it client server is what it becomes.

  • So the current one that's pretty popular is called EOS, where I think they're doing this

  • kind of thing. And they're like, well, there's 20 computers that run the network. And you

  • can endorse one of them, and they'll give you some kind of profit back or something.

  • And you need a million dollars to run one of these computers. Because it's going to

  • be super powerful, and you can do free transactions that way.

  • So this gets pretty far into client server territory, where you're not up here. You're

  • just the client, and you ask them what is going on, which, in many cases, works, right?

  • But then again, it's not quite as interesting because that's sort of the system we already

  • have with banks. So meh.

  • But in a lot of cases, yeah, that's what people want. I sort of joke that I should just make

  • one called Central Coin, where there's just a nice server, and it just keeps track of

  • who owns what, and then have an ICO. And people would use it. It's like, hey. So I think people

  • would be into it. Anyway, so that's distributed proof of stake.

  • OK. So proof of stake, in general, it's hard to resolve conflicts using only the system

  • itself. Proof of work has this really nice property where it's taking something from

  • the external world, be it CPU time, be it chips, and using that to get a dead reckoning

  • on the system itself. That's nice.

  • Proof of stake, the really difficult part is it's a closed system. You're trying to

  • resolve conflicts within the system using no external data. That's really hard.

  • Another problem people complain about is that the rich get richer. I agree it's a problem.

  • It kind of sucks. But proof of work is the same. I don't feel like any of these systems

  • will change the inherent Pareto distribution of wealth in the universe. That just seems

  • to be how things work. It'd be cool if everyone had the same amount of money, I guess, maybe.

  • But I don't think it's going to happen.

  • Yeah. And then it relies on different assumptions. So the assumption in Bitcoin is 51% of miners

  • can destroy the system. So in some cases, people say, well, you assume 51% honest in

  • Bitcoin. Kind of. It's more like 51% rational. In Bitcoin, you could have miners with 51%

  • attack the system, but they make more money by doing the right thing.

  • So there are certain cases in proof of stake where honesty is not as profitable. And if

  • honesty is not profitable, well, maybe there's a lot more incentive to be not honest in the

  • terms of the system, whereas in Bitcoin, it's like you've got this nice system where it

  • seems like the honesty is not just enforced by people trying to be nice. It's enforced

  • by people being greedy, which seems more common than being nice in the world.

  • So there's tons of research in proof of stake. Some of it's pretty interesting, pretty clever.

  • I'm not super hopeful. But the thing is it works until it doesn't. And so it's really

  • hard to show security under different attacks.

  • So what I would worry about is you've got this proof of stake system. It seems to be

  • working. And then something weird happens. And it's revealed as, oh, actually, this was

  • a lot more centralized than it seemed to be, which is also a worry in proof of work. OK.

  • Any questions, proof of stake? Yes?

  • AUDIENCE: A quick one on the economics. Is the stake the nodes have. Yeah, right. So

  • in essence, if it was on EOS, it's how many eos coins you have.

  • TADGE DRYJA: Yes, yes.

  • AUDIENCE: So then there's probably some economics where people who are not miners will lend

  • their stake to get a return.

  • TADGE DRYJA: Basically, yeah. And a lot of coins, the majority of the coins, are held

  • on different exchanges. And so that means the exchanges would possibly be able to then

  • stake and get some kind of revenue.

  • AUDIENCE: Right. So they would be taking their customer funds that are in wallets-- they

  • would have to be, probably, hot wallets-- and then the exchanges would have a leg up

  • to be the miners.

  • TADGE DRYJA: Yes.

  • AUDIENCE: Or a [INAUDIBLE].

  • TADGE DRYJA: Yeah. And so that's also an issue, that there's all different ways to mitigate.

  • And you can say, oh, I'm in an exchange, but I get to sign and delegate my stake to someone

  • else. And then I get some kind of revenue sharing from that.

  • But yeah. It's also tricky, how do you incentivize it in terms of how much new coins get issued

  • to the people staking? If it's zero, then there's no real incentive to do it. You could

  • have a lot of different chain ports.

  • If it's very high, then it's very, I don't know, Gini net curve goes way crazy because

  • the rich really get richer. Because the more coins you have, you have an enormous amount

  • of revenue. So you need a balance there that's also a bit difficult, economically.

  • That's also a problem in proof of work. I feel like one of the big issues with Bitcoin

  • is half the coins came out in the first four years, where hardly anyone was aware of it.

  • And that makes people not want to adopt the system. Because it's like, well, wait. You

  • guys just got all this coin for, basically, free. You were just running your computer

  • in 2011. I'm not going to be part of that system.

  • So I feel like it would have been nicer if it was more of an S curve and less of a log

  • curve. Because then, maybe it would ramp up to 2015, and then lots of coins were coming

  • out. But anyway.

  • So Ripple or Stellar are sort of an extreme case of that, where all the coins were initially

  • made by one entity. And so to me, I'm like, I don't want these. That's your money. You

  • just made it up yourself.

  • I don't know. It just feels like kids being like, I have a bazillion dollars, and I write

  • a bazillion dollars. It's like, OK. Well, you just wrote that. I'm not going to honor

  • that.

  • Anyway. OK. So proof of stake, kind of interesting. Proof of space, there's a bunch of ideas here.

  • Some of them-- SpaceMint was some people here. I know Bram Cohen, who is the author of BitTorrent,

  • right-- he made BitTorrent whatever 10, almost 15 years ago now-- he's now working on some

  • of these kind of things.

  • He's working on a proof of space coin called Chia. And the idea, it's still similar to

  • proof of work. But you're using some kind of memory or storage space, rather than your

  • CPU. And the idea is the benefit is, well, maybe it doesn't use as much electricity.

  • And also, from talking to Bram with his, he's saying there's much more dead storage space

  • than dead CPU. So every computer has a CPU, but the CPU here is not that powerful. It

  • can't really compete with ASICs. But lots of people have empty hard drive space.

  • And you might have a terabyte of empty hard drive space, and one terabyte's as good as

  • another. And it's also empty is what you need. Because you need to fill in space for these

  • systems.

  • And so if you're like, well, I'm AWS, I've got tons of hard drives-- right, but people

  • are using them. So you're not able to then just fill it in for these kinds of systems--

  • well, to some extent. They do have a lot of slack, and they can probably do it. But several

  • ideas. Some are pretty cool.

  • So one example-- this is sort of an example idea. It's not fully fleshed out, but to give

  • you an idea. So you buy a 10-terabyte drive, OK? You precompute 100 billion key pairs.

  • And this takes a long time. And this is work, right? You're doing 100 billion computations

  • of coming up with the random private key, multiplying by G, getting the pubkey.

  • And you store it in a key-value store, like a database-- LevelDB or something-- on your

  • hard drive. And the key is the pubkey. And the value is the private key. So you remember

  • your key pairs. But you've sorted it in a way so that you can quickly go through the

  • pubkeys, right? So you have logins, search time, some kind of binary tree-- whatever

  • it is-- in your database.

  • And so then, the idea is, to create the next block, you want the key closest to the current

  • block hash can sign. So a valid proof of work-- you have some threshold, maybe-- a valid proof

  • of work is whoever's got a key that's very close to this, they're able to sign. And those

  • keys do not exist on the network prior to the signing procedure. They exist just hidden

  • on people's hard drives.

  • And so the idea is you could just try to keep computing keys till you find one and then

  • sign with it. And that would just make it completely proof of work. So it is proof of

  • work. But the idea is you can precompute. You can do all the work beforehand.

  • And then you can use that precomputed proof of work later on and possibly multiple times.

  • In practice, it's not going to be multiple times. Because you've got 100 billion, and

  • you're never going to use the same key twice.

  • The idea is everyone does this, right? So you have trillions, quadrillions, however

  • many keys out there that everyone's generated. And every block that comes out, someone will

  • say, ah, I was lucky, and I made a key that can now sign the next block.

  • So it's work, but it's amortized over weeks, months, years. And it's basically how big

  • is your storage. If you have a lot of storage, you can precompute a lot of this stuff and

  • then use it. So it's kind of a cool system.

  • There's other asterisks that actually get a little more complex because you need some

  • timing mechanisms, as well. But I think it's a cool idea. Hard drives then maybe get more

  • expensive instead of graphics cards getting more expensive. I don't know.

  • But the idea is like, yeah. You use the work but later on. So I don't know. Any questions

  • about that one? Kind of cool. There's a SpaceMint-- it's a cool paper-- about how to do this cryptographically.

  • And then Chia is another one doing this kind of idea. I like it because it doesn't really

  • change the assumptions of proof of work, right? It is still a form of proof of work. But instead

  • of burning electricity, you're using hard drives. Kind of cool.

  • AUDIENCE: Wouldn't you still have the same issues, like you'd have to have ASICs just

  • filling racks and racks and racks of hard drives for keys. Is it different?

  • TADGE DRYJA: You already have that, right? There's server farms where they're just storage

  • farms, and they just have tons of hard drives. So that's already a thing.

  • AUDIENCE: But I'm saying it isn't any different. You'd still be-- it would be [INAUDIBLE]--

  • TADGE DRYJA: I guess the idea is the economies of scale are not quite as bad in that hard

  • drives are already, basically, optimal at doing this. And if you can make a system that's

  • better at doing this, you've just made a better hard drive, which, hey, great. You made a

  • better hard drive. Everyone can use it. So I guess the idea is it's not as specific because

  • it's just, hey, store a bunch of data and then [? seq ?] quickly through it.

  • AUDIENCE: It still seems CPU-bound, right, compute-bound.

  • TADGE DRYJA: No. Once you generate this-- OK, generating this is compute-bound, right?

  • You need to populate your 10 terabyte drive. But that might only take a few hours, right?

  • To make 100 billion key pairs, I'm guessing less than a day, right? Yeah. And you can

  • do that in parallel. So you make it. And then once you've made it, you leave it there. And

  • then you're going to be able to mine with that forever.

  • AUDIENCE: But see, the winner would be whoever can fill the most number of keys per second

  • going forward.

  • TADGE DRYJA: But you need something to fill. I think the hard drive cost is much higher

  • than the cost to fill it, right? Because a 10 terabyte hard drive is going to be, like,

  • $200. And with a cheap CPU, you can fill a 10 terabyte hard drive every few hours. So

  • yeah, the CPU is a factor, but I think it's going to be smaller. Yeah?

  • AUDIENCE: At least from what I understand about SpaceMint, the idea is to make it not

  • I/O bound [INAUDIBLE]. So if I have a better or faster hard drive, that's not [INAUDIBLE].

  • It's just [? another ?] space.

  • TADGE DRYJA: Because yeah. This is just a seq, right? And even a crummy hard drive,

  • you just read through your binary trainer. You're like, oh, found it.

  • AUDIENCE: I think the point is that you're only supposed to do one with those pub [INAUDIBLE].

  • AUDIENCE: Yes. [INAUDIBLE].

  • TADGE DRYJA: So you look at, OK, here's the current block hash. What do I have that's

  • close? Seq to that on my drive. Nope. I'm not going to win this one. OK. Let someone

  • else do it. Or you seq, and you find it. You're like, hey, cool. I can sign. Yeah?

  • AUDIENCE: Is this also known as proof of space and time?

  • TADGE DRYJA: Yeah. So in Chia, they add this time component, which I'm not 100% clear on

  • how it works. It's changed a little bit. But the idea of a time beacon is you want some

  • function that cannot be parallelized so that if you have 100 computers doing it, it's not

  • going to be any faster than one computer doing it. So basically, whoever's got the fastest

  • single CPU will always win this. And that can be a time beacon for these space things.

  • Yeah?

  • AUDIENCE: Once you start to have a lot of storage, if you're in a search will find [INAUDIBLE],

  • do you kind of go back to-- you're almost getting hurt. [INAUDIBLE] So what I'm saying,

  • you're just doing the same thing again?

  • TADGE DRYJA: I think that's a [INAUDIBLE]. If you have tons of hard drives, and you want

  • tons of key values, and you just want to find one or find the closest match, you can do

  • that in log n time, even over a whole data center. Google, you just search, and it's

  • like, hey. It comes up in a fraction of a second.

  • So that's doable. You need good software, and you need a good infrastructure to do it.

  • But I think it's doable. It scales pretty well, I think.

  • But yeah, it has the same issues where you just end up with people buying a whole bunch

  • of hard drives. And what are the economies of scale there? There's arguments that it

  • might be better than the economies of scale with, like, ASICs, that we heard about on

  • Monday. Maybe not. I don't know. We'll see if this takes off. It's fairly new. It's an

  • idea that's been talked about for a few years.

  • AUDIENCE: It's [INAUDIBLE] space. And they've been around for years in this [INAUDIBLE].

  • TADGE DRYJA: OK. Well, so there's different ideas. I don't know. It seems like one of

  • the more interesting. There's cool math and cool crypto involved. OK. So it'll work but

  • amortized.

  • So and perennial MIT favorite, IOTA, they use a directed acyclic graph. And now, a chain

  • is also a DAG. Because it's directed. There's no cycles. It's a graph. But it's a pretty

  • simple one. But the ideas have multiple parents, right?

  • So if you have a block, instead of just pointing to one, you could say, well, now, this can

  • happen in Bitcoin, right, where you've got two blocks, both supporting the same thing.

  • But this cannot happen in Bitcoin, where you say, oh, I'm coming off, and I'm referring

  • to both of these. But in a directed acyclic graph, you can do that.

  • So Ethereum actually does it. I think Joe Bonneau was mentioning that. And so what happens

  • is you endorse one as the correct one and one as the uncle. So you're saying, no, this

  • is the real one. But I also saw this one. And give this one a little bit of money, right,

  • maybe not the whole reward they were hoping for. But they get something.

  • And so then, something like IOTA says, OK, we have lots. And every node points to two

  • previous. And so you get this whole map. They could even point to different heights. So

  • I can point to here and here. I don't really know why you'd do this.

  • So there's some ways it could reduce latency, right? So one of the trade-offs in Bitcoin

  • is 10-minute block time seems fairly arbitrary. It's kind of slow. Latency-- people don't

  • like latency because they have to wait. Fine.

  • The more important metric, I think, is that it leads to miner centralization and miner

  • pools. Because if there's only 144 blocks a day, like in Bitcoin, if you have a millionth

  • of the hash power of the network, you're just never going to find anything, right?

  • If you're just mining on your own, over the course of a year, you're probably not going

  • to find a single block, and you'll have wasted all of that effort. So instead, you join a

  • pool and try to pool with other people to distribute those rewards.

  • However, if there's, like in Ethereum, a block every 15 seconds, and there's millions of

  • blocks that come out, if you have a millionth of the hash power, you might find a block.

  • The blocks have smaller rewards, but chopping it up more finely is a nice way to do it.

  • So like P2Pool, which you were gone, is a way to try to make that. And it's important

  • to get it more decentralized. But it's hard. Yeah?

  • AUDIENCE: P2Pool does that?

  • TADGE DRYJA: Yeah. Yeah. P2Pool sort of does this as a layer on top. So it could help latency.

  • And then, it could help reduce the amount of orphans in the blockchain, which then helps

  • miner centralization. So there are interesting ideas for it.

  • But it doesn't help scalability at all, right? It actually hurts scalability. Because now

  • I have to keep track of all these things instead of just one chain. And I'm going to have to

  • keep track of all the data, anyway, if I've got the UTXO set. I can't just ignore parts

  • of it.

  • So it doesn't help scalability at all. And in the case of IOTA, their custom ternary

  • hash functions also don't help much, either. So that was what we wrote about last year.

  • They made all their own weird stuff. I don't know.

  • So there are interesting ideas between directly acyclic graphs. But it feels like when they

  • say, hey, this is more scalable, I get very suspicious. Because it doesn't seem to help

  • scalability. It does possibly help some other things. Yeah?

  • AUDIENCE: Is, effectively, Bitcoin refreshing [? test? ?] They've made it so every block

  • has min difficulty. And so the transactions are instant because, right, it doesn't change--

  • TADGE DRYJA: What, in IOTA, or in--

  • AUDIENCE: In any of these stack coins. So it doesn't cost much to make a new block and

  • make a transaction. And if everyone's competing to do that, then they're just another ton

  • of orphans, and [INAUDIBLE].

  • TADGE DRYJA: Yeah, yeah. So also, in the case of IOTA, the idea is-- well, they don't call

  • it this-- but it's the equivalent of saying every block must have one and only one transaction.

  • The transactions themselves have proof of work on them, and they point to each other,

  • which, basically, is the same as blocks have one transaction, and you do the work yourself

  • instead of paying a miner to do it.

  • I think that's not a great deal. And they say that that means there's no fees. I think

  • there's still fees. Because you're just doing the work yourself. I think that's equivalent

  • to saying, there is a refrigerator at Home Depot that doesn't use electricity. So hey,

  • it's electricity-free. But there's a crank on the back, and you have to crank it to make

  • the refrigerator cold.

  • Yeah, you could make a refrigerator that way. I don't think people would want it. You're

  • still doing the work. You just have to crank it instead of plugging in it. So the idea

  • of you don't have to pay miners a fee to get into a block because you just mine the block

  • yourself or, in this case, you mine the transaction yourself. Doesn't seem that useful.

  • Anyway, so IOTA's fun. We talked about them a while ago. OK. Last one, and it's fun--

  • proof of idle. It's an old idea that I wrote up four years ago, almost. It probably doesn't

  • actually work that well. But a lot of these things don't work that well. Even if it works,

  • it would just move the costs from opex to capex.

  • But what you do is you prove that you're not mining, and you get paid. And the other fun

  • thing about this is it led to some of the ideas in Lightning Network. So the idea is,

  • in Bitcoin, the difficulty adjusts so that blocks come out every 10 minutes, right? Every

  • 2016 blocks, you look at the timestamps, adjust the difficulty.

  • So new miners coming in make it harder for the existing miners. So if you're a miner,

  • you really don't want anyone else to start joining this network and mining. You really

  • like it as it is. So if you have the first ASICs, you're good, and you don't want everyone

  • to come in.

  • And this is why so many people buy mining equipment and lose money. Because they look

  • at the current difficulty, and they say, hey, here's this device. Here's how much electricity

  • it uses, how many coins it generates.

  • This is profitable. I'm going to buy this thing. And what they don't realize is that

  • by the time they actually get it, or maybe a few weeks later, the difficulty is doubled.

  • And now it's making half as many coins for the exact same amount of electricity.

  • So yeah. And that's a fairly unique property of bitcoin that's not the case in, say, gold

  • mining or other extractive industries. There's some kind of curve in gold mining where if

  • you pay twice as much money to have twice as many people dig holes and mine gold, you

  • won't get twice as much gold. Maybe you'll only get 10% more gold. But you will get some

  • more, right? And if you drill for oil, you pay twice as much, you'll get some more. But

  • yeah?

  • AUDIENCE: And it's worse than that. Because you're still obligated to mine. Because making

  • $0.50, they're making half as much as they're going to make, it's still better than making

  • nothing.

  • TADGE DRYJA: Yeah. So that happens, too. So yeah, in Bitcoin, two times the mining leads

  • to 1X the coins mined, right? There is zero marginal product of labor in this system,

  • which is weird and counterintuitive and doesn't really exist in normal life.

  • Most things have some kind of sublinear curve, where, yeah, the first low-hanging fruit--

  • if you're mining coal, and you start in Pittsburgh, and it's just sitting there on the hill, and

  • you're like, hey, that was easy. And then, eventually, you have to start open pit mines

  • and digging holes. And it's expensive, and you don't get as good. But you still, if you

  • double your effort, you're going to get some extra stuff out.

  • Then again, there might be cases, I'm sure, in economics, where eventually, it goes negative,

  • where if you continue adding members to an organization, eventually, they're just like

  • deadweight, and they make it less efficient or something. But in Bitcoin, it doesn't matter

  • how much you mine. You always get the same number of coins.

  • So the obvious thing there is, well, we should all just stop mining. And then we'll have

  • zero electricity usage, and we'll still get the same amount of coins.

  • AUDIENCE: The example is Nobel prizes. It doesn't matter how many academics chase them,

  • there's a unique number [INAUDIBLE].

  • TADGE DRYJA: OK, yeah. Yeah, that's another. Yeah. However good the science is, you just

  • get one Nobel Prize. So OK. So let's say there's two miners. And there's, obviously, more.

  • And they're each mining with 2 gigawatts.

  • And they both think, well, wait. If we both turned our mining down 5%, we'd still get

  • the same amount of coins, but we'd be using 5% less electricity. We should have a meeting,

  • maybe some kind of cartel.

  • So this is sort of OPEC, right? This is a classic cartel. If we all restrict our output,

  • we can raise prices and reduce our costs. In Bitcoin, it's the perfect cartel environment.

  • Because if we all reduce our output, we get the same output, sort of, right? If we all

  • turned down mining 50%, we all still get the same number of coins. The network still works

  • fine. Maybe nobody even knows we're doing this. This is ideal cartel scenario.

  • Problem for cartels, generally, is that cartels are hard to maintain, especially when there's

  • not a lot of trust. Because there's so much profit in defecting and going against the

  • rules of the cartel. And OPEC has this all the time, where one of the OPEC countries

  • says, we're just going to pump a bunch of oil and sell it. Because everyone else reducing

  • their output raises the prices. And now we can sell more with higher prices.

  • So in this kind of system, if all the miners said, hey, let's all turn down 50%, the one

  • miner who then mines at full blast is going to make a lot of coins. So this is the problem.

  • In Bitcoin, nobody trusts anyone, right?

  • So the solution here is trustless collusion. And in the papers, I was like, well, is it

  • collusion or cooperation? They both sort of mean the same thing. And collusion is just

  • a bad word for cooperation. Cooperation's good. It's on Sesame Street.

  • OK. So the basic system is Alice pays Bob not to mine. So first thing, Alice needs to

  • prove that Bob can mine. Because she doesn't want to pay Bob if Bob doesn't have any mining

  • capacity that he's taking offline. She only wants to pay Bob for having the ability to

  • mine and then not doing.

  • So A posts a block header at a specified time and says, OK, B, mine for 10 seconds, and

  • give me your 100 best shots, right? So in Bitcoin, you have this fixed difficulty. And

  • you just say, OK, anything below this block hash is valid.

  • But you could make one where you say, hey, give me your best 100, and I can then extrapolate,

  • or interpolate, from that what your hash rate is. And you can get pretty accurate. So they

  • have to do some work, right?

  • Bob does some work but for a brief period-- I don't know, 10 seconds. You don't want latency

  • to be an issue, so maybe 10 seconds, maybe a minute-- whatever-- some small amount of

  • work to prove that they have the capability to do the work. They respond with that. And

  • Alice validates it and says, OK, you've got X amount of work capacity.

  • Alice then creates a 2 of 2 multisig transaction and sends one bitcoin to this address and

  • builds two transactions with Bob. This is sort of like, how Lightning Network looks,

  • Lightning Channels. But this predates it by a year or two.

  • So the idea is you've got this funding, and then you've got two transactions. They're

  • both signed by both parties and held by both parties, although in practice the one that

  • pays out to Alice, Bob doesn't really need to store. He doesn't like it. And the one

  • that pays out to Bob, Alice doesn't need to store.

  • But the idea is they have conflicting locktimes. So in the transaction header, you can have

  • a locktime, say, OK, this transaction is only valid after this point. So the one that pays

  • Alice is height plus 144. So the current height of the blockchain plus 144, well, that should

  • take about a day, right? If blocks come out every 10 minutes, 144 blocks is one day.

  • For Bob, Bob gets a coin with the current locktime plus 24 hours. So in Bitcoin, you

  • can specify either Unix time or block height. And I think everything above 500 million is

  • a time. Everything below 500 million is interpreted as a height, which means this whole system

  • runs out in a couple thousand years.

  • So this is a race, right? There's two transactions. One of them can be broadcast first, depending

  • on how fast blocks come up. So if blocks come out very quickly, this will be valid first--

  • 144 blocks. Maybe it only takes 20 hours, and these 144 blocks have come out. And Alice

  • can post this transaction and get all of her money back, get her one coin back.

  • However, if blocks come out slowly and, after 24 hours, only 120 blocks have come out, Bob

  • can post this transaction first. And it will be valid and confirmed, and Bob gets the coin.

  • So now Bob's incentives are, well, I'd like 144 blocks to take longer than 24 hours. Because

  • then I'll get this coin.

  • And Bob has the means to influence this, right? Bob's a miner. So Bob can say, well, I'll

  • just mine less. And if I mine such that, in 24 hours, only 130 blocks come out, I get

  • the coin. Cool, right?

  • If blocks come out fast, on the other hand, Alice gets her money back. So Alice has no

  • real risk here that Bob will run away with the money without doing his part of the job.

  • So Bob can slow down his mining in order to get the bounty coins. If Alice estimates incorrectly

  • how much profitability Bob has, Bob just keeps mining. Alice gets her money back. This collusion

  • didn't occur, at very little cost, right? Bob had to prove a little bit. There's some

  • coordination costs. But basically, nobody loses the money.

  • So Alice can put whatever bounty she thinks is beneficial to her. OK, I'll pay you three

  • coins not to mine as much. And you can chop this up. You can have a lot of different,

  • smaller transactions and make a curve. If you mine a lot less, I'll pay you more-- things

  • like that.

  • Yeah. So that's the idea behind proof of idle. It feels like it might happen, to some extent,

  • long-term. It feels sort of like nuclear weapons, where everyone's got them, but they don't

  • really use them. They just threaten.

  • So it feels like mining could be that kind of thing, where, well, we've all got all this

  • mining capacity, but we just threaten each other with it, and we don't really mine. Because

  • the mining's actually really expensive, and it's just the threat of mining that you need.

  • And if someone tries to do, say, a 51% attack and reorg, the existing mining infrastructure

  • can spin up and say, oh, no. You thought you were 51%. You were actually 5.1%. And we're

  • 90% offline. And we all come back online and reorg you out.

  • It's an interesting-- I think it's a fun idea. In practice, it doesn't work now because it's

  • mostly capex. So this doesn't help if your main constraint is building the chips, which

  • it sounds like it still is, from David's talk on Monday, right? Yeah, you need to get electricity,

  • sure. But also, the really big problem is getting a supply of all these chips.

  • And this would just exacerbate that. This would make it so that I don't even need electricity.

  • I just get the chips. I don't really care how much I'm paying in electricity because

  • most of the time, my chips sit off. I just need to occasionally prove I have them and

  • have the ability to mine with them.

  • So it wouldn't solve the problem of proof of work in terms of people spending tons of

  • money on it. But it would move it towards less electricity usage, more fabrication plant

  • usage. Is that a good thing? Is that a bad? I don't know.

  • And in certain cases, it may be that it saves people money. It may be that, hey, if we can

  • collude in this way, actually, we save money. And then we can use it to build more hash

  • power.

  • So this might happen. I was sort of convinced in 2014. I'm like, oh, I think this is going

  • to happen. I also thought that it would become predominantly opex in 2015 or '16. And it

  • just didn't-- not even close. So who knows? But it's, I don't know, kind of a fun idea.

  • OK. So in general, lots of new ideas out there. Proof of work does seem to work. But I think

  • one of the big issues is it's not really compatible with the Kurzweil/Roddenberry future idea.

  • Has anyone read Ray Kurzweil, like, Age of Spiritual Machines?

  • It's sort of this futurey AI is going to make everything great, and we're all going to live

  • forever, and computers are going to be our best friends, and we're going to take over

  • the universe. And Gene Roddenberry of Star Trek is sort of a popular, not quite as crazy--

  • maybe just as crazy-- view of that.

  • In Star Trek, they don't have money. They just sort of explore the universe and make

  • the world a better place and stuff like that. And it's like, cool. And there's a lot of

  • people who are into technology and research who are, maybe not consciously, but identify

  • with these ideas, like, yeah, we're making the world a better place. Computers are going

  • to help people, and it's going to be great.

  • And I think one of the issues with Bitcoin and proof of work is it doesn't fit into that,

  • right? It's sort of dystopian, in a way. And then, it's like, wait. We're going to have

  • giant server farms performing SHA256 for the next 50 years? Like how? How does the benevolent

  • AI fit into this system?

  • So that's one of the reasons people-- the proof of idle idea was-- I was at University

  • of Virginia, and Avi Shalot, who's now at Northeastern, he was like, I hate Bitcoin.

  • Because the whole point of SHA256 is that you can't find collisions. That was the design--

  • collision-resistant hash function.

  • And now, you've built this giant system, which the whole point of the system is to find collisions.

  • Like, ah. That's the opposite of what it was supposed to be. And so it was just sort of

  • inelegant and ugly. And that was where I'm like, well, maybe you don't really have to

  • mine that much. And so I wrote this thing about proof of idle.

  • But anyway, that's one of the issues that people have with proof of work. And that's,

  • I think, one of the big motivating factors for all this other research into different

  • consensus algorithms. And further research is required, maybe.

  • The interesting thing is a lot of the people doing proof of work are fine with it, right?

  • So like David, Monday, he's not interested in proof of stake. Despite the proof of work

  • ecosystem being so crazy, he's just like, nope, this is what I'm doing.

  • So none of the miners are interested-- I mean, miners, their job is to mine. So they're usually

  • not interested in proof of stake. And then Bitcoin, in general, a lot of it's like, no,

  • this seems to work. We're OK with it. This is the cost we're willing to bear.

  • But other people want to do other systems. So further research is required, or not. But

  • it's happening. There's tons of research into different consensus mechanisms. I would say

  • in academic research, that's the biggest thing.

  • What I would like to see more of is more academic research in proof of work. Because there's

  • a little bit, but there's all sorts of interesting things with proof of work where it's like,

  • oh, something like proof of idle or something like the stuff David was talking about on

  • Monday. There's not much economics research into this.

  • And I think it's a really interesting question, where you've got, hey, I've got a device that

  • prints money, and I want to sell it to you. What? How does that work in terms of economics?

  • How much should I sell it for? How much should I buy it for-- things like that. So there's

  • a lot of new research into new proof of stake, different consensus mechanisms, economics

  • that way and not as much into new forms or how proof of work works, which I think is,

  • actually, really interesting.

The following content is provided under a Creative Commons license. Your support will

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級

22.22. 替代性共識機制 (22. Alternative Consensus Mechanisms)

  • 1 0
    林宜悉 發佈於 2021 年 01 月 14 日
影片單字