Placeholder Image

字幕表 動画を再生する

  • The following content is provided under a Creative

  • Commons license.

  • Your support will help MIT OpenCourseWare

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

  • at ocw.mit.edu.

  • NEHA NARULA: Welcome back.

  • Today, we are going to talk about forks.

  • So I think you guys have had a guest lecture last week

  • from Alin Tomescu, who talked about his project, Catena.

  • And one of the really interesting things about Catena

  • is that he's trying to prevent a server from equivocating.

  • So he's trying to keep a server from being

  • able to say one answer to some people and another answer

  • to another person.

  • That's kind of the goal of this whole blockchain thing.

  • But there's actually something really complex

  • that happens when we start to change what's

  • happening in the network, and we start

  • to change the software that's happening in the network.

  • And so this lecture is going to be about forks.

  • And I want you guys to feel free to raise your hands

  • and ask questions during class, because this stuff is actually

  • kind of non-intuitive sometimes.

  • So a blockchain is a chain of blocks which have previous hash

  • pointers inside of them.

  • So a question-- can a block point to two previous blocks

  • at the same time?

  • Anybody know the answer to this question?

  • No, exactly, that is the whole point.

  • There is exactly one spot in the block header

  • for a previous hash block.

  • And so a block can only point to one previous block.

  • A single block cannot point to two previous blocks.

  • However, can this happen?

  • Can two different blocks point to the same previous block

  • header?

  • Yes, yes, and this happens all the time.

  • Now, part of the reason that this happens all the time

  • is because the way that blocks are

  • found in the bitcoin network is completely probabilistic.

  • There are many people who are trying

  • to find the next block at the same time.

  • And it's entirely possible that two different miners

  • will get lucky in a time period that

  • is within the time it takes for a block to get gossipped

  • around the network.

  • And so, totally, two people can find the same block

  • at the same time.

  • This is actually what's known as a fork.

  • And you can kind of see why.

  • We have a fork in the chain right here.

  • But what does it really mean when

  • there's a fork in the chain?

  • I just told you that this is something

  • that happens all the time.

  • And these cryptocurrency networks seem to keep running.

  • They seem to be keep going.

  • So perhaps it's not as bad as it seems,

  • even though it seems to be violating

  • one of the major tenets of what a blockchain is.

  • Well, it is kind of bad, actually,

  • because when you have these two blocks here,

  • is there anything that makes one the right blockchain

  • over the other blockchain?

  • Just if this is one blockchain right here,

  • and this is another blockchain right there,

  • how is one supposed to distinguish between this?

  • Yeah?

  • AUDIENCE: The one with the most work.

  • NEHA NARULA: The one with the most work,

  • OK, that's a great sort of way of thinking about it.

  • What if they have similar amounts of proof of work.

  • Then what?

  • AUDIENCE: The one that's accepted

  • by the majority of the network.

  • NEHA NARULA: The one that's accepted

  • by the majority of the network.

  • How do we know which one is accepted

  • by the majority of the network?

  • It gets extended, OK, great.

  • So that's a really good way of looking at it.

  • Before we go into what that means,

  • do people understand why if this state were to persist

  • it would be a really bad situation?

  • One thing that we could have, given

  • that there's two blocks, what that really means

  • is that we have two versions of history.

  • We have two versions of the ledger

  • if these two things are not the same.

  • Different coins might be spent on one side of the fork,

  • versus on the other side of the fork.

  • In fact, the same coin might be spent in two different people

  • on either sides of these forks.

  • And so over here, Alice might be spending her coin to Bob.

  • Over here, Alex might be spending that same coin--

  • and, remember, coins can only be spent once.

  • Even if Alice has other coins, she

  • specifies which coin she's spending.

  • Alice might spend that coin over to Carol.

  • And so if Bob sees this, he thinks he got paid.

  • If Carol sees this, she thinks she got paid.

  • And we violated one of the fundamental tenets

  • of the blockchain, which is not to double spend coins.

  • You can't create money out of nowhere.

  • If these two things would persist,

  • if we don't resolve this fork somehow,

  • then we literally have two different versions

  • of the same currency.

  • This is kind of as though I took the money

  • in my pocket, my dollar bill, and I xeroxed them all,

  • and managed to convince some people that the Xerox was also

  • real.

  • This is the exact same thing as what's

  • happening when you have these two things persist.

  • OK, so how do we fix it?

  • Well, which is the right one?

  • And just given what I've shown you right here,

  • it is not clear which is the right one.

  • And like I also said, this happens all the time

  • in the bitcoin network because the bitcoin network

  • is probabilistic.

  • So the way that people figure out which one is the right one

  • is they wait.

  • They wait and see which side gets extended.

  • And by the nature of probability,

  • one side is going to eventually win out, and get extended

  • more often than the other side.

  • It's very unlikely for two forks to randomly sort

  • of probabilistically exist at roughly the same way

  • for the same amount of time for very long.

  • Now, as someone said, you might look at this.

  • How do you distinguish between these two things?

  • There is this common idea that in blockchains we

  • take the longest chain.

  • Longest is a little bit misleading actually.

  • It's not the longest chain.

  • It's the heaviest work chain.

  • So we pick the chain that has the most proof of work

  • on it, even if that happens to have

  • a smaller number of blocks.

  • Usually that's not the case.

  • That's not what happens.

  • The reason for that-- does anyone

  • know why we take the heaviest chain instead of the longest

  • chain?

  • AUDIENCE: So that nobody can cheat and lower

  • the level of difficulty.

  • NEHA NARULA: Right, so it's not very easy to do this.

  • But over time, someone could slowly

  • decrease difficulty level, and then

  • create a nice, really long chain with many low difficulty

  • blocks, and then say, hey, I've got the longest chain.

  • I have the most number of blocks.

  • Despite the fact that your chain has more proof of work on it,

  • you should all take my chain.

  • And they could do that with less than a majority

  • of the hash power.

  • Now, this is not easy attack to do.

  • But it is a possible attack.

  • And so that's why we take the heaviest chain, which

  • represents the most hash power in the system, the majority

  • of the system.

  • So forks happen all the time.

  • Forks are normal.

  • The way that people who see forks decide

  • which side of the fork to use, is they

  • check and see which one has the most proof of work,

  • the heaviest proof of work.

  • Now, one thing that's kind of cool,

  • is, as you probably learned about two classes ago,

  • even SPV nodes, even clients, can

  • tell which chain has the most proof of work

  • simply by looking at the headers, the block headers.

  • They can see what the difficulty is.

  • And they can measure for themselves

  • which side of the chain has the most proof of work.

  • They don't even need all of the chain.

  • So this is a nice property of light clients,

  • is that they can download all of the block headers

  • and immediately tell which side of a fork

  • has the most proof of work.

  • Great, we call the block that ends up-- so what

  • do we do with this block?

  • Does anyone know what actually happens with this block?

  • Anybody?

  • OK, so this book is basically abandoned.

  • This block is just left.

  • It exists.

  • It points into the chain.

  • That's great.

  • In bitcoin, in particular, it's meaningless.

  • It doesn't mean anything.

  • Every transaction that was in that block

  • is not considered to have happened.

  • So those transactions need to be replayed

  • on the chain that ends up being the longest chain.

  • And this happens, like I said, all the time.

  • We call that block an orphan, because it doesn't have anyone.

  • It's kind of the wrong way around.

  • I mean, I think of this as a child.

  • But, whatever, this block doesn't have a parent.

  • But we call those blocks orphans.

  • And, again, remember, we pick the side

  • of the chain that ends up having the most proof of work.

  • Now, we draw these figures in two different ways.

  • Sometimes we draw the figures like this,

  • like there's this blockchain that exists out there,

  • that is written down, and that everyone is sort of looking at.

  • There's one blockchain.

  • But this isn't a logical representation.

  • In reality, there are many, many, many, many different

  • blockchains.

  • In fact, every node in the system

  • has its own version of the blockchain.

  • And it's what those nodes are doing together

  • that ends up deciding what the blockchain actually is.

  • So if these are nodes that are running the bitcoin protocol,

  • and when I say nodes, what's the difference

  • between a miner and a node?

  • AUDIENCE: Nodes verify transactions,

  • but miners push blocks.

  • NEHA NARULA: Exactly, so miners actually

  • create blocks in the system.

  • Miners have write access to the blockchain.

  • They actually produce new blocks.

  • People think a lot about what the miners are,

  • and what the miners can do.

  • And there's a lot of game theory thinking about the miners.

  • And, oh, what if they collude, but the hash power does this?

  • And sometimes we forget that nodes in the bitcoin network

  • are actually incredibly important too,

  • because it's the nodes in the bitcoin network

  • that are now creating blocks.

  • And, to be clear, someone could be a miner

  • and a node at the same time.

  • They're distinct roles.

  • The same entity could certainly run a node and be a miner.

  • But nodes are doing something really important

  • as well, which is they're reading all of the blocks.

  • And they're deciding which side of a fork to take,

  • and which blocks to accept and which blocks not to accept.

  • So let's say that these are all bitcoin nodes.

  • And this is what the blockchain looks like right now.

  • And we've used this figure multiple times.

  • Every block has a previous hash, which acts as a pointer

  • to the previous block.

  • Every block has a set of transactions.

  • And every block has a nonce, such

  • that when you take the hash of the block header,

  • you end up with something that has a sufficient number

  • of leading zeros.

  • It has valid proof of work.

  • So let's say that this is the state of the system right now.

  • And then, we see this new block come along.

  • So what happens here is that a miner has produced this block,

  • and has sent it out over the bitcoin network.

  • They've started gossiping the block around the bitcoin

  • network.

  • And so every one of these nodes, hopefully, will eventually,

  • if they're well connected, will see this block.

  • They're going to see the block at different times.

  • And they're each going to make an independent decision

  • about the block.

  • So every node is going to decide when it sees

  • this block what to do with it.

  • And there's basically two things it can do with it.

  • One, it can add it to its own local version

  • of the blockchain.

  • And number two, it can reject it.

  • Does everyone see why that is?

  • So sure, every node is maintaining this local copy

  • of a blockchain.

  • There is no single, global copy that everyone

  • is referring to physically.

  • There's no single database running the blockchain.

  • Every node has its own local copy of the blockchain.

  • Every node is making its own local decisions about

  • whether or not a block is valid, and about whether or not

  • it's going to add that block to its own local copy

  • of its blockchain.

  • So the way that the node decides this

  • is that it has a set of validation rules.

  • So it has its own set of rules, which are specified

  • by the bitcoin protocol.

  • And it checks that block against its set of validation rules.

  • So every node, every bitcoin node,

  • is constantly validating, constantly validating blocks.

  • Here are just some of the validation rules.

  • And we've talked about a lot of these sort of off and on

  • during the class.

  • So first of all, there's a max block size.

  • And the way that this works is if at any point

  • you fail one of these validation rules, you reject the block.

  • So first, the block has to be smaller than this variable max

  • block size.

  • At the moment, max block size is set to 1 megabyte.

  • Every single transaction in the block also has to be valid.

  • And what does that mean?

  • Well, it needs to be formatted a certain way.

  • And it also means that when we concatenate the script pub

  • key and the script sig together, and then run that

  • through the interpreter to evaluate

  • the script on the stack, it ends up returning true.

  • And if at any point, any transaction-- and not just

  • any transaction, any input in any transaction,

  • does not satisfy this, we reject the entire block.

  • Another thing that each transaction

  • needs to satisfy if it's valid, is if the transaction specifies

  • an end lock time, than that end lock

  • time needs to be greater than whatever is specified

  • in the transaction.

  • That transaction is now is now far enough in the future

  • that it can be satisfied.

  • The block as a whole needs to have valid proof of work.

  • So it needs to have a nonce, such

  • that when you hash the block header,

  • you end up with a hash that has a certain number of leading

  • zeros.

  • And what's really interesting is the protocol also

  • specifies exactly how many leading zeros there need to be,

  • depending upon how many leading zeros there have

  • been in blocks in the past.

  • There cannot be any double spends.

  • So given the version of the blockchain that I, as a node,

  • have, this better not be double spending any outputs.

  • There are some rules around what the block

  • can have as its timestamp.

  • It cannot be more than--

  • if I see a block that has a timestamp that's

  • more than two hours in the future from my own timestamp,

  • I will reject it.

  • And if it isn't after some point that's

  • the median of the previous block's timestamps,

  • then I'll also reject it.

  • And, of course, the block needs to actually point to a block

  • that I've seen before.

  • And as a node, I will keep around

  • blocks which have a previous hash pointer that I

  • don't know about.

  • But I'm not going to keep them around forever,

  • because that's a potential Dos attack.

  • And in order for me to actually insert this block

  • into my version of a blockchain, I

  • need to know which block to put it after.

  • Note also, note what's not on here

  • is that it needs to be the only block pointing

  • to a previous block.

  • I'll keep around multiple blocks at the same level

  • until I have some sense of which one is going to win out,

  • because of the probabilistic nature

  • of maybe this block I'm seeing is not going to end up

  • being part of the blockchain.

  • Maybe it's going to be an orphan.

  • So these validation rules are what

  • are called consensus critical rules in the bitcoin network.

  • And what that means is that if you want to tweak these rules,

  • if you want to change them, then you

  • may end up changing which blocks nodes will accept,

  • and which blocks nodes won't accept.

  • Now, something that's kind of interesting to note here

  • is that the entire script interpreter in bitcoin

  • is consensus critical.

  • Yes?

  • AUDIENCE: If you reduce the amount of transactions,

  • does that reduce the size of the blocks as well?

  • NEHA NARULA: Yes, it can.

  • Yes, so you can definitely have a block--

  • so that's a great question actually.

  • So let's say that we had a block that was half a megabyte.

  • What would nodes do?

  • What do you think?

  • AUDIENCE: I think an advantageous miner would

  • potentially process it faster.

  • NEHA NARULA: That's true.

  • What would you as a node do.

  • If you're running the bitcoin protocol as it exists today,

  • and it has the following set of rules,

  • and I hand you a block that's half a megabyte,

  • what would you do?

  • You would say OK, exactly, because the rule that I

  • specified here just says the block has

  • to be less than 1 megabyte.

  • It didn't say it has to be greater than anything.

  • And is half a megabyte less than 1 megabyte?

  • Yes, so you're going to pass the checks.

  • And you're going to accept the block.

  • AUDIENCE: Is that a good thing for miners, so

  • maybe remove the transactions from a potential block,

  • because they want to process it faster?

  • NEHA NARULA: Sure, so the question is, should miners

  • remove transactions from a block,

  • or perhaps not put transactions in a block,

  • because it seems like they could process a small block faster

  • than a large block, right?

  • So that is very true.

  • Miners, if there are fewer transactions,

  • they have fewer things to verify.

  • So they can check and see if the book is valid faster.

  • However, the fewer transactions, the fewer the transaction fees.

  • And so the less the miner will earn from the block.

  • Yes?

  • AUDIENCE: And also, the energy put in, most of it mining,

  • is like mining the block, not actually verifying.

  • NEHA NARULA: Yeah.

  • So verifying transactions is nowhere near as CPU-intensive

  • as it is to actually find the nonce

  • and produce the proof of work.

  • However, miners should verify transactions

  • before even starting that process.

  • And so if a miner didn't verify transactions,

  • they would get a head start on the proof of work process.

  • So there's that sort of balance.

  • And, in fact, I think we've talked about this in this class

  • before, there have been times in history

  • where things have happened that have shown that miners actually

  • haven't been verifying blocks.

  • They'll just mine on whatever.

  • It's caused some problems.

  • And they ended up losing a lot of money

  • because they should have been verifying blocks.

  • Great.

  • So these rules are what are called consensus critical.

  • They are the rules that each node independently

  • uses to decide whether or not they're

  • going to accept the block.

  • Yes?

  • AUDIENCE: When you talk about nodes,

  • you talk about SPDs, right?

  • NEHA NARULA: No.

  • I'm not talking about SPDs when I talk about nodes.

  • I'm actually talking about full nodes.

  • So I'm talking about nodes that are holding

  • onto the entire bitcoin blockchain, that

  • are looking at every block, every transaction.

  • AUDIENCE: So the difference between a miner

  • and and a node are [INAUDIBLE]?

  • NEHA NARULA: A miner--

  • yeah, they're distinct roles.

  • So a miner is running this proof of work algorithm

  • to try to find--

  • to produce blocks.

  • A full node does not write blocks.

  • It doesn't create new blocks.

  • It receives blocks, and then validates them, or not,

  • and adds them to its local copy of the blockchain.

  • A miner might also be running a full node.

  • Yes?

  • AUDIENCE: Miners should be running full nodes.

  • NEHA NARULA: Yeah, they should be.

  • But it's not clear that that happens, for the reasons

  • we were talking about before.

  • I'm sorry?

  • AUDIENCE: You can force miners to [INAUDIBLE]

  • NEHA NARULA: OK, so let's go back to this image right here.

  • These nodes are all running some version of the software.

  • They see this transaction.

  • And they say, yes, this looks like a valid transaction to me.

  • And note that they have to--

  • or, sorry, block.

  • They look at this block.

  • Yes, this looks like a valid block to me.

  • And note that they kind of have to evaluate

  • that block with respect to all of the other blocks

  • that it's seen.

  • No double spends, all of the scripts eggs, the script pub

  • keys, work out correctly, it's the right size, et cetera,

  • et cetera.

  • And then once it's decided that that's all OK,

  • each node will independently make the same decision

  • to add that block to its blockchain.

  • So you can see here that determinism is actually

  • really important.

  • It can't be the case that there's

  • any randomness in this process.

  • It can't be the case that sort of randomly,

  • depending on the time of day, one node will decide

  • this is a valid block, one node will

  • decide it's not a valid block.

  • That's not the greatest situation to have happen.

  • We want this to be as deterministic as possible.

  • We want them to all independently arrive

  • at the same decision.

  • Great.

  • So this is how validation works.

  • This is what nodes do.

  • Major problem, though-- sometimes,

  • we need to change the validation rules.

  • Sometimes, we need to upgrade the software.

  • I mean, software is not a static thing.

  • The software that these nodes are running,

  • there's going to be bugs.

  • There might be security vulnerabilities.

  • We might want to add new features.

  • And so we're going to want to change the validation rules.

  • It's pretty much inevitable.

  • And, yet, given the nature of the system,

  • we can't upgrade every single node at the same time.

  • So I think a useful analogy here, something to think about,

  • is actually browsers.

  • So web browsers-- right now, a lot of people run Chrome.

  • But not everyone runs Chrome.

  • And Chrome actually has auto update

  • where it will push changes to your browser.

  • Google will automatically upgrade you.

  • But the way the browsers used to work

  • is that you didn't always have auto update.

  • Or it would bother you, and ask you

  • if you were OK with auto updating before.

  • And people would say, I don't deal with this right now.

  • I'm in the middle of something.

  • I don't want to auto update my browser,

  • and have to restart the whole thing.

  • And so what would end up happening

  • is you'd have significant numbers of people on very

  • different versions of browsers.

  • And this was kind of a disaster for the internet,

  • because people who were developing websites,

  • they wouldn't have any confidence

  • that the majority of their users,

  • or a significant majority of their users,

  • had upgraded to the new features.

  • So they had to support all these old versions of browsers.

  • And it was a nightmare.

  • So that's what we're dealing with here in cryptocurrencies,

  • except it's even worse.

  • So you definitely cannot guarantee that everyone will

  • upgrade their software at the same time.

  • You can't guarantee that everyone will even

  • upgrade ever.

  • And so the designers of the software,

  • when you want to create a new version of software,

  • you have to think really, really carefully about it.

  • So let's say that we're in this situation right

  • here, where these three nodes are running V1 of the software.

  • The developers have worked out V2.

  • V2 has some interesting new features,

  • which slightly changed the validation

  • rules about what a node running V2 will

  • consider valid or invalid.

  • So now, when we see this new block, and we ask the question,

  • is this block valid, these nodes might make different decisions.

  • In particular, maybe the old nodes will think it's valid.

  • Great, passes all the validation rules.

  • I will append this block to my blockchain.

  • And the new node will not think it's valid,

  • and will say, garbage block, fantastic.

  • I will not append this block to my blockchain.

  • And what we end up with when this happens

  • is we have two different versions of history.

  • The nodes running the old version of the software

  • think that there are four blocks in the blockchain.

  • The nodes that are running the new version of the software

  • have decided that that block is invalid.

  • And they only have three blocks in the blockchain.

  • So what does this mean?

  • First of all, is this like the situation we saw before,

  • where if we just wait for enough proof of work

  • this will sort itself out?

  • What do you guys think?

  • I'm seeing some people shaking their heads.

  • And, yes, this situation is different than the situation

  • we saw before, because the situation

  • we saw before, all the nodes still had the same validation

  • rules.

  • They just saw the blocks in different orders,

  • or they got later, whatever.

  • All of that can be resolved by looking at the proof of work.

  • Sometimes when this happens, sometimes

  • when nodes are actually running different versions

  • of validation software, things can

  • be resolved by just looking at proof of work.

  • But quite often, actually, they can't.

  • And so in this situation, what might happen

  • is another block comes along.

  • So this is a different block than this one.

  • And this set of nodes might decide

  • that this is the next block in the blockchain,

  • whereas the blue nodes will never, ever, ever validate

  • this block.

  • They will never decide that this block is valid,

  • given the version of the software they are running.

  • They will never switch to a blockchain

  • that has this block in it, even if it

  • has the most proof of work.

  • So I think this is a really important point.

  • And I think it sort of fundamentally

  • gets to why miners don't actually

  • have as much power in the system as one

  • might think that they do.

  • And the reason for that is that the way bitcoin is designed

  • is that a node will never accept a chain with a single invalid

  • transaction.

  • If, according to its set of rules,

  • a single transaction is invalid, it will completely

  • ignore that chain.

  • Doesn't matter if it has the most proof of work.

  • Does that make sense to everyone?

  • It's kind of intense.

  • It's kind of crazy, right?

  • Like, even if it has mountains upon mountains

  • of proof of work, it will completely

  • ignore that chain because there's

  • something invalid about it.

  • So miners can mine what they want.

  • But they better mine within the validation rules

  • set of the economic majority of the nodes.

  • Otherwise, those nodes are all going

  • to ignore whatever they mine.

  • And their money is not going to be worth anything.

  • Great.

  • So in this situation, we end up with two different blockchains.

  • And we actually end up with something quite irreconcilable,

  • unless we change the software again, somehow.

  • And what we've ended up with that's irreconcilable

  • is we now have a block over here, and a block over here.

  • This node will never accept a chain with this block in it.

  • And so we've got two different blockchains.

  • So when this happens, we call it a fork.

  • Now, the word fork can be used to mean many different things

  • in software.

  • For example, you fork a project on GitHub.

  • When you fork a project on GitHub,

  • you might make changes to it.

  • This is a little bit different because of the linearity

  • of history here.

  • When a fork happens in a cryptocurrency,

  • in particular a sort of a fork that can't easily be resolved,

  • that isn't just going to, oh, one

  • side has more proof of work, OK, great

  • we're all going to switch to that other side.

  • When you have a fork that can't be resolved

  • that easily then it's actually a pretty big deal,

  • because like we were saying earlier

  • we now have two versions of history, two different versions

  • of money.

  • It's like I took the dollar from my wallet,

  • and I photocopied it.

  • And now there's $2 where there was only one.

  • So maybe you like this kind of dollars.

  • Maybe you don't like that kind of dollars.

  • We've basically taken this entire network

  • that all sort of agreed on what this form of money was,

  • and we've divided it into two.

  • So there's two different kind of forks

  • that people will talk about mostly in this industry.

  • But forking is actually much more complicated than that.

  • You can't just talk about forks as

  • in-- so the two different kinds of forks

  • are soft forks and hard forks.

  • And I'm going to explain what a soft work is,

  • versus a hard fork.

  • But, actually, that delineation, it

  • gets much more nuanced because different things happen

  • in a soft fork versus a hard fork,

  • depending upon who's decided to adopt the rules.

  • OK, so a soft fork--

  • a soft fork is a fork which is backwards compatible.

  • So we have some rule set.

  • And under that rule set you apply

  • that rule set to every single possible one megabyte

  • chunk of data.

  • And we're going to end up with some set of what

  • are valid blocks.

  • A soft fork is when you add rules to the rule set,

  • such that the set of valid blocks actually shrinks.

  • So what does that mean?

  • We had a whole bunch of rules before.

  • Blocks have to be less than 1 megabyte.

  • Transactions all have to be valid.

  • It means that their scripts certify, like validate,

  • under the certain script interpreter,

  • et cetera, no double spends.

  • Let's take one of the rules that's actually pretty simple,

  • which is that blocks have to be less than one megabyte.

  • Let's say that I change that to blocks

  • have to be less than two megabytes.

  • Is that a soft fork?

  • AUDIENCE: Yes.

  • NEHA NARULA: Oh, wow, there's some actual dissent over this,

  • right?

  • OK, so someone who says no, why is the answer no?

  • AUDIENCE: Because you have something that is now accepted

  • that wasn't accepted before.

  • NEHA NARULA: Right, so remember, valid blocks

  • before newly valid blocks fit inside of this.

  • Now, someone who said yes it's a soft

  • fork, why do you think that?

  • AUDIENCE: All blocks still have less than two.

  • NEHA NARULA: Right.

  • So it's actually not a soft fork.

  • And the reason that it's not a soft fork

  • is because a block that is 1.75 megabytes, previously,

  • the old rule set, was invalid.

  • New rule set, it's valid.

  • But we just said everything that's newly valid

  • has to fit inside what used to be valid.

  • So a soft fork is restricting the set of valid things.

  • You can think of it as expanding the set of rules

  • that a block now has to comply with.

  • So a feature of this is that if you don't upgrade--

  • so V1 is the old rule software.

  • V2 is the new rule software.

  • If you don't upgrade, you will continue

  • to see the new blocks as valid.

  • And this is actually a very nice property,

  • because, remember what happened over here,

  • we had this property where the people on the blue side

  • were just never, ever going to accept

  • one of these blockchains.

  • And if it were the case that this were a soft fork,

  • the old side would never, ever--

  • well, if this sorry, if it were the case

  • that this weren't a soft work, the old nodes

  • would never accept this new stuff.

  • So soft forks are really nice, because they're

  • backwards compatible.

  • Old nodes will still see the new blocks as valid.

  • They won't reject them.

  • If that chain gets a ton of proof of work,

  • then the old nodes will happily switch over to that chain.

  • So, what does that mean?

  • So let's say that the black nodes are the old rules,

  • and the blue nodes are new rules, new rule blocks.

  • And, again, we have to look at this from two

  • different perspectives.

  • There are the people creating the blocks.

  • And there are the people reading the blocks.

  • And sometimes those are the same people.

  • Sometimes, they're not.

  • So we're looking at blocks here.

  • So these are people who are creating the blocks.

  • And, again, both of these sets of people

  • might upgrade or not upgrade.

  • So we might have miners who are following the old rules

  • and miners who were following the new rules.

  • Then we might have validating nodes

  • who are following the old rules, and validating nodes who

  • are following the new rules.

  • And this is not even talking about SPV yet.

  • OK, we're just talking about miners.

  • And we're talking about nodes.

  • So let's say some of the miners upgrade to the new rules,

  • but not all of the miners upgrade to the new rules.

  • The miners who didn't upgrade to the new rules

  • are going to continue producing old rule blocks.

  • They're going to continue producing V1 version blocks.

  • But if the majority of miners upgrade to the new rules,

  • remember, the new rule people have new rules.

  • So they have more restrictions on the set of blocks

  • that they will accept.

  • So they might not see that block as valid.

  • So they're never going to accept that chain, because it

  • has invalid things in it.

  • Once you've upgraded, you might no longer

  • accept the old chain as valid.

  • And so what's going to end up happening

  • is something that looks very much like the orphaning

  • situation that was happening before,

  • where if the majority of the hash powers, which

  • is over here, this chain is going to keep going bigger.

  • These guys might keep trying to produce old style blocks.

  • But they just keep getting orphaned off.

  • It's actually like very much in their economic interest

  • to hurry up and upgrade, so they're not wasting hash power

  • on orphan blocks.

  • Are there questions about soft forks?

  • Yes?

  • AUDIENCE: So are soft forks also used

  • for changing software other than validation?

  • NEHA NARULA: Yes, that's a great question.

  • Are soft forks also used for changing software other

  • than validation?

  • So we can certainly upgrade more than just the validation

  • parts of the bitcoin software.

  • If it doesn't change the set of blocks that would be accepted

  • or not accepted, we don't even bother calling it a fork.

  • So let's say that we wanted to change something about the peer

  • to peer network, or the way that things are stored on disk,

  • or something like that.

  • We would see that a change like that,

  • if it didn't change the set of blocks that would have been

  • accepted or not accepted, if after the change

  • a set of blocks accepted or not accepted is the exact same,

  • we don't call that a fork, a change that induces a fork.

  • It's only when the set of blocks are accepted or wouldn't be

  • accepted are actually changed.

  • Yes?

  • AUDIENCE: How often do updates get pushed on the network?

  • NEHA NARULA: Great question.

  • How often do updates get pushed on the network?

  • So Bitcoin is at version 0.16 right now.

  • And 0.16 came out like a week or two ago.

  • And I think it's sort of been on the order of a couple months

  • between different versions of Bitcoin.

  • Other cryptocurrencies release more frequently.

  • Some release less frequently.

  • Some do forks very, very regularly.

  • And we'll speak a little bit about that.

  • But the software is pretty much constantly getting updated.

  • Yeah?

  • AUDIENCE: So in practice, people are just

  • updating their versions?

  • NEHA NARULA: Yeah, so in Bitcoin in particular,

  • Bitcoin does not have an auto update function.

  • So in order to run the new version of the software,

  • you have to decide that you're going

  • to run the new version of the software.

  • Or there might be a way to decide to turn auto update on.

  • I can't remember.

  • But the point is that they try to leave it

  • in their user's hands.

  • Yes?

  • AUDIENCE: How are versions created?

  • So if you like on the GitHub, there are a ton of features,

  • and sometimes they're pushed forward.

  • Is there a subreddit, where they're like, OK, version?

  • NEHA NARULA: OK, how are versions created?

  • It's actually very similar to any other software project,

  • where the people who work on the software project

  • get together, and decide which pull requests are going

  • to be part of the new version.

  • So, yes, at some point, they're just

  • like, new version, release.

  • Yeah?

  • AUDIENCE: Do software get released as updated versions?

  • NEHA NARULA: Yes, soft forks are definitely

  • released as updated versions.

  • So that's a great question.

  • I think not every version has a soft fork in it.

  • But if there is a soft fork, it will definitely

  • be a new version.

  • Yes?

  • AUDIENCE: Why can't this black miner

  • not just look at the version in the blue block

  • and decide not to?

  • NEHA NARULA: Because it's not a blue block.

  • So you're talking about here, right?

  • OK, so the nodes are running different software.

  • And then a block comes along that--

  • ideally, yes the block would have a version number in it

  • that specifies which version of the software.

  • And this is a very useful field in the block header.

  • But that's not really--

  • so what it has a different version?

  • AUDIENCE: If it's lower than mine--

  • sorry, higher than mine, then I don't do it.

  • Then I won't update first.

  • NEHA NARULA: What do you mean by don't do it?

  • You mean, you ignore it?

  • AUDIENCE: No, I [INAUDIBLE] myself,

  • because I see that a higher version is in circulation.

  • NEHA NARULA: So that would be one way

  • of running the network, which is if I ever see anything that

  • indicates that there's newer software out there,

  • I just realize I'm old, and that I need to update.

  • I think that Bitcoin simply made a different design

  • decision, which was that older nodes should still be able to--

  • because think about nodes that were sort of set it

  • and forget it, they're out there running.

  • One tenant that is absolutely true

  • is that users will not upgrade.

  • They will not all upgrade.

  • It just won't happen.

  • You will have old versions of software running.

  • And given that you will have old versions of software running,

  • I think it's a question as to whether or not those

  • nodes should still be a part of the network,

  • or whether you just want to slice them off

  • because they're not running the latest version.

  • And I think in Bitcoin, they want

  • those nodes to still be a part of the network.

  • They want people to be able to make the active decision not

  • to upgrade.

  • Tadge actually, I think is still running 0.13, or some older

  • version of Bitcoin.

  • Still works great.

  • He can still validate transactions totally fine.

  • OK, so we just talked about soft forks.

  • And I think the important thing to remember about soft works

  • is that soft works are backwards compatible.

  • We also talked about an example that is not a hard fork, which

  • is if we decided that we wanted to allow blocks that

  • were less than two megabytes, instead of less

  • than one megabyte.

  • And so a 1.75 megabyte of block appears.

  • That is not a soft work.

  • What if we changed the rule to say

  • that, instead of only accepting blocks that

  • are less than one megabyte, we're

  • only going to accept blocks that are less than half a megabyte.

  • Is that a soft work or hard fork?

  • AUDIENCE: Soft fork.

  • NEHA NARULA: That's a soft work.

  • The reason that that's a soft fork,

  • is because a block that is less than half a megabyte

  • was also still less than one megabyte.

  • So it's still valid under the old set of rules.

  • So if the change made here was now we want smaller blocks.

  • So we're only going to take blocks that

  • are less than half a megabyte.

  • That's fine.

  • Everyone will still see this chain as valid.

  • This is still backwards compatible.

  • Just because your blocks are 300 kilobytes now

  • doesn't mean that they violate a rule.

  • AUDIENCE: Can I ask one last question in relation to that?

  • So what happens if I want to do something

  • with the old version, and [INAUDIBLE]..

  • And they realize, wow, I love [INAUDIBLE]..

  • NEHA NARULA: Right, so what happens

  • to all the previous stuff in my chain, right?

  • Now, ideally, the way that the rules

  • would be setup, the new rules, is that they would take effect

  • sometime in the future.

  • So you wouldn't apply those rules

  • retroactively to the things that you already put into the chain,

  • because then you just throw away all history.

  • And that would be kind of a bummer.

  • Instead, you say, after this block,

  • we are only going to accept blocks that

  • are less than half a megabyte.

  • AUDIENCE: So what happens if after that block,

  • so a majority of miners are running old software.

  • NEHA NARULA: Great question.

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: We'll get into that.

  • We'll get into what happens when the majority, versus minority,

  • of different parts of the ecosystem decide

  • to adopt the change, versus not adopt the change.

  • But first, we're going to talk about hard forks.

  • What is a hard fork?

  • A hard fork is not backwards compatible.

  • And so a hard fork is a fork where,

  • if this was the old set of rules,

  • under the new set of rules you actually accept

  • more blocks than you would have accepted before.

  • So just to be clear, under the new rules,

  • you might produce a block, which a node running

  • under the old rules will reject.

  • This is not backwards compatible,

  • because any chain that has this new type of block in it

  • will not be accepted by any of the old nodes, full stop.

  • It doesn't matter about proof of work at all.

  • OK, so the thing with hard forks is

  • that because they're not backwards compatible,

  • they're a little crazier and a little bit sort of harder

  • to manage in your network.

  • Because if you do a hard fork and not everyone upgrades,

  • you might end up with two chains, possibly forever.

  • If we assume that those nodes are not going to upgrade--

  • and let's say they're not upgrading because there's

  • no one really maintaining them.

  • Then they're not going to upgrade in the future.

  • And they're not going to upgrade to a change that

  • might fix what's going on here.

  • They're just going to keep doing their old time thing.

  • Then with a hard fork, these nodes

  • are never going to accept the new blocks.

  • It doesn't matter what the proof of work is on that chain.

  • So hard forks versus soft works--

  • hard forks, as I keep stressing, are not backwards compatible.

  • Guess what?

  • A fork can be a hard fork and a soft work at the same time.

  • Yay.

  • Super confusing, actually, because you

  • can both restrict the set of rules

  • and expand the set of rules at the same time.

  • Basically, it means it's a new, overlapping, but not entirely

  • inclusive or not inclusive, set of rules, very unfortunate.

  • In fact, most things should actually

  • be both, to avoid some of the things

  • that I'm going to show you in a minute.

  • Yes?

  • AUDIENCE: But then for all useful purposes,

  • isn't it just a hard fork, because that

  • means some nodes won't be inside the blocks.

  • NEHA NARULA: For all useful purposes,

  • it's not just a hard fork.

  • Let me see if I can--

  • The reason that it's not just a hard fork--

  • this is something that requires a little bit more thought.

  • It's not just a hard fork.

  • But I will think about how to explain this, and perhaps

  • say something on this.

  • Or, yeah?

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: It is.

  • But he's asking, isn't that just a hard fork?

  • And it's not just a hard fork, because I

  • think old nodes will do something different.

  • Ah, OK, so there's two reasons why it's not just a hard fork.

  • One is because of reorgs.

  • So different things will happen as the majority of hash power

  • starts to accept or not accept the change,

  • whether or not all nodes will switch over or not.

  • But if it's both a hard and a soft work,

  • they will never switch over.

  • But I think the question is whether old nodes can

  • even still function.

  • So I think one way to use combination

  • hard and soft works is to actually stop

  • the old nodes from being able to have blocks at all.

  • Like, you design things in such a way,

  • that given a majority of hash power moves over,

  • they're just going to end up with nothing.

  • But this is a really good question.

  • And we should go into more detail on this.

  • And I will try to figure out a way to get that to you guys.

  • OK, so who controls forks?

  • Yes?

  • Sorry?

  • AUDIENCE: The developers.

  • NEHA NARULA: OK, the developers, which I didn't even

  • write down as a note here.

  • OK, do the Bitcoin developers control forks?

  • Who thinks yes?

  • You're not even raising your hand.

  • Who thinks no?

  • Determines whether or not a fork is going to go through.

  • There's the Bitcoin developers, who are actually

  • writing the software, and who also

  • have a lot of influence in the system,

  • because presumably they understand it really well

  • if they're writing software.

  • So they can write some software, and decide

  • that they want to do a fork.

  • Does that mean that the fork is going to go through?

  • No, certainly not, everyone can ignore them.

  • And there have been situations in the past

  • where everyone ignored them for quite a long time,

  • and argued about it, and didn't push a fork through.

  • Well, miners are the ones who actually create the blocks.

  • Are they the ones who control forks?

  • I see a very strong head shake no.

  • Why do you shake your head?

  • AUDIENCE: So if the miners decide

  • to change what types of blocks they're putting out,

  • they can do that.

  • But the nodes that are actually validating it,

  • no one can say they're not going to accept it.

  • NEHA NARULA: Very true.

  • So as we saw before, there are times when nodes will not

  • accept a chain no matter how much proof of work

  • it has on it.

  • I think that's a very common misunderstanding.

  • The nodes run their own validation rules.

  • And so if I'm running a node, I can run whatever

  • validation rules I want.

  • And I can decide what chain is the one that

  • aligns with my interests.

  • Yes?

  • AUDIENCE: If you're doing a hard fork,

  • and you are accepting new blocks,

  • and they just never mined any blocks with those new rules.

  • NEHA NARULA: Exactly.

  • So there's certainly incentives in many different directions.

  • If all the miners decided to go to one side,

  • then I'm a full node with my side of validation rules

  • who has no new blocks.

  • Great, what am I going to do?

  • How am I going to make transactions?

  • How am I going to spend my money?

  • Also, let's say all the miners don't go to one side,

  • but most of them do, and most of the nodes go to the other side.

  • Then what am I going to do?

  • Who's going to listen to me?

  • Who's going to trade with me?

  • Who's going to take the coins on my side of the fork?

  • So I guess that's just to say that it's complicated.

  • There's the developers.

  • There's the miners.

  • There's nodes.

  • There's the users who determine the economic value

  • of these tokens, and which side they think

  • is more valuable or less valuable.

  • And we've seen this happen with lots

  • of cryptocurrencies multiple times.

  • And it's kind of exciting.

  • So Bitcoin has forked multiple times.

  • And every time it's forked so far,

  • it has created a whole new version of the coin.

  • So it's been like a pretty serious hard fork.

  • And so now, in addition to Bitcoin,

  • there's Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond.

  • Ethereum also has fought.

  • In Ethereum's case, they tried to take along everyone

  • with them.

  • And so the hard fork was supposed

  • to be an upgrade to Ethereum.

  • But some people decided they didn't

  • want to go along with it.

  • So there's Ethereum Classic.

  • And there's Ethereum.

  • Both of them have value.

  • So it's really unclear who controls forks.

  • So now, let's talk about hash rate and forks.

  • So nodes are pretty--

  • OK, what nodes will do is they have a set of validation rules.

  • If a block validates under their set of validation rules,

  • they will accept it.

  • And if all the blocks validate under their validation rules,

  • they will accept the chain that those blocks are on.

  • And if there are two different chains where

  • all the blocks validate under their validation rules,

  • they'll take the one with the heaviest proof of work.

  • That's what nodes do.

  • So heaviest proof of work is clearly kind of important

  • here, if both sides of a fork validate.

  • So if both sides of a fork validate--

  • so we have to think about this from the perspective of nodes

  • who upgrade to the new software, and nodes who

  • don't upgrade to new software.

  • So it might be worth it to try to kind of write

  • this down a little bit.

  • So we have the old rule nodes, and the new rule nodes.

  • And let's just talk about one kind of work for now.

  • Now, let's say less than 50% of the miners upgrade.

  • And let's say greater than 50% of the miners upgrade.

  • OK, so let's use this chart, as we're

  • kind of trying to reason about what's

  • going to happen in the ecosystem for soft works and hard works.

  • So what happens if a soft fork does not obtain more than 50%

  • of the hash rate?

  • So we've got the old rules.

  • We've got nodes.

  • Some nodes have upgraded.

  • Some nodes haven't upgraded.

  • Less than 50% of the miners have upgraded.

  • So the old rule chain is going to be longer,

  • because they're going to continue mining

  • on the old rules.

  • By the way, sometimes they don't ignore things

  • with the new rules.

  • Sometimes they do.

  • It's very complicated.

  • But let's just pretend right now that they are ignoring things

  • with the new rules, because they haven't upgraded,

  • and they don't see that.

  • Or, sorry, they would see the new rules as valid.

  • But the majority of the hashing power is over here.

  • So what's going to happen?

  • Yes?

  • AUDIENCE: The benefits of the fork

  • aren't going to really be useful much, because be there'll

  • be some blocks with the new rules.

  • But the majority is just not going to change.

  • NEHA NARULA: Right, so it kind of depends on the soft fork.

  • So it depends on what the new rule nodes think of old blocks.

  • If they think that old blocks are still all valid,

  • then they're going to build upon old blocks just fine,

  • because they think they're valid.

  • If they think that old blocks are no longer valid,

  • then they're going to try to do their own chain.

  • But the majority of the hashing power is with the old side.

  • So they're just going to get reorged out.

  • Yes?

  • AUDIENCE: If it's a soft fork, but they also

  • think all the blocks are valid, how is it a fork at all?

  • NEHA NARULA: So an example of this

  • is taking what was an unused op code,

  • and now making it meaningful.

  • So it just so happens that none of the old rule nodes

  • ever used this silly unused op code.

  • Because they never used it, they never

  • had any invalid uses of the op code.

  • So the new nodes will still accept old blocks,

  • because none of them use this op code anyway.

  • But if they were to use the new op code,

  • and they used it as a no-op op code,

  • instead of what the new rules are then

  • it would be an invalid block.

  • Does that make sense?

  • So you have to think really carefully

  • about how you are designing these upgrades

  • to your software.

  • You have to think very carefully what

  • will happen to the old nodes.

  • What happens if 50% of the miners take this thing?

  • Well, under the old rules, was anyone actually using

  • this thing, that we are now maintaining

  • must be used in a new way?

  • Or pay to script hash is a good example of this as well.

  • Pay to script hash, technically, looks like you're just

  • paying to a hash.

  • So old nodes will see it, and say, OK,

  • if you can produce a signature that

  • shows that this is valid, blah, blah, whatever, whatever,

  • that's fine.

  • But nobody ever did that.

  • Nobody ever did that in a way that was

  • meaningful under the new rules.

  • No one ever used it.

  • So all the old things will still validate, simply

  • because no one ever did anything that

  • was under the subset of the new rules.

  • Sorry, this is very kind of complicated.

  • So what we have here is that if old rule blocks are still

  • valid, the software will get reorged out.

  • So no fork there, no fork there.

  • You're just not really going to end up

  • with stuff in the blockchain.

  • If old rule blocks are now invalid,

  • then we're going to end up with two chains.

  • Do people see why this is?

  • Because the new rule people are not

  • going to accept any chain that has an invalid thing in it.

  • So they're not going to reorg out.

  • They are going to continue.

  • And they are going to have their own chain.

  • And they're going to ignore all of the blocks

  • on the other chain, which they deem to be the invalid chain.

  • Yes?

  • AUDIENCE: Is this the case for Bitcoin Cash?

  • NEHA NARULA: No, it's not the case for Bitcoin Cash.

  • It's actually the case for something

  • called a user-activated soft fork, which the bitcoin

  • community threatened to do when the miners wouldn't

  • do a soft fork they wanted them to do.

  • They said, fine, you miners won't do the software

  • that we want you to do.

  • So, normally, people don't like the situation.

  • So you don't want this to happen.

  • So, normally, soft forks are written such

  • that if you don't get 95% of the miners to sign,

  • on the soft fork never activates.

  • So that's the way that, traditionally, soft works are

  • done in the Bitcoin ecosystem.

  • What does that mean?

  • It means 5.001% of the hash power

  • can stop a soft fork from going through.

  • So usually, things are written in such a way

  • that you really want to guarantee this two chain

  • thing never happens.

  • We see hash power is kind of voting.

  • And if you can get 95% of the hash power

  • to agree with the soft fork, then only will the soft fork

  • activate.

  • And the way that miners do this is they signal in their block

  • headers that they are going to adopt the soft fork.

  • And then the software is usually programmed in such a way

  • that it looks at some sliding window of block headers

  • to determine whether 95% of the hash power

  • has decided that they're going to go along with it.

  • And it only activates once that's the case.

  • So doing protocol upgrades is really hard.

  • It's not a trivial matter.

  • You don't just push some code.

  • So usually, it's the case that you

  • want to wait for a significant majority of the mining power

  • to indicate support for the soft fork.

  • And, by the way, they can indicate support

  • without actually running the soft fork.

  • This happens all the time.

  • But you want to wait for significant support

  • from the mining community before actually

  • activating the soft fork.

  • What happened recently with something

  • called Segregated Witness, which we'll talk about,

  • which was a soft fork to Bitcoin to introduce new functionality

  • that the miners opposed, was the community actually said,

  • forget it.

  • We are going to start running the new rules.

  • We're going to ignore you.

  • We don't care what the majority of the hash power does.

  • We are going to go ahead and create this two chain

  • situation, and follow the chain with the new rules.

  • Interestingly, this actually worked.

  • I think it was like 80 plus percent of the hash power

  • was not in favor of the soft fork.

  • And the users managed to create this kind of detente where they

  • forced everyone to go along with what they wanted,

  • super interesting.

  • They had no actual way to vote.

  • It was entirely sort of via Twitter.

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: Yes, so this is one of the major reasons,

  • and I think some of the strongest evidence,

  • that miners have nowhere near as much power

  • as you actually think they do in these ecosystems.

  • Certainly have power, and part of the power they

  • have is to do what's called an evil soft fork,

  • which I'm not going to talk about in this class,

  • but I think we probably should talk

  • about at some point in time.

  • OK, great.

  • Let's see.

  • OK, if the soft fork is greater than 50%,

  • old rule blocks will follow the new rule blocks automatically.

  • So we get soft fork successful.

  • We do not have two chains, because these will simply

  • be orphaned and abandoned.

  • And, in fact, there's actually pressure for the miners

  • to move over to the new rules so that their blocks aren't

  • abandoned.

  • Yes?

  • AUDIENCE: So [INAUDIBLE] making it easier

  • mine, are those considered types of forks?

  • NEHA NARULA: It depends.

  • So the question is around difficulty,

  • and the number of leading zeros required in the proof of work.

  • That changes all the time.

  • There's a formula which determines

  • what that number should be.

  • So, no, it doesn't require a fork.

  • But if you want to change the formula, that would be a fork.

  • Requiring more proof of work would be a soft work.

  • Requiring less proof of work would be a hard fork.

  • OK, now let's talk about hard forks.

  • So what happens if a hard fork doesn't

  • obtain 50% of the hash rate?

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: It depends, again.

  • It depends on if the old rule blocks are still valid.

  • So we're doing a hard fork.

  • We're changing the set of valid blocks.

  • If blocks are still valid under the old rules,

  • then we're going to end up with a situation like this.

  • If old rule blocks are still valid

  • according to the new rule nodes, then the new rule nodes

  • will just follow along.

  • OK, so basically no work happening here,

  • because the new rule nodes are going to produce blocks.

  • They're not going to have enough of the hash power.

  • And so they're not going to be considered valid

  • by the other set.

  • So they're going to end up following

  • along with the old rule nodes.

  • Yes?

  • AUDIENCE: Again, isn't the whole point of a hard fork

  • that you're expanding the set of things that are valid?

  • So aren't all old blocks going to be valid in a hard fork?

  • NEHA NARULA: Not if it's a combination hard fork,

  • soft fork.

  • So maybe I should split this up into

  • whether or not it's a combination

  • hard fork, soft fork, or not.

  • OK, so what happens if a hard fork doesn't obtain greater

  • than 50% of the hash rate?

  • What's going to happen then?

  • AUDIENCE: We'll be mining to the old rules.

  • NEHA NARULA: Yes, we're going to end up with two chains.

  • This is going to have chain--

  • whatever, the point is, there's going

  • to be an old chain and a new chain.

  • The old nodes are never going to accept the new nodes blocks.

  • And we're going to end up with two chains forever.

  • And this has happened multiple times.

  • Are there questions about hard forks?

  • Yes?

  • AUDIENCE: Are there ways for the hard fork to make life

  • really difficult for the smaller chain?

  • NEHA NARULA: Are there ways for a hard work to make life

  • really difficult for the smaller chain?

  • That is a good question.

  • I think it depends.

  • So there's multiple ways to make life difficult.

  • I think what you're asking is not,

  • what if the hard fork becomes more popular and more people

  • decide to move over to it, and abandon the smaller chain?

  • That's one way in which life could be more difficult.

  • But another way that life could be more difficult

  • is if the hard fork somehow made the previous chain no longer

  • a productive chain to be on.

  • And I think that the primary way that that would happen

  • would not actually be a hard fork,

  • but would be a combination hard fork, soft fork.

  • But there are definitely ways for miners

  • to play with hard forks and soft forks in such a way that-- see,

  • this is actually kind of ideal in some ways.

  • This is like, OK, we disagree on what the rules should be.

  • I want some new set of rules.

  • You don't want some new set of rules.

  • Fine, let's just split the ecosystem.

  • You guys go your way.

  • I'll go my way.

  • We'll have two different coins.

  • Life will be great.

  • What's kind of not so nice is when

  • one side tries to coerce the other side to go along,

  • which is kind of what a greater than 50% soft fork is.

  • You're kind of coercing the other side

  • to go along, because they have no way of opting out.

  • And there are ways that miners can make the side of the chain

  • with less harsh power basically useless.

  • This is totally something miners can do.

  • People talk about it occasionally.

  • It just doesn't seem like they figured out

  • that they can do it, or they haven't tried to do it.

  • I don't know.

  • Maybe they don't want to do it.

  • I'm not sure.

  • It would be pretty disruptive to the ecosystem.

  • OK, so question-- we've talked about what happens here

  • from the perspective of full nodes,

  • and from the perspective of miners.

  • What happens from the perspective of people

  • with wallets who might be running SPV?

  • What do we think?

  • Depends on which node they're connected to.

  • So one problem with SPV is that they don't actually

  • get the blocks.

  • So they don't actually validate blocks.

  • All they validate is proof of work.

  • Some changes that make a block invalid

  • might show up in the header.

  • But a lot of changes that might make a block invalid,

  • or new blocks valid, don't show up in the header.

  • So given what we've learned about how SPV works,

  • what happens when there's a fork?

  • So let's go back and take a look at what SPV wallets see.

  • They see the block headers.

  • You have to download all the headers, which

  • includes the nines for the proof of work,

  • the Merkle root for the transaction, timestamp,

  • stuff like that.

  • They also get Merkle paths for the transactions

  • that they've told the node they're interested in.

  • So what would happen if there were a soft work or hard fork?

  • What would happen to an SPV?

  • They don't really have a say in the situation.

  • They aren't really participating in validation.

  • They're not participating in mining.

  • And they're kind of at the mercy of whatever

  • node that they are talking to.

  • And, in fact, if they try to talk to multiple nodes,

  • they might get multiple different answers.

  • And they don't really know which answer is the right answer.

  • And this could get really tricky and complicated.

  • Now, I think probably it's fair to say

  • that the majority of the Bitcoin ecosystem, in terms of users,

  • actually does not run their own full nodes.

  • They interact with the Bitcoin network,

  • at best, through SPV, and at worst through a trusted

  • third party like Coinbase.

  • So what does the ecosystem have to say or do about

  • whether or not forks are accepted or not accepted?

  • Yeah?

  • AUDIENCE: They don't really have to.

  • NEHA NARULA: They don't really have a say.

  • They kind of I would say at like a meta level, in that users

  • can pressure Coinbase to start following Bitcoin Cash which

  • is a hard fork of bitcoin.

  • They kind of have a say at an economic level,

  • in that if Coinbase starts accepting Bitcoin Cash,

  • then the price of Bitcoin Cash will go up.

  • And so that's kind of a big deal.

  • But in terms of like a protocol level,

  • in terms of accepting or rejecting transactions,

  • they don't really have a say because they

  • can't see enough to determine whether or not

  • they're interested in following a fork or not following a fork.

  • In fact, it's even worse than that.

  • There were multiple situations where

  • we ended up with two chains.

  • So an SPV wallet might think that they received money

  • on one chain, and they didn't receive money

  • on the other chain.

  • So very bad things can happen to wallets and to SPV clients

  • during a fork.

  • And it's incredibly disruptive.

  • And people who create software on the behalf of users--

  • so not even running SPV, but like the Coinbase's

  • of the world, and the exchanges of the world--

  • they have to do a fair amount of work

  • to make sure that they aren't going to lose users' money when

  • there's a fork.

  • And the exchanges, and the Coinbase's of the world,

  • have screwed this up in the past.

  • There's been money lost.

  • There are ways to safely design your fork

  • so that it's less likely that wallets

  • will do the wrong thing.

  • But I think we're kind of just figuring out how

  • to really do that effectively.

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: Yeah, so this is kind of pretty bad,

  • because if Bitcoin is really going

  • to undergo a hard fork or soft fork,

  • everybody is paying attention.

  • If Ethereum is going to do it, everyone's paying attention.

  • But there's so many altcoins out there.

  • And, yeah, there's so much opportunity

  • for people to take advantage of the disarray that

  • happens when a fork happens.

  • So I think we're right in the middle of trying to figure out

  • best practices for handling forks safely, and also,

  • giving users some way of choosing what side of a fork

  • that they want, because there's this sort of thought

  • that eventually there will be economic pressure to--

  • for a long time, people thought that if Bitcoin hard forked,

  • one side would win, and the other side would go to zero.

  • And now, we've seen that that is absolutely not true.

  • In fact, when Bitcoin hard forked,

  • sometimes the total market cap of one side plus the other side

  • is bigger than the total market cap of what Bitcoin used to be.

  • So money is literally created out of nowhere.

  • So hard forking is very lucrative.

  • It literally gives every Bitcoin user more money.

  • So if you own Bitcoin within the past--

  • like, if you owned Bitcoin a year ago,

  • you probably have like four other coins right now.

  • I don't know.

  • You should go sell them, or sell the Bitcoin,

  • and buy the other coins, or whatever you want to do.

  • But the point is, you have more money

  • than you might have even known that you had,

  • because someone has done these forks.

  • Don't even like get started about the tax

  • consequences of this.

  • It's very confusing, extraordinarily confusing.

  • And people are trying to figure out what to do,

  • because you didn't ask for this fork.

  • Like, I as a holder of Bitcoin, didn't

  • decide that I wanted Bitcoin Cash to be a thing.

  • I didn't accept Bitcoin Cash.

  • But now, the same private keys I used to control my Bitcoin also

  • control the same amount of Bitcoin Cash.

  • It's kind of crazy.

  • Let's talk about forks in practice.

  • So soft forks in practice-- there

  • have been lots of soft forks.

  • Soft forks are very useful.

  • Soft forks are helpful.

  • This is the major way that people upgrade software.

  • And, again, the way that they do it

  • is they try to make sure 95%, or some huge majority

  • of the miners, are on board.

  • And that way, it's sort of like as non-disruptive

  • to the ecosystem as possible.

  • So pay to script has was a soft fork.

  • The introduction of Segwit was a soft fork.

  • In operation, check sequence verify

  • was added as a soft fork.

  • So that's kind of why they're all these like unused ops

  • out there.

  • In case we want to use one of them for something new,

  • we can do that with a soft fork.

  • Hard forks in practice--

  • there's lots of new Bitcoins, Bitcoin Cash, Gold, Diamond,

  • like I said.

  • Ethereum went through a really interesting hard fork.

  • And there's some cryptocurrencies that actually

  • hard fork quite frequently.

  • For instance, I learned the Monero hard forks

  • about every six months.

  • Vertcoin, how many hard forks have you guys done?

  • Three?

  • Three hard forks.

  • So, despite the way that I said that hard forks are

  • very disruptive, if you can get all the nodes to upgrade,

  • it's not really a big problem.

  • So for cryptocurrencies where the nodes are really well

  • connected, or they auto update, or things like that,

  • hard forks are much less disruptive.

  • So let's talk about the Ethereum hard fork for a moment.

  • So this happened two years ago--

  • a year ago?

  • I can't remember when this happened, two years ago,

  • I think, almost.

  • And so what happened was we haven't

  • talked a lot about Ethereum, so we'll

  • be coming to explain Ethereum in much greater detail.

  • But the point is Ethereum had a smart contract

  • which had a bug in it.

  • And someone hacked the contract, and started siphoning off ether

  • from the contract.

  • So the Ethereum team all got together, and decided,

  • we're going to rectify this wrong.

  • Now, rectifying the wrong--

  • I mean, I already said it's a hard fork.

  • But why is rectifying this wrong a hard fork not a soft fork?

  • AUDIENCE: Because you want to change history.

  • NEHA NARULA: Because you want to change history.

  • That's an interesting way of putting it.

  • And the way that we change history

  • is not by actually going back in time and editing history,

  • unless you are Accenture I guess,

  • which creates editable blockchains.

  • But the way that we edit history,

  • is we add something to the blockchain which

  • indicates that we're going to undo, or change, or rollback

  • or somehow create an operation, that

  • does something that effectively undoes

  • what happened in the past.

  • So the Ethereum developer got together.

  • And they originally tried to do this as a soft fork, actually.

  • So it could have been a soft fork.

  • And the way that the soft work would have worked

  • is that it just would have ignored

  • all of the transactions that were sort of--

  • I can't remember exactly how it worked.

  • But, basically, the general idea was, ignore

  • all of the transactions that might spend the hacker's money.

  • Ignore the transaction where people gave money

  • to the hacker, what ultimately became the hacker, which

  • is a new rule.

  • Now, you're shrinking the set of acceptable blocks.

  • And the problem was they realized

  • that if they did this as a soft fork, then

  • they were inadvertently creating an attack

  • vector, because people could now spam the network

  • and potentially waste the resources of the miners--

  • very challenging to do soft forks and hard forks correctly.

  • So they decided, OK, you know what?

  • We're just going to do it as a hard fork.

  • When this block comes about, block 1,920,000,

  • we are going to simply transfer around 12 million

  • either from the hacker's account into this other account,

  • this other contract, which is going to give the money back,

  • where people can reclaim their money.

  • So literally just hardcoded in this transfer.

  • 85% of the hash power in Ethereum went along with it.

  • So that means 15% didn't.

  • And that means that there are two currencies now.

  • There is Ethereum, and Ethereum Classic.

  • And they persist to this day, almost two years later.

  • And when I looked this morning, it was about a 30 to 1

  • ratio between Ethereum and Ethereum Classic.

  • Yes?

  • AUDIENCE: So Ethereum Classic says,

  • we are not OK with you guys undoing this hack.

  • NEHA NARULA: Exactly, so Ethereum Classic

  • says, we're not messing with people's accounts like that.

  • No, no, no.

  • What happened happened, fair and square.

  • We are not changing history.

  • And so in Ethereum Classic, the hacker has money.

  • On Ethereum, the hacker does not have money.

  • Yes?

  • AUDIENCE: [INAUDIBLE] one specific contract.

  • So the argument is we shouldn't be fixing people's mistakes.

  • They should learn--

  • Was this analogous to the Parity?

  • NEHA NARULA: Yes.

  • So here they decided, there was a bug

  • in someone's smart contract.

  • It was exploited.

  • We're going to give people their money back.

  • This happened again with a different type

  • of smart contract in a different way a couple months ago.

  • And they decided-- well, they could still decide to do it.

  • But so far, they decided not to give everyone's money back.

  • So there's about 90 million or something dollars

  • worth of ether that's locked up in these contracts,

  • due to a bug.

  • And in the case of the DAO, they decided, let's do it.

  • In the case of this Parity bug, they decided, let's not do it.

  • And if you talk to the Ethereum Foundation people,

  • they'll talk about governance.

  • And they'll say, well, we feel like this made sense

  • for these reasons.

  • But this doesn't make sense for these reasons.

  • But it's still it's a set of people

  • getting together and deciding whether or not

  • to give money back.

  • Yeah?

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: No, it's not the Ethereum Foundation.

  • The Ethereum Foundation was not a fan of Ethereum Classic.

  • It's a separate group of people.

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: No, actually, so it turned out,

  • interestingly enough-- and this was something

  • that I saw at a conference that looked

  • into who were the contributors to all

  • of these different forks, when trying

  • to understand governance?

  • It actually turns out that no one from the Ethereum

  • Foundation works on Ethereum Classic.

  • And no one who used to work on Bitcoin

  • works on Bitcoin Cash, Gold, or Diamond.

  • So it's entirely new sets of people.

  • Yes?

  • AUDIENCE: The former lead developer of Bitcoin core

  • is working on Bitcoin Cash.

  • NEHA NARULA: He's not actually.

  • You're talking about Gavin Andreessen?

  • Yeah, I don't think he actually makes commits to Bitcoin Cash.

  • AUDIENCE: In a general sense, he's

  • contributing on GitHub, not specifically

  • to any implementations.

  • But to protocol, block-level exchanges.

  • NEHA NARULA: Interesting.

  • Yes?

  • AUDIENCE: [INAUDIBLE]

  • NEHA NARULA: It depends on how you

  • define contribute, certainly.

  • This is a really interesting example of a hard fork.

  • In summary, just to wrap up here,

  • forks are extremely challenging.

  • Upgrading software in decentralized cryptocurrencies

  • is extremely challenging.

  • And so the lesson that I want you to take from this is,

  • unless you need what a decentralized cryptocurrency

  • has to offer, you will probably be better off not using

  • a decentralized cryptocurrency.

  • They are very hard to update.

  • They're very hard to upgrade.

  • There are frequently bugs.

  • And so I think that forks and the challenges around forks

  • are an excellent reason not to do this when you don't have to.

  • And also, what's really interesting, I think,

  • is that your traditional consensus systems

  • don't address this problem at all,

  • because your traditional distributed consensus

  • systems don't have any notion of what nodes

  • are going to find valid, or not valid,

  • or changing the rules of validity.

  • And so these problems really only

  • arise when you start to have these validity

  • rules that you're dealing with, and you

  • have nodes that might take one set of rules,

  • and nodes that might take another set of rules.

  • The consensus mechanism here ultimately

  • becomes irrelevant if you don't agree with the validity

  • of the blocks.

  • It doesn't matter that a majority of hash power

  • said that this is the blockchain.

  • It doesn't matter if a majority of signers

  • say this is the blockchain.

  • If you don't agree that the things in that blockchain

  • are valid, you're going to ignore that.

  • Majority be damned.

  • So it's very different than distributed consensus.

  • Okay, and so real quick, last thing...

  • on Wednesday we will have another guest lecturer. Her name is Sharon Goldberg.

  • She's a professor at Boston University and she's worked on a lot of really

  • interesting things. In particular, something really cool that she's worked

  • on is using the peer-to-peer network to create attacks in Bitcoin, and then very

  • recently she nor co-authors released a paper on peer-to-peer network attacks in

  • Ethereum. And so she's gonna be here to talk about the peer-to-peer networks

  • behind these things and to share some of the research that she's done.

The following content is provided under a Creative

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

8.フォーク (8. Forks)

  • 1 0
    林宜悉 に公開 2021 年 01 月 14 日
動画の中の単語