BDL Transcripts

Lecture 6:

SPEAKER 0

SPEAKER 1
So, so how, sorry, sir, how do you, how, how do you work out how much computational power. Everybody has.

SPEAKER 0
Oh, you don’t know. Like, uh, it’s just like, uh, proof of strength. Like, uh, I say, no, like solve this puzzle. Like everybody tries. Somebody maybe here has more computational power. It has a magic machine that is fancier than the other, or like maybe it has like more machines than the other people, and they can solve this puzzle first. Like this is proof of work, yeah, I’m talking about the system of the last time. Yeah.

SPEAKER 2
I guess file terms, it’s just like whoever gets there first because then the implication.

SPEAKER 0
Whoever gets first like gets to add the new block and so whatever competition the other people did, like maybe immediately after this block was added somebody solves this, but like most people at that point probably have already adopted this and that block that was mined like will be discarded because it’s no longer in the longest chain. Yeah So that is why. We want to move away from this design using this proof of stake. And we want to design a lottery in which your probability of winning does not depend on the amount of computational power you have. Instead, we want that your probability of winning is proportional to your stake. What is the stake? It’s the amount of cryptocurrency you have on your account. So the richer you are, the more likely you are to to win the lottery. So, it’s not democratic at all and I agree that like it’s not ideal. Um, I personally think it’s not optimal, but this is uh why like this design was chosen because like we could analyze the game theoretic uh um security of this system. And yeah, now we will achieve security as long as the majority of resources uh of cryptocurrency in the system is held by honest participants. And yeah, the main idea of why this particular design is that if you have a lot of cryptocurrency, it means that you’re kind of winning the economy game of that blockchain. So, you are a winner, so you’re less likely to want to change what is happening. So you want to keep the system up because you are winning, like pretty ruthless, I agree, uh, but yeah, uh, this is what is happening. Yeah.

SPEAKER 2
Like how does it resolve the time issue? Like, does it say that you have like the computation? Yeah, because I mean. Before we were saying that, you know, For you. Like whoever creates the first is assumed to have more

SPEAKER 0
computational power. It’s not assumed like they are more likely to have more.

SPEAKER 2
But with this. I guess like how do you, let’s say, you know, you, you create, you find this value and you create the block, but then I come along and I, I find the same value later, but then I have.

SPEAKER 0
More stake. Yeah, I’m going to explain it in a second. Like we will need to modify, of course, like our system, right? Like we will keep the first parts of this Nakamoto design, so namely longest chain and like this structure of blocks arranged in a chain. What will change is instead the lottery. OK. And yeah, so that is why we, that is what we are gonna do now. So I, I mean, there are many different ways one can design such a, yes, so in, in proof of

SPEAKER 3
stake, what if the malicious party has more currency than the honest party? Wouldn’t that be like that for the system?

SPEAKER 0
Yeah, like if the malicious parties have in total more currency than all the other honest parties together, then you have no security guarantees. The system could collapse. Like you don’t no longer have liveness. Potentially you don’t even have a consistency.

SPEAKER 3
And so how does Ethereum actually ensure that this is

SPEAKER 0
like uh indeed you cannot like enforce it totally. Like you just have to somehow trust like there is, otherwise you’re running in impossibility. You need always some sort of assumption like uh you cannot like build like such a protocol without some some assumption, some trust in something at the base. We are assuming that we are assuming that if you are winning the game, meaning you have a lot of money, like you don’t want to change the system because if it collapses you lose all your money, yeah. Does it make sense? Yeah So now I would like to explain to you how one can design such a proof of stake, uh, protocol or in particular the lottery. There are many designs we are just um studying one like, uh, and I will do it, um, in. Like, uh, starting from our proof of work construction, making small changes. Most of these will not solve the, uh, problems completely, but like we will notice some issues, we will fix them, then we notice other issues, we fix them until we find something that actually works. And why do I do this? First of all, because I want you to understand, uh, a bit the ideas behind the construction of this lottery, and secondly, I want you to understand how hard it is to build one. Like, uh, it’s not that one like wakes up in the morning, oh, I do this and this, because most likely that is something that is broken. Like there is a big analysis going on making sure that what you are designing is actually safe, OK? OK, so. We want to remember this is what was happening in proof of work, so to create a new block we Like try to find a counter that satisfies this equality. But now we want that if you have more stake, you are more likely to mine a block. What does it mean? We will modify this threshold so that it depends on the minor. In particular, it depends on the amount of stake they have. So, first thing to note. The stake is public. Why? Because it’s on the letter and everybody has access to that letter, right? So everybody can tell how much money I have on my account. There is no privacy here. OK. OK, now we will try the following. This is attempt one. If I call it attempt, it means it’s not secure. And we Mine a block if the hash of can uh and now I simplify the notation. I remove this g because I don’t want to write like uh it all the time, but I mean we will need to change it anyway. So suppose that the hash of the counter of x and s is smaller than t times some uh constant k stake that depends on my stake, OK. The more they can have, the larger the scale will be. So, meaning the threshold is larger and finding, so satisfying this uh inequalities is easier, right? If instead I have a little stake, this is gonna be small and I’m less likely to find once the satisfies this. Yeah. K is some constant like that depends on my stake, like some function of the stake. Like something, I don’t know, between 0 and 1. OK. Like it’s up to you to decide how this depends on the state. Like, uh, it could be that it’s linear or it could be like some fancy function you want like uh. What do you mean It’s up to who designs the proof of stake, like uh Oh I see. Yeah. It could be that you want to design something in which like, uh, I mean like it wouldn’t even make too make too much sense that if you have double my amount of money like uh you have double the chance of uh winning like or maybe you want some more complicated function but doesn’t really matter. What I’m just saying is there is some function that depends on the stake that modifies the threshold. This is the, the most important part, yeah, isn’t it, uh, harder to solve it if if k is bigger? If k is bigger. If T, I mean T is fixed for everybody, yeah, like, uh, if, if this thing here becomes bigger, it’s easier to solve the problem, right? Uh, for example, if T is smaller, that means there’s a lesser sample space of possible values. Yeah, doesn’t it make it easier to solve? No, like, like the output space of this hash function is the same, right? Like you can imagine that this outputs a 256 bit, uh, string, it means that it outputs values between 0 and 2 to 256. If t is smaller, like you’re less likely to find a value that, uh, is smaller than threshold, right? Does it make sense? Like, uh, the probability, I mean, assuming that 8 behaves randomly, the probability that you find something that satisfies like the inequality is essentially T times K stake. Divided by 2 to 256 if this hash function outputs 256 bits, right? So, the smaller this, the smaller the probability, OK? Um, yeah, but this is the first attempt. That means that there is something that does not work here. What is it? The issue is that we want to avoid that your probability of winning like depends on your computational power, but here, if you have a lot of computational power, you can still try to win the lottery even if you have a very low stake. Namely, you do what we did before with proof of work. You keep changing the counter and like uh you try to find something that is smaller than, uh, this, right? So what do we need to do? We need to remove at least the counter, right? Is it clear why So this was an attempt to. No counter. But like this sort of attack can still be done now. What would you like to do, like if you have a lot of computational power and a very low stake? You try to modify the content. Like you try many different possible blogs. Like until you find one that like satisfy the inequality. Right? This is called the grinding attack over x. Yes, uh, if you change, change x, then it won’t link correctly in the box anymore, right? Correct, yeah, that is the issue that will come next, but we need to remove this x from here because otherwise we run into the same problem. So no X. So this is to prevent what we call the grinding attack. You try many different Xs until you find one that satisfies the inequality. But before going to the issue that he pointed out, there is another issue here, namely that if we remove also X, now everybody is performing the same computation, right? Because X was the one that was linking the computation to us because it contained our, uh, account, like our address, right? So everybody is doing the same computation. It means that if this value is, uh, high, probably nobody like uh can mind. And if this value is low, there are potentially many different winners depending on how much stake they have. So we don’t want that. We need to have like a competition that is different from party to party. So let’s add here the verification key of the account of the buyer, OK? So VK is Minus Um, er, signature. Public key. Are you able to see uh the people here in this corner? OK, I guess I need to remember not to use this corner here. Um Does it make sense? Yeah.

SPEAKER 2
value The what?

SPEAKER 0
X? Yeah, because now imagine I have a lot of computational power but very low stake. What I can do is I can try to Like, I can generate many different axis. Like it’s up to me what I want to add into the block, right? I can add fake transactions or I can, like, I don’t know, randomize the whole thing and try to find something that satisfies the, the inequality with. Yeah, you would still have the dependency on the computational power. The more powerful you are, the more likely you are to, to win like the lottery. We don’t want that.

SPEAKER 2
Like the, the person trying to create the block can’t change so.

SPEAKER 0
Yeah, there will be an issue with that. I agree. Like we will discuss it in a, in some time, but like for the moment assume that like the signature keys are on the blockchain, so they are fixed. Like you cannot change them. To perform that attack, yeah, I, I really didn’t get how like this is possible because isn’t a known value on, on, on the, yeah, that is, everybody knows us, yeah. So won’t all do the same like amount of computation together or it’s not really sorry so this value is known by byever right so there’s no randomness or for the moment there is no randomness yeah. What, I didn’t understand the question. Like, uh, yeah, this. Computation now is different from every party because every miner will have a different verification key, right? Like that is what I’m saying. If instead there was no verification key, everybody would compute the same thing because this S is the pointer to the last block, OK. OK. But yeah, like uh the issue is what he described. Now there is no connection between the lottery and the, the value of the block. And to understand why, let’s consider the following attack. Um, let me era. I suppose you have, you’re saying like. There could be many blocks in the past, but I do not care about those. So what do we have as part of the block? We have, uh, some value and the pointer. We remove the counter, we don’t need them anymore. I like, yeah. So let’s. Let’s, let me introduce some notation. Suppose that this is the ice block, so the context will be Xi and SI will be the um. And the pointer to the previous block. Here we have X1 minus 1, S1 minus 1, Xi minus 2. As I minus 2 and then I minus 3. Now, um, let’s write here who the miner that created the block, uh, was. So let’s call this Pi minus 2, meaning party I minus 2. This is party I minus 1, and this is party I. OK? Now, imagine that this is me, like I’m corrupted. Like this is the Myanmar OK? And imagine that in this block here, so 3 blocks in the past, I made a transaction that says, I spent. Uh, 1 €1 for pizza. Very cheap pizza. OK. If there is no connection between who wins the lottery and the, the content, there is nothing that binds. When I create this block, I can double spend that coin. I can say, first of all, I erase this opera this. Like a transaction from that block. Nothing prevents me from doing. And here I say I spent. Um, that €1. On pasta. OK, I double spend my money. And I say, OK, I erased the past and now my chain is the longest one when I published the blog and everybody adopts it. So I don’t. Do you see what is the issue here? So we need to create some sort of connection between who wins the lottery. And like the content of the blog they publish and to do that, we rely on digital signatures. Namely, now the block will no longer contain just Xi um and the pointer to the previous block but also a signature, sigmai on XI using The signature key of the of the minor. So this is Signature. On XI. And uh Decay essentially the Like the signature key we use for mining. And now why does this attack not work anymore? Because if this part is honest, Like I cannot like change the history. I cannot say that transaction does not exist because I would need to sign it, but I do not know the signature of this party. I do not know the signature key of this party because they are honest.

SPEAKER 3
Yeah, could you please explain how you were able to erase the first it’s simple.

SPEAKER 0
I just like design like I create my computer like the chain like. Like Xi minus 2 now doesn’t contain that anymore. Like I had this new blog, I broadcast to everybody. Now my chain is the longest. Everybody would adopt it, right? You basically erase it after PI minus 1 is added. Yeah, like This is me now, right? Like this chain is what everybody has, but now when I generate this block, I take the chain that everybody has. I remove this transaction from the block X minus 2. I generate this new block. I broadcast it, and now this is the longest chain. Everybody adopts it, right? racist. Like, remember, like the history is not written on stone, like the history is the longest chain. If I managed to create the longest chain and I like the longest chain and I change the past, I change the past for everybody, right? I just created an alternative chain that is longer than the main one, and in that alternative chain this transaction never happened, but the piece uh I mean it’s already eaten. Does it make sense? But now, if we sign the transaction, I’m not able to to craft a new block XI minus 2. Because I would need to sign it with the signature of the winner. And the winner here is honest. I do not know the secret key of the uh signature. I cannot sign.

SPEAKER 2
We have to know like everything that’s in that block in order to.

SPEAKER 0
Yeah, I mean, the letter is public. Everybody knows everything, right?

SPEAKER 2
Yeah, but you wouldn’t. No, the signature Yeah, yeah, like I cannot do this

SPEAKER 0
attack anymore if this party is honest, right? If the, this party is the miner, the person that created this block, right? Like I cannot like craft the signature with the modified xi minus 2. Do you agree? Like you cannot craft the signature unless you know the secret key. But the secret key is not only to this party that won the lottery in that round. I did not win the lottery in that round, I cannot. Yeah. Would you be able to explain quickly like how this

SPEAKER 6
differs um to the proof of work scheme. In terms of With the proof of work and you can’t go back and change.

SPEAKER 0
And the proof of work, uh, of course you can go back insane, but like the issue is that. Then the pointers would all change. Like, so I cannot just keep the blocks that were mined. Like if I change this block in proof of work, like this block wouldn’t point anymore to this one because like the pointer would change. So I would need to mine a lot in order to keep up.

SPEAKER 6
But now we don’t have.

SPEAKER 0
Now, like the pointer does not depend on the content, does not depend on X anymore. So we have this issue. Like we removed the pointer because otherwise we could do this grinding attack. Like we would run back into the, the more computational power you have, the more likelihood you have of winning the lottery, yeah.

SPEAKER 5
What’s, uh, what’s making it such that people who adopt the longest chain understand that the signature from PI minus 2 is the signature PI minus 2, meaning what’s stopping an adversarial PI from just saying, oh, that was the signature?

SPEAKER 0
I mean you can verify a signature, right? So but do they do the verification when they adopt? Oh yeah, of course you need to do it. Like you need to be very paranoid and check like everything like uh. Like, uh, if like the chain has been changed, like you need to verify that everything is, uh, consistent. Like if there is a signature, you need to verify that.

SPEAKER 5
In that case, if they’re, if, if when I, my laptop adopts a new chain that that you just declared is longer and I’m already doing an analysis of the signatures on the blocks that came before, why wouldn’t I just compare if the results have changed from what the one I had just, you can also do that like,

SPEAKER 0
uh, it depends. Like sometimes there are a lot of hashes that are hidden in this. Like for instance, if what is this point uh. This pointer is the value of this hash function in the previous block, right? Like if you have a version of your chain and you receive a new one, you start from the most recent block, you go back and at some point maybe you find some pointer that is one that you already have on the previous. Version of your chain right at the point you can stop because like if those met you’re certain essentially with high probability that actually from then on like they will all uh coincide. This is because this is essentially hash and you have this collision resistance of the hash function probably you saw it in the first lecture. Like it’s hard to find two different values that hash to the same thing. So if you have. Matching hashes, you know that whatever is like a computed from actually matches. So you don’t need to, to check all the, the stuff before. Right, but like, otherwise you would need to go through like the whole chain, yeah, sorry, just to follow up,

SPEAKER 5
if, if the xi minus 2 was hashed and there’s a record of the hash, but then you, the adversary, goes back and changes it, then wouldn’t everyone know without the signature nec like why would the signature be necessary if they know that something in the xi minus 2 must have changed?

SPEAKER 0
I has changed, of course I can. I mean, if I am the adversity, I can still hash xi minus 2, but like, uh, here there is no hash of xi minus 2, right? Like this SI minus 1 does no longer depend on Xi minus 2. This SI now depends only on the S and the verification key. Like we remove the dependency on the content. This Thing here has no information about this XI minus 2. Does it make sense? Yeah, I think it becomes clear if you use indexes

SPEAKER 4
like just say that the age of VK and S minus 1 is S1 is S I so then like Yes, and then like I think that is something that lots of people get confused about because Yeah, yeah.

SPEAKER 0
Does it make sense? It it does make sense.

SPEAKER 1
I’m looking on my X. Is it because. So if you’ve got, if you’ve got a historic chain and you get a new, you get to accept a new chain. You could look at what the X is and the X is and do comparisons.

SPEAKER 0
The previous chain and uh your current one, yeah, sure, you can do it. So you, you could test whether a change has been

SPEAKER 1
made.

SPEAKER 0
Oh yeah, yeah, yeah, sure, sure, but you adopt the longest one, right? You never know. Maybe like, uh, the shorter one was an adversarially made one. Like maybe the main reality has always been the, the longest one. Like it’s not that if you see a change like, oh for sure the, the old one was the right one and like the new one is the honest one, sorry, the attacking, uh, the, the attacker one. It could be vice versa. You do not know.

SPEAKER 1
So what if you, if you won the lottery twice in the trot or very then you could potentially.

SPEAKER 0
You can put it, yeah, correct, like, but we are gonna talk about this in a second, yeah.

SPEAKER 5
But, uh, as you mentioned, because we’re just adopting the, the longest chain, you said we’re, we’re adopting the longest chain as long as it’s also the signatures match, yeah,

SPEAKER 0
yeah, so always you never adopt anything where the signatures do not verify that like, uh, if I say like we need to, if there is a signature is there because it needs to be verified like, uh, like we always verified.

SPEAKER 5
Is there a reason why we wouldn’t just rather than do the verification just adopt the longest chain that also that also the previous chains that we already are storing and accepting as truth are the same?

SPEAKER 0
Like you want to, I mean, You can potentially like you, or at least it could be that like there are forks in the last few blocks so that would be a bad idea if you just stick to the first reality that was pushed to you like then an attacker that has a lot of control over the network would have a lot of uh um power like what you could do in some cases, but you would need to make an analysis is that. You discard any uh change you received that has fought far into the past. But if the fork is recent, you need to stick to the longest one. OK. But this is like something that I would try to avoid this, in this lecture. Like, think about take the longest one, doesn’t matter when the fork was, OK? OK. Now, we have added the signatures to prevent the attack I just described, but this is still not secure. Like now I do not know if this is attempt 4 or 5, but like. Try to attack this, like, uh, think, uh, adversarially. What could happen is that this block here was not generated by an honest part but was generated by me. I mean, It could be that I win like sufficiently many uh blocks like lotteries. Like it could be that this one was generated by me and once again, like I can do this attack because now I know how to sign the, the modified transcript, the modified history. This is like my signature. I know the secret key. So to solve this, we need to modify once again what is happening here. Instead of signing just the xi, we sign a hash. Of the whole history until exile. So this is gonna be from x0 ta ta ta ta to xci. And yeah, now, of course, I can once again change the, change the history. However, if this part is honest, I cannot append this block to the change block here. Why? Because this party now has also the signature. Onto the hash of the whole thing here. So if I change this block, I change the hash that this party signed. And so, like, uh, there would be a mismatch. So as long So it could be that actually all the transactions here are controlled by me and in that case, yes, I can still control the history. And that is why usually you need to wait sufficiently long until the transaction is validated. You need to hope that in between there is some honest participant, right? Once we are sure that there is someone as participant in between, we can be sure that like uh the transaction is validated and the history cannot be changed anymore. So, eventually, blocks will be finalized. But when they are freshly generated, you don’t know if they will become part of the main history or if they go into a fork. Yeah, um, yeah, so if we always have to compute the hash on the whole blockchain, isn’t that like too much? No, because the hash can be updated like, uh, like you, it’s a rolling hash like, uh, the hash, if you add a new block, like you take the previous hash and you like the hash function have these properties like this streaming thing, yeah, yeah.

SPEAKER 4
So the hash, just on that, so the hash is basically like is it the hash of x0 to xi minus 1 plus uh like the input to the hash function is the hash of the entire previous history. And the current information or actually the entire thing up

SPEAKER 0
to you like uh pick the like this is a general thing. I’m not talking about any blockchain in speci in like any specific blockchain. Use a hash function that is secure. It’s an efficient show. Like, anyway, there are uh hash functions that have that design like uh like the hash functions that are used today have all this property that essentially if you want to extend your uh sequence of your string that you want to hash, like you don’t need to restart from zero, like you take the hash of like the substring and then you do some more computation. OK. OK. Still, this is attempt 5, but it’s still an attempt. It’s a complicated problem. So. Think adversarially once again. Suppose that um This, this party is the one that is preventing the attack for the moment. So, what I could try to still. Like, make this attack work. I can attack PI-1 machine. I can try to, I don’t know, phishing or like some hacking that I have no idea how to do, but like I can try to enter into the machine and I can try to steal from them the secret key, right? If I manage to do that or I manage to do it for all the honest parties in between this block and this one, like then I can once again, uh, change history. Yeah, I have a question.

SPEAKER 4
Like, could you not also, if you have enough computational power, just like start from the last block you did yourself and just overtake the rest because you’re the only one working on that.

SPEAKER 0
You’re less likely to, yes, but like you need to win the lottery, right? Yeah, like you don’t have like a super high chance assuming that you don’t have a lot of money. Yeah I agree, but like if sufficiently many honest parties are in between, like, uh, the process you would take as an adversary is like attack the machines. There are just a few parties. Maybe you manage to, to get their, uh, verification key, and then you can change, uh, the signature keys, and then you can change the history. So how this is called adaptive attack, adaptive corruption. In the sense that based on what is happening, you adaptively choose who to attack to corrupt. Um, how do you Um, solve this issue. Key update. Meaning, once you win the lottery. What do you do? You add to the block you’ve just created a new signature key. You say, OK, from now on, this is my signature key. You sign using the old one and then you throw the old signature, the old secret key away. Does it make sense? You are essentially, when you sign, like all signature will be, all signature keys will be one-time use. And like in the blog, you say, OK, my new signature public key is this one. Like Yeah, so basically every time you create a block

SPEAKER 2
we would generate a new.

SPEAKER 0
Yep, yeah. Yeah, but won’t this be very chaotic? Like everyone needs to update everyone’s public keys. Yeah, but it’s all in the ledger, right? Yeah, this is all chaotic. I, I agree, but it’s like, this is the cost of security. What is it if you throw your key away in

SPEAKER 4
a fork and on the main blockchain it’s actually adapted and never happened?

SPEAKER 0
Yeah, yeah, good question, yeah. Yeah. Yeah, yeah, yeah, like, uh, I agree. Maybe you would need like to spend some time like um like uh make sure that like the block is validated before like throwing it away, but like. Yeah. Uh, yeah, this is. One attack, so you do adaptive corruption in the past based on like uh what had happened in between these two blocks, but there is another attack. And we are slowly going towards the end, namely adaptive corruption to the future because you know, this competition can be done by everybody, right? I know everybody stake. I know everybody, uh, public keys. So I can start like trying to check in the future who’s gonna win the lottery and before they even realize they do that, I attack the machine, I take over, and now like, uh, I will generate the block in their stead. Doesn’t make sense. So, This computation is not OK. This is a public computation everybody can do. We want that only the miner can perform this evaluation. But at the same time, If I win the lottery, I should be able to convince all of you that I did that, right? How do we do that? We need to modify like this construction. We do not use the hash function anymore. We use a tool that is called VRF. It’s called verifiable random function. Now, instead of having this verification key for the signature, we will have a secret key K. So K will be the minus, it’s not this K, it’s another one, bad notation, I’m sorry, but it’s the key. It’s the minus VRF. Secret key. So something that needs to remain secret. And there is also a public counterpart to this key. So PK will now be uh the minus. VRF Publicly. This public key will be used to verify my statement. I say, look, my VRF like has a low value. I won the lottery. And you can take this value. You can take my public key that will be on the ledger. It will be part of my like uh account, like the address of my account. And you can check that indeed my statement is true. And now, like I do not know who’s going to win in the future because this computation is private. Somebody is gonna win the lottery, but who? I do not know. Like I do not know who to whose computer to attack.

SPEAKER 3
Oh, why are we like using VRF? I don’t understand why VRF?

SPEAKER 0
Because if we use the hash function like and we just put the signature public key here and the pointer, everybody could compute that for you like. I can try to see when in the future you’re going to win the lottery. And when you’re about to do it, I attack your computer like I get your secret key and I generate the block that you had to generate in your stead. OK, so this VRF is like a signature. It has a pair of keys. Like a signature has the secret key that is the one used for signing and the public keys that is used for verification. Now the VRF is the same. It has a secret key that is the one that you use for evaluating the VRF. And the public key is the one to verify that actually if I tell you the evaluation of my VRF on this particular point gives this value, you can check that what I’m saying is actually true by checking it against this public key. That I put on the letter We are slowly getting there. I know it That is why like there is actually a lot of research in this, uh, proof of stakes like uh even the theorem one it’s not really amazing to be fair, like, uh, but like it’s like something that has entered into the world of research in the last less than 10 years, still we do not have like super nice solutions. OK, um, What is the issue now? The issue is that. This, um, what, 78, I’m sorry, I lost track. Um, it could be that nobody wins this lottery. And if that’s the case, the state of the system like is not updated and the whole system stalls. Like that would hurt liveness, right? We want that if you want to add a block, eventually it will be added, but this could stall. So uh yeah.

SPEAKER 2
16 with the BRF?

SPEAKER 0
The VRF is that if you have a hash function and you just put public information and that it is available for everybody in here, everybody can like evaluate the hash function for you. I can check when is the next time you’re gonna win the lottery. Right?

SPEAKER 2
So it was the same problem.

SPEAKER 0
Mm, not sure, like I So we were using like,

SPEAKER 2
uh, BK instead of just.

SPEAKER 0
Yeah, yeah, I’m talking about the same thing, right. Yeah, yeah, this is what we’re talking about. There is, uh, I think the question was more what’s

SPEAKER 4
the problem with just using VRF and SI.

SPEAKER 0
Oh, I see why that doesn’t. The issue is that it could be that at some point nobody, like everybody, all the participants have a high value here and so nobody is winning the lottery, right? And then what happens? Like you’re blocked, like the whole system stops because there is nobody that can add a new block and there is no change like in the system, right? Being unlucky.

SPEAKER 2
Because, so because it’s some sort of random motion.

SPEAKER 0
Yeah, yeah. There is a chance that nobody, everybody gets very high values. Nobody satisfies the quality. Nobody can add a block, and the whole system stalls. You don’t want that. So, to solve this issue it is quite simple. You just need to add a time stamp here or this is a time slot. Um, you need to pay a little bit of attention on how you do that. Um, what you do is like, suppose that this is the line of time. You want to split the whole execution into slots that are sufficiently large. So that’s like if one party wins the, so what is this time stamp? It’s gonna be the index of the slot, the temporal slot. And yeah, um, if one party wins the lottery in that slot, there is sufficient, this slot is sufficiently long that like the party can tell everybody um that they won the lottery. Like you don’t want the slot to be too short. Also because then you can perform grinding on the time stamp. Yeah. Final attempt. It’s what now I, yeah, don’t have issues with synchron yeah, definitely you need to hope that like that is not an issue. You need to assume that you have a sufficiently good network that if you send something eventually it will arrive like uh and you need to assume that everybody has a clock that. Like it’s up to date.

SPEAKER 5
Is there a reason that the VRF itself can’t be like it can’t be the responsibility of the VRF to handle the odds that its output is, uh, is, you know, is not too high a number, but how do

SPEAKER 0
you know like what other people’s VRF evaluate to?

SPEAKER 5
No, but if the VRF is, I’m saying if the VRF is a function that produces some. Oh, you want, yeah, but like there is the possibility

SPEAKER 0
that that VRF like has a high value, right? Like there is the possibility that you do not like win the lottery and everybody has the possibility. What if it happens? Like you have at least one half probability that you do not like win the lottery actually sire. Like what if you are 10 people and you are all, all these 10 people are unlucky, then the whole system will like stall.

SPEAKER 5
Can it help by just making the individual odds greater that the odds of each of those successfully happening if

SPEAKER 0
you increase the odds of single people, then like you have too many people that can publish blogs and like uh you would lose consistency like it would be insecure. Like it’s a better idea, yeah, sorry, can you explain

SPEAKER 2
again about the time stamp and the slots like what

SPEAKER 0
do you do to prevent like uh this stalling. Is that you add some time stamp like something that like gets updated if like the system stalls like eventually this part will change and eventually somebody will win, right? Because if I don’t know, let’s say at time stamp 1000, nobody wins. Then times continues running at some point we get into the slot 1001 and maybe somebody at this point wins because like the whole value here changed, right? If nobody wins again, let’s wait for slot 1002 and maybe now like we somebody wins like there is something that is changing like you don’t stop. The important thing is that the counter depends like it’s not the counter on the number of blocks, right? Because if you stall and the counter is the one number of blocks, that does not increase, it stops too.

SPEAKER 2
Yeah, but it’s still the same principle.

SPEAKER 0
Kind of, but like it’s different. Like the important thing is that tech counter is not the number of blocks. Because it like it could be that like for some slots there is no block added. But the counter, if there is no block added, the counter still goes up.

SPEAKER 2
Yeah, but then what condition has to be met for the, like.

SPEAKER 0
It needs to keep changing. Doesn’t matter what happens, and it should be that the slot is sufficiently large so that if somebody wins, you can tell everybody in that amount of time that like, uh, they have won the lottery and secondly, you don’t want to perform grinding over TS. You should not be able to try many different values of TS uh yeah, yeah, yeah, like, uh, it’s like I don’t know, like, uh, it’s the time exactly. Like you need to assume that everybody is synchronized, like, uh, they have a, a clock, uh, that runs at the same speed and like uh the network is sufficiently good. But yeah, like, uh, yeah, so, uh, TS is basically

SPEAKER 3
the time at which that person has started like computing.

SPEAKER 0
It’s the time, yeah, the time like, uh, like the time stamp of that particular slot, right? Like, uh, it’s the time at which the block was mined if you want. OK. Now, uh, final issue. Somebody, I think, uh, the girl on top of uh the room, um, she said, what, why can’t you do the grinding attack on the keys? Meaning like, why can’t I um try to generate many different keys so that I make sure that I win a lot of lotteries? Meaning like these values are gonna be small. And there is another attack. What prevents me to put a lot of like I have multiple accounts and I move the money like around so that like uh the stake is high for uh the accounts that have a low value here. So those are like a lot of these accounts we will have a high probability of winning the lottery. The solution to this is quite complicated actually. So we add another structure of our timeline. Essentially, the slot will be organized in what we call epochs. So, so maybe this could be an epoch. And for the whole epoch, The set of participants, in particular, their VRF keys. And their stake is fixed. What does it mean that? Um, now I’m a bit short in space, but like there will be some deadline here for that particular epoch. Well, essentially the participants here will be all the parties that joined and published the VRF key. Until the point and their stake during the epoch will be their stake. Like the amount of cryptocurrency they have at this particular deadline. But there is something that needs to happen in here. Because, I mean, so far this whole computation is somewhat um I mean, it’s deterministic, right? If I’m just before the deadline, I know the current uh SI minus 1. Like, what I can try to do is I can still try to find the K and the stake that gives me the highest chance of winning like lotteries in here. So to make sure that I cannot do this attack, we need to randomize what is happening in the epoch so that I cannot predict at this point in time what is gonna, how the lottery will be run here. So this time here is used to randomize the lottery. In particular, Each epoch will be associated With a random string are, this random string should be unpredictable at this deadline. This is fundamental. It doesn’t matter what the adversity does. That random string should be unpredictable to the adversity at this point in time. And that R is added in here. candidate We concatenated to like whatever. Now, of course, the question is how do we generate that R? I’m gonna explain it in a second. Um, yeah, this is where maybe proof of stake like really differentiate like every proof of stake has a different way of generating this randomness, but it’s fundamental to have that randomness and it’s fundamental that this are is unpredictable at the time of the deadline, the time in which like the parties essentially commit to their keys. By putting them on the chain and commit to the stake. So one possible way to generate this R to generate this R is to hash all the uh pointers, the size. So what is the society? This is the value of the BRF of the blocks. Here Of this time in between. So R can be like this is one of the many stantiations. The hash of then I do not know how to call them but like S J S J plus 1. And so on until S J plus uh. where this is like The block just before the beginning of the epoch. Why is this sufficiently unpredictable for the adversary? Because if this lot is sufficiently large, there is some blocking here that is generated by an honest party. And I cannot predict like what VRF value the Donner Party. Hat In that bloc. Yeah, so the talks from the deadline until the start of the airport, yeah. Yeah, like this is a solution. Like, uh, if you want, you can also hash everything from the start. It doesn’t matter. Like, as long as you have those blocks. If you want to hash something that is honestly generated, so something that is not, is unpredictable to the adversity. Uh, unpredictable to the adversary. At the time of this deadline, because if you has an honest block that was in the past at that point, like the adversary knew it, so it could like try to grind for a key that gave a higher chance of winning of winning the lottery, yeah, yeah, maybe

SPEAKER 5
this is going back a bit, but how would I as an adversary know what the S is. The essence of a block in the future if it’s a pointer to a block that might not yet exist, like it’s two blocks in the future instead of one in the future, yeah, but maybe like I win all

SPEAKER 0
the lotteries in between, right? Like if I win all the lotteries in between, like I mean, it’s unlikely, but like, uh, you know, like, uh, over a long span of time, maybe at some point it happens, and that is the moment in which I start the attack, right? Like if, if you flip coins, right? Like if you try to flip coins, at some point you will have a sequence of 10 ones. Like it sounds counterintuitive, but like a truly random string of bits like may have 10 ones in a row. Like with very high probability, like, so I just wait for that uh situation to perform my attack. If I, what I mean is that if I win all these blocks, I know like the state of uh desire at the beginning of this, right? Like what you want is that this is sufficiently large so that the probability that you have like uh uh all those blocks mined by you, the adversary is very, very low, like, uh, as low as like being hit by a meteorite like uh tomorrow.

SPEAKER 5
And haven’t we further already kind of made an assumption that at some point along the process there’s gonna be an honest party.

SPEAKER 0
Yeah, like we need to assume that there are honest parties. Like we need to assume that like, like the majority of the stake is in the hand of the honest parties, otherwise. So then how can we kind of assume both?

SPEAKER 5
How can we assume that we’ll both be able to predict or to know an S1, uh, like an S in the future?

SPEAKER 0
Like we don’t know which of the size will be of the honest party, but if we take a sufficiently large window, like we are pretty sure that there is, uh, one of the honest parties because. If the majority of the stake is in the end of the honest parties, at some point they will win, right? Uh, a lottery like they will add a, a block. Does it make sense? Uh, it does. But in that case then we wouldn’t be able to

SPEAKER 5
predict what the ass is gonna be.

SPEAKER 0
Yeah, you as an attacker, you wouldn’t be able to predict like, and then like, uh, your attack fails. Does it make sense? Yes, OK. OK, and that is the final solution. Um, I know I’m a bit late on the break. Like I want to. Just talk about one other attack that is the final one regarding proof of stake and then we can have the 10 minute break also because I need it. Um This is called the long range attack and it doesn’t attack the lottery, it attacks um the way in which uh we choose uh chains when we have conflicts, meaning like the longest chain because, um, Hello. Doesn’t want to collaborate. Do I need to turn it off and on again? Well, I can explain it like uh in words. So what an attacker can do is the following, like the stake is dynamic, right? You can move it around as you want. So as an attacker, I can take the Genesis block. And I can create a parallel chain in which I consider only the transactions that give money to me. Right? Like when I win a lottery, like I add the a block containing all the transactions that give money to my account and I ignore all the rest. So in this alternative reality, so imagine that here we have the normal chain. I’m slowly. Like accumulating stake, right? So as I go, my chances of winning the lottery keeps increasing. Because I’m accumulating stake, I’m ignoring all the outgoing transactions like I’m only accumulating money and I’m only increasing my chances of winning the lottery to the point that maybe at some point all the stake, the majority of the stake is in my hand, and I can start adding blocks like uh at a very fast rate. And maybe at that point I have the the longest chain. So How do we Like, fix this attack. How do we prevent this attack? The solution is that when we are given two different Change Like with a fork. We check the density of the blocks in the new candidate. If this attack was run. They at the beginning there were, there are very few like blocks per number of slots like in the time because like I’m only considering I’m only doubting the blocks for the slots I win for the lotteries I win and at the beginning I don’t have a lot of stake. So I have a very low chance at the beginning of winning the lottery. So there is, there are very few like uh like uh blocks per slot at the beginning. Then they suddenly increase. So essentially, if we have two different chains like we are uh like uh we need to choose in between. We also need to check like the density of the blocks. If it is too low, we drop it. And this is what we call the long range attack. Yeah Break Let’s see. Check. Perfect. Uh, back to the lecture. So yeah. Pa pa pa dines attack. Yeah, we start again. Please silence. Um, yeah, now, second part of the lecture that is shorter. Um we study the permission setting. Um, historically, this is the first one that was studied in this, we have solutions of um distributed ledgers in the permission setting since the 80s, like the permissionless setting was analyzed and finally we had solutions only with the Bitcoin paper, so 2008. And yeah, this kind of letter are letters where, uh, the set of participants is fixed and only the parties belonging to this set are allowed to read and write from the letter. Everybody else doesn’t have that permission. And they’re actually is somewhat simpler to design. We need, however, some tools that maybe you haven’t seen because if the access to the laser is um. Like authorized only to some parties, you need some tool to verify identities, right? But how do we verify identities over the Internet? Like, imagine now you go, you all go home and like in the evening, you find a message from me. How do you know it’s really me and not somebody else? Somebody that pretends it’s me. One possible solution to be sure is that now during the lecture I give you my signature public key and then when I send you the message this evening I also sign it using this key and you can verify that actually the signature verifies under the public key I give you here. But what if Actually, you never met me. Like, what if I am somebody on the other side of the world and you never had the possibility of exchanging the public key as I’m doing now. That is why we on the internet we rely on what is called a certificate authority. And these are some trusted nodes. There are a few like they usually are companies. Um, that take care of essentially issuing certificates that bind together my physical persona and my digital identity represented by my public key. What does this mean? It means that When I enter in the system, I contact the certificate authority and I say, look, I’m Damiano Abram born in this place like, uh, in this year. And like I provide some documentation proving it like I don’t know a picture of my passport like or if you are a company it’s a bit more involved. I do not know exactly what are the checks it depends on the company you contacted. And you prove also that you know the secret key of the corresponding to the signature key to the public key. You don’t reveal the signature key. There are ways of proving that you know the sec the secret counterpart without revealing it. Um, but yeah, if you pass all the texts, essentially this certificate authority releases this certificate that says, OK, Damiano Abraham born this pla like in this place this year, like has the following public key signed the certificate authority, meaning there is a digital signature, uh, on the certificate that verifies under the certificate authority public key that everybody should know. OK. There are few around the world. Usually you have them installed like stored on your computer, OK. So essentially it’s as if the certificate authority is an intermediary. Like it comes to you and says, oh look, like this is Damiano like uh um like you can talk through this uh um public signature key. OK. Now this is the 10 1 of what is called the public infrastructure like that. Like, uh, encompasses the whole world if you want or like if you want you can generate one for your specific system with, uh, you create a certificate authority of your subsystem and like you issue the certificates. Um, actually in practice is a bit more, uh, complicated because certificate authorities can delegate other certificate authorities to issue certificates. So essentially I, the main certificate of authority, I delegate her to uh issue certificates to you like uh on my behalf and so when you talk to somebody you don’t just give them the certificate that says like look the certificate of authority says that this is me, this is my public key. Like you actually give a chain of certificates. Like the first one is the certificates that the main certificate of authority delegates the second certificate of authority. The second certificate is the one that says the second certificate of Authority delegates the 3rd certificate of authority, and so on until you have the last one that says the last certificate of Authority guarantees that this is my public key, OK? But yeah, and then the other issue is that sometimes um cyberattacks happen and somebody enters in your computer and finds your secret key. And then the person can take your certificate, which is public, maybe they just talked to you like in the past and you just send your certificate to them and now they also know your secret key, so they can go around pretending it’s you, but they are not. So how do you deal with this? When that happens, you would need to contact the certificate authority and you say, look, I had a security breach like my key is no longer secure, please put it in the blacklist of certificates that are no longer uh should no longer be accepted, OK? So the certificate authorities have like the uh blacklist of uh broken like insecure keys. And when I come to you and I say, look, I’m Damiano. This is the certificate like this certificate authority guarantees it’s me, what you do is not you just of course you need to check the signature if it like verifies. If it does not verify, discard me immediately. But if it verifies, you also need to contact the certificate authority and uh and say please send me the updated list of uh blacklisted, uh, uh certificates. If my account is in there, you should not accept it. But yeah, yeah, how do you blacklist it?

SPEAKER 4
Is it because like, obviously you need to somehow prove that it’s actually you that’s blacklisting yourself like an old version of yourself somebody else blacklisting.

SPEAKER 0
I do not know exactly the details. Probably depends from certificate authority to certificate authority, but yeah, of course you would need like to provide sufficient like a guarantees of that. For instance, you at least would need to say like, look, I know the secret key of this uh public key, right? I can do that. Like the worst case, like I’m just blacklisting a certificate that is actually secure, but yeah.

SPEAKER 1
If it’s not sort of fundamentally going against the distributed nature that you have a sorry it’s going against fundamentalist or distributed nature, yeah, yeah, absolutely, but there is no

SPEAKER 0
way you can link your personal identity to your digital identity without some level of trust, right? Like you need to rely on like, uh, that is a bit like the misconception a little bit like a blockchains you hear, oh trustless, trustless, trustless, is it truly trustless? No, there is always a little bit of trust like you’re kind of minimizing it, but like. You need to have some trust somewhere because otherwise you’re running into the many impossibility like we’ve seen one the last time, OK? OK, um, the other issue with this permissioned ledger is that typically if reading access should be authorized only to some parties, you want to keep the ledger private, right? But now imagine that I want to perform a reading operation on this letter. Like, uh, the information should come to me, but if you know, like it’s the internet, like, uh, it’s not that I have my private channel like a pipe in which I speak and like on the other hand there is somebody else like this is information that goes through routers and like anybody can listen and check like what is what my message is containing. So how do you ensure, uh, the privacy of this communication and to do that you would need uh encryption. Um, I won’t go into the details about this and how you like set it up, like, uh, for this, there is the modern cryptography course that I recommend, um, But yeah, there is this tool is called TLS 1.3. It’s just a protocol that is used everywhere in the Internet. Every time you have this, you know, you open a website HTTPS, it means that S means they’re using encryption like it’s private, uh, communication. Like once you have this exchange of certificates, you know who you’re talking to. Like you can rely on this tool to encrypt the whole communication, making sure that. Only you and the person on the other side can understand what is communicated. Anybody that listens in between routers like uh proxies, whatever, like uh they cannot do anything. They just see some random looking string of bits, OK, without really understanding what is going on. OK, um, now imagine we have these two tools to set up some sort of virtual, uh, channels that are authenticated and, uh, private, virtually in the sense that it’s not a pipe that connects me to you, but like it’s through the Internet, but like you still have the guarantee that whatever comes in on one side like arrives to the other side, nobody can. Listen to it and uh also you’re sure that whatever arrives is actually me and it’s not somebody else. um OK, given this tool, how can we build the permission ladder? There is one, Let me see this one that I think it’s the boring solution to the whole thing like I wouldn’t, it’s not a distributed letter, it’s a centralized letter essentially pick the most um trusted person in this room and you say no you keep the letter every time uh you want to insert something contact I don’t know her and you tell oh please add this transaction in the whole thing. And if you want to check some transaction that happened in the past, you come to her and you say, please um send uh the transaction that happened at that point in time. And of course, since this is an authorized setting, like every time you talk to her, you know, you need to first exchange the certificates and you need to establish an encrypted channel. OK. So nobody else outside of this room can understand what is happening. So this is called proof of authority, but essentially this is the boring solution. Sometimes it’s not too bad like. With 2010 in which there was this boom of blockchain application, people like, like try to apply blockchain solution to systems where this solution was working perfectly. Like, uh, there was, there were fridges that were putting stuff on the blockchain like at some point. And sometimes you can just try if you can trust somebody to, to run the ledger because I don’t know, it’s a server you own, sure, like use this solution, like it’s perfectly fine like. Distributed ledger are needed when You’re not really sure who to trust. Like you can just trust that in the system, the majority of people is honest, but you don’t know who is honest and who is not, OK? Or like depends computational power stake like it depends a bit like in the system how this is phrased. OK, uh, anyway, this solution works as long as the server is trusted. If she is not behaving as we expect her to behave, if she says, OK, now I don’t respond to read operation anymore, or she starts being more malicious and sends like wrong information to your queries or not storing your, uh, like, uh, the transaction you want to add or even storing fake transactions. Um, we would run into an issue like the whole system would collapse. That is why there are more, um. Um, better solution in this regard, uh, which are called like a distributed permission, uh, letters. Here we don’t have only one server, uh, but we have a bunch of, uh, servers. I don’t know the first row here. And these letters will run a consensus protocol like either the ones we described in the last two lectures or the one that I’m going to describe soon, hopefully. And uh um yeah, essentially to write uh something in the letter you connect to all of them and you say add this uh information to the letter. And um if you want to read some information, you contact each of them establishing this uh authenticated private channel and uh when you get all the answers, you take the majority. And as long as the majority of them is honest or a majority of the resources in their system is held by honest participants or the same thing with the stake, you have to guarantee that like the system works. Slightly better than the earlier one in the sense that um trust here is distributed. You don’t care if one particular person is honest or dishonest. You care that the majority of them or the majority of the competitional power or the majority of the stake is in the hands of the honest people. OK. And uh, yeah, I mean, this is kind of it. Um Finally, I want to say a few words about the old kind of consensus protocols that maybe we mentioned the last time. These were the pre- Nakamoto style consensus, uh, protocols. Um, they’re called BFT style. BFT means, uh, Byzantine fault tolerant, and Byzantine was this term, weird term that we saw at the beginning of the last lecture. Um, What are the main differences between this BFT type consensus and the Nakamoto style consensus? Uh, BFT typically is, uh, permissioned, first of all, like it’s not permissionless. Permissionless was something that was introduced with the Bitcoin paper, so Nakamoto style. Um, they don’t need, which is a positive, they don’t need this weird assumption on distribution of resources either computational or stake. Like, uh, they work no matter what, but of course they need a majority of honest participants or a supermajority depending on the context. Supermajority meaning like more than 2/3 of participants is honest. Um, So on one hand, they have weaker assumptions they need. Uh, on the other hand, the computational, the communication cost is much higher because to generate a block, essentially all the participants need to speak, whereas in like proof of work or proof of stake, the communication per block is one person. One person says, I won the lottery. Here is the block, right? And yeah, the goal for the last 10 minutes would be to uh give an example of this uh BFT type consensus. Uh, I’m not sure I will have time to go like in the actual mathematical details, but maybe just to give an idea. So this follows the following paradigm. First we achieve what is called graded broadcast, and then we use binary consensus protocol to, to actually agree. What is graded broadcast. Essentially the problem is the following. I am the sender. I want to speak to all of you. And You want to be sure that everybody receives everybody that is honest receives the same message, OK? If I say I don’t know, suppose it’s just a bit. I say 1, we want that all the honest participants here receive 1 and agree on it. We don’t want some people that are honest that receive 0, OK? And it’s created because essentially as part of the output. You have also a grade means meaning how confident you are. It could be 01, and 2.2 means you’re absolutely certain everybody agrees on this output. One means, uh, like most likely output is this, but it could be that maybe not all of us are agreeing on this. 0 means I do not know absolutely, OK? So, yeah, this is essentially like er how it works. And how do you build this? First of all, we need to assume that the majority. That we need to assume is honest supermajority, like 2 at least 2/3 of the participants are honest. And it works like this. First of all, me, the sender, sends the message to all of you. But now you need to make sure that like everybody received the same thing because it could be that I’m malicious and I send to half of you some value and to the other half some other value. So how do you proceed? Next, you exchange the message you have received with everybody else. You say, oh, Damiano told me one. And like she said, Damiano told me 0. And of course you don’t know, like it could be that I am malicious and both of you are honest. Like I sent, uh, um, I don’t remember 1 to you and 0 to her like and so nobody’s lying or it could be that I’m actually honest. I sent 1 to both of you and like, uh, she is lying and trying to convince you that actually I lied and I sent 0 to her like, um, so there is this second round of um sending the message to everybody else. And then what do you do? You check the messages that you have received in this 2nd round, and if there is one that has been received by at least 2/3 of participants, You can send it again to everybody else. So you understand how much communication is going on here. Everybody is speaking to everybody. And this is just to agree on what I said. It’s not even to agree on a blog. OK. Um, yeah. Essentially That’s the end of the protocol. Then what you do is you check the messages you have received in this last round, and if there is a message that you have received like uh by at least 2/3 of us participants in the last round. You say this is the output and the grade is too. I’m sure that every honest party agrees on this. If instead there is no such message, you check if there is one that was sent by at least 1/3 of participants. And in that case you say most likely this is the output. But like uh like uh maybe not everybody agrees on this. And if there is not like uh output whatever you want like uh with 0. Like escarade, you have no idea of what is going on. And yeah, like, here are some theorem proofs you can take at home because I don’t have time um that uh shows that, like it shows that this is indeed a graded uh broadcast protocol, won’t have time to go through. Um, yeah. So how do you go from this to like an actual ledger? It would start like do some sort of round robin like um. Like, uh, we take the timeline, we split it into blocks, and each block there is a person that is the leader. That leader will run this credit broadcast. I mean, imagine that I am the leader for the first round. I collect all the transactions we want to add to the ledger and I use this graded protocol to send it to all of you, OK? But now you’re not sure that everybody of you agrees on this block. You need to make sure that like still like uh everybody is on the same page. So how do you check? You need to run like what we described the last time this Byzantine agreement protocol like between all of you. Your input will be 1 if like uh you have 2 as a grade, you are absolutely certain that like that is the value. And uh the um your input will be zero otherwise. If the output of this Byzantine agreement is one, meaning everybody agrees that like uh this is uh uh that all honest parties have received this block I sent, then you can add it to the chain. This works. Why? Because at some point in the round robin, you end up hitting an honest participant. So the guy that like me, the sender, the one that broadcast the block, um, will behave honestly. And in that case there is the guarantee that in a creative broadcast everybody has confidence too in the output, all honest parties. Maybe this is something that I forgot to say earlier like creative broadcast. Like if the sender who speaks out to everybody else is honest, everybody uh has confidence gra too in the output. So all honest parties agree on the final output and they are sure that everybody else agreed. And yeah, of course the question is once again how do you do the Byzantine agreement like with 01 as input? We haven’t seen it like uh the last time. Uh, the solution is quite um annoying because what you would need to do is the following. You have T plus 1 round where T is the number of, uh, corrupted parties. Like you don’t know for sure, but like you take an upper bound like suppose 1/3 of the participants. So, in each of these rounds, everybody sends like whatever they have received in the round before to everybody else. So in the first round, like every, each of you has a vote, like, namely we take this block 0, sorry, 1, we don’t take this block 0. You send this message to everybody else. Then we enter the 2nd round. It means that in this 1st round you have received the message from everybody else. Now you resend those messages to everybody else again. So, if at the beginning there were n messages in the 2nd round, there would be a squared. Then you go in the 3rd round and you repeat again. Like, and so there would be an exponential amount of like messages sent around. You end up arranging them in a tree because essentially. You can view these messages as some sort of gossiping. Like, if I receive a message at the at the J’s round, it’s as if you’re saying, oh. You receive the message that says this person told me that person said that this person said that this person said like it’s a chain of J people like so you can arrange it kind of in a tree saying like you2 is the message sent by party 2 in the first round. This is the message sent uh by party 3 claiming that party 2 said something in the previous round like. You can create this tree and then to determine the output you start from the leaf. You take a majority of like uh the value as the children. You substitute the parent with the majority of those children and then you repeat until you reach the root of the tree, and that will be the output and it turns out this gives you Byzantine agreement, but super complicated, super expensive in terms of communication. And it turns out you cannot do much better. Yes, you can avoid this explosion in the total communication so that it doesn’t grow exponentially, but like you still need this number of rounds that is proportional to the total number of parties. You can’t help, uh, otherwise. I’m sorry for the rush. Like, if there are questions about this part, the next time, you’re really welcome to come and ask questions.

Lecture 5:

SPEAKER 0
Can you hear me? Yeah, nice. So, hi everybody, and welcome to this lecture. Uh, my name is Damiano and I will be the lecturer uh of this course for the rest of the semester. And with today we start the more theoretical part of blockchains and distributed ledgers. So, first of all, some information I wrote on the whiteboard, my email address and uh uh uh my uh office address. You’re welcome to come whenever you want but maybe send an email first so that I’m sure that I’m there to receive you, OK? Um, as the communication, um, I really want that if you have any questions, you just stop, you raise your hand and like you ask whatever you need to, uh, ask. Uh, you can send me emails, you can come to the office, you can talk to me after the, uh, lecture or during the break. I really want this to be some sort of discussion, OK? Like I’m here to help, like you understand the subject. OK, um, it could be that I’m a bit, uh, scattered today. Uh, it’s my first, uh, lecture ever, so, uh, bear with me, but like, uh, I’ll do my best. OK, um, let’s start with, uh, the content of today. So, probably in the first lecture, I told you what a distributed ledger is. It’s this public book, uh, to which everybody has access. So if you want to read, like you can get whatever is written on the book, like it could be transactions or like uh the state of your smart contract. And you can also add pages if you are willing to do enough work. Like you can add new transactions or you can update uh the state of your smart contract. Now, I have a question, namely, where does this book lie? Where is it? Like, where is the physical book? Like, any answers? Yeah.

SPEAKER 1
It’s like on all the computers.

SPEAKER 0
Yeah, essentially there is no single book. There are many copies, one for each, uh, machine in the system. But then it raises a question, namely how do we ensure that these copies are consistent with each other. This is important because if we put transactions, for instance, in this letter, we don’t want people to double spend their money. I don’t know. Imagine I have 10 pounds and I need to buy land and I attack the system in a way that in her version of the letter, I pay this 10 pounds for a piece that she made. Whereas, uh, in his version of the letter, I paid this 10 pounds for, you know, pasta carbonara or whatever, uh, would be essentially happy Italian. I paid £10 and I get both pizza and, uh, uh, pasta carbonara. So this is an important problem and it’s something that people have studied for many years. Uh, it’s called either the consensus problem or with this we are named the Byzantine agreement problem. The reason of this weird name is, uh, because of a story from which everything stems from mainly imagine we have a castle that is besieged by the army of, uh, Byzantine like uh it’s the old name for Istanbul. Um, and this army is controlled by several generals that are positioned, uh, over the territory surrounding the castle, and these generals cannot move. They need to stay in place, otherwise people from the castle would run away. And so to communicate, they just need to send a messengers. They cannot meet in person. And yeah, these generals need to decide, uh, what to do, like, uh, in particular whether to all attack, uh, the castle and conquer it or to retreat because maybe they run out of resources. But it doesn’t matter what they choose, they need to do all the same thing. Either they will attack or they all retreat because if a small group of, uh, generals attacks the castle, they are more likely to be defeated and The army would lose strength. So, now imagine each of these generals have a different opinion on what to do. Some people say attack, some people say retreat. Uh, how do you decide? How do you reach agreement? And one could say, oh yeah, you can just send messengers and then you take a majority vote. And sure it works. But what if one of these generals is a traitor? It’s somebody that colludes with the people in the castle. This traitor will try to uh prevent agreement. He will try to make sure that only a few of these generals attack the castle, so the people in the castle will defeat them and then like hopefully they manage to win the war. And yeah, this is kind of what we are dealing with in uh a distributed ledger because, yeah, people need to agree on the history of the transaction of how these resources move throughout the system. And everybody has a different opinion on what to do, uh, on how to spend money and how this was spent, and potentially there are people that are willing to like, uh, act maliciously to like, I don’t know, become richer or whatever. And yeah, um. First of all, to understand that this problem, we need to define it. And so let me make uh some sort, some sort of simplification. Let’s split the participants in two big groups. There are the honest parties that are those that run the code as we wrote it, like they are following the protocol, and then there is everybody else which are parties that are potentially acting maliciously. Like, uh, they misbehave, they can do arbitrary things. Potentially they can also collude. So without loss of generality we can assume there is this evil entity we call the adversary that takes control of all of these and coordinates them to attack the system. And yeah, a bit of notation we call the number of all parties and and the number of uh corrupted participants t. OK? So if I say malicious, dishonest, corrupted, or Byzantine, we mean parties that may misbehave. OK. What is a consensus protocol? It’s a protocol in which all participants have some input corresponding to um the desired choice, like in the case of the generals, whether they want to retreat or to attack. In the protocol, they interact and at the end of the protocol there is the final decision what people will enforce, like the final decision whether all generals attack or all generals retreat. And yeah, the consensus protocol needs to satisfy some properties. The first of all, first of all, it just needs to finish. Like we don’t want the communication to go on forever. We need to reach a conclusion. The second property is agreement. Like this is written in a mathsy way, but essentially it says that at the end of the protocol, all the honest parties agree on what to do. It doesn’t matter what the malicious parties do. And third property, validity. It says that if all the honest parties have the same preference at the beginning of the protocol, then the final decision they take will be exactly this preference they all want. If all the generals wanted to attack, in the end, the honest generals will attack. Doesn’t matter what the malicious uh generals do. If they all wanted to retreat, all the honest generals will retreat at the end. Now, um. I Like the difficulty here is to achieve both agreement and validity simultaneously. Achieving only one of them is quite easy, OK? How can you achieve uh agreement? Without validity It’s quite simple. Like if you have the room, you all output, I don’t know, some predetermined value 0. Like you all agree it’s 0. Maybe everybody wanted 1 but like uh the output is 0, you all agree. Achieving validity is also easy if we don’t want agreement. Everybody outputs whatever they want. Like you don’t agree, but, uh, everybody, like if you agree all on what to do, you will all agree on what to do after. The difficulty is indeed in achieving both along with termination. There is also a stronger form of validity, uh, that essentially says that, um, All honest parties will output something that is the input of some other honest party. So I understand if all the honest parties agreed at the beginning, like er they will end up like uh like outputting that value uh at the end of the protocol. Yeah.

SPEAKER 1
If you only have agreement and valid validity. Wouldn’t it also be possible that all honest parties just always op like a constant value?

SPEAKER 0
If you have only agreement.

SPEAKER 1
No, both because it would also be valid, right?

SPEAKER 0
Like they all output what a constant value but validity says what if the parties, the honest parties to start with, prefer something else? Like, I don’t know if the constant value is, I don’t know, let’s say it’s 0, it could be that all the honest parties want one. Validity says in that case, the final output is 1.

SPEAKER 1
OK, this is normal valid validity. I don’t. Could you explain the formula again validity says.

SPEAKER 0
If the honest parties at the beginning of the protocol all have the same input, they all have the same preference. The output on which they agree is exactly that preference they wanted. So, if all the honest generals wanted to retreat, The final decision will be that the owners generals retreat. If all the owners general wanted to uh attack, the final decision is that the old owners general will attack. OK.

SPEAKER 1
But it’s like talking about when there is disagreement, like

SPEAKER 0
a validity doesn’t say anything. Strong validity says something there like strong validity says that all honest parties will output something that is the input of uh some other honest party. We don’t know which one, yeah.

SPEAKER 2
Can we even achieve validity or strong validity without termination because we don’t have an output Yeah, there are situations

SPEAKER 0
like it doesn’t, they are not even defined to be fair, like, uh, yeah, yeah. So like, do we even like need to specify we

SPEAKER 2
need termination because validity technically implies to us.

SPEAKER 0
It’s a bit of a technicality like uh you need to like define termination to say the output is well defined. But yeah As the questions Yeah, I just double check

SPEAKER 3
strong validity means that uh the output of an honest party will may they may not get their own input, but they will get the out they will get as

SPEAKER 0
output the input of some other honest party. Yeah, yeah, it means that I don’t know, like imagine that the possible uh preferences are 01 and 2. All the honest people here um have preference that is either 0 or 1, like maybe the corrupted parties have preference too, but it doesn’t matter. Like um the uh output will be ISO 0 or 1. It cannot be true, OK. And of course it it implies validity because if you all, if they all, if all honest parties have a preference one, they will output one. OK. Now, um, The question is, how can we build this consensus protocol? And the first thing we noticed is actually that we can do this only if there are not too many corrupted parties. In particular, we want that, the majority of participants is honest. Now I’m gonna prove this, like I will do it on the board. So essentially we consider 3 world cases. That’s cool. World one. A little too. And we’ll see. Now, let’s start from world one. Here, the adversary that I denote by A corrupts nobody. So everybody’s honest. And we assume we have N parties split into two groups. Half of them Run the protocol, protocol honestly with input. 0 The other half We run our um uh consensus protocol with input one. Now, every, everybody is behaving honestly. What can we say about the output of these parties? If this is a consensus protocol. We have 3 properties, right? Termination, it means they terminate. Second property agreement. What does it mean? Yeah On the output.

SPEAKER 2
Hm, I mean they all agree that they like in this case they all agree that the input to the consensus protocol is gonna be 0, so the output should be 0.

SPEAKER 0
The protocol is. No, uh, these people have input 0. These people have input 1. They all run the protocol together, right. Like, you don’t know which one is the output, but you know that they all output the same thing, right? These are all honest parties. Agreement says it doesn’t matter what the input is, at the end of the protocol, the honest parties reach agreement. So it’s gonna be either 0 or 1. It’s a 01, but for sure everybody agrees on what to do, OK, so is it strongly. No, I’m talking about only agreement here. Agreement Can you see what I’m writing or like is the computer in the way? Uh, I’m sorry. So maybe uh. Maybe I wrote it here Agreement Uh All outputs. are the same. Does it make sense? Is it clear to everybody?

SPEAKER 5
Will you clarify on what exactly all outputs are the same.

SPEAKER 0
So these are a group of parties and everybody will output uh something right at the end of the protocol. They send messages and at the end the output will be the final decision they will enforce, right? Like agreement says that doesn’t matter if they disagree on the input like, but the output will be the same because all these parties are honest. Yep.

SPEAKER 6
the resolved In practically, or it depends on the protocol,

SPEAKER 0
but now assume we have such a consensus protocol. I’m saying, assume you have such a magic box. It doesn’t matter the details. What happens if we run this magic box between these two sets of parties, honestly. We don’t know exactly the details of what happens, but for sure since this protocol satisfies agreement, all the parties output the same value. Correct, because I tell you, uh, it’s a promise. This box I give you satisfies termination agreement and validity.

SPEAKER 6
The final response will be either 0.

SPEAKER 0
Uh It’s either 0 or 1, but the important thing is everybody agrees on what to do. It’s not that some people output some value and the other people output something else, OK?

SPEAKER 6
Yeah, so everyone participates in this.

SPEAKER 0
For sure, yeah. Second world Now, It work, yeah. Let’s assume that adversary can corrupt a majority, like 50% of the participants. OK. The adversary corrupt. The first set. So now, The first group of parties, oh well. The one with input zero. Will be corrupted and the other will be honest. And they still ran the protocol. And yeah, this is a weird adversary. Um, it potentially, it can behave as it wants. So, in our example, it will behave honestly, as if the input is zero. It’s a bit weird, but yeah, the adversary can do whatever it wants. It can also behave honestly. Now, what can we say in this context? About the output of these honest parties.

SPEAKER 4
D Hm?

SPEAKER 5
It should be.

SPEAKER 0
The output should be different from what would No, the agreement says that all honest parties will achieve, like will have the same output. It doesn’t matter what the adversary does. So these parties will still output all the same value. The corrupted party can do whatever they want. We do not care. Like if they are corrupted. We give no rights to corrupted parties in this world, OK. Um, my question is more, uh, the output. What is the output of these parties? We need to apply the other property, validity. Remember, what does validity say? If the honest party all have the same preference to start with, the output would be that pre preference. But here all honest parties have the same preference. It’s one. So, all these parties will output one. Does it make sense? So validity. Oh Parties On uh Uh, the right. Output one. Third world We still have and have parties that output 0 sorry, that have input 0. But now the adversity corrupts the other half. The ones that have input one. And once again, the adversity behaves honestly. What can we say in this world? What is the output of the honest parties? 0, again by validity. What do you say? Parties On the left, on the, yeah, on the left. I’ll put 0. But now there is a, yes, uh, yeah, so I’m

SPEAKER 1
just a bit confused because you’re saying the adversary corrupts one group at the same time the adversary behaves honestly.

SPEAKER 0
Yeah, it’s a bit weird, but like, so how can

SPEAKER 1
like the other group know that they are the honest group. The the other parties do not know who is honest

SPEAKER 0
and who is not, but it’s like kind of saying

SPEAKER 1
we always say, OK, if they are part of the honest set, then they will all agree on their own thing, but how can they.

SPEAKER 0
They do not know who else is honest. Yeah, they do not know. Like they just know that whoever is honest, like in this room will agree on this. So we’ll do this thing like the other people are corrupted, like, uh, the assumption of this magic protocol, yeah, yeah, there is the assumption of the magic protocol. Like we will explain later how to achieve it, but like, uh, it’s not an easy question like, uh. They started like uh asking this question in the 80s and to this day, there is still a lot of research on this sort of protocols, so. Yes, how do you tell who’s malicious?

SPEAKER 6
Sorry, how, how do you? Concerned like which, um, You can’t.

SPEAKER 0
You can’t. You imagine that like this part is, is this room. You don’t know like who is uh honest and who is not. You don’t know who to trust. Like, uh, but it doesn’t matter. Like uh if we have this uh magic box. Like it will happen that whoever acts honestly will agree on what to do next.

SPEAKER 6
But then is that output then also I guess kind of forced on the mili?

SPEAKER 0
No, you can’t, of course, like who is corrupted can do whatever they want. Like, you can only Coordinate among the honest ones, but like the corrupted parties, they can do whatever they want. They can now put one like the corrupted, the traitor general in the bus in the seeds can often like can attack the other generals. There’s nothing you can do, right? Here it’s only about what the honest parties can do like uh the best we can. Now, going back to this uh argument, I want to show to you that this is actually um We reached some sort of contradiction because these three worlds are actually the same one. Why? Because whatever these parties do is always the same thing, right? Even when they are corrupted, they behave honestly, so they send the same messages. And they compute the output in the same way. But here it says That They output the same thing. Here they say this block on the right. Always outputs one And here, the block on the left, I’ll put 0. Like this is a contradiction. So essentially there is something, yes, could you please explain

SPEAKER 5
how would you get like a stronger validity in the cases of this?

SPEAKER 0
I mean you. Like you get a box that satisfy validity. I’m not talking about strong validity, so it’s maybe impossible. Like, uh, it’s not that there is a way that if you have a protocol that has validity, you get strong validity, OK. Um Yeah Going back to the situation, like what I’m saying is that these are actually the same world. And we have contradictory properties here. So what is the conclusion? The conclusion is this magic box cannot exist. Or at least, it cannot exist with this particular property that the adversity can corrupt half of the participants and still we have validity and agreement. Essentially what I’m saying is If consensus protocols exist, they cannot withstand like a majority of corrupted parties. The majority of people should be honest. Let’s see. OK. So this was the impossibility. You find it on the slides if you need to check it again or anyway on the video. Now the question becomes, Is honest majority sufficient to build these protocols? And actually, also here, the answer is quite tricky. Like as I said, we have been studying this from the 80s and still like uh there is research to do. It’s a very complicated question. So the answer to this question depends on two factors. The first one is whether we have as a tap or we don’t have it. And the second one is whether the network is synchronous or uh partially synchronous or asynchronous. I explain what this means. So the setup means simply that the protocol starts with um some dealer, I don’t know, somebody that we can assume is honest that provides the uh participants with some correlated information. Something to begin the protocol. Typically, this is a list of the signature keys of all the participants so that you can use it to authenticate your communications like He knows my key, so I can send the message signs under my key, and he knows that I sent it. Yeah, the, uh, regarding synchrony, synchrony essentially tells you how, uh, reliable the network is. We say that a network is synchronous when, um, if we send the message, we are sure that this arises within a certain interval of time, OK? Like it’s a network that it’s ideal. Like you send, I don’t know, in 10 seconds or even 1 hour, it doesn’t matter. It arrives within that interval of time. A network is asynchronous when you don’t have this guarantee. Like messages can be delayed arbitrarily. For instance, when there is a denial of service attack on the network. And then there is partial synchrony, that means you switch between phases of synchrony and phases of asynchrony. But yeah, As you can see on the slide, We can build. Um consensus protocols that will stand, uh, that have agreement and validity with an honest majority only when we have both the setup and a synchronous network. In all other cases we need a supermajority, meaning that the number of corrupted parties is less than 1/3 of all participants. Yeah, um. Yeah, this is about this stuff, yeah. Anyway, uh, we won’t go deeply into this possibilities and impossibilities. Now I would like to explain to you how we really construct one of these, uh, consensus protocols. But we don’t build exactly, uh, the protocol I described, we build something slightly different, namely, A letter, a distributed letter. And here essentially we want, it’s a particular form of consensus. First of all, because a consensus protocol is one shot like you will have an input and then you have an output. Instead, with the ledger there are always cont like a continuous input of uh transactions you want to add to the letter. Secondly, we do not care so much about validity. Uh, we care more about no censorship. Meaning that if any of you wants to add a page to the ledger, we cannot censor you. Like this page will be added. And so, yeah, the two properties we need are actually the one you see on the slide. The first one is consistency that is more or less derived from curement. And it says that if you take any two honest parties, And any two intervals of time. I is The ledger of the first party is a subset of the ledger of the second party or vice versa. Could you say it again? So, take 21 as parties and, and the letters that they have at two different intervals of time. Either the letter of the first party is contained in the letter of the second party, meaning that the second party has a slightly longer book, but at least they agree on the, uh, the shorter, the, the first pages. Or vice versa Leibni instead says no censorship. Like, if an honest party comes up with a new transaction to add to uh the book, this will be added eventually. We don’t know if now or like uh in a day, but like eventually it will be added. Yeah. So, these are the two properties we want. And yeah. Actually, we found a way to solve this question, um. At the end of the 90s with this paper by Castro and Liskov. And there they uh proposed a solution that works in a synchronous network. As a consequence, we need a supermajority of honest participants. It has a fixed number of parties, so There is a setup in particular, like, uh, at the beginning, the set up exchanges information about uh the participants and then if anybody wants to join, they cannot. You would need to restart. And what else? Yeah, the communication complexity of this consensus protocol is pretty high. It grows quadratically in the number of participants. But then something new happened like this was uh 2008, I think, or 2009. There was the Bitcoin white paper by this unknown person, Nakamoto, probably a pseudonym. And they proposed a new way of obtaining consensus. And yeah, um, the approach of uh Nakamoto is very different and achieves uh very interesting properties. First of all, in some sense it’s a weaker form of consensus because it works in a synchronous network. It assumes that if you send the message, this arises within a certain interval of time. But on the other hand, it has no setup, so parties can Leave and join arbitrarily like as they please. They have a slightly stronger um. Assumption on the adversaries, on the corrupted parties. It assumes they they don’t own like a majority of uh resources. of computational resources in the system. And yeah, it has other very interesting properties. In particular, like it can also withstand spikes of adversarial behavior. It could be that momentarily the adversary has a majority of all resources. But with time, the system will heal like so. It will still guarantee agreement and validity. And yeah, also the communication is somewhat optimal. Like we don’t have this N square communication complexity. Now, I want to explain to you how uh we have achieved this uh how Nakamoto achieved this uh consensus protocol. And yeah, um, there are 4 core algorithms we need to uh analyze. The first one is how um we validate like the chain. The second one is How we select a chain, like when there are multiple people that propose a different version of the chain. Um, how we add new pages. This is the proof of work function and then the general loop iteration that is what like essentially what happens like continuously in the background of a minor. And yeah, let’s start from the model, um. Suppose we have parties. And all of them have More or less the same computational power, meaning that They can only have a quota of times they can evaluate a fixed hash function 8. And yet, we assume that there are at most 3 corrupted parties. Now, I would like to start, maybe I will use the board, which is maybe better. Um I would like to start by explaining How A page look like. So First of all, how does the book look like? It looks like a chain of pages we call blocks. And each page points to the previous page, OK? So the block is made of 3 parts. So There is. A counter There is the actual content, meaning your transactions or like the state of your smart contract or whatever you want to write there. And then there is a pointer to the previous page. So counter content. This would be the big part. And this is OK, now, I will start by explaining how you can add a new page. So Suppose we want to add a new block with content X. And uh yeah. What we do is the following. We rely on two hash functions. 8 and Z. First, we compute. A hash of the new contact x. With Like the pointer to the last page in the book. So This is Find that To last Page In the book. So this pointer will be essentially a hash of the previous page, but I will explain more in detail how this is computed later. Next, we set the counter. The counter to one. And then we start checking the following inequality, whether the hash of the counter with age. It’s smaller than some target threshold. So this is called um target or harness parameter of the same. Now, if this equality is not satisfied, what do we do? We increase the counter and we will try. And we continue this way until we find a counter that makes this uh inequality hold. Now, this is an operation that takes a lot of effort. Like it’s very inefficient. It depends, of course, on how you choose this tea. Like if this is, I don’t know, I imagine that this hash function outputs uh 256 bit uh in integer, yeah. So if T is set to 2 to 256. You’re done with one try. If this tea is instead one. It’s unlikely that he will ever succeed. So, essentially this T tells you how hard the the problem is. The larger it is. Like the easier the problem, the smaller the harder the problem. OK. So, the new blog, the new page. will be made of this counter you have found X and S. X, sorry. Yes, so the counter here, here is the number that

SPEAKER 4
you, it’s the last number that satisfied this inequality, right?

SPEAKER 0
The first number that satisfies, yeah, like you start from 1, most likely 1 does not satisfy that inequality, then you try with 2, then with 3, and so on. The first one you, uh, get. You’re done. You have created a new page. Like it’s a hard problem, meaning that It’s essentially a race like. If Imagine like the chain is at a certain state, like uh all of you want to add a new page, like you need to rush, like to find the counter before everybody else. And even like, I don’t know, I think that currently in Bitcoin, it takes 10 minutes to add a new block. So, it means that if you consider all the computational power around the world and all the people that are trying to mine, finding the content to satisfy this. Uh, it’s so hard that like there is on average one computer in 10 every 10 minutes that finds it. Yeah, do people just start the counter at random, a

SPEAKER 3
random number? No, it starts at 1.

SPEAKER 0
So everybody starts at 1. Yeah, everybody starts at 1, but like potentially you have different like, uh, input. If you have different transactions, the hash is. It’s different. It could be also that you are working on the same page like, uh, hm, because you’ve, you’ve created the

SPEAKER 3
list of transactions you want to put in the block, so your transaction, yeah, actually like this x will contain

SPEAKER 0
like, uh, information about you, the minor, so essentially different minor, different x.

SPEAKER 3
And then it fascinated with it in some way with the counter and that then then it’s OK to have

SPEAKER 0
the same counter. It’s not that you are like uh using work yeah. Yes. Uh, yeah.

SPEAKER 6
So this is Yes.

SPEAKER 0
It’s the same thing. A block equal page doesn’t matter. Like it’s just a name.

SPEAKER 6
Yeah, so because like each block multiple transactions, yeah, the

SPEAKER 0
transactions will be inside this X prime.

SPEAKER 6
I see. So we’re trying to add transaction X to.

SPEAKER 0
No, we have the chain. Like view it. Each block is a page. So if this is a book, the chain is a book. A block is a chain. A block is a page. Yeah So, to create a new page. Like you do this.

SPEAKER 3
the hash is of all the three things in the previous block this, uh, which hash?

SPEAKER 0
There are multiple hashes here. The pointer I’m gonna explain in a second. This pointer actually will be whatever you found here in the previous block. So, it’s kind of a hash of the concept but a bit of a particular hash. So, Is it clear to everybody what I just said? Like, is it fixed or we will see. It will change depending on the number of parties in the system.

SPEAKER 5
OK, the number of pages are added to a chain. Oh, so then does that mean that the target like 2 days to, like whatever, does it like increase or decrease or sorry, like, can you repeat?

SPEAKER 0
Uh, like, so, uh, like once, like, let’s say like

SPEAKER 5
uh Bitcoin during like the initial days like way less people used to like mine it and right now it’s like gaining popularity. Yeah, so suppose like more number of people if the

SPEAKER 0
more people join this target will become smaller so that the like the problem becomes harder. Because you have more power, like uh more computational power, but uh we will see it towards the end of the lecture, OK? Yes. It’s like a proof of what. This is the proof of work function. Yes. Uh, my question is, well this, this happens when you

SPEAKER 4
want to create a new page, right? Yeah, not a new transaction inside the page.

SPEAKER 0
Yeah, like, usually you create a block containing many transactions,

SPEAKER 4
and you can add a transaction to the block.

SPEAKER 0
Yeah, yeah, you can also have a block with just one transaction, but it’s a bit inefficient. So usually what happens is that if you want, like if you want to make a transaction, you broadcast it in the system. And then somebody else will mine the block that contains your transaction. So you don’t find what’s the last block?

SPEAKER 4
Does it have enough space for my transaction.

SPEAKER 0
No, it’s not like that. Like, uh, what you do, so it depends if you are a minor or if you are a user. Like if you are a user, you just put like the throw like the transaction in the system and then somebody will mine a block that contains your transaction together with other people’s transactions, OK? Uh, like, yeah, that is, then if you want, you can also try to mind the block yourself like with your transaction, but you are very unlikely to succeed. Yeah Yeah, so, um, as you mentioned, like you can

SPEAKER 1
also put only one single transaction in the block. You can only what you can put one single transaction. Yeah, it’s not efficient, but from the miner’s perspective, it doesn’t matter to him if he puts one or all, right, because you will get the money anyways.

SPEAKER 0
Yeah, it depends a bit like how you design the system like, uh, maybe like, uh, you get a lot of like uh you get like uh money depending on the numbers. Like there are two types of uh ways you can get a reward like when you mine. One is a reward for having created a block. The second one is like, uh, the fees for like, uh. It’s proportional to the number of transactions. Yes, I was just wondering, so you make a transaction,

SPEAKER 7
you broadcast it to the system, yeah, and then can multiple different minors include that. And then is there. Like, is there a chance that no miners put it in their block and then you’re just waiting for this transaction?

SPEAKER 0
You assume that there are always like uh honest participants, so those honest participants will add it like to the block. Yes, uh, on that, like if you have too many

SPEAKER 2
transactions that need to be put in blocks, it still means you take, like you have no guarantee that your transaction ever will get included if there are enough other transactions to choose from.

SPEAKER 0
Like you never have that problem. Like you can put like actually all the transactions that have been added to Bitcoin, they could really stay just in one like uh block. Like there is infinite spaces just because you don’t put. Like the whole like set of transactions you put in, you use a hash like uh.

SPEAKER 5
Yeah, like how would we decide that like for this block these many transactions are like enough and up to

SPEAKER 0
you. Like, uh, there is no depends on the minor. It depends on the minor, but there are economical incentives for you to add as as much transactions as you have like what, yeah. This is something very similar. Like, yes, this is what the Naka Nakamoto did in the Bitcoin paper but like it can be applied for many other distributed letters. I’m not talking about one specifically, OK? This is the general functioning of this sort of blocks. OK. Now, I repeat maybe about this um um pointer. What is this pointer? Like, what is the This points to the previous page. But how do we derive that as that will be this value. For the previous page, so if now somebody wants to point. To the new page we added, they will add as as what we have just computed. Does it make sense? OK I guess we can take the break, so. Like in 10 minutes we come again and we discuss like uh how to Validate and um Deal with inconsistencies when multiple people propose like simultaneously uh different pages. That. Let’s start again, uh. Let me see. Yeah, during the break, I had some, uh, I received some interesting questions. The first of the first one is, how do you, like, set the first block? Like, uh, And yeah, um, the main problem is this pointer like that block points to nothing, like, uh. What happens, like with Bitcoin is they said, OK, we will start mining from tomorrow. And the S we will choose for the first block will be derived from the headline of the times of that particular day. OK. And from there, like, essentially the competition started. Like once the headline of the Times was out, people started looking for counters to add the, the first block and then it like uh continue as a cascade since then. OK. All right. Now, imagine we have created this new uh page in our letter, what do we do? We broadcast it. We send it to everybody. Look, we added a new page. Actually, we do not only send the page, we send the whole book with it. OK. And now let’s take the perspective of somebody that receives this book from somebody else. How do we verify that this book is a valid book? We need to check that. Yeah, what we need to do is to just check this uh chain of hashes. Right? Like you will take a block. You, you start from the new space. You hash this You get your aid Then you put the counter and 8 into the other hash function 8. And you check whether it’s less, smaller than the threshold, OK? Then you repeat, you take the 2nd block, the 2nd newest page. You check that And The S in the latest page matches with like. The hash of the 2nd as speed. And you repeat like uh each check whether the uh hash of the counter of the second page concatenated with the corresponding eight is smaller than the threshold. You check whether that matches with the of the uh last page and you repeat again.

SPEAKER 2
Is the uh if the target is dynamic, how do we check that because it could be that we at some point had a target that was for the moment

SPEAKER 0
assume that the target is fixed like it will change, yes, but like, uh, over the long run, OK, and I will explain later how this my second question is

SPEAKER 2
if you join the network. And you have not had a book. You need to get a book somewhere. How do you know that you get a good book? Like, yeah, that is another issue, correct?

SPEAKER 0
Like, uh, you need to ask some people around and get, uh, their books and you hope that you have gotten somebody that is honest. OK. But essentially to validate a chain, you need to continue this validation proper pro uh this validation uh chain. Till you reach like the uh first block and you need to check that the S of that block is exactly the one from the Times uh the headline of the Times of 2008 or 2009 I don’t remember yeah

SPEAKER 4
why do we need to get back instead of just validating the last uh added one because like you don’t

SPEAKER 0
know like uh if you just validate. The last one, I see what you’re saying. You’re assuming that all the previous blocks are already something that you have, right? Not necessarily, not necessarily. It could be that like you are in a bad position of the network and you never received like, uh, the last 100 blocks or something like this. Like, so you need to revalidate the chain. Like you need to always do like doubt your reality. Maybe the chain you have is not like the updated version or maybe it’s not the real one, yeah. OK, now, we have received this chain, we have validated it, like we check these hashes. And what do we do with it? Like, uh, do we adopt it as our new chain or do we discard it? It depends like. We check whether this change we have received is longer than the one we have. If that is the case, we adopt it. Why do we do that? Essentially because to adopt, we want to adopt the chain that had the most work in it. Because remember, the adversity has limited computational resources and to generate the chain, you need a lot of work. So If a chain had a lot of work, most likely that had a, a greater contribution of the honest parties. Yeah, uh, if we adopt it, do we just basically

SPEAKER 2
adopt at the moment it’s longer even though it is different from our chain?

SPEAKER 0
chain as soon as I have a chain that is longer, I discard check what’s in the, in your chain

SPEAKER 2
and what’s in the other chain. You just immediately go, yeah, you switch, yeah, as long

SPEAKER 0
as the new chain is one that validates. Like it could be that it’s inconsistent with my previous one, doesn’t matter. As long as it’s a chain that validates and it’s longer than my previous one, I adopt that. And then you reiterate, you want to mine a new page, again, start mining. Like you take your latest page and uh like uh you take the new content, you hash, and then you look for the content that satisfies the inequality. And if you manage to do that, you broadcast like the whole chain to everybody. And if you don’t, and instead you receive somebody else’s chain, you check whether it’s longer than the one you already have. If that’s the case, you adopt that. Questions I guess this is maybe the most important thing of the course. So, uh, if there are people that have, uh, questions or doubts, like, uh, it’s a good moment to, to ask. Yeah.

SPEAKER 5
So you basically mentioned that, uh, like once a miner mines a page, they see which one is like the longest chain, uh, and then they adopt that chain. What happens to like the, the, the, the rewards or like the fees they’re supposed to receive for mining that.

SPEAKER 0
I mean, like, uh, if somebody mines, like there are some, I mean, this depends a lot on the system. Like in Bitcoin, it works in a particular way. In like Ethereum, it works in another way. Like, uh, it’s up to you to design that system in Bitcoin. What happens is that when you mine a block, you take the transaction fees like plus a reward for having mined a block, and that gets onto your account, on your Bitcoin account. And like what happens if someone else adds a few

SPEAKER 5
more blocks to that chain before you could like, oh

SPEAKER 0
yeah, you don’t get them, yeah, yeah, yeah, so you don’t get the fees, yeah, yeah, yeah, that is why sometimes, yeah. It’s annoying. Indeed like that can, like, that is the issue. You cannot assume that a transaction is validated until some other sufficiently many blocks are added. Because it can always be that you added a new page, a new block, but then somebody else takes over with some other new blocks like and that becomes the longer chain. So if you essentially, I don’t know. If you pay with Bitcoin for a coffee, it’s OK to like er Like to receive the coffee like immediately after the block is on the chain because you don’t lose, you lose 1 pound, 2 pounds, maybe I’m Italian, so €1.02 euros, but yeah, um, if instead you buy a car, like maybe you need to like uh. Like 10-20 blocks till you can uh give the keys of the car to like whoever bought it like uh yeah but that also does mean technically if you have

SPEAKER 2
a certain number of res like obviously you need to come up with your consensus to figure out what the block is but if you have a bad network connection it might be that you actually mined the whole block but everybody else did not receive it. Yeah, yeah, yeah, and then like, yeah, you did a

SPEAKER 0
lot of work for nothing, yeah. Yeah, I know, like it’s uh uh it’s ruthless, but like.

SPEAKER 5
Yeah, so when does the miner get the fees? Is it like immediately after the block is mined or like after the, the, so like, good question.

SPEAKER 0
Like it depends. Each fork of the chain has a different reality because the chain that adopts the block you mind will see that on your account you have that money. But like in the other fork like that never happened. Right? Like that transaction with the reward is the one you mine, right?

SPEAKER 3
So, so, so you can’t trust what’s in your wallet and sell your multiple blocks.

SPEAKER 0
Yeah, you need to wait like that sufficiently many new blocks are added to the chain. At that point you can be sufficiently sure that everybody is on the same page and like, uh, everybody agrees on those. Yeah. Is there like a minimum number of blocks that you

SPEAKER 2
have to wait or technically you would have to wait forever to know that your chain is actually longer.

SPEAKER 0
I mean, if you want 100% probability, yes, you would like, uh, then it’s a statistical argument as you say, OK, like with uh this number of blocks, like I’m relatively sure like with probabilities that are huge, like, uh, I don’t know, like greater than the probability of like a meteorite hitting Earth today, like, uh, then you’re sure that like. You can trust that that transaction is validated, right? But this is exactly what we are gonna discuss now, so. I’m going back to the slides. Yeah OK, this is all pseudo code of what we just said. Um, yeah. There are these 3 basic qualities of the construction I just described that we need to discuss. The first one is called common prefix, uh, the second one is in quality, and, uh, finally, it’s in growth. OK, common prefix. Essentially it says that. If you take any two honest participants. And two different uh intervals of times, R1 and R2, assuming R1 smaller than R2. Then Essentially, um, the chain of, um. P1, like uh the first party will be contained in the chain of the second party except potentially for the last k blocks. So you see this weird notation with this, I don’t know how to call it, like ceiling, I don’t know, K, that means like you drop the last k blocks. So, essentially this property is saying we agree on the history. It could be that we do not agree on the last key blocks, but all the previous ones, yes. Even in the long term, like this R2 could be in the far future. OK. How big is K? As I said, it depends. It’s uh up to you, like, uh, to, how to choose it depending on the context. If it is for a coffee, like uh K can be smaller. If it is for a car, maybe like uh take it longer. Uh, but yeah, the probability that this property does not hold, that we do not agree on the history like uh. Decays exponentially in this case. So pick a sufficiently large scale, then the probability becomes so small that it’s more likely that meteorite hits the Earth today.

SPEAKER 2
Yeah, on the actual formula we quantify over R1 and R2 and we never use it and the case R1

SPEAKER 0
and R2 means the times at which those chains are taken. R1 means that C1 is the chain of party P1 at time R1. C2 is the chain of party P2 at time R2. OK. Now Imagine that you are attackers. How would you try to uh attack this property? What you would do is you start You take an old block and you start mining new blocks trying to take over the main chain, the one of the honestest parties. Once you have more blogs than that, you can broadcast it and all honest parties will switch to your reality. OK. But why is this unlikely? Well, because the corrupted parties have less computational power than the honest parties. So, essentially, the honest parties will convert onto a chain and that chain will progress faster than any other alternative chain the uh adversary is trying to mine. It could be that the adversary is able to mine one or two blocks. That is why we need to wait for sufficiently many blocks to be validated until, uh, sorry, sufficiently many blocks to be added till we are sure the transaction is validated. But like you cannot mine a long alternative chain. Yeah, that’s why the system is so dependent on.

SPEAKER 6
Yeah. can like generate enough. Chains that like overtake the amount of work done by the honest chain that theirs become the standard.

SPEAKER 0
Yeah, exactly. So that is why I mean that proof of work is a hard function because if it was easy. Me as an attacker, I can go back to the headline of the Times in 2009 and start like mining a new chain that like in which all the money comes to me. Like, uh, if it is easy, maybe at some point I will manage to like overtake one of the honest parties, right? So that is why it’s important to pick that threshold T sufficiently low. Too low And it, the chain becomes extremely slow like a transactions are very rare, like new transactions are rarely added. Too high, the system becomes insecure. So it’s a bit of fine tuning. Yeah.

SPEAKER 2
Could you like technically combine the racing attacks with like some form of network to ensure that you’re if you have a lot of computational power but not as much as the honest party, you could just split the network in a way that the honest parties can’t work together on the yeah yeah and then overtake them.

SPEAKER 0
Yeah, that is the main issue like uh if. Like mining the chains is easy for everybody. You can exploit the network and making sure that your chain, like, uh, is the one that is adopted. I don’t know. You just isolate on these parties or, uh, you pick yourself in a particularly good location of the network that easily reaches everybody, like, uh, yeah, so you want to prevent that, yeah. Yeah, is it an assumption that most parties competition? Yeah, it’s an assumption, you cannot be sure like, uh, but you need to trust something like, uh, if you don’t start with some assumption, you cannot achieve anything. Like you run immediately into an impossibility. You wouldn’t be able to design these protocols now the

SPEAKER 4
highest competition. Falls down right if the adversary has like more than

SPEAKER 0
like more computational power than all honest parties uh together then yeah it fails like uh all these blockchains wouldn’t be secure. Other questions? Yeah What prevents the minor from adding uh wrong transactions? I mean, yes, you would need also to check like, uh, yeah, I agree, depends a bit on the system like uh you should, when you validate the chain, you should also check the transactions are valid like uh yeah like uh sure like uh I’m sorry for not saying it earlier, yeah. So you don’t accept chains where there are transactions that are not valid. You would need also to, to check those. Yeah Um, if the threshold was really high and it

SPEAKER 7
was really easy to make these chains, um, and then, uh, this woman’s party makes this super long chain that comes on, could they effectively in that sense rewrite the

SPEAKER 2
whole history of correct.

SPEAKER 0
Yeah, it would be terrible. I agree, but like, uh, we peak this, the threshold is sufficiently high. So the system becomes very inefficient, like, uh, indeed Bitcoin like has the energy consumption of a small country, uh, but like if you don’t do that, like the whole system would be insecure. Like uh you could rewrite history of all like, uh, transactions. OK. Second property chain growth. This essentially says that for. Like every honest party eventually will add a new block on their, uh, chain. Uh, in particular there is this parameter tau, and it says that, uh, any period, uh, period ofs rounds, meaning, uh, as like a mining, uh, attempts, like, uh, there is at least a tau times s blocks that are added on the chain of an honest party, OK. Now, once again, imagine that you are the adversary. How would you try to like uh Attack this property. Attack the chain so that this property does not hold. An idea You would just stop mining, right? You cannot prevent the honest party to from mining, but you can stop, like, of course, that means that you produce less, less blocks. But yeah. An honest party eventually will add more because there are also honest parties mining and you cannot prevent them from doing so. Questions So, so, so you’re slowing the growth of the

SPEAKER 3
chain because you’re not mining.

SPEAKER 0
If I am, yeah, if I am an adversary, I can slow the growth of the chain. I can try to Uh, prevent the honest parties from adding new, um, uh, blocks in this way, but you cannot really stop them completely because there are of course other honest parties that will try to like, uh, mine new blocks, and those will be added to your chain eventually.

SPEAKER 3
The benefit of me for me as a bad, bad actor there is what growing a different chain, or yeah,

SPEAKER 0
potentially yes, or maybe you just want to censor like, uh, yeah.

SPEAKER 2
Yeah, uh, like a question, the underlying assumption is always that everything like a malicious party or or any conglomerate of malicious parties does is inside the network inside the Bitcoin or inside the blockchain system, not, not they don’t worry. Outside this, what do you mean? Because like you could also like you can force them to stop producing blogs but just attacking the energy grid system and like cut off that energy or you can, sure, so you guys get inside the system you don’t go around or like actively like the participants individually, yeah,

SPEAKER 0
sure, sure. Yeah, yeah, yeah, yeah, uh, yeah, you assume that the, OK, yeah, sure, you could also just like actively like

SPEAKER 2
cyber attack the actual like hardware systems, but no, we’re on like, yeah, we assume that like you cannot touch

SPEAKER 0
the other people’s machines, yeah.

SPEAKER 6
And essentially the attackers.

SPEAKER 0
Stopping, yeah, yeah, that slows the, yeah, it’s not actively doing anything to prevent, it’s just stopping and that like means that fewer blocks are added to the chain of the honest parties, but eventually they will add some, yeah.

SPEAKER 6
Yeah, but when we say like producing blocks, you mean like acting as a minor. It’s not a question of like just being a user and maybe like not getting an updated change.

SPEAKER 0
Yeah, yeah, yeah, acting as a minor, yeah. OK. Last, uh, property, chain quality. Essentially, it says that if we take a sufficiently large segment of blocks. A good fraction of these are generated by honest parties. And yeah, this is strictly stronger than uh uh chain growth because it’s true, OK, eventually like uh chain growth says eventually an honest party will add uh some new block in the chain, but what if all these blocks are adversarially generated. That would be bad. You would have censorship, right? Like if all the blocks are generated by the adversary, like maybe my transaction as an honest party will never be added. Here instead with same growth, uh, with same quality you have the assurance that yes the chain will continue growing and for its sufficiently large segment of blocks there are some that are generated by honest parties so. My transaction as an honest party will be added to the block of this uh uh generated by this honest miners. Yep.

SPEAKER 2
Question on the notation here, like technically at the moment it’s like the set 0 and 1, so the, the ratio of blocks to whatever is either, yeah, it should

SPEAKER 0
be, it should not be that like the slides are not mine like it should be it should be interval, yeah.

SPEAKER 3
Um Yeah. But if, if an honest. Uh, party creates a block on a chain which has blocks created by dishonest parties, yeah, and that’s the longest block. Yeah, the longest thing that chain that’ll be adopted by everyone, and those in dishonest blocks will be locked into the chain.

SPEAKER 0
Yeah, yeah, the in the chain, are you confused by the fact that there are adversarially generated blocks on the chain? Yeah, there’s nothing you can do like maybe the adversary is behaving honestly, like, uh, yeah. Right? Like, uh. It could be also that it’s behaving in a dishonest way, but like, still like you check that the transaction they are like are valid, like a Like you don’t uh so earlier maybe I forgot to say it, like try to remember when you check the chains you also need to check the transactions are all valid like uh or I don’t know there is some protocol running over the chains so you need to make sure that the content is a valid content, OK. Like you don’t adopt chains that have invalid content, yeah, so when you accept a new block, you said you

SPEAKER 3
go back and check all the blocks all the way

SPEAKER 0
back. Yeah, yeah, you need to go all the way back to like the, the Genesis, yeah. But what about the track you go every single transaction

SPEAKER 3
within those blocks.

SPEAKER 0
Yeah, you would need to do that. Like then usually you can, you don’t need to go too far back, right? Like you can just check, OK, like this part is, uh, the same. Like, uh, I just need to check the last two, like, uh, or the last 3 transactions, like, uh, you don’t have to do a lot of work. Like you can just check a hash, for instance, so. OK. OK. um Now, this formula you see here tells you like what um fraction of uh honestly generated blocks you can expect uh given a threshold of corrupted participants. And a total number of parties that is. And I will explain in a bit how you can derive that, OK? First, we will need to understand how to attack this uh property. How can an adversary Maximize the number of corrupted of Maliciously generated like blocks in the chain. What you would do is the following. You mine a block, you try at least. Once you have it, you don’t broadcast it immediately. You wait for the honest party to continue like to, to do their work and when you see that an honest party is like about to send the like a new block. You use, I don’t know, your privileged position in the network to broadcast that block. In that way you may be able to censor that anonymously generated block. Does it make sense? Of course, here for this attack, I’m assuming that adversary has some sort of control of the network. Maybe it has some node that is close to you and it can check whether you are about to send out uh to broadcast a uh a new block or not. When that happens, I am in a privileged position. I can reach everybody else first with my blog, yeah.

SPEAKER 6
You don’t know, but yeah, because it arrives earlier.

SPEAKER 0
Like there are two chains, like, uh, same length, but I have a better position in the network. I’m able to spread mine, uh, more easily. So everybody looks, uh, at this chain. I say, oh, it’s longer than the previous one. I adopt this. And then I arrive the chain of the honest party, but this is not longer than the one they already have, so it’s dropped, OK.

SPEAKER 6
of the Yeah, yeah, you need to assume that the

SPEAKER 0
adversity, so you don’t want the adversary to use their position in the network to, to attack the system like, uh, also because it’s so hard to understand like, uh, how a network is designed, who has control of what, like, uh, you want to design a system that withstands like, uh, network attacks yeah. Yeah, it gains the fact that the honest parties will waste resources mining something that will not go on the chain. And I will explain how that formula comes. Um Let me turn off once again. So, suppose that everybody in the system has the same uh Hash power so they Suppose that you run. I don’t know, like this, uh, blockchain protocol for some interval of time, let’s call it, uh, oh, as. OK. There are parties in the system. Like, how many blocks do you expect to have in this time? It’s gonna be. And times like some uh I don’t know, some constant that is derived by the uh power like uh n times S, right? So Constant. Um, depending. Oh, well. On, uh I don’t think you can see this stuff. brand On Ash power. Now, suppose that we have uh 2 corrupted parties. We can assume that in this interval of time, the corrupted parties will be able to mine. T 10K 10S new blocks. These are not necessarily blocks that end up on the chain. These are new blocks, OK? It could be that they go on a fork, OK? Mind By. But now imagine that our adversary does the attack I just described, so it uses the privileged position in the network to, I don’t know, uh, broadcast the blocks, uh, first so that like they reach everybody before like they honestly generated blocks, right? At the end of this interval of time, how many of the total number of blocks will be generated by the honest parties? This is the the number of blocks that are mined that do not necessarily go on the Seine, on the main Seine. It could, they could go on a fork. For every block the adversary generates. One of the honest participles of chain, right? Does it make sense? We have our chain And then, the honest party mines this, so it puts work in this. This is one of these blocks. But adversary managed to like generate another block and send it to everybody first, so the chain will go this way and not here. OK? So, we wasted a block for its adversary block. So, at the end, the main chain will have um NKS. Minus TKS blocks. So this is The total number of blocks. On the main chain. The longest one. But how many of these blocks are generated by the adversary? Well, TKS. They all go on the main So, what is the fraction of number of er So, number of honest blocks. On the main chain. Divided by number of blocks. On maintain. So this is what in the slide was called mu or like it was maybe 1 minus mu, I don’t remember. This is gonna be And We said this is the total number of blocks, so this is gonna be uh below, so it’s gonna be N minus TKS. And above, we have And minus 2 ts. Which is just like the difference between this and the number of er Blogs generated by that person. So, KS here disappears, we have M minus 2 T divided by M minus T. Yes, this is the worst scenario for the honest, yeah, yeah, but in cryptography, which is kind of what we are doing, you’re always a bit paranoid and you always assume like, uh, the worst case you want to have security against the worst kind of adversary. Questions OK. I have 10 minutes, so probably I need to go a little bit faster. Yeah. So, essentially, these three properties are the ones that give you um consistency and liveness. Consistency comes from this common prefix uh property, meaning we agree on the history. So, like, uh, as long as we like drop the first, the, the last K blocks, the rest is uh uh agreed by everybody. The other two properties, same growth and same quality, uh, ensure liveness. If you are an honest party. Your transaction will be added to the chain of all honest parties eventually. Why? Because the, uh, chain that the honest parties have locally will keep growing and a sufficiently large fraction of blocks will be generated by other honest parties. So you broadcast your transaction, it will be picked up by an honest miner, and that honest miner eventually will add it to, uh, the chain. OK, um, I mean this is like, I will skip like it’s nothing, uh, particular. Here instead it’s more practical, uh, parameter like uh. The power of a regular PC is around 30 millions a second. And the, the current difficulty is, uh, the one you see there. And then Yeah, it would end up, like if you try to mine a new block on your computer, it would take that amount of time. So, don’t try. OK? So how do we mine new blocks? We do it all together. Everybody will try like all around the world to mine a new block and once every 10 minutes or so, a new block is added, OK? Usually, people organize in what are called pools, essentially. Like, uh, they share the work. They say, you take care of this, uh, batch of canes, I take care of these batch of canter, and when one of us like finds one, like, uh, we will get like uh like uh the reward, and then we will share it among us. And so, the picture that happens in practice is the following. There are these big uh mining pools that Mine the vast majority of like uh all uh blocks on Bitcoin. So it’s ample, what is it, is like uh more than one quarter of all blocks like uh yeah. Essentially these are just groups of uh miners that like Share like uh the work. And yeah, most likely all of these people have very advanced hardware to do all the hashing. It’s not computers like the one you see here. Like those are very unlikely to like mine any block. Actually you would lose money because uh they would be like essentially the probability that you get like the uh the reward. It’s not even worth the electricity that you use to run the hash function, OK? Um, yeah, uh, now, finally, we can talk about, uh, how to set this uh difficulty parameter T. Because, yeah, if there are more parties joining the system, we have more hush power and so uh it would become more likely for the adversary to use like uh network attacks to like uh like undermine consistency of the chain. So, essentially we need to change the parameter T depending on how many parties are in the system or also the state of technology, like meaning the total hash power in the system. OK. And yeah, in the history of Bitcoin, this changed dramatically. You can see here like uh the change since the beginning to today, or at least, I don’t know the picture. It’s 2022, but still. And on the right you see. I’m sorry, on the left, you see that the selection of the difficulty parameter grows proportionally. OK, um, This raises immediately a question like what happens if um Like we, we need to change essentially the longest chain rule, the one that says if you get multiple chains, you take the longest one. Why? Because maybe the adversary can craft like a chain that has the difficulty parameter that is very low, right? And it can make a very long one. Like and it could overtake the honestly generated one. So the new criteria on which that we use to select the chain is we pick the one that contains more work. The hardest one to generate. And yeah, we can measure the hardness of uh the chain by computing this sum. This is the sum uh where I spans, uh, it’s the index of all the blocks of one over the hardness parameter used to mine that particular block. Remember, like if T is very high. Then, um. Like it’s easy to mine a block if T is small instead, like, uh, the hardness increases. So, you have to change, you compute. This sum for each of them and you pick the one that has the higher value. OK. Um Yeah, essentially, this is how Bitcoin, uh, adjust the, uh, hardness, uh, parameter. Essentially, it estimates the number of er parties in the system. How does it do that? It checks um like. How many blocks have been added to the chain in the last, I don’t know. In the last interval of time. And depending on how hard the parameter, the harness parameter is, like you can estimate how many miners have like tried to mine blocks. Right? And then you change the threshold accordingly. In a somewhat of a linear manner, meaning that if there is double of the hash power. You will have the hardness parameter because if there is more hash power, you need to lower the hardness target. Right? Smaller target. more hard. Does it make sense? Like, uh, I see some puzzled faces. Yeah So the formula is a bit weird, like, uh, you see, essentially the part at the bottom is what I just described like T0 and N 0 are and 0 essentially is uh um. Uh, an estimate of the hash power at the beginning of the Bitcoin protocol, um. T0 was the original threshold, the, the original harness parameter, and N is an estimate of the current one. Yes, so is it how adversaries can actually slow down

SPEAKER 8
the proof of work done by honest miners? So basically if a lot of adversaries join as a miners and then it will not work, it means that the target will, yeah, will decrease.

SPEAKER 0
Yeah, yeah, that is a potential way you can attack. It does not give much like, uh, but like, uh, you can still try to do that like. Like, why are there the first two lines? The first two lines essentially says that if there are spikes of like a big increase of computational power or a big decrease. Then we don’t set the new um. Uh, computational parameter, uh, linearly. We just like divided it or multiplied by this parameter tau that in Bitcoin is just 4. It’s just a little bit to smooth out like the And that is actually important. Like, uh, I don’t, I will just catch because I’m running out of time. Um, the idea is the following that, um, An adversary Um, could try to do the following. It starts from the Genesis block. And it tries to increase the hardness parameter by generating some fake like uh um some mining some blocks with like fake uh time stamps so that it seems like there is a lot of computational power in the system that would lower the harness parameter, making it extremely hard to mine new blocks. And this would Um Like, um, Favored adversary. Because Like there is a very little chance of mining another block, but if you manage to do that, you have a big reward. Like you have a huge 1 overt parameter. So with just that one block, you will be able to overtake the other chain, the one of the honest parties. Yeah, that would be modifying the, I guess like the

SPEAKER 6
time stamps, yeah, yeah, yeah, you can set them arbitrarily.

SPEAKER 0
I can, can start from the Genesis and I can like mine a few blocks and I put fake time stamps like that it looks like they are all like there are a lot of blocks in a small interval of time, right.

SPEAKER 6
To create those walls. And it actually It looks like there is more power

SPEAKER 0
in the system like, uh, because a lot of blocks were mined in a small interval of time it means that they put a lot of computational power in that small, yeah, that would, uh, tar like the target would be recalculated it becomes very small so the proof of work becomes very hard. And at that point adversity can try to like uh mine a new block. It’s unlikely that it manages, but if it manages. Like then you have a huge reward, and it could be that already with that block. Your chain becomes the hardest one that was ever mined. And so everybody will adopt that. That is why there is this parameter tau that makes sure that if there are sudden spikes of computational power, we don’t immediately change the uh threshold. Uh accordingly, you kind of slow down the change. And we run out of time, so I’m sorry. Uh, I’m here for a question. Maybe I stop just outside if anybody wants to ask.

Lecture 4:

SPEAKER 0
All right. Hello, everyone. Um, let’s begin. So, last time, we talked about Ethereum and Smart Contracts, which are programs that are run on the blockchain. Let’s do a quick recap of that. Um, a developer can write the code for a smart contract, and then deployed on the blockchain, and then it leaves on the ledger, it leaves on the blockchain. And then, there are users that can interact with the contract via transactions. Uh, so a user can create a transaction that interacts with the contract and then when this transaction is processed by the maintainers of the blockchain. They’re minors or blog proposers, however you want to call them. Um, when they try to include in a block, the code of this contract is going to run. And remember that once the, the code is public, once it’s out there, uh, once it’s deployed, it’s public and anyone can interact with it. No, I said anyone can interact with it and this includes potentially malicious individuals who may attempt to exploit the functionality of the contract in some way. So, in this lecture, we’re going to talk about Exactly this, where an attacker is trying to exploit the functionality of a smart contract in one way or another. So, first of all, we’re going to learn how to identify such hazards in contract that can be written by others, for example, that you have to review. Uh, and then, we’re going to go over how to Uh, defend against, uh, such hazards when writing your own contracts, how to protect your users. So we will cover things like uh denial of service attacks or re-entrance attacks from running. You will soon know what this means and go over some good design practices for writing smart contracts. And we’re going to also look at some solidity-specific hazards. So how to interact or rather, not to interact with some features of Ethereum smart contract language to avoid potential vulnerabilities. Uh, then, we’re going to look at some challenges in the generation of random numbers for the blockchain. And last, we’ll briefly go over uh the concept of gas fairness. So, let’s start with the first type of attacks, which are denial of service attacks. And you might already be familiar with this type of attack where the idea is that the attacker wants to prevent other users from using a certain service. So let’s see how this can manifest in the blockchain setting. Uh, here, we have a piece of solidity code, which is quite straightforward. It’s just um an array. So there’s this array called investors. Uh, and there’s a loop that iterates over this array of addresses. And for every address in the array, it makes a transfer that represents the investor dividends. So what can go wrong here? Uh, let’s look at that first line of code. Uh, where there is some array, but we don’t know what is the length of this array. And remember that that the time is going to take for this loop to complete is um obviously like linear to the size of this array. And, and then There is also the The gas that we’ve discussed. So, the more time it takes, the more gas this uh transaction is going to consume. And there is also a gas limit that can be reached. So, if at some point, this array becomes too large, then it won’t even be possible to run it because it, it will, it will exceed. The, the gas limit of the block in order to run it. Let’s say, you know, there are at 1st 100 investors and it’s fine, but if that becomes 100,000 or like something large, uh, then it might not even be possible to run these lines of code. Uh, so, what an adversary could do is just uh fill this array with entries. They can be fake entries like creating these fake identities for investors. Uh, and this way, the, the array gets large, uh, and it’s impossible to complete this operation to even send the, the transactions to the honest users. Uh, and then a similar concept is that of griefing. So, let’s see what else can happen here. For example, uh, let’s see the second, the second line, basically. Uh, what it does here is That it sends the some ether, let’s say that this could be, yeah, the dividends that correspond to these advances, it sends them. Um, directly to some address. But remember that. So, so here, basically it’s doing in, in one transaction, in one, in this one loop. It’s going to call many times this send function that attempts to send some ether to an address. So let’s say we have 10 investors there and so it goes loop and for the 1st 9 of them, it, it, it’s successful, so the, the Ether is transferred successfully. But then, if the 10th 1 fails, for whatever reason, then all of the previous ones will fail too, because they’re part of the same transaction. So, they’re all going to revert. It’s like the the state of one send depends one transfer, depends on the state of the others. Uh, so, gas is still consumed, but that’s the only thing that happens if, if one of these transactions fail, if one of these transfers, uh, fails. The, the rest of the state is going to revert. Uh, so, for example, The the point here, I want to make with griefing, um, which in general, griefing is a type of attack that doesn’t necessarily benefit the attacker, but makes using the system more difficult for other users, for some victim. Uh, so here, what the adversary can do is make this transfer fail. So they could register as an investor here and provide an address that it doesn’t necessarily have to be from a personal account. It can be uh the address of some other contract that the adversary has written. So if this function then calls um tries to send ether to a contract address. It’s going to trigger its fallback function, which can have some logic, which could, for example, consume a lot of gas and make this fail. Uh, therefore, the, an attacker here can make the transfers of other individuals fail by making their own transfer fail. Uh, so, uh, in, in short, uh, we, we saw that if one sign of, if one transfer, uh, fails, the whole contract or the whole electron, uh, the whole contract can get stuck in this case cause that was the functionality that the contract was offering and it, it was no longer able to offer that functionality. And it is possible to force this kind of call to fail, for example, by setting. Um, by calling the function of another contract. By forcing the ether to be sent to another contract rather than a personal account which can then have whatever logic to handle that. Uh, so, uh, I also a reminder, a general reminder here that errors need to be handled. So this would not solve all of our problems, but it would still be useful to have some error handling here to know what happens if this fails. Uh, OK. So, what is, how can we avoid, uh, these hazards? What is a good pattern to use? Uh, one design pattern that we’ll talk about is what we call pull over. Push. But before I explain the pattern itself. I, I will, I will show an example of the anti-pattern of what we’re not supposed to do. Ah So, here we have a code snippet that represents an auction. Uh, so there, there’s a function that someone can call to make a bid. And if that bid is higher than the previous highest bid, Then the contract uh refunds basically the previous uh highest bidder and then it sets the new highest bidder to be the current color of the transaction, the message center. Um, now, this. This sounds simple and we can see an example of that. Like if, you know, Alice sends um a bid of one ether and she’s the highest bidder there because there was no one else before. Uh, but then Bob might send 2 ether and that will cause. So when Bob sends the 2 ether, uh, this will make a transfer to Alice to refund here 1 ether and then make uh Bob the current highest bidder. So, what is the problem here? The problem is there specifically. Uh, so, we, we already talked about being able like having some uh malformed address or uh for making transfers, not necessarily malformed, but having it go to a contract which can call it fallback function, which they have some logic and do whatever kind of thing. Um, so, Uh, so for example, if, if the adversary makes some bid, uh, they can make it impossible for someone else to bid again. How? Uh, they can make this transfer call fail. Uh, so again, if we already told how, how it’s possible to, to make this fail, but let’s see what happens if that transfer fails. Uh, then, Alice is the highest bidder and let’s say she’s the adversary, so she bids one if in one ether. Uh, but then like her address there is something. Uh, it’s the contract address. And then when Bob tries to bid to ether, uh, the contract will try to transfer the one ether back to Alice, but this transfer will fail. So, the, the rest of the code will not be executed. The highest bidder will not change, and Alice will remain the highest bidder. No one else will be able to call the contract. Yes.

SPEAKER 1
Is that just because when the transfer goes. You know, Alice’s contract, it runs its own code that. Makes it.

SPEAKER 0
Exactly, yeah. So when the When the transfer happens, if that’s to a personal account, there’s nothing there. It’s just a simple value transfer. Uh, but if, if it’s, if it’s the address of the contract instead, then what happens during an ether transfer, uh, in general, if you transfer ether to a contract, not via calling a specific function, but just a transfer, then this calls the contract’s fallback function. Uh, which can be a received function, for example, as we saw last time. Uh, and that function can have some logic. It can have, let’s say just an infinite loop, which just runs until it, it gets like a, a, a gas, uh, until it runs out of gas, basically. Uh, so this would cause the transaction to fail and Bob wouldn’t become the highest bidder. Like Alice would stay the highest bidder here.

SPEAKER 1
What makes it What checks to make sure that.

SPEAKER 0
Uh, here, if, if the transfer fails, the, the whole transaction fails basically. Because this is also not handled. It’s part of what I said before. There could have been some code that says, you know, if the transfer goes through, do this or do that. This doesn’t do it. Um, but, but in general it’s a, it’s a transaction. So, and, and then, so if, yeah, if the transfer fails, the whole transaction reverts in this case. Uh, but we can fix this in a simple way by doing pull instead of push. So in this case by letting, yeah, yes, the way I described it, yes. So the, the first user because that’s when it, it tries to transfer back to the previous. OK, cool, um. Yes. So, to fix that, we can take another approach. That um lets uh users withdraw their funds on their own. So basically, this approach separates the transfer part from the logic of the contract, the logic of the auction. Uh, what we see happens here is that when someone makes a bid, Uh, there is a check that is made again to see like if it’s higher than the highest bid. And then it just changes the state of the contract. It just changes some variables. In this case, there is a variable called refunds and it adds to that. So the state of the contract changes, but there are no external functions to contracts that could Mess something up there. It’s very like deterministic what’s going to happen here. Uh, and then, uh, once. The refunds have been increased. Like once Alice gets a refund there, if Bob makes a higher bid, then uh Alice will be able to withdraw her refund from this separate function which does only this thing. So even if this fails, it’s only to Alice’s detriment. It it’s not going to harm anyone else in the system. Um, Right, yeah. So, so what this also achieves is that it isolates each external code into its own transaction. And we don’t bundle the codes together. Uh, or push the data to any address that hasn’t asked for it. So, this is more secure for this reason, but there is a trade-off here with user experience. Because the the the first approach we saw, it’s very simple from the perspective of a bidder. They make a bid and then, you know, if they, if they’re not the winner, their uh money will be transferred back automatically. Well, with the second one, there there is more hassle like they have to ask for their money back. Uh, and this is something that often happens when you have, uh, we, we arrive at this trade-offs between security and user experience. Uh, typically here we try to prioritize for security, uh, but Yeah, it is a trade-off. Uh, so, we, we will move on to the next attack. I don’t know if there are any questions so far. OK. Um, so, this attack is very specific to blockchain systems. It’s called the re-entrancey attack. And it it basically it can happen because we have these different programs that can interact with each other in the same environment. OK. So let’s go over the steps to see how this can happen. Um, suppose we have these two contracts here. Contract A, which is an attacker, and contract B, which is some benign contract, some honest party. Um, so, contract B, we can assume that offers some service that allows users has this withdraw function like the one we saw in the previous example. It could literally be the the contract we saw before with that withdrawal function. Uh, so, what the adversary can do is make a call to the withdraw function through This contract. Uh, which would then Yeah. Call the withdrawal function from the other contract. Um. So, in this case, we have Yeah, we have a call happening from the attacker’s contract to the victim’s contract. And then the contract, the good contract will respond and give, transfer the ether back like we saw. But then, as we said, what happens when uh E3 is transferred to a contract account? Because this is not a personal account, it’s a contract account. The fallback function will be activated. And what if in this fallback function, anything can be there. So, the attacker has this uh lines of code that say to call withdraw again. So we end up having this loop where whenever the the attack the attacker contract calls the withdraw function, the victim contract is going to send ether. When this ether is sent, it activates the fallback function of the attacker contract, which includes a command to call withdraw. And, and we have this loop until, until it runs out of gas or or until the adversary stops it. There could be some. Um, limit there that’s set. So, uh, let’s try to better understand why this is a problem. Um, let’s look at this code which is the withdrawal function from some contract. Similar, sorry. Similar to the one we saw before. Uh, this contract has an array of user balances, and there’s a public function, withdraw balances, withdraw balance that allows the user to withdraw her coins. So it uses this required statement, um. That, uh, in order to move forward, meaning that if this transfer fails, then the transaction will revert. That’s what the required command does. It’s basically like saying, if this is not true, revert. Um, So, the, the key point here is that This happens uh before the user’s balance is updated. So, the attacker, uh I think there’s another slide. Yeah. So, when this runs, the, there is the initial balance of the user. Let’s say that the attacker has a balance of one in this contract. So, uh, it checks that. Uh, and it goes, so the user balance is run, then it goes there and then basically the execution of this code stops and we’re transferred into the environment of the other contract and the code runs in that state and then this calls back. Uh, this one, but it starts from the beginning. So the function will start again from the beginning and it checks the balance and it’s still one because it hasn’t changed. So that keeps happening as many times, for example, until there is no ether left in the contract. Um, Right. And this attack is probably the most uh notorious one in the space because it happened very quickly after smart contracts were introduced. And it was quite catastrophic. Uh, what happened is that back in 2016, there was this uh smart contract on Ethereum called the Dow Distributed Autonomous Urbanization. Where the idea is that it offered the the service of a fund. So many users can come together and pool their resources, and create a fund, and then they can vote on which proposals get funded and so on and so forth. Uh, at the time, the Dow was really big. Um, it, it attracted millions. Hundreds of millions of dollars in the span of one month. And many prominent members of the Ethereum community were invested in it. As you can imagine from how I prefaced it though, uh, there was an attack on the Dow, uh, back in 2016. And the whole issue there, the, the, the main part was that the Dow contract had a re-entrance bug that allowed the attacker to drain the funds of the contract. So, it was very similar to what I showed before, like, obviously this example is simplified, but that’s what was happening there that the attacker kept calling a withdraw function and managed to um to withdraw I think like 1/3 of the contracts funds. Um, interestingly, this was first identified, like we have a bit of a timeline here. Uh, it was identified in a blog post, uh, in a forum post, rather, uh, but the designers of the contract at the time, like reassured the investors that everything was fine. But everything was not fine. Uh, and the attacker had, uh, drained a large part of the funds. Uh, and then this attack was so catastrophic that in order to recover from it, Ethereum had to change. Uh, basically the, the consensus protocol of the ledger. Uh, which then created this whole debate, um, where some people argued that The attack should not be reverted because everything is mutable on the ledger and we shouldn’t set the precedent of rewriting the ledger, while others argued that it was, it was an attack, so if it could be reverted, it should be reverted and it was the responsibility of the community to change the protocol and recover from the attack. This basically caused a split in the network where the first group of people uh kept using Ethereum as it was, like the previous version of Ethereum, which was then renamed to Ethereum Classic. While the majority switched to the new version which reverted the attack. Um So, the, yeah, the key idea here is that if there is a bug like that in the smart contract, it it can have very large consequences. And what can we do to prevent this from happening? But First The, yeah, if we compare this, the very first thing we can do, uh, is what I said before was the main problem, uh, was that the in in the example contract we had before, it was basically the same as this, but those two were Um, reversed, so the transfer was done first and then the the update of the balance. But just, just by reversing this, it suddenly solves the problem. Because then, even if, if, if the first time, the amount is 1st, the balance is first set to 0 and then the transfer happens, then the second time when they try to go in, the, the balance will already be zero. So they would try um to transfer zero and it wouldn’t make a difference. So, in general, this is called the Uh, checks affects interactions pattern where first, um, the, the, the key idea is that first you perform checks on the inputs to make sure that, yeah, the balance is positive and whatnot. Then you, um, you make the updates to the state. So if you have any, if you want to change any state, if there are any effects of that. Uh, from that action, then they take place first and last, you interact with external accounts like making calls to other contracts. And yeah, I guess, sorry, I could also have mentioned, there are uh also the pull over push pattern we mentioned is useful for that or having a mute text that checks like a flag at the beginning of a function. Um, but, but Mainly like the, the biggest thing I want you to have a takeaway is this pattern of first checking, then making state changes, and last, interacting with other contracts. And, yep What do you mean by mutexes like this

SPEAKER 2
like. No threats are executing this cole at the same time, right? So why would you need it?

SPEAKER 0
Uh, right. So it would just be like having basically like a flag that says uh mutex equals true or false. And so, at first, um, once you first go there, you change that flag. So then if the other function tries to go back in there. The, the flag is changed, it’s set to false, so it wouldn’t even go in the function. If you have a check at first, that only goes in the function if That this flag is true.

SPEAKER 2
OK, I see. And uh can you go back to slide. Through the reactive data. Here, what, what, what is this message send our value. Is this a contract or is it this is a

SPEAKER 0
simple value transfer. It’s just a call. It says message sender. Um, is, is basically, um. Well, the sender of the transaction, the sender of the message. Uh, it’s, it’s like a field specific in in solidity. So every, uh, transaction is considered a message here and has some, uh, attributes and one of them is the sender. So this is something you can always access. So it’s like, it’s an address. So it says take this address and then call uh this uh this function on it, which is just um a transfer basically. You make a call with a specific value and the value is the amount to withdraw.

SPEAKER 2
OK, but then is it different from just actually sending them like some ether to an account. I don’t know what it was called, uh, no, it’s,

SPEAKER 0
it’s the same thing like there are some slight differences between like there are three main functions that can be used to send ether uh call like this, send and transfer. I, I think in the last slide of the previous lecture, there were some. There was a table with some of their differences. Um, one of them is that. They they they all do the same thing in the sense that they just transfer some ether, but send and transfer have a limit on how much gas they can consume. So, nowadays, it is actually recommended to use coal, so this method, uh, so that your transaction doesn’t risk running out of gas. Um But it, it needs to be combined with like these checks for re-entrancing.

SPEAKER 2
Because otherwise you can like uh otherwise I mean if

SPEAKER 0
you send if you use the send function which has I don’t remember the amount but like some specific um upper bound for gas. Then if there is some complex mechanism, but you want some logic that you want to happen, it might still not go through because of the upper bound on the gas. You, you can still use it for simple things, but in general, the recommendation is to use coal because it doesn’t have this uh limit on the gas you can use.

SPEAKER 2
But wouldn’t it be better if you sent them? It’s like specifically because of this feature like you don’t want to have like infinite gas if you are getting exposed to this.

SPEAKER 0
Yeah, I mean it’s, it’s not going to be infinite gas anyway because you always have, like you always said sorry like lose everything you have in your account. I mean, you, you, you can’t lose everything just because of them. Oh, you mean because of the re-entrance or because of the yeah like I mean every time you’re doing this.

SPEAKER 2
So I’m not sure if it’s a contract or not, but we have to pay gas to do this, right?

SPEAKER 0
Yes, yeah, and then if we do it many times,

SPEAKER 2
then at some point we don’t have gas anymore.

SPEAKER 0
Uh, you, you may, OK, so actually as an attacker, this is one thing that you have to be careful not to exhaust all the gas from the transaction because if this transaction, remember where it’s one, it’s a single transaction, but then it goes in this loop of calling the functions back and forth. But it’s still one transaction, so there is one like gas limit there. So if the attacker is greedy, let’s say, and keeps doing this indefinitely, then at some point the gas will be exhausted, the transaction will fail, and all of these transfers will be reverted. So, as an attacker, you would have to be careful to do it enough times so that you get uh a lot of the funds but without exhausting the gas. OK. OK, uh, shall we move on? OK. Let’s move on. Um, OK. We’re, we’re going to go now, um, to some very specific Uh, some hazards that are very specific to Solidity, which, as mentioned before, is also the language that you’re going to use for your coursework. So, let’s consider the this contract, um, It’s we we can see it has this full book functions and then it has a function that supposedly does something good. So, but in order for that to happen, for the something good to happen, it requires that the balance of the contract is zero. Uh, and that’s why if, if you see the fallback functions, both receive and fallback, which is what will be executed when, um, if it is sent to the contract, they both say revert. So in theory, like every attempt to send funds to this contract will fail. So, the, the developer can be sure that the balance of the contract will be zero. So when they make this check, it passes and something good happens. In theory, However, uh, it is possible. Uh, for an attacker to To make the balance of the contract positive in this case. Uh, and in general, you cannot always control how much money a contract will have. Uh, so, Um, so, then the question is how to do it. Of course, we haven’t seen anything like that so far. And it is slightly far-fetched, but there are ways to do it. So, One, the, the first option um has to do with the fact that the address of the contract is deterministically um calculated. So, if you remember, it’s uh a hash of the address of its creator, uh concatenated with some nouns. And and this nonces is the The number of transactions that have been created by this account. So, let’s say um I have my personal account, my address on Ethereum, and I’ve created 10 transactions. Someone can take my address and the number 11, which could be the next, um, the nones of the next transaction, hashtag and they would have the address of the contract that I would create with my next transaction. If I create the contract. But if, but if I want with my 11th transaction to create a contract, then someone could have pre-computed this um hash, this address, and they could have sent ether to the contract before the contract was even deployed. Uh, that’s one option. Uh, another method is to create a new contract. Uh, and then in that contract, called the self-destruct method, which is um what what is used. It’s the code that is used to destroy a contract and this takes as an argument an address where it can send like the funds and the remaining funds of the contract. So if there the the contact creator adds the the address of the first contract we saw, then again, the contract would receive some ether because that that would not trigger trigger the fallback functions. And, uh, another way to do it, perhaps more straightforward than the first two. is to set the the address of the contract as the recipient of block rewards. Because I think we’ve mentioned. Briefly, in the past that uh validators in the case of Ethereum receive uh rewards for creating blocks. So and so they they need to receive those rewards somewhere. Like there is some address specified. So in theory they could specify the address of that contract and then um increase its balance. So, the lesson here is just to, to be careful when making checks with the, with the balance of the contract. So this field, this always refers to the current contract. I don’t remember if I’ve mentioned this. So this is like saying self in other languages. uh and balance, the balance of the contract. Yeah, but just be mindful when using that or don’t use it for something important. Um, now, the next. Hazard we’ll talk about has to do with um what is called the delegate goal. Now, a delegate call is a special function that forwards calls from one contract to another. But the context, so the, the state variables, the, the storage, the current address, the balance, they still refer to the calling contract. So what can go wrong here? Um, Let’s, um, normally, when you, when you, when you have, when you want. Uh, to run the code of subcontract C from the code of the contract B, uh, there would be a call to this function which would, uh, cause the execution of B to stop and the code of C would be executed in the context of C. It would jump to that and it would run in the context of that contract. So, the variables would be those defined in C like the message sender or like the balance. Everything would would have to do with that contract. Now, if instead of that, Uh, the contract makes a delegate call to the other contract. Here, lowercase c is an instance of the contract, uh, the uppercase C contract. So um B can use a delegate code to run the code of contract C using the context of contract B. This means that the the balance would be the same, that of contract B and so on. And why could that be a problem? Um, here’s an example of why that can be a problem. Uh, suppose you’re using a a library. Which is uh is a specific type of contract where the logic of the library um is run on the state. Of the calling contract, of the smart contract. So, if the library is malicious, It can change the state variables of the color contract. So, in this case, we make this delicate call, uh, and changes like the, the library makes this delicate call and it has, it’s possible for it to change the owner of the contract, let’s say. So when that is used later for some checks, there are going to be problems. Uh, now, the, the idea here is that. Uh, it’s not to say necessarily to never use delegate call because there are legitimate uses where you would want to use that. Uh, for example, or, or when you use libraries and you do want to use libraries, but you should always inspect the code of the contract, of the other contract. Um, you want the code to make sure it doesn’t do anything malicious. Yes.

SPEAKER 3
Um, that they are in the function delegate. It’s just a sample.

SPEAKER 0
Uh, delegate call is. It’s something that exists in Solidity for all contracts. It’s a function that exists for all contracts. So, it’s like delegating a call to another contract. So, here, a library is an instance of the library. So we, I don’t know if, yeah, uh. Yeah, there is, it’s, it’s like you’re creating an object, library that is of type, library, and then you delegate the call to that library. But then, Uh, this, this is the library and has this code that Um, that can basically, uh, when this changes the owner knows that, you know, this, this contract has an owner. And basically, in a normal call like we saw before, if a call was made, then the, the state variable there would be the variable of that contract only. But now, we’re calling it from this contract with the delegate call, meaning that the state variables are the variables of the left contract here. So when it changes the owner, this changes the owner of this contract, which is not something you want to do. OK. Um, another type of attack that can happen here. Has to do with this um other field, TX origin. So the Solidity has these two Different fields. One is message center and the other is the transaction origin. And So, let’s take this example it will become more clear. Like when a personal account um sends a transaction to a contract, when it interacts with a contract. Uh, they are both the center of that message and the originator of the transaction. But then if that contract calls another contract, if it calls contract C, then there is a message between those contracts. So the center of the message that arrives to contract C is actually contract B. Uh, but the, the the origin, the originator of the transaction is still A, the personal account where the transaction originated. That doesn’t change. OK. So, what can go wrong here? Um, here we have an example of a bank contract where only the the owner is supposed to use this function, the the send to function. Uh, but it uses the transaction origin instead of the message center to check if that’s the owner. So, let’s imagine this scenario. Uh, the bank owner sends some money to the attacker because it could be that, you know, that legitimately they have some, the attacker has some balance here, they asked to withdraw it and the Uh, the bank owner verifies that and sends them. Um, some ether. Uh, then. This call function will, will trigger the receive function, the fallback function of the attacker’s contract, which in turn will call again this send to function of the other contract, of the first contract. Uh, now, in this case, the center of the message is the attacker, but the transaction origin is still the owner of the contract cause we’re still in the same transaction that the, the bank owner initiated that then went to that contract and came back but we’re the same transaction. So this would go through again uh and we would have this loop problem. Uh, but if here, instead of checking for the transaction origin, the check was for the message sender, then this wouldn’t happen. Because the message sender would be that contract. And finally, a rule of thumb is to keep the fallback functions simple. Uh, we don’t need to have any complex logic in the Fallback function. Um, cause we don’t want, for example, to Run out of gas or, or whatnot. Any questions so far before we move to the next topic? OK, good. I. Huh. Let’s take a break now because this will take longer than 4 minutes to explain and and let’s start in, in, in 10 minutes again. So like 6 past. OK. So, the next type of attacks we’re going to look at um are the ones that rely on default values that are used in solidity. Uh, recall from the previous lecture that there is no such thing as null, uh, or like an invalid value in solidity, that every variable, everything has, is initialized by default to some zero value. So, before we go into that, let’s take a look at sparse myrtle trees. Um, which is an example of how these default values can be used in practice. So what are sparse myrtle trees? Uh, they are perfect binary myrtle trees. And hopefully, you remember what Merkel trees are from the second lecture. And perfect means that all their layers are filled and binary means that um all they have 2 children. Like each node has 2 children. Uh, and the unfilled leaves then take default values. Uh, And then you build, so you have the, the leaves here. Uh, and some of them have values and some of them don’t have values, but in fact they all have values cause they are default values. Think of it as some sort of zero value. And then you build the Mel tree based on these values. Um, so, why would you want to use these trees? You may want, for example, uh to have this key value store. Where it’s like a default dictionary in in a language like Python. Where you don’t want to have to initialize every possible value in the dictionary. Instead, everything is automatically initialized to zero. Uh, in, in that way, someone could do operations on the leaves directly like trying to add something to them. They, they wouldn’t get any undefined errors. Um, so you can construct a myrtle tree that sparse myrtle tree with as many leaves as the size of your dabay. So you could have, for example, um, 2256 leaves. uh and then you can use this as a key value store. And this is a structure that is generally used in Ethereum and it’s quite useful. But now, remember again uh that there are no null values in solidity, but every variable is initialized to a respective zero value. Uh, a 0 integers, 0 bytes, and so on. So Let’s look at uh an attack that happened a couple of years ago that um Took was taken advantage of these default values. So, there was this contract called the Nomad Bridge. Uh, you don’t need to worry about what the bridge is, but briefly, it’s like a way to move funds across different ledgers. So if you want to use your Ethereum on Bitcoin or something like that, you can use the bridge. Uh, the point is that this service, uh, they, they provide a service and this is a smart contract. And this smart contract had some internal variables and we can see one of them over here, for example, this mapping called confirm add. Um, where the idea here is that you have a miracle tree. Um, and this mapping tells you whether, uh, it tells you after which point you can start using the root of the myel tree for validation in order to validate the leaves. So, after which point the route is valid and can be used to perform operations like transferring money. Uh, then there was another mapping called messages. Uh, and the idea there is that you have a message and, you know, uh, a message is supposed to be in some tree. Um, and you want to validate. So you want to validate. In order to validate the message, you use the Merkel tree root. So when you see a message, you want to check which Merkel tree root it corresponds to. Uh, and then you check, uh, for this Mercule tree root if the time has passed, if it has been confirmed. Um, and, in, in this case you validate the message and everything goes through. Now, where, where does the problem come? Where? Oh well. Uh, the, the company behind this launched a new smart contract on June 2022. Uh, a new version of the contract. And when they did that, they made this initialization over there where they set the value of the 0 bytes on the confirm at uh mapping. They set that value to 1. Um, that’s all they did, but it was enough for the attack. Uh, not that the reasoning here, like why they wouldn’t think it’s a big deal, for example, is that a Merkel tree root can never be zero. It’s, it’s some hash. So, in theory you’ll never have a miracle tree root be zero. So, and this, since this is something that maps Merkel 3 roots to these times, there wouldn’t be a problem since the the root can never be zero. It would seem inconsequential. Um, however. Um, if we remember the previous mapping as well that we had and we combine those two mappings, we, we arrived at we arrive at the problem. Because basically, um, what happens is that every message that has not yet been validated in this mapping of messages is initialized to the zero value. So the messages of some um unvalidated message would be zero. Um, so, a, a verified message we have would correspond to an actual Merkel tree root, but a non-verified message would have zero there. So, when this initialization happened, Uh, it meant that the zero Mel tree root can get confirmed at time 1. So at the beginning of the system, basically. And in other words, every message that hadn’t been validated immediately becomes valid and you could execute this message and you can think of this message as a transaction like stealing money from the bridge, which is exactly what happened. Um, and a lot of money was lost in this attack as well. Uh, an interesting part of this again, or perhaps disappointing is that this uh vulnerability had been flagged in a security audit. Um, but, but it was, um, not taken into consideration by the developers. So rather, they didn’t think it was important. So, what are the lessons to learn from this attack? We always check user values, user input thoroughly. uh, and especially in this language where every object has a value. We need to remember that. And very importantly, if an auditor, uh, flags a bug, an issue with the contract, if an external entity, if anyone finds an issue with your contract, address it. Um, now, I have another example here from uh a similar situation where the Binance bridge was hacked. Um, I’m running a bit low on time though. So, I’ll just say that. Um, they used like their own like a custom implementation of an AVL miracle tree. And an AVL tree is basically a self-balancing tree. Uh, so, the, the calculation of the root wouldn’t happen in the, uh, in the simple in the straightforward way we’ve seen, but the there were some complex operations whenever something was added in order for the self-balancing to happen. So basically what the attacker did is that they changed a leaf’s value, but they added an inert note in a way that even though the leaves had changed, um in in the way that The route was calculated, it was still the same. So the verification for the original route was still uh passing. I was getting validated. Uh, and again, uh, millions of dollars were lost, hundreds of millions from this attack. Um, no. And the lesson here would be to keep things simple as much as possible and don’t implement your own cryptography. Don’t implement some new primitive that has not been analyzed in the context that you want to use it. Especially if something already exists for that purpose. Uh, now let’s go to the next type of attacks, which are again very specific to blockchains and have to do with the way the database gets updated. Uh, now remember that a blockchain is a chain of blocks with each block linking to the previous one. And uh each block has this uh list of transactions, which are again ordered in some way. Uh, so, who decides how these transactions will be ordered? It’s the minor, it’s whoever uh creates the block with these transactions can decide what their order will be. Uh, and because of, like in this case, we’ve discussed that there can be different, uh, gas prices. So, if someone offers a higher gas price, uh, a minor can sort, can can prioritize this transaction, so we can assume that This uh array of transactions is sorted by gas price. This is something a miner would want to do. Now, imagine that you’re a user and you create a transaction and you give this gas price of 2 GW. And then a malicious user can create their own transaction. Uh, and have a higher gas price, in this case, 50 Gwa. Uh, and that will cause the attacker’s transaction to be prioritized over yours. So, for example, they can, the attacker can monitor the network and when they see an honest user sending a transaction, they may want to act on it. Um, for example, if it’s about buying or selling assets that might change the price uh of some token. They may want to act on it and issue their own transaction first that does something similar. And they can do that by providing higher fees. And this can also happen um from the perspective of the minor. So we can have two like honest users, let’s say that each provide their own transactions. And then the person who includes those in the block can Um, can include their own transactions, can create transactions based on these transactions. So they can see the user transactions and they can copy them, for example, or do something that Um, yeah, it will, it will be profitable to have, uh, their own transactions before those and then can do that. Uh, in the blog. Now, as an example, we’re going to look at this uh very simple way to register a domain name, let’s say. That we have this function in a contract that Uh, has this mapping that assigns a domain name to. To an address. Uh, yeah. Uh, and this is clearly bad from a front running perspective because uh what can happen is that if, if I can try to register a domain, let’s say Google.com, and then, uh, if the attacker sees that, they can um try to register the same domain, Google.com with a higher, with higher fees. Uh, and then presumably they would get the domain first, then I would not be able to get the domain. Uh, so how can we prevent this from happening? The answer we’re going to provide here is commitment schemes. Uh, what is a commitment scheme? It’s a standard cryptographic primitive based on hash functions. And the idea is that you have a two-round protocol. Uh, were first. You commit to some value, so you Uh, you create a commitment by hashing the value and some nouns, and then instead of sending to the contract the value on its own, you send the commitment and at a later stage, you, you send the transaction that reveals this commitment. Uh, so, why is this? Interesting? It has two properties. It is, uh, a commitment is binding. Which means that Uh, if If I commit, let’s say the value 10 for in some context, I can’t go later and reveal value 12. Like it wouldn’t be valid. So, if I’ve committed to value 10, and it’s binding, I can only reveal value 10. There’s no other value that I can reveal. And importantly for In this context here, uh, commitments are also heightened, meaning that they don’t reveal any information about the underlying value. So, I may want to commit value 10, but since this is hashed, um, and we’re assuming like a large domain space and if not, we’re adding the the nouns anyway. Um, so, uh, someone seeing the final hash, the output. Um, of, of the hash, should not be able to tell whether my value was a 10 or a 12 or anything else. Uh, and this is the property that ensures this. So, back to our example. Uh, with the domain registration, you could do something like this where, um, I mean, this only shows them the second step, but first there would be an initial, um, transaction that creates the commitment. Uh, and then you. You, you check when the user wants to reveal and actually like register their domain name. You have to check if this matches, if the revealed value matches the commitment they have they had made. I, however. Even though using this value, when, when a user sends a commitment, no other user can know what is the value they’re trying, um, to send, what’s the domain name they’re trying to register. There is still possibility of front-running. So, for example, here, Um, the user is, um, is committing this value. This is a hash of the actual name. They, they want to, to use and the attacker doesn’t know what the name is, but they can see the commitment, so they can go and commit the exact same value to the contract and front run the transaction. Or, or even, OK, no front running maybe at this time they just make a transaction um that makes the exact same commitment and then at the reveal stage when the user wants to reveal their super domain name, then this is where the funds run the transaction and they’re the first to reveal because they see the user’s transaction, so they know what um the commitment, what value the commitment corresponds to. So they make transaction with higher. Uh, gas fees, uh, and make the reveal first. So Why was that possible? Uh, it was possible because the contract allowed for uh multiple users to, to commit to the same commitment. So, it, it could be solved if, for example, you, you keep track of committed values and you prevent users from posting the same values. Though this also has, would have a problem. Um, where the attacker could, for example, uh, front run the initial transaction of trying to make the commitment, uh, which then wouldn’t allow the honest user. To create their commitment. Um, uh, which would effectively be a denial of service or griefing. So, uh, front-running is like commitment schemes help a lot to mitigate front-running, but it’s not. Um, a complete solution and it is a very real problem in modern day systems, uh, especially when we’re dealing with financial transactions and arbitrage and the order of the transactions makes a big difference. So, it’s, it’s basically, there are mitigations, but at the end, at the end of the day, it’s a trade-off. Uh, and we need to be mindful when choosing I was doing these cases and just have in mind that front-running, uh, is the thing when writing your contracts. Uh, are there any questions before we move to the next? OK. Uh, so the next topic is about generating randomness. Um, which is useful in many cases. Suppose you have a game, you want something like a lottery, you want randomness. From there, that there are many situations where we want randomness. Uh, but the issue is that the blockchain is, uh, deterministic. So, how, how can we insert randomness there? It’s not, it’s not a simple question to answer. But let’s say we have a smart contract, where can we get randomness from? So these are some um Potential sources of randomness. Uh They, they are basically attributes that the blog has. Uh, remember, every block has a time stamp, it has a sender, it has a hash, it has a difficulty, you know, back in the proof of work error. So, in theory, we, we could use one of these, uh, fields, um, to, to, to generate a random number, let’s say. So, we take the hash of the block and we make some operations that that provide them a random number from there. I, would this be good though? Uh, would, would they be a good source of randomness? The answer is no. And the the reason why they’re not a good source of randomness is because these values can be manipulated by minors. Uh, so, for example, the block timestamp, you know, if, if a minor. Once, if, if there’s a contract that uses the time stamp of the block to determine some randomness, a minor can withhold the block they made until the timing is right, so that the the randomness would be favorable. Or even the hash, because if you remember, the hash would have to do. Um, Uh With um Sorry, yeah. They they can manipulate cause um the hash has to do with the contents of the block. So by changing the contents of the blog, they can change the hash to something favorable. Uh, and another issue is that even if they could not be manipulated by minors or if we assume that they’re not. Uh, this would give the same randomness for, for all transactions in the block. So, if we use the block hash as a source of randomness and then there are 100 transactions in the same block, then all those 100 transactions would use the same randomness, which is not good. Um Yeah, so this is just an example of using Uh, different block attributes, uh, as sources of randomness, but they’re generally discouraged. Um, and this is, uh, another option is to have like a variable in, in a smart contract that settle private here, for example, uh, or even Um, A function that calculates some randomness. But even though these are set to be private, like this visibility is only about how can they can be accessed by smart contracts, for example, but it doesn’t mean they’re not still public. So even if this is set as a private file in a smart contract, everyone can read it. So, it, it doesn’t help. Um, and, uh, this is, uh, what I briefly mentioned before where if you use the The same source of randomness. For different transactions in the same block, then uh an attacker can check whether the conditions are favorable and only then uh like run something. So, to summarize, we’ve seen some possible sources of randomness, um, mainly block information or having um variables on the smart contract. But none of these are considered good sources of randomness, uh, because they can be manipulated by blog creators. Um, because the data post on chain is public, uh, and because we don’t want different transactions to share the same sort of randomness. So Uh, a good idea that we can have here is to use information from future blocks. Since um it’s a probabilistic process, who will produce the next block. At least in, uh, in the proof of work setting that we’ve mainly seen. Um, it’s, it’s not, we, we don’t know who is going to be the entity to create the next block. So in theory, we could use um some uh block information like the, the hash from a future block. Uh, as a source of randomness. So for example, we can have this casino contract where A player can make a bet. And the contract would store the block number of the transaction. But then, uh, the player would request the cas the casino to announce the winning number at the future block. Um, and then the casino will, will use a source of randomness, uh, from a block in between those two basically. So from a block that is after the bet was placed. Uh, there is, there are some things to keep in mind with this though. That, uh, for example, uh, in Solidity, you can only see the hash of the past 256 blocks. So, if the block is older than that. Uh, if the player lets enough time pass, uh, you could select uh an older block and in that case, uh, that would be, uh, set to zero. So it wouldn’t be it wouldn’t be random because uh the, we have the hashes for 256 blocks. If you try to access the previous one, it doesn’t have its actual value, but It’s always initialized to something, that something is 0, so it stops being random, it’s 0, and the player would know what this is. Um, so, uh, another problem with, uh, with using the, the hash of a future blog as a source of randomness is that Um, OK, the first two we said. But, but yes, there is also some probability that a malicious minor will create the specific feature, uh, block. And they can actually wait until they, they have a favorable block. So, if there’s a malicious minor and they know that the block will be used as a source of randomness, uh, they can manipulate the contents of the block until they get something that is favorable to them. Um, yeah, so they, they can keep the block hidden until then. And this is actually uh very relevant in proof of stake systems where um in most cases, the Some future uh block creators are known. Some future miners, let’s say. So, you don’t know all of them in advance, but you might know, for example, who are going, who’s going to produce the next 10 blocks or some number like that. So, in the, in this uh case, this becomes um harder to do in an unbiased way. So Can we do better? And the, the answer takes us back to commitment schemes again. So, as a reminder, uh, we have this uh commitment, this uh hash value. Uh, so instead of publishing the message, um, a user will publish the commitment to the message. And after some time, they reveal the message and it is verified that, uh, the hash of the message is equal to the commitment that was originally posted. Uh, it, it has the binding and hiding properties that, that we discussed above. Now, we can see this example of a two-party coin flipping that is done via commitments. So both parties can commit to some value. Uh, and then at a later stage, uh, both parties reveal their values and the casino can just exor these two values, um, and has a 01, let’s say. If, if we’re talking about binary, we can have, um, Yeah. And then and then like one player, let’s say has a 0, the other has 1, and that’s how you get the, the final randomness by extorting these two values. and what we’re saying here in this slide that if either one of the participating parties is honest, then the, the seed that’s produced at the end is random. And that is because Even if, um, One of them is malicious, let’s say. There there’s not much they can do since at the stage of the commitment, they don’t know what’s the value of the other person. And they have to commit, the both parties have to commit before anything is revealed. Uh, what, what an attacker or malicious entity could do there though is that if Like both parties commit to a value and then one of the parties reveals. Um, but then using the revealed value, the other party can calculate what the randomness is going to be because they know their own value. And if they see that it’s not favorable for them, uh, they might just not reveal at all. Um, which, which is the case of aborts we have here. Or this can even happen because of some failure. Uh, but this is, um, This is something the contract should take into consideration. Uh, for example, there could be some timer where, um, the contract, there can be a predefined amount of time in which users can post their commitments and then the same for, uh, revealing their values. And if someone doesn’t reveal, the contract can handle, handle it in an appropriate way. OK. So, now I’m briefly going to talk about oh 00, sorry. Um, Yes, this is just them. A summarine Slide, uh, to remind you that Um, there are many applications that require, uh, randomness or data to be held private and that everything that’s published on chain is visible regardless of whether it’s defined as private in the smart contract. And the best strategy to use here is a commitment scheme, a commit reveal scheme. Uh, but remember that front-running is still an issue even there. Now, uh, another topic I’ll briefly talk about. If there are no questions, OK? Uh, is that of, uh, overflow and underflow, which is really very, uh, general problem and not specific to solidity. Where, for example, if you have. Uh, there is a certain range that Uh numbers can take and if you take the highest possible number uh and add to it. Uh, it will actually go to 0. Or if you take uh 0 and subtract from it, it will actually go to the highest possible value. Um, this is not specific to solidity, but there are, uh, things. But there are attacks that it was possible to do because of this problem. Uh, I want to highlight though that this is no longer the case. Uh, this is just an example of uh such an attack where it, um, it decreases the value, but then there’s the The underflow so the um the attacker gets a higher amount of money. Uh, but I, I don’t want to spend a lot of time on that because uh newer versions of Solidity protect natively against this. Uh, so it’s only something to keep in mind if you’re using, for some reason, some older version of Solidity, in which case you would need to perform some checks manually or use the safe math library. And the last thing I want to talk about. Uh, is actually, um, fairness and specifically fairness in terms of how much gas is consumed. Or spent by each party. So, suppose we have a crowdfunding contract. Uh, where There is a certain party that starts a campaign and they set a threshold. than the threshold that they want to reach for the crowdfunding. Then the contract collects contributions. And when the contract’s balance exceeds the threshold, then it sends the funds to the party R, the creator, and the returns and surplus to the contributors. Uh, so the, the, the approach I described. Basically says that when like the first person who is going to fund the contract pays some gas amount X. The second pays some gas amount X. But then, the last person who’s going to fund the contract, that’s going to cause Um, the, the threshold, the balance to go over the threshold, then they will have to pay a lot more gas because this action will, will trigger additional operations like distributing the, the balance, the, the funds to the campaign creator and the other contributors. So this doesn’t seem very fair. An alternative approach would be To have the same thing, basically. But then when the balance uh exceeds, when the balance exceeds the threshold, it it just changes a state variable, let’s say, changes the state of the contract so that it allows the campaign creator to withdraw uh the balance and return the surplus to contributors. So, in this case, it’s the creator of the contract or the creator of the campaign that will pay this gas. Um, and there is a third case, kind of. Uh, in the middle, where when the balance exceeds the threshold, uh, each contributor and the contract, uh, creator can withdraw their funds individually. Uh, each paying for their own gas. Uh, so this is just an example, but in general, remember that for every line you, you have in your code, someone will have to pay for that to be executed. They will have to pay in gas. So, when, when writing your smart contracts, it’s important to keep a note of this fairness part. Like, is there a user that will have to pay more gas than other users even though um they get the same value out of the contract, they’re doing the same thing. Uh, though, of course, there is also uh a trade-off between fairness and efficiency because you might be able to do something um faster um with your lines of code or using, uh, and because of that, like you would be using less gas overall. So if you take all your contributors, like all together, they would pay all your users, they would pay less gas. But it, it might mean that individually, um there was one individual that paid a lot more than others. Whereas to fix that, you might need to increase the total amount of gas spent but uh the amounts would be more equal. Uh, any questions? OK. Now, this is basically the end of the lecture. The 2nd hour went faster than the 1st 1. Uh, but I do have a contract here, uh, that is a rock, paper, scissors contract, uh, and Basically, what I’m asking you is to tell me why it’s a very insecure contract. Like what’s, what’s wrong with it. There are various things that are wrong with it. If you can tell me a few of them, like take, take your time to read it and if you can tell me a few things that are wrong with it, it would be great. It would help you with your coursework. OK, I’ll give you one, and, and I’ll leave the rest for, for homework. Uh, so here. We can see uh that there is actually a commitment scheme being used. So, OK, it’s not a horrible contract. There there are worse things it could do. Uh, it uses a commitment scheme to Um, so that the user commits to some value either rock, paper, or scissors, and then they open their hand. They reveal their value. Uh, which in theory would be good, but in practice, what happens is that The, the players are asked to compete. OK Um, when calling the commit function. And the players are asked for their hand, for, for their actual value, and then this, uh this is committed. Inside the contract. Like the, the hash is calculated there on line 16 uh inside the contract. So even though there is a commitment, uh, the user still has to sense, sense their value. Uh, and this is visible on Shane. So it wouldn’t help. So, uh, the other player, if they see the first player committing this, they would know, uh, if their hand was 12 or 3, which corresponds to rock, paper, scissors, and they would know how to beat them. Uh Yeah, that’s one of the issues with this contract. It has a few more, but I, I’ll let you study this at home and think how you could make a nicer one. Or rather, well. Uh, later today, we will release the coursework, uh, hopefully. So, you can also have a look at it and if you have any questions about it, you can post on chatum. And, uh, this is the last lecture from me, uh, next week, uh, there will be a new lecturer, Damiano, that will take it from here and do the, the rest of the course. Uh, but I will probably be back in 2 or 3 weeks’ time, maybe during the break if you have any questions you want to ask in person. Uh, but you can always ask them on CASA as well. Um, that’s it. So if you don’t have any questions, you’re free to go.

Lecture 3:

SPEAKER 0
OK. Hello, everyone. Uh, I hope you can hear me. For those of you who don’t know me, my name is Christina Visy and I’m a teaching assistant for this course. Uh, I’ll be giving this lecture today and also the one next week. Uh, and today we’ll mainly talk about, um, smart contracts, uh, how, so programs that run on the blockchain, how they were initially implemented in Bitcoin, and then we’ll talk more about Ethereum. So first of all, what is a smart contract? Uh, a smart contract is basically just a computer program. Uh, it’s a program that runs on the blockchain that is stored on the digital ledger that we’ve talked about in different the previous lectures. And it’s executed by all nodes that maintain this ledger. And because it runs on the blockchain, it has some additional context compared to normal programs, let’s say, like um access to transactions or most recent blogs and things like that. I note that the code of a smart contract cannot change when the contract, once the contract is deployed. And this is because blockchains are append only databases. They are immutable. So once the code is deployed, it’s not possible to change it, which can make it a bit complicated in, in the case of finding bugs, for example. Now, uh, I just want to take a moment to, uh, contrast this to the traditional definition of contracts in a legal setting. Where a contract is this binding agreement that governs the rights and duties among parties. Uh, now, by contrast, the smart contracts are neither smart nor contracts from a legal perspective. So, the terminology may be a bit misleading, but it, it’s basically I just want you to remember that we talk about smart contracts, but basically what we’re just referring to programs. Programs that run on the blockchain. So, let’s first have a look at how our programs work in Bitcoin, which you’re already familiar with from previous lectures. I mean, Bitcoin, not the program’s part. Uh, as a quick refresher, the in Bitcoin, you have transactions and here we have two users, Alice and Bob, who interact via transaction. Then from the output of the transaction, the, the receiver of the Bitcoin, in this case, Bob, can issue a new transaction and a transaction can even have multiple outputs as we see there or even in the case of Eve, uh, one can combine multiple UTXOs that they own that and spend transaction outputs as input in a new transaction. And this is how the transaction graph is formed. Now, what can we do in Bitcoin apart from simple value transfers? Uh, not, not a lot more, but, but there are a few things that can be done. Um, so, first of all, each transaction consists of two main fields, the input and the output. So, the input is basically an output uh from a previous transaction. And we we also need the index from that transaction because as we saw a transaction can have multiple outputs. So if we have output 12, and 3, then you would reference the transaction and the index of the output to form the input. And you also have a signature that basically proves that the sender uh of this transaction, the issuer, um, is the owner of the value they’re trying to send. And then uh a transaction also has an output, uh, which is the, the value, the amount of Bitcoins that are sent and crucially, this instructions for how this Bitcoins can be used. So there can be conditions uh for how the output can be used and this is captured by this uh script pub key field. And then to validate a transaction, uh, what is done is that, um, a minor like whoever process the transactions, uh, concatenates the signature, the script of the current transaction with the script pad key of the reference transaction, and if it’s valid, it successfully executes the transaction. Uh, we’ll, we’ll see an example of this shortly, but let’s see, uh, what The script language looks like in Bitcoin. Uh, first of all, it’s, it’s a stack-based. It’s a simple stack-based language and it includes some op codes. That’s how they’re called for basic arithmetic operations like addition or multiplication or uh there are also some cryptographic primitives that are included here like hashing or other functions. Now, we, we can look at this through an example. Uh, this is the output of a transaction that is included in some block and this is what, uh, this is an example of a script pub key field that has instructions, uh, basically the conditions under which the, the output, the value of the output can be used. Uh, OK. So basically, what it does is that it duplicates the top value of the stock, then it hashes it and then checks if this hash um is equal to the public key that’s provided and then verifies the signature. We’ll also see this step by step in a bit. Uh, but yeah, then, basically, in the next, uh, block or in the next transaction that is referencing this transaction, uh, there will be Uh, the signature that will reference this and the public key, it will be con concatenated with this and if it runs correctly, the transactions, the transaction will be executed. And here we have this example in more detail. Uh, so, basically, the, the script is what we see. What we see there in the center of the top row. And each of these things um are, so it’s either a data entry like the signature or the public key, or it’s an op code for an operation, for an action to do. So whenever, uh, so the, the, the script is processed, uh, entry by entry and whenever a data entry is seen, it gets um added to the stack. Uh, and then whenever an up code is seen, it, it gets executed and it might also require some data from the stack which then gets popped because it’s a stack, it’s uh First thing, last out. So the, the last item that has been um put in the stack gets popped out and it is used as the argument for the up code. Uh, so here Let me just come here. Um, we have the, the constant values that are the signature and the public key that are just added one by one to the stack. The, the top of the stack is the right, the way we look at it. Uh, and then we have, uh, the op code to duplicate. So the, the last item that was added in the stack gets duplicated, the public key in this case. Uh, and then we have, uh, another. Oh, yeah, we have the hash operation. So, the, the public key that was like the copy of the public key gets hashed, so it gets popped and then the hash of the public key gets pushed to the stack. Uh, and then we have the equal verify of code which checks if the last two items in the stack are equal and in this case, they’re equal. So it proceeds to check the signature and if everything is correct, then the stack at the end should be empty. If the stack is not empty at the end of the execution, it means that something has gone wrong, so the transaction fails. Um, so, there, there are a few things we can do with the Bitcoin scripting language, but there are also quite a few limitations. Uh, importantly, the, it’s not a pure incomplete language. It doesn’t have loops, for example, and it doesn’t even keep, uh, an internal state. So, a script can remember anything from one transaction to the next and it can’t access any data from previous blogs or time stamps or things like that. Uh, now, let’s say that we like Bitcoin. Uh, and we want to extend its functionality in some way. One way to approach this is to just build a protocol on top of Bitcoin. Now this can be very simple. You just Well, it’s rather simple. You make a solution on top of Bitcoin. Let’s say you have an API that communicates with Bitcoin, uh, and this takes advantage of the underlying network of Bitcoin. There’s already, uh, all these miners, this computing power, running the infrastructure. So you already have that. There’s lower development cost, but you’re still restricted on what you can do because there is this point. Uh, where you connect to the Bitcoin network, the Bitcoin API, uh, so there, there is again limited flexibility. Now, another approach would be to uh create a fork of Bitcoin as we say, uh, which means to fork the database to create a copy of uh of its code base, sorry. Um, and then you, you can add new op codes, sending new functionality that you want. Which, uh, of course, gives a lot more flexibility. It’s easy to add functionality, uh, but it has the issue that it’s much harder to, to attract participants. So, you need to add, you need to start from scratch in a way and the development cost is much higher. Any questions so far? Good In that case, we can move on to the main part of the lecture. Uh yeah, uh, could you maybe go back to the

SPEAKER 1
slide of the stack. Yeah, so Can you maybe explain like one example again like is the stack on the left hand side always like the result of executing the script or how should I so the, the stack here it’s not really shown

SPEAKER 0
as a stack, so it doesn’t help, but it’s like the left side is the bottom of the stack, the right side is the top of the stack. So you read the script at the top. Entry by entry. And whenever you see something that is a data entry, in this case, if it has those, uh, what they’re called like the, the brackets anyway, uh, you just push it to the stack. So at the very beginning, we see a signature, we just push it to the stack. We see a public key, we push it to the stack, but then we see an op code, so it’s, this is an action, it’s telling us to do something. And this specific op code, the there is a whole like table of op codes and what they do, how many arguments they take, but this specific one, it’s an up code that says to duplicate the last item in the stack. The the the the the item at the top of the stack. So, what you do is that You take the top item in the stack, which is the public key in this case, and you duplicate it, and this gets added to the stack. And then you move on because you’ve done the op code, so you move on to the next op code. Is, is it clear?

SPEAKER 1
OK, and then like when I have to like brackets, it’s added.

SPEAKER 0
Uh, yes, here, basically you don’t have the brackets, yeah, you started with, with this script. This was provided in the, uh, in the part of the transaction like in the input you had this part. If you take the whole script, you process it. Uh, field by field and if, if you noticed there was already a public key there. So, basically, what this whole thing does is just make sure that the public key that tries to spend the, uh, the bitcoins is the same as the public key that is specified in this script. So it, it, the script already has a public key and then uh it checks that the signature of the person who’s trying to spend uh this UTXO. Here, the the last part is that it checks that the signature with this public key is valid. Does that.

SPEAKER 1
OK, but it’s the stack. What we have at the at the at first the

SPEAKER 0
stack is empty and you have the script. Then item by item the yeah, exactly. You, you read from the top. So the initial part there is what the script is like and then you push to the stack or remove from the stack like depending on what the op code says basically. Yeah, so here, this is like the uh last step basically where there are only 2 items in the stack and then you have an opt code that takes 2 arguments. That’s why I’m saying each op code, uh, you can see the specification. It has a specific functionality and it takes a specific number of arguments. This one takes a signature and a public key and if the signature is valid with this public key, it returns true. And then the stack is empty because these things get popped. Um, I, yeah, so the second row you’ve got there

SPEAKER 2
in the middle of the script. It says an operation #160 public key hash. Is that not gonna push a hash to the stack though?

SPEAKER 0
It, it is, it is. But if you go to row 3 of the stack,

SPEAKER 2
there’s no hash there.

SPEAKER 0
Uh, there is a hash here. So, OK, uh, can, no, this doesn’t work, uh, yes, it’s one operation at a time. So first it hashes this, so you have a hash, and then it also, you see the script still has the hash here and then at the next step the hash is added. No it’s like 11 thing at a time. Yeah Uh, OK, uh, I’ll move on now, but you can also ask me during the break if there are more questions about this. Uh, so, another way to overcome the limitations imposed by Bitcoin is to create a whole new blockchain. Uh, where you can have more complex programs like smart contracts. And this is what was done in the case of Ethereum. Uh, and the, the principles are the same as in Bitcoin. So we still have a peer to peer network. We have uh civil resilience, but previously with proof of work like in Bitcoin, now it’s proof of stake, which is a bit different, but you don’t need to worry about that now. It will be covered in a different lecture. Uh, and again, it’s a digital ledger with its own currency, uh, which is called Ether in this case. Uh, in Bitcoin, it just happens that the name of the system is the same as the name of the currency, but this is not always the case. Here, Ethereum is the name of the ledger, the blockchain, Ether is the name of the currency. Uh, and again we have this shared global ledger, uh, that has blogs, transactions, addresses, and so on. Uh, but in the case of Ethereum, we also have a lot more functionality, uh, because what we have in Ethereum is a replicated state machine. So at any time, there is a state and the state gets updated by adding transactions. So every time a transaction uh is processed in the network, the, the state of the system gets updated. And anyone can create um their own programs, smart contracts, and add them to the database. And importantly, this um language, the Uh, for the EVM is Turing complete, uh, or rather quasi-Turing complete, but in any case, what I want to say is that, uh, we have loops now, so we can do a lot more things. There is access to the state and uh there are, there are a lot of applications that are enabled by this like decentralized applications or DPS as we call them. Uh, now, in Ethereum, there are no UTXOs as we had um in, in the case of Bitcoin. There are instead accounts that are more similar to how a bank account operates, for example. So, each personal account has a private key and a public key and they can control the account using this key pair. Uh, accounts interact with each other via transactions and they, they have a state and an address or the address is basically a hash of the public key that is associated with the account. Um, so, uh, an account in Ethereum, a personal account has, uh, these three fields. The address, the balance, which shows how much ether, how much money, uh, is associated with this account and and non, uh, which is basically, oh wait, yeah, we’ll say here more detail. So we have the balance. Uh, which, um, there is no UTXOs in this context, so you don’t need to link different, uh, unspent outputs to determine the balance. Instead, you just have one, balance field that gets updated every time. Uh, and you have this nons which specifies the number of total transactions that have been published by this account. So when, when a new transaction gets published from this account, this nons gets incremented. And uh we’ve seen that the, the approach used in Ethereum is different than the one in Bitcoin and there are pros and cons in both. Like, I mean in the sense of keeping track of who owns what. Uh, Bitcoin’s model is, is more like the physical cash. Like, you would have a 50 pounds note and then 20 pound note, and 5 pound note in your wallet, and then if you want to pay, let’s say something that costs £13 you have to give two of your nodes and notes and get some change. This is how it works. While in Ethereum, uh, you just have your entire balance it, and what you have to pay gets deducted from it. And the, the pros of the UTXO model uh is that it’s harder to link transactions together. Well, it’s a pro if you require um privacy. Uh, so it’s, this is a benefit in the sense of giving more privacy to the user. Uh, it’s still not impossible to link transactions. There are techniques that do that, but like on a high level, it’s, it’s not as straightforward. So, uh, even though it’s not anonymous, you have a greater level of privacy in this case. Uh, and it’s also a better approach for parallelism because transactions are, uh, valid no matter what order, uh, they’re processing. So you can imagine that. Uh, you can paralyze the operations or sharing or different techniques like that. Um, however, the account-based model is concept conceptually more simple and also saves a lot of space because for every account, you just need to track one balance. You don’t need to keep track of all the different UTXOs. Uh, now back to Ethereum accounts. What we’ve seen so far are personal accounts, but in Ethereum, smart contracts, the programs we’ll talk about more, can also have their own accounts. Uh, so a contract account has the same fields that were in the personal accounts, but it also has two extra fields. Uh, the code, which, as you might expect, it stores the code of the smart contract, uh, and the storage that uh stores the state basically of the contract. So if there are any state variables that get changed, uh, this gets saved there for keeping like persistent data across transactions. Uh, so this is the common data structure that is used for an Ethereum account. Uh, so we can just tell that if the code and storage fields are empty, then it’s a personal account. Whereas if, if they’re full, it’s a contract account. Uh, any questions at this point? Yes.

SPEAKER 1
So how is the balance actually verified like. How can I What prevents you from just putting any balance?

SPEAKER 0
Uh, well, you’re not the one putting the balance, um. So that when when you issue a transaction, it gets it gets processed uh by the whole network. It’s, it’s similar. To what happens in Bitcoin. It’s just that what you keep track of is the, the, the balance. So, again, if you, let’s say try to spend more than, is in your balance, for example, then this is an invalid transaction. So, basically the, the miners, the, the blog producers who are going to include your transaction in the blog, well, they’re not going to include it. Because you can say like in your local copy of your database that oh this is my balance, but then, this, this will not be valid for the people, the other people who hold, who hold copies of the database cause you still need There are still each transaction links to a previous transaction and it links to previous transactions. So, there needs to be, it’s not going to be valid. So, yeah. In order to do that, you would need to have some transaction that increase your balance and that can come out of thin air. Basically.

SPEAKER 1
So, so all the transactions are like in the blockchain and then this is like used to verify if you actually can spend this or not.

SPEAKER 0
Yeah, yeah, exactly. It’s like every, every minor has their own copy of the entire database and every time a transaction goes through, uh, they all run it to see if it’s valid, like if it matches the records basically.

SPEAKER 1
And uh why can the miners not just include my bad transaction? Like is it just that they’re nice and they say, oh no, this is not fair.

SPEAKER 0
Why, why would they do it because basically you’re creating money out of thin air. Who does this money come? Where does it come from? Yeah, in a sense it’s, it’s not in their interest.

SPEAKER 1
Nice things like that, it’s like decentralized and like nobody, you have to trust no one, but in the sense that now we’re like trust the miners, they will do like the right job and it’s not like treated badly, you know.

SPEAKER 0
It’s, it’s not the right job only, it’s like the job that is good for them too, because by, you know, you creating money out of thin air is worse for them who also have stake in the system. Yeah And even if, you know, there is a small collusion of miners that tries to do that, if the network is sufficiently decentralized, this is still not going to work. Like it’s similar, I’m, I’m guessing you’ve talked about um majority attack in Bitcoin, like the double spending. So, in order to do that, you need a large fraction of the network to agree to misbehave. So, if you assume that That there is we have honest majority, then this works fine. By honest majority, I mean that there’s a majority of participants that behave as the protocol dictates.

SPEAKER 1
OK, so this is like the caveat that only works if there’s like really the majority which is behaving correctly

SPEAKER 0
always. Exactly, yeah. Yeah, uh, do we have, do we still track the

SPEAKER 3
history of the transactions for the account anyway, or no, we, we lost them.

SPEAKER 0
Oh yeah, you, you still have the history of the, yeah, everything is on the blockchain. It’s append only. It never leaves, so you can. See for every account, you can see all the transactions. That’s why I said um also that it’s, it offers less privacy in a way because you can very easily link a um an account to all the transactions that it has participated in. While in Bitcoin, this would be more complicated. It’s not undoable, but it’s more complicated. It looks like matching all the different UTXOs.

SPEAKER 4
Um, I’m not really understand why does a contract account need a set of code to be executed, whereas a personal account.

SPEAKER 0
Uh, I mean, that, that’s what a contract is. Like a, a smart contract is a program. Uh, that’s why we have them to run code and this code needs to be stored somewhere and this is exactly where it’s stored. So the Yeah, that, that’s why we have smart contracts to run code on the blockchain, and this is where it’s stored. That that’s all there is to it.

SPEAKER 4
So contract accounts are basically just bits of code that are being stored.

SPEAKER 0
Uh, yeah, I mean, you still have the other fields because the, the contract can still have a balance. You can top up the contract with ether, so the other things still make sense or announce like the number of transactions executed by the contract, and you just additionally have a field with the code of the contract and another field with its state variables. Yeah. Uh, could you please explain the difference between a personal

SPEAKER 5
account and like a contract account?

SPEAKER 0
Uh, yeah, the, so a personal account corresponds to a public-private key payer. So basically, an individual, uh, where the, uh, yeah, and the address is basically, yeah, you, you see there it’s like the hash of the public key in the case of the personal account. Uh, and what, the only, sorry, um. And, and this account has a balance which is the, the ether that this individual owns. Uh, and, and that’s it. And then we also keep the nouns for reasons I’ll briefly explain later. Uh, so it’s, it’s simpler and it’s only about owning ether. Whereas a contract account is an account that is associated with the smart contract, with the program that runs on the blockchain. So in this case, we have the same fields uh where uh the address in this case is the hash of the creator’s address unknowns, uh, and, but we also need to store the contract’s code.

SPEAKER 5
So then where could we use a, a contact account? I’ll come back to like a personal account.

SPEAKER 0
Well, you, um, A contract uses the contract account. So basically, we’ll talk about smart contracts more, so maybe it will become more clear. Uh, but You, an individual can control a personal account but then they can deploy, they can use this account to deploy smart contracts. And when this happens, like when the smart contract is deployed on the chain, uh, this basically creates a new account, which is a contract account. So that every smart contract, every program that runs on Ethereum has an associated account. Uh, that’s it. You, you don’t have to necessarily make the separation. You can look at it as just an Ethereum account, but some of the accounts don’t need the code and storage fields, so they’re unused. Yeah.

SPEAKER 6
Uh, first of the.

SPEAKER 7
Where it says the address and not the creator hashed together. If the non of the creator changes after the creation of the. Account is that value updated or is it just the non of the creator at the time?

SPEAKER 0
At the time that the account is created, that’s why if you create multiple contracts that they’re going to have different, um, addresses. So if the same personal account creates two, smart contracts, they’re not going to have the same address, and we don’t want them to have the same address.

SPEAKER 7
But then the address is the address to the contract will be publicly available on the blockchain as it updates. Everybody else in the blockchain knows that the address is. I guess, or the non-suspense.

SPEAKER 0
Uh, yes, everybody knows that anyway, yeah, they could also see it from the personal account. This is also public on the chain. So, all, all of these things are, are public. OK. Uh, I’ll move on, but we can get back to it if needed. Um, so how do contracts interact with each other or rather how do users interact with contracts. This happens via transactions. Um, so, we have the sender of the transaction, a field that has the address of the sender of the transaction. Then a digital signature that is created using the sender’s private key, again to make sure that they’re authorized to spend the funds. Uh, then there is the, the address of the receiver of the transaction and the amount, like how much ether or rather uh how much weight, which is a denomination of ether, the lowest denomination is going to be transferred. Uh, now, the nonce again. Um, it The reason why we have uh the nons, which is incremented every time, it’s to protect against replay attacks. Uh, I think we’ll talk more about them in the next lecture, but basically a replay attack is like. Oh, you know, since you already have a transaction with a valid signature that says you can spend this much of Bob’s money, let’s say Bob sends $10toAliceandsignsthis,uh,thenwewould{n}^{\prime }twantsomeonewhoseesthatsincei{t}^{\prime }spublictobeabletodoexactlythesamething.Theycouldtakethisandreplayit,likerepostontheblockchainsothatyouknowAlicegetsanother$10 from Bob and another $10 from Bob. If we didn’t have this nonce value, then this would be possible, but by adding this nonce and incrementing it every time, then the signature is only valid for this nonce. It’s like a number that is only used once. It’s, so it’s like an index, so you sign, the sender signs not only the amount and the recipient but also this nons so that it’s valid only once. Um, now, interacting between personal accounts is simple. It’s, uh, like transferring some value from my account to your account. Uh, but to interact with the contract, uh, things get a bit more interesting as you need to run the contract’s code. Uh, so how is this done? Again, it’s via transactions. Basically all state changes happen via transactions. Uh, so we have a new field in the transaction that is called data that has um information in the case of contract transaction. Uh, it has the data that’s needed to run the code in the contract. So it could be the name of the function, uh, that you want to run in the smart contract. Uh, it could be values for function arguments like if the function takes has some parameters. Uh, while in the case of personal accounts, again, this field exists but it remains unused. Um, and the life cycle of a smart contract is that it first gets created, then people can interact with it, people and contracts can interact with it, and it can optionally be destroyed. So, let’s look at the first part, how can a smart contract be created? Uh, this is a transaction for contract creation, uh, where the data part here that we saw, the data field of the transaction contains the code of the smart contract and and initial arguments. So if the smart contract has a constructor that takes arguments, this would be, this would go there. And and the two field is empty there as there is no recipient. While the form is the, the address of the creator of the contract and the signature. Uh, not to interact with the smart contract. This is an example of transaction or rather the structure of a transaction again, where the recipient this time would be the address of the contract. Uh, as we saw before, each contract account has an address. So you would use this in, in the recipient field of transaction to specify that you want to interact with that contract. Then optionally, like if you want to transfer amount and some ether to the contract, you can specify the amount there. But this is not necessary in all cases. Uh, and crucially the data field is the most important one that says which method to call and any potential arguments. Uh, and again, just an example of personal accounts interacting via a wire transfer, while, uh, a personal account can also send a transaction to interact with a contract. Like call a message from a contract. Uh, now, we can see what happens in a bit more detail. Uh, when, um, the contract account is activated. Basically, the code will run. Uh, and it can read and write to storage or it can send other transactions. Uh, but importantly, the contracts, they cannot file transactions on their own or you can’t have a timer, let’s say, saying in 10 minutes, send this transaction. They can only issue transactions. Uh, as a response to a transaction they receive. So, maybe a contract uh receives a transaction that calls a method that tells it to send a transaction to another contract that’s valid but they cannot just on their own, um, issuing new transactions. And now, I, I said that the contract code runs, but I wanted to reiterate again where the code runs. Any ideas about that, like who runs this code once. The smart contract is deployed to the network or when we have an interaction with the smart contract, who runs the code? Yep. Sorry? What does it mean the blockchain?

SPEAKER 8
Uh, it’s Ethereum is all the nodes of the miners that are involved in it for gas.

SPEAKER 0
Exactly, yeah. So, but basically the the crucial part to keep here is that all nodes in the network are going to run the code. So if you issue a transaction that creates a smart contract, then this code is going to be run by every node in the Ethereum network. It’s not like the first node who’s going to see it is going to run it and that’s it. Every node who sees it is going to run it locally in what is called the Ethereum virtual machine or EVM. Uh, yes, so all nodes are going to add, to run the transaction. And, and importantly, they’re going to run the transaction before they try to include it in a block to make sure that it’s valid. Otherwise, if they first try to include it in a block and let’s say in the case of proof of work, you know, they find the right nouns, but then it turns out that the transaction was not valid, then their block isn’t going to be valid as well. So they would need to do the work all over again. So they, everyone runs the transaction locally before trying to include it in a block. Yep, so when is the non value is given to

SPEAKER 9
the transaction? So you say that well if there is transactions then there is a non for the transaction, right? Right. But what if the transaction is canceled? What’s gonna happen to the nons counter?

SPEAKER 0
Uh, well, well, if a transaction, uh, gets reverted for some reason, which we’ll see some reasons later too, then it’s like it never happened, so it, it goes back. So the state only changes after the transaction runs successfully, otherwise the state doesn’t change. Yeah, so I saw in this slide that uh there

SPEAKER 6
is a transaction that doesn’t have to that, does it mean that uh we can use a 3, aside from transferring money and can we run any quote on the contract accounts?

SPEAKER 0
Uh, well, you can, yes, you can definitely use Ethereum for things other than uh value transfer. This is the main selling point of Ethereum that it’s like a global computer that you can use it to build a lot of applications on. Uh, and now about running any code. Well, there is a specific language called Solidity that is used to write smart contracts in Ethereum. So, basically you can run any code that you can write in that language. We’ll talk about that in the second part of the. Lecture today. OK. Um, so contracts can also, uh, talk to each other. Uh, and they do, they do that via messages. So a message is like a transaction, but it’s produced by a contract. And the reason why we differentiate between the two is because messages are virtual objects, so they don’t get written on the ledger. Transactions go on the ledger while messages, so this interaction between contracts, they’re only executed in the Ethereum virtual machine and they don’t go on the ledger. Uh, yes. And as we said, like a contract can send a message to another contract which is executed in the EVM of every um participant in the Ethereum network. While here, we can see this example of a personal account, issuing a transaction that interacts to interact with a contract account and then this contract sends a message to another contract and so on. Uh, no, so these are types of transactions that we can have in Ethereum. Uh, for example, the create, we already saw was to create a smart contract. The send is to transfer ether, uh, and call is to call any type of function, but you have to specify, like in the data field you specify which function and what arguments you’re using it with. Uh, and now, as I mentioned earlier, there is also the option to destroy a contract, but if, if we want that option to be there, it needs to be added at the point of creation. So, um. Once Uh, when, when we create the contract, if you want to be able to destroy it, then you must add a, a method that calls the self-destruct opcode. Uh, though I did read recently that now it’s discouraged to use the self-destruct top code and it’s best practice to use a pause function or something like that. But like the, the general idea remains that if you want to be able to like stop the functionality of the contract, you need, when creating it to add certain conditions saying That, for example, if the owner calls this method, this specific method, then uh destroy the contract or make it, pause it, make it. Uh, suspend its operations. Um. Uh, again, I, I alluded to this before, but where, where is all this happening? Uh, it’s happening in the Ethereum virtual machine or EVM. This is where these contracts live. Uh, and the ABM consists of a series of bytecode instructions and allows you to write programs or contracts, uh, programs which are called contracts, uh, in high-level programming languages. And in this case of Ethereum, this language is Solidity. Uh, so when you write a contract, you’ll write it in solidity. You, you actually will do that for the coursework, just saying. And as we said before, this, um, this is quasi-Turing complete machine, so it allows for loops and so on. And like in Bitcoin, it has a stack-based architecture and it includes some uh functionalities for crypto primitives. Now, we will take a break in a few minutes, but before that, uh, let me briefly talk about the different types of memory that we have in the EDM. Uh, so we have the stack, as we saw before, similar to Bitcoin. Uh, and then we have memory, which is a non-persistent memory. And then there is the storage, uh, which is where values are stored that you want to be persistent, but have to do with the state uh of the contract. And crucially, all memory is zero initialized. There is no such thing as null in this case. Uh, and the contract has access to Uh, like some fields like the block header, the sender of the transaction, and so on. And, uh, as highlighted before, all nodes run the AVM locally and execute the code of the smart contracts. So, uh, a block, Ethereum will look, uh, somewhat like this. This might be a bit outdated because I think it was for the proof of work, but, but the main, uh, fields are the same here, uh, where we have, uh, a pointer to the previous block, a hash, and no, and so on. Uh, and this is, uh, the state root that’s shown in this slide. Uh, is the root of the Merkel tree, which I think you talked about Merkel trees in the last lecture. So this is the root of the Merkel tree where uh the leaves of the tree are the accounts uh that live in Ethereum. So all every Ethereum account is a leaf on this Merkel tree. That’s why we see here. This is the account example we saw before with the address and balance and so on. And similarly, there is also, uh there’s the root to another myrtle tree that stores transactions. So, the leaves of this myrtle tree uh correspond, like each leaf corresponds to one transaction. And then the root of this tree is stored in the, in the block. Uh, and then. Uh, yeah, just how. Let’s talk a bit, uh, about how blogs are produced in the Ethereum and then we’ll go on the break. Uh, again, The the blocks contain transactions and the most recent state. Uh, and they are produced every 12 seconds now. Uh, if you remember in Bitcoin, there was a block every 10 minutes. In Ethereum, there is a block every 12 seconds. It happens much faster. It, the mechanism um with which they were produced used to be proof of work like Bitcoin until 2022. But in September 22, they transitioned to proof of stake. Um, but as I said, we’ll see that in a different lecture, so don’t worry about that for now. And the, the rewards and fees there are a bit more complicated than they used to be because before it was just, it was very similar to Bitcoin where uh each successful blog blog producer would get to ether and then some transaction fees. Uh, but now, um, yeah, it’s a bit more complex, so there is still some reward that goes to the proposer of the block, but the, the value is dynamic. It, it, the amount depends on the total amount uh of it that is staked in the system. Uh, and there is the transaction fee is like there’s a base fee that is burned, um, and there is like an optional tip that goes to the blog producer, blog proposers. So, and, and I, I’ve included a link here with more information about this because it’s a bit of a complex topic to add in one slide. But if you’re interested in learning more about rewards and fees in Ethereum, there is pretty good documentation there. Uh, so with that, I’ll leave you for 10 minutes and then after the break, we’ll talk more about fees in Ethereum and then about Solidity. To I.

SPEAKER 4
this.

SPEAKER 0
Hello, hello. Sorry. Hello, OK. Ah, yes, let’s get started again. Um, so. I think you’ve already talked a bit about fees in Bitcoin, maybe. But uh in Ethereum fees are a bit different. So we’re going to talk about how that works. Um, an analogy we can use here is the phone booth model. Though I doubt any of you have ever used a phone booth, uh, but, you know, we still have a lot of them here. We can take photos with them. Uh, and basically the way they work is that you add some money, and you can make your call. But if you, and, and if uh you end your call and you’ve had enough money, it’s fine. But then if, um, and you get charged like per minute or per second or something. And if your money runs out before you finish your call, then your call gets dropped. And this is quite similar to how uh fees are done in Ethereum. But let’s see more about that. Uh, well, first of all, why do we need fees in the first place? Well, Uh, we need fees to incentivize the participants to, to keep, uh, maintaining the blockchain and to compensate them for the work they do basically. Because they, they run, um, they use up electricity, they run their computers. So they need to be compensated for the work they do. Now, in Bitcoin, uh, there is a simple approach that says You have a transaction, uh, usual transaction, and the bigger your transaction is, so the bigger the Uh, what the state you want to store, the higher the fees you’re going to pay. And you can know for sure like Uh, how much. You can see the transaction and you can tell how much storage is going to need, for example, or how many computation steps. Uh, but remember that in the case of Ethereum, We also have loops. So, why does this approach not work here? Yes.

SPEAKER 1
You can just have like an internet loop.

SPEAKER 0
You can just have an infinite loop, yes. Um, so, in general, what you would try to do if, if say we, we try to build Ethereum, and we’re at this stage where Bitcoin works like this and we try to think, oh, let’s, let’s use the same model for Ethereum. So in order to do that, uh, but remember that we have this code that runs now. So what you want to do is basically estimate how long the program will run. So if you can estimate how long the program will run, how many computation steps it will take, then you can decide how much to charge like in Bitcoin. Now the catch is that this is not something you can actually do. Uh, it’s a big thing in computer science, the halting problem that you can’t actually determine if and when a program will finish just by looking at, uh, its code. Um, so, what stops someone from running a program that says, you know, while this is true, do nothing or do something useless. And which would basically be like uh a denial of service attack. Like if they did that, uh, and then all miners were running this infinite loop and couldn’t process any other transactions. Uh, so what actually stops them from doing that is that fees are charged in a different way in Ethereum. Uh, so, the solution is that every computation, uh, step has a fee. Uh, this fee is paid in gas. That’s how it’s called in Ethereum because you can think of it a bit like fuel for your car, but you have to add in advance in order for your car to keep running. Just like in the phone booth, you need to add the money in advance. Um, and so gas is the unit that is used to measure this computation. And, and this ensures that uh no program can run forever and stall the network. So When I showed the transaction earlier, Um, I, I showed just until there, but it also has these two extra fields, the start gas and gas price. So, the start gas field determines the maximum amount of gas that um the user is willing to pay. While yeah, while the gas price is the The amount they will pay, they’re willing to pay per unit of gas. Uh, so, the maximum amount uh of gas that can be used in transaction, the gas limit is equal to that field we saw, the start gas. And if there is any unused gas at the end of the transaction. Uh, it, it gets refunded. So basically, um, think about it like there is a price chart for every operation that says, for example, that an addition costs 5 gas, a multiplication costs 10 units of gas, as well, hashing costs 15 units of gas. I’m obviously making these numbers up, but there is actually a table like this that says for every operation, how much gas it consumes. So, when uh issuing a transaction, uh, a user or, well, typically a wallet now but a user could also do it if they want. Uh, they can calculate how much gas their transaction will need, uh, depending on the operation, the, the operations that uh need to be computed. Um, and if the transaction runs out of gas, uh, meaning that if you start, if a miner starts processing a transaction and step by step they remove like some gas, uh, if it runs out and the transaction hasn’t finished, then, uh, the miner still keeps the gas. And why did they do that? Because if they didn’t do that and if they refunded it to the user, it would mean that users could run their code on the miner’s machines for free. And we don’t want to do that because again, it could lead to attacks. Uh, and then entire blocks also have the gas limit. So the sum of all transactions in the blocks need to, uh, of their gas needs to be under the block limit. Uh, and as I said earlier, the gas price is the price that the user is willing to pay per unit of gas. Uh, and, uh, for example, if The the higher this gas price is, the more likely it is that a transaction will be included faster in the blockchain because miners will want to process the transactions that have higher gas fees. Um, and it is measured in Gwa, which is, uh, again, just a denomination of ether. Um, and this is just an example of Such a multiplication where the user sets the gas limit to 50,000. So they’re saying that for this transaction, uh I’m willing to pay for up to 50,000 units of gas, and they set the gas price to 20g way, meaning that for each unit of gas, I’m willing to pay 20g way, meaning that at most, this transaction can cost the user 0.001 ether. It can also be less. Uh, this is an example of. Uh, gas prices from Ethereum. Uh, this is from October 2023, where we can see, for example, that the average, uh, gas price during that time was 21 G way. But if you want it priority, if you want your transactions to be processed faster, you could give something more like 24 GW and It would be processed faster, yeah.

SPEAKER 1
Uh, yeah, so I was wondering, can you explain like maybe a bit more why we can set the gas price ourselves, but I guess like now because you can set the priority.

SPEAKER 0
Why did you ask why we can set, uh, yeah, because basically the, the higher you set that price, I mean, obviously if you set it very low, it’s, it, it might not get processed at all, uh, so you know if you said below the average, let’s say or below the, you know, what people are are willing to accept. Uh, but if you want to be sure that it gets processed quicker, you can increase what you pay per unit of gas. And here, for example, in this chart, you can see um the confirmation time. Depending on the gas price, uh, So you see that a higher gas price, this is like the highest 24 meant lower confirmation time. Confirmation time is like how quickly your transaction gets finalized, gets included in a block basically. So that’s why you would want to set a higher price, yeah. So how is the cash price determined. The the the user determines that. Yeah, but, but then if for example you try with a very low price and your transaction doesn’t get processed, you can try again with a higher price. Yeah. uh I mean in practice it will be your wallet. That proposes a gas price, and most people would just keep the default, but you have the option to change it if you want. yep, are you paying the actual gas price after the

SPEAKER 9
transaction, uh, I’ll get there one second.

SPEAKER 0
Uh, and I, I just wanted to compare this with um the average gas prices from yesterday. Uh, so, in, in general, gas prices do fluctuate quite a lot like even from day to day as we can see from this chart here. Uh, but, but the The difference from the slide I showed before is very large. Like before it was like 23 Gwa, now it’s like 2.something. Uh, and this like significant drop in gas prices was mainly caused by last year’s upgrade uh in Ethereum that introduced. What’s known as proto dunk sharding but anyway it was an approach used for a solution for scaling that enabled um More transactions to be run on layer two solutions and so there was uh less. Um, it made it more efficient to post, uh, data on Ethereum via this data structures called blobs, and this caused a dramatic decrease in gas prices. But it still, they still fluctuate a lot. Uh, so, for example, with this, uh, slide, what I want to show is that it’s quite expensive to use Ethereum as storage space. Uh, so if you want to store a picture that is 1 megabyte, uh, most pictures are more than 1 megabyte nowadays, but even that it would cost like $6000. These are based on yesterday’s, uh, prices. So, it’s, it’s quite pricey, uh, not very efficient as a storage solution, uh, but it can still do many other things. Now, back to that question about when the gas is deducted. So, this, this is a breakdown of the computation steps. Uh, when a minor processes a transaction. So first, they’re going to check if uh the balance of the user is sufficient to cover the maximum possible um gas. Uh, if it’s not sufficient, they just stop and they don’t process the transaction at all. Uh, if the user has sufficient balance, then they straight away deduct deduct this maximum amount from their balance. Uh, and then they run the code and for every operation they deduct from the, the maximum gas. And after the program terminates, if there is gas remaining, it gets uh refunded to the balance. Uh, so this is an example of this like happy path, let’s say where the sender, um, gives like the divide 250 as the start goes and then we see the different operations, let’s say some hashing or multiplication or whatnot, uh, that use up. Uh, only 80 gas. So at the end, there is 150 units of gas that hasn’t been used, so it gets refunded to the center. But at the beginning, it has been deducted to make sure that uh it can be paid for in case it reaches the maximum. However, if there was not enough um Gas. So if 250 in that example was not enough to cover the all the different computation steps, then um the transaction would throw this out of gas exception and it would basically be like the transaction never happened. It the state gets reverted. So if any changes were made during the transaction, they get reverted, they don’t happen. But the gas um price like the maximum. Uh, gas is still deducted. So because as we saw it happens first, the deduction of the gas. So, uh, the transaction might fail but the user doesn’t get a refund. Do you have any questions at this point? Um, yes.

SPEAKER 7
Maybe I But is the, the gas price can be paid like I, I understand that. When we’re referring to the gas prices. G wave, is that, is that considered different from just regulation? Way or is it just a way of differentiating what we’re spending it on? Like if I have like 50 way, can I spend that 50 way on gas, or is it like a whole other unit that is being tracked?

SPEAKER 0
Uh, no, you, you, you can use it. It’s just instead of saying, uh, well, Gwei is, yeah, another denomination, so it would just be instead of saying it costs, you know. 1000 of something small, you can say it costs 1 of something bigger. So it’s just the way you express it, but, but it’s the same value. Ah, yeah, will users usually have an idea of how

SPEAKER 4
much gas their transaction will cost, or are they kind of going in blind?

SPEAKER 0
Uh, they’re not going blind. So, first of all, there is the, you know, like this big table that says that each computate this computation step uh costs that much gas. So this is something that you can actually calculate if, you know, if it’s a small transaction that does, you know, just an addition to the balance or something like that, you can very easily calculate that from the table. Uh, if it’s something larger, you know, you make an estimate. In practice, your wallet will make that estimate. Like they see the transaction you try to do and they, they make this calculation or it will do. I estimate that it will do that many steps. It could be wrong depending on the on what you’re trying to run, uh, but typically, you know, it will give you a range. Uh, but yeah, because there is like a standard. Um, cost per computation step. If you know, if you don’t have any infinite loops and you know, uh, pretty much what you’re running and how much, how many steps it’s going to do, you can calculate that yourself. But that is, um, an issue when interacting with contracts that may have bugs, for example. Uh, where they might end up draining your funds because they have some loops or something like that. So, if you haven’t, if you don’t know exactly how the smart contract works, this might be an issue, but that’s what the wallet is trying to do, uh, under the hood like estimate how many steps the contract will take to run the code and propose the the right cost.

SPEAKER 4
So the gas is paid to the miner or?

SPEAKER 1
OK, so, uh, if, if we see it as a

SPEAKER 0
proof of work error, uh, yes, that, that’s what used to happen. The minor that included the transaction in a block gets the, the gas, the fee. Uh, so this is what happens in Bitcoin as well, for example. Now it’s a bit more complicated. Um, the way it happens in Ethereum, because some of it gets burned. It’s like a deflationary method so that uh some ether is are removed from circulation. Um Some of it get gets burned and then there’s another part uh that’s called now the priority fee or tip that is optional, but then this part, again, like the higher that this is, the more likely um the block proposers will include the transaction in the block. uh and then that part goes to the block proposer. OK, uh yeah, so you said that.

SPEAKER 6
If it gets to the proposal. Um, do the block blue poster also confirm when you, you, when you bid for the for the transaction to be computed? Does the block proposer is the one doing the confirmation whether your transaction will be.

SPEAKER 0
Um, what, what kind of confirmation do you mean? They, they check that transaction is valid? Before they execute it, you said that the priority gets

SPEAKER 6
prioritized, right? They click on um accept the transaction to be completed manually or the system does that uh so basically every

SPEAKER 0
participant in the system will get transactions. They get flooded in the network, let’s say, and they’ll have this mempool that is called of transactions. Basically a data structure that includes transactions that they know of that have not been added in blocks yet. So from these transactions, they can see what the transaction is and how much the corresponding fee is, and they can choose to include in a block the ones that give the most value, the most fee.

SPEAKER 6
And um if the If all nodes are computing the Transaction will the rewards be shared to almost or only the proposer?

SPEAKER 0
Uh, they will only go to the blog proposer, but the point is that You know, it will be a different blog proposer every time. uh, so all blog proposers will get rewarded eventually. Uh, all participants will get rewarded, but it is the specific blog proposer that gets the rewards. Specifically in Ethereum now with the proof of stake, the amount of rewards also depends on how many other blog proposers have. Validated the block, this method of called attestations. So the more attestations the blog has, the higher the rewards that the blog proposer is going to receive. But this is not very relevant for now. You can just keep that the blog proposer will keep uh some fees from transactions.

SPEAKER 6
Thank you.

SPEAKER 5
Uh, so, uh, like from what I’ve understood, uh, in, uh, the proof of work error, uh, the minor used to get the, uh, the gas fees. Right. Uh, but like nowadays, part of that, like the ether gets burned, and then the rest of it, uh, the priority fees goes to the, uh, block proposer, then what would like the minor be getting?

SPEAKER 0
All right. So I understand where the confusion comes from, but when I say block proposer, it is the minor. Uh, I’m just, um, using this terminology because we, we say minor more in the case of proof of work. Um, we can keep using it for a proof of stake, but in proof of stake you would have validators in some systems or stake pools, and the more neutral term to use is like blog creator, blog proposer. So this would capture, yeah, either minors in proof of work or validators in proof of stake. But yes, it’s the same entity. OK, if there are no more questions on this part. Then, uh, I’ll continue with a brief introduction to Solidity, which is the uh high-level programming language that is used for writing smart smart contracts in Ethereum. Um, I will, uh, the slides have a lot of information. I might not go through all of it now, but you can also use as a reference later on or of course ask questions in CAASA and so on. Um, so, Uh, it’s quite similar, Solidity to other like high-level programming languages like JavaScript or even Python. You can see it’s documentation here, which is pretty good I would say. Um, so it will be helpful, especially for when you do your coursework. And a contract in solidity is similar to a class that you would have in an object-oriented language. And it’s a statically typed language, which means that types need to be declared. When you, when you create a variable, you need to say that this is, you know, an integer or this is a boolean and so on. Um, but then like most of the control structures are similar to other languages like conditions, loops, exception handling, and so on. Now, let’s start, as always with the Hello world program, um, and we can, we can take this line by line to see what it does. First, um, this pragma line, very solidity-specific, it’s always the first line of, uh, a program in solidity, and it specifies which compiler can be used, uh, to compile the program. Uh, and this says, the first one, for example, says to only use this version, uh, whereas the, the one with the current, uh it also allows to use future releases, uh, or you can specify specifically that you want to be greater than this or lower than this. So, there’s a lot of flexibility there. But typically you would use um the latest version. As it’s the only one that receives security updates. Uh, and then this is how a contract gets defined. You just write contract and the name of the contract. Uh, and then in the brackets, you’d have a constructor. Uh, which is the function that is run when the contract is created. So we could optionally in the constructor, uh, initialize some variables or do anything we might want the the contract state to be. And there are State variables in solidity that are persistently stored. Uh, in the contract storage. Uh, and there are also local variables that are used within fact functions and they’re accessed within the scope of the function. So, if you define a function and a variable inside a function, you obviously can’t use it outside of a function. These are like standard stuff. Uh, and then the arguments of the function are, uh, saved. Uh, are also local variables, uh, but they’re published on the ledger too. Now, um, as I said, Solidity is a typed language. So the type of each variable needs to be specified. And we have two broad categories, uh, value types and reference types. And Remember again. I will say this again later, but there is no such thing as null or undefined values in solidity. So, the moment you define a variable, it already has a value, which is a 0 or a 0 equivalent. Um Yes. And what are some value types that we have in solidity? There are boolean, standard types which can be true or false. Uh, then we have integers, uh, which can be signed or unsigned and you can also have like different size of integers. So if you know that it’s not going to be a large integer, you can, uh, specify to only use um. Like you went 8 or 16 or whatever, then it’s it’s in increments of 8, so that you save space. Uh, importantly, there is no such thing as floating point operations in solidity. So there are no floats, uh, all numbers in solidity are integers. There’s no such thing as 2.5. Uh, then a special type, uh, in this language is the address type. Uh, you don’t have them in other languages like Python or JavaScript, but obviously here it corresponds to Ethereum address. And if you declare it as payable, you can also send ether to it. To that Then we have a fixed size byte arrays, uh, that again you can have different sizes for, but you, you, it’s, it’s a fixed length. So when you specify it, if it’s bytes 32, it’s 32 bytes and you can’t change that afterwards. And you have inams uh which are special types like custom types that you can have um. You can use to enumerate uh objects or states basically. So in this example, we have uh a state of a purchase that can be created, blocked, or inactive. And you, you could then similarly here, like you have an in them for going left, right, or straight. You could do that just as well with, you know, an array of 0 12 or something like that, but it’s, it helps with readability. Uh, to have, um, this structure. Uh, and then there’s reference types like arrays, um, dynamic arrays, uh, which can be bytes or string, and you can allocate some memory to them, uh, when you compile and when you declare them. And you can also allocate extra memory using the, the new keyword. This is more similar to C C++ kind of approach. Uh, and. Yeah, not all of them. The point that’s made there, that denotation for declaring two-dimensional arrays is different from some other languages. Uh, but just for the declaration, not for the axis. Then we have mappings, which are key-value pairs. They’re basically like a hash map in Java or like a dictionary in Python. Uh, and importantly for mappings, you need to remember again that every value. Uh, is initialized to zero in fluidity. So, if for example, you have this, you declare this balances mapping. Um, and then you try to say balances of, you know, John or whatever, some address. Then this is not invalid. Like other languages would give you uh an error that is not defined or something like that. Here, this would already be zero. So, it’s like for every possible address, every possible key, there already is a value which is 0. So, you could even do things like increment it without having assigned anything to it. Uh, so you could just say balances of X, you know, plus 1, even if it’s the first time you’re using it. Uh, now structs are complex structures that can have different types of variables in them. Like this one has a bullion, and address, and an integer and all together they make the voters tract. Uh, and it can also contain mappings, but it cannot contain extract of the same type. And it extracts again you could use, you could do the same thing without extract, just keeping separate variables, but it helps keep the code cleaner and like not repeating yourself. These are some examples of struts again, where we have the voter or a funder. Or a campaign campaign where again it just includes um Different types of variables. Now, let’s talk a bit about uh visibility of functions and variables. In solidity. So There are some of it is quite similar to other languages. So when you declare a function as public, it means that it can be called from anywhere. And this includes, you know, the contract itself or other contracts uh that are using this contract or a um a user can call the function via transaction if it’s public. Um, and then. If it’s external, it’s same as public, but it cannot be used within the contract. So only Um, on the other contracts or through transactions, um, that that’s how external functions can be used and variables cannot be declared as external. Now, internal functions and variables can only be called internally, but when I say internally, it’s not just the contract itself. It’s the contract itself and any contracts that inherit from that contract. We’ll talk about inheritance in a minute. Um And finally, private functions and variables can only be called by the contract where they’re declared and not even by contracts that inherit from them. Um, you can also. Uh, declare a function as view, which is a function that doesn’t modify the state of the contract, or you can declare a function as pure, which means that it doesn’t modify, but it also doesn’t even read any state. Uh, you can declare a function as payable, which means that it can be used to accept ether. Uh, no, these are like we said before, but one thing that is very important to remember, um, is that when I say private, for example, that, you know, it can only be accessed through the contract. I mean that, you know, you can only update its value, for example, or you know, fetch that value through the contract, but it doesn’t mean that it’s Private in the sense of other people not knowing what the value is. Because these are still posted on the blockchain. So if a variable is declared as private, it means that another contract can’t use it. It can only be used in this contract, but it doesn’t mean that the value is not known to anyone, anyone and everyone that has access to the blockchain. Uh, so yeah, just something to keep in mind about the visibility of the functions that it’s different. It, it doesn’t mean you can’t know the values just because they’re private or internal and so on. Um, now in Harringtons. Oh yes, uh, in the previous slide we said they

SPEAKER 3
promised not to modify. Is there like a way that they will modify and an error will occur, or, uh, no, I mean, yeah,

SPEAKER 0
they will not compile. Like there will be an error if you declare it as pure, let’s say, and then it tries to modify the state. It, it’s not going to compile. Yeah. Yep, and, uh, yes, though it will make a bit more sense after we talk about this, so I’ll, I’ll explain it right after I talk about inheritance. Uh, so. As we said, contracts are similar to classes in object-oriented programming. Uh, so we can also have contracts inheriting from different contracts. Like if you have a contract of this contract animal, and then you have a contract frog, you can have the frog inheriting from the animal, so it has all the functions that the animal has plus any specific frog functions. Uh, and the, the way this is done is that you use the is keyword. So, in my example, you would say contract, frog is animal, and then you, you would write the contract as normal. Uh, and then the derived contracts. So these are the contracts that uh inherit from another contract. The frog in my example. They can access all uh functions and variables from the parent contract as long as they’re not private. So, if it’s public, if it’s external, if it’s internal, the derived contract can access it. But if it’s private, only the contract itself can access it. The contract animal, let’s say, can access it, but not the contract frog if it’s private. While if it’s internal, contract animal can access it, contract frog can access it, but no other contract that doesn’t inherit from animal like contract human would not be able to access it. Does that answer your question now? Good Um, and similar to other languages, we also have uh can overwrite functions so we have abstract contracts and interfaces. And, and this is just an example contract. Of, of having, you know, an interface of regulator and a contract that implements this interface. So we have, uh, and well, first we have the contract bank that implements the regulator interface and then we have the contract local bank that inherits from bank. Uh, and then we can see some examples here of What you can and can’t do again with the visibility that we discussed. So here we have the contract uh Jedi that has two functions, one of which is internal and the other is private. So if you have the contract human that inherits from Jedi. Uh, when you try to use the internal code, the compute force, this is fine because it inherits from that contract, so it’s OK. But if you try to use the uh function that is private, then this will throw an error. Uh, now if you have a completely different contract that doesn’t inherit from the Jedi contract, you also can’t use the internal function like this would throw an error. And let’s also briefly talk about Uh, different locations where you can store data. And mainly remember that storage is persistent, uh, so it stays in the miner’s computer, let’s say. So it’s more expensive. Whereas memory is allocated, uh, when the function is running. So, and it’s not persistent. So if the function runs, you have memory that’s allocated, but then when the function finishes, this memory is freed up again. So it costs less. Uh, and there’s a special location for uh function arguments that is called cold data and it’s temporary. Um, again, just some more details about the different types of memory. You can also read that at your own time. Uh, and in terms of reference rules, uh, I have here different combinations of assignments. For example, copying from storage to memory, uh, and so on. Hey, now let’s briefly talk about uh blogging. Uh, in smart contracts, which is done via events. So, there is a logging mechanism. Uh, and arguments are stored in the transaction log, and it’s a way to store data cheaply and to also communicate with other programs. For example, you can have some client software, let’s say JavaScript program that has listeners that wait for events to happen. And this is an example of that. Uh, the idea is that you write a contract that emits some events um upon something happening. So here, uh, when the function deposit is called, uh, an event is omitted that uh shows the sender and the value of the deposit. Uh, and then you can have uh some client software that watches for changes, watch listens for events, and then will use the results to do whatever. Like you can have a website or something. Uh, then Solidity also has these things called modifiers. Uh, which are basically ways to combine checks or name checks, let’s say so that you don’t repeat yourself. Uh, for example, here at this line that says require, message sender equals owner. In general, the required keyword is used instead of saying, you know, if the message sender is the owner, then do this, else do that. Required just says that. Um, if this is not the case, then reverse transaction fail. And you can have this kind of statements as modifiers. So here the only owner modifier has this requirement and then when you declare uh a function, you can say that if you are the only owner. Like here, the close has the only owner modifier. Uh, which means that at the very beginning of the function, this code will run to make sure that the sender is corresponds to the owner. Um, there are also some global units that are used in Ethereum like um ether units, for example, like way, G way, and so on. And I mean you can use that just write way and it has a meaning there. Uh, and there are also time units, like seconds, so you can write 2 seconds, uh, and so on. Um, and these are just some properties of blocks and transactions. So these are values that you can use within the contract, within a function. You can have access to the block’s timestamp, for example, uh, the center of the message, and so on. And there is also error handling like other languages that require statement is one I already mentioned. Uh, you can also have custom error objects, um, you use other functions like assert or revert. And there are uh also specific fields that relate to um address objects or contract objects. For example, uh the every address. Um, type variable is going to have a balance field or uh a transfer function and so on. Uh, now, one important thing to say before we close, um, is that Um, there a contract can have this fallback functions as we call them. Which are functions that are run when you don’t declare a specific function to run when sending a transaction. So if if you try to interact with the contract, but don’t specify which um which function you want to use, which function to run, then it’s the full function that is going to run. Uh, for example, this can be used, you know, if you have the receive fallback function, it can be used to accept ether. So it can be used to top up the contract, for example. Uh, and then there are different ways to, to send this like different functions that have their advantages and disadvantages. Uh, we’ll, we’ll talk about this again in the next lecture where, um, we talk about a type of attack called re-entrancing. Uh, but yes, it’s important to note the differences. And finally, uh, contracts can also interact with other contracts. So within Uh, the contract universe. You can create new planets which are uh another type of contracts. And that’s it. Uh, we’re done now. I will see you next week. But if you have any questions, feel free to come now.

Lecture 2:

SPEAKER 0
So, I’m going to, oh, wow. All right. OK. Um, OK. No, it looks fine actually, now. Yeah, let’s see. I don’t know, maybe it was one of those things. It was not ready. But Oh. Uh OK. That’s fine. I know how to fix that. Hopefully. OK. Um, Right, it’s blinking now in some way that I don’t like, but All right. So, I’m gonna pretend everything’s all right and this is lecture two of our um Uh, of blockchains and distribulate course and, um, so today we’re gonna spend a little bit of time on things about data structures. Related to distributed ledgers. And uh an important concept, uh, we’re gonna start thinking about is this broader concept of authenticated um uh data structures. So, Um, the So the basic tenet here is that we’re building a system where we say don’t trust. Uh, verify And And this is an important tenet to keep in mind in general when you design computer systems. So we’re talking about computer systems that have multiple components. And a distributed system is definitely one, so it’s. Um, uh, a system, right? So you have a lot of components, they want to interact with, with each other in some way. And um the idea is that you never take a component for for granted like the way it works. So you don’t wanna assume it’s doing the right thing. You wanna check, you wanna verify. So the other components are taking um are taking uh um. Any component that they they interact with and of course we we’re gonna be discussing this in the context of distributed systems, uh, nevertheless this is also important in the context of standalone systems because as you know standalone system is comprised of many different components. Right? And uh of course, you can take the um you can make the assumption that the components behave as expected, but as we’ve seen on and on, you know, practice says otherwise. It could be the case that. I mean, obviously components may be malfunctioning, so they don’t operate as expected, but even worse, it could be the case that components are um running some malicious code that makes them behave in a way that it’s even worse. It’s not, they’re not just failing, right? So failing is, well, you know, it’s one thing to fail, let’s say you, you call a function and you don’t, you don’t get the output because it’s not available or the component is not working. Um, or let’s say the network is cut off, so you don’t have, um, you’re not, you’re not listening, you’re not getting any, uh, any messages. OK? So that’s one type of fault, but, but even worse could be the case that you’re interacting with the component and it’s not giving you, it’s not running the code that you think it’s running. So Uh, blockchain systems are in a way the epitome of this logic, so don’t trust but verify. Everything has to be verified. Uh, no components is assumed to be trusted in any way. It’s exactly because blockchain systems are meant to operate in an environment where we don’t wanna make any assumption about the code that different computers that participate in the network are running. So, um, if you run a node and you’re part of the Bitcoin network. Um, then you want to verify. Um, basically, all the, all the input that you get from, from other nodes. Um, so, now to unders we’re not gonna dive directly to what Bitcoin does because um we’re gonna leave this for the second part of the lecture, but I’m gonna start with some simpler examples which are still quite useful, uh, and we’ll introduce you to this, uh, to this logic and I’m gonna start with this authenticated file storage problem. So, suppose you have a file with name F. And contents D, uh, and we have a, a, a client that is also, we’re gonna call it like a verifier and, and, and wants to store that file to the server. And the idea is that Uh, the, the file is stored in the server and after a certain time, uh, the client, uh, wants to receive the file back, right? So. That’s the, uh, that’s the general problem. And um the, the, there is like standard use cases here that I’m sure I mean this is a problem that you also, you know, faced and try to solve at some point and you have already maybe used exactly some type of solution like this either you don’t have enough storage or you want to use some external, uh, some external, um, uh, cloud storage. Um, or, um, or the issue is redundancy. So, uh, for example, you’re afraid that your device might fail. The storage device that you have might, uh, fail. So you want to have a backup, right? So for example, you’re writing your thesis and you wanna make sure that you have a, you have a copy of it. Um, so, the basic protocol, obviously, um, is a sort of straightforward one, like you, the client puts the, puts the file on the server and then, um, and then request it and, and, and receives it later, right? So, that’s, that’s the standard, standard file storage, uh, protocol. And obviously, What we’re interested in, given the introduction I gave is that we want to be able to say something meaningful about that setting here. So, what happens if the server is corrupted and returns a file which is not the same as the one that we stored originally. Um, now, I mean, there is a trivial obviously solution uh which is like the client keeps D, which is the contents of the file and then tries to make sure that the file is correct, um, but obviously that’s not, that’s not the solution we’re after, right? I mean, it works, at least narrowly speaking, but it’s not, it’s not solving the problem. I mean, after all, the idea was that, you know, we wanna use this extra storage so that we don’t have to worry about. Keeping the contents locally, so So this trivial solution doesn’t work. Now this brings us to this topic of authenticated data structure which is like regular data structures but are cryptographically authenticated and we’re gonna see an example of them, or at least two examples of them in the context of this. Um Um, of this, of this setting. So we would like to solve, to solve that, the problem here of um authenticated uh file storage with uh the key point being that we don’t want to trust the server. Now, I should say in this context, the client is also called the verifier and the server is called the, the prover. And we’re gonna provide 22 solutions to that problem, one using a hash function and the other using a digital signature scheme. Recall the discussion we had last time about these two cryptographic primitives. So what’s the solution about using a hash function? Uh, the solution using a hash function is that the client is going to compute the hash of D. It’s gonna store the hash locally and is going to, um, Uh, keep that, keep that hash. And when the server at some point returns D, which it’s, let’s say, the contents of the file, the, the, the client is going to check that the two hashes are the same. Observe now that the client cannot check whether D is equal to D, right? But, but the client can still check that D equals to D. Um, so, Yeah, so, hopefully that’s that’s straightforward. Um, we did have a conversation last time about the properties of hash functions and um hopefully just by looking at this, you have, you have an easy way to um. Um, sort of explain. Hey there. So, coming guys, late. Yeah. So, so hopefully, You do have a um a feeling like why, why this makes sense. Any So maybe I’ll ask this question directly. So do you have any suggestion like why, what property of the hash function here is relevant? To me suggesting this this protocol, yes. The 1 to 1 property, yeah, OK, um, it’s a good attempt, but to be clear, hash functions are not 1 to 1, unfortunately. Um, just think about it, hash function, the hash function takes anything and maps it to find it. Um, range. It’s actually a many to one function, so we cannot invoke a 1 to 1, a 1 to 1. Nevertheless, your intuition is not wrong, so I should point it out. So just think about this a bit more. Yes, I mean, if you change the file, you would

SPEAKER 2
have to change it in such a way that the hash function still returns the same hash value, right? Then you have a very limited amount of things you can change.

SPEAKER 0
OK. What is that? And so, so what would that amount to based on our conversation last time if you were able, as you say, to change it in a way that the hash value is the same. Any, any, um, sort of insights from our previous discussion, what would be such a thing? Two files hash into the same value. We discussed this last time, you remember something about birthdays and all that. So, what is that thing for a house function? What is it called? Collision, right. So, so that’s a collision and if we’re gonna use a hash function, um, cryptographic hash functions come with a property called collision resistance. Like basically this says it’s hard to find collisions, right? So, uh, if the server is able to confuse the client, they have found a collision against the hash function, something that we believe, um, I mean, provided the hash function is secure. Uh, we believe that that’s not happening. So, so this is a good, this is a good instantiation of this authenticated 5 storage problem and also it gives us this first data structure which is authenticated like basically the ability to. Uh, keeping a fingerprint now I’m gonna give you an alternative solution. Uh, that is using digital signatures and I, I would just like you to think a little bit about the difference between the two. So, digital signature, um, it goes like this. The client creates a verification key and a sign-in key. It computes uh a, the signature. Uh, of the, of the file. Of the contents of the file as well as the name, and then it deletes the the file and the signature. And, and when the server um returns the the the D, the client is going to verify that that this is um true, right? So the signature is correct. OK. So, the solution looks very similar, right? Very similar. So Oops, just wanna put them, uh oops, just next to each other. Do you see any Can someone say what’s the difference? So that’s the question for you now. Uh, what’s the difference between these two? There, there’s a difference. I mean, obviously there’s a difference. One uses hash function, the other uses this a signature, right? But that’s not the difference I’m after. Um, there is a more, um, sort of nuanced difference like, so, um, or a more salient difference like in the way that these two systems, um, these two systems, um. Work. So, there’s a, there’s a fundamental difference between the way that you would write this software. Um, if you were asked to write this, uh, in a client-server setting, there is a fundamental difference between those two. So, could someone um mention it, like, so maybe another flip, um, question is, or a flip related question is. Does digital signatures buy us buys us something, right? So, so here, yeah, I think the digital signatures uh

SPEAKER 1
flow is more of a verify verify like aspect of

SPEAKER 3
the thing where why the hash is like you trust that the, the hash that it’s coming from the server

SPEAKER 0
and then you’re compare. Uh, to be clear, you don’t trust on the left side. You don’t trust the hash coming from the server because you keep a version of the original hash, right? So there’s no trusting here. There’s no trusting that takes place, yeah. So as I see the digital signature-based way to like verifies the file.

SPEAKER 4
It’s more similar to having a public key and a private key.

SPEAKER 0
It is, yes, one is a hashba. There’s no public key private key. That’s a good observation, but. That still doesn’t say that that’s still, I mean, it’s a difference, but it’s a difference that says it’s more akin of saying the right-hand side use a diesel signature, the left hand side use a hash function. All right, I mean there’s a public here obviously on the, on the right because it’s a signature maybe like a better way to lead you into, into finding the salient differences like is the protocol on the right any better than the protocol on the left? Is it any better? Who wants to say yes. It’s more secure. So why is it more secure? Uh, because the digital, we have to find the key

SPEAKER 1
to hack it. I want to know the key before I.

SPEAKER 0
Well, um, I mean, Yeah, so I, I, I won’t, I, I mean. You can hack it. You can hack both of them or none, right? So they’re based on different assumptions, right? So the thing on the right is based on the fact that it’s hard to do a desal signature forgery. Uh, the thing on the left is based on that it’s hard to, um, find a collision against the hash function, um. Being more secure or not is not is not the difference. They’re, they’re secure under different assumptions. That’s correct, um, but that’s not again like the salient difference between the two, yes.

SPEAKER 5
In the hash base we are verifying like comparing the data and in the digital signature base we are also including the file with the data.

SPEAKER 0
Uh, alright, so, let me understand what you’re saying. Um, so you sort of say it again like it was a bit not clear, yeah, in the hash, yeah,

SPEAKER 5
we are only comparing the hashes you’re only comparing the

SPEAKER 0
hashes. That’s right. And here the signature we are including the file and

SPEAKER 5
the data together and verifying it.

SPEAKER 0
Yeah, that’s, that’s right, but it’s probably like a rather superficial difference. I mean, I’m, I’m writing this a little bit. You know, it’s pseudo code, right? I mean, obviously when you do this check. Where you get this value from, I mean, you, you do get it from, you know, it’s a stores HD. I mean, OK, I mean. If you were coding this, you would probably create a little table there that says for every file F I’m keeping the fingerprint, right? I mean it would have been, yeah, would have been appropriate to write this, but that’s not, I mean there’s no fundamental difference we do check yes I think by

SPEAKER 3
hash method there’s no need for clan to remember the key here. ah good so now we’re going somewhere so.

SPEAKER 0
It’s actually, but I would highlight this the client remembering is the key difference between those two, yes, you wanna say it better.

SPEAKER 6
Collision like always collisions like does it make it 1 to 1 happen instead of many to one.

SPEAKER 0
Uh, well, a collision resistant has function. It will behave like a 1 to 1. It’s not a 1 to 1 function, but let’s say for all practical purposes it behaves like a 1 to 1 function, right? So, so that’s why I said the original observation of 1 to 1 is not wrong. It is an intuition is right. But, but it’s a many to one function, right? So let me come to the difference. So the difference here, and, and that’s something good so to start building your intuition about this public key versus secret key and hash functions, etc. So in the left hand side, the client has to remember those hashes. In other words, if the client forgets the hashes. It’s gone, right? All the checking capability is gone. So on the left hand side you must have a table with all those hashes and keep updating it. So in other words, suppose the client wants to share, wants to upload to the server 1000 files, so it needs to have a database of 1000 hashes so he can do the checking, right? So that’s necessary on the left hand side. Now that’s not needed remarkably it’s not needed on the right hand side so the right hand side actually has the property that the client just needs to remember the public key, just that. And that’s the only thing he needs to check. It’s the same one value. So the state of the client is linear in the number of files that the client wants to store and constant on the right hand side. So that’s the difference between the two, right? If you want, uh, to, to highlight this and so I hope you see this as, you know, like why is it, you know, like the essential difference I was, I was looking after, right? So. Um, so, so it does buy you something, this, there’s a signature. So the thing that it buys you is that, and you can say like this is kind of a. Sort of remarkable property there is a similar thing that there’s this signature right? but, but the signature you can put it you can also outsource it. So you can also outsource the signature while here you cannot outsource the hash right because if you outsource the hash it’s gonna give you another hash right so. That’s the thing. All right, good. Um, so, that’s the difference. So, let’s, um, You know, jump a little bit further. Um, so, now we’re gonna go to a little bit more on the, on the same, on the same, on the same tangent but get a little bit more detailed. Uh, so we have a case where imagine the file is very big, but we only need a certain part of it, so let’s say just one bite. Suppose we want to only, so suppose like the the the file we’re storing is a big table and we only want row 100 of the table, right? So then it sounds a little bit inefficient to say uh OK so we start this huge table on the server then we’re gonna get like um I don’t know row 100 so it’s kind of uh we don’t wanna get the whole table back obviously so how do we do that? So there’s a very nice idea called Merkel trees. So, so, here is uh probably you’ve seen some of these definitions. Of trees in computer science. They are very popular data structures. There’s binary trees, full binary trees, complete binary trees. And what we will care about in this discussion is called a Merkel tree, which is an authenticated binary tree. It’s called the Merkel tree because the inventor of the Merkel tree is Ralph Merkel. Uh, a very important, uh, crypto um early cryptographer and, uh, and scientist that made a lot of developments in, in, in computer science. So, so what’s the idea? It’s, it’s not, it’s very simple once you, once you, um, figure it out, uh, or once you have been, um, shown how it works. You take the file, you split it in small chunks, like let’s say 1 kilobyte chunks, and then you are hashing every chunk. Individually, right, so you get all these hashes now observe that after you do that you do get quite a lot of hashes right? so you don’t wanna store those guys. You know, and it’s one of them. I mean, it’s like it’s not gonna, it’s not gonna, it’s gonna be too many hashes, but now you’re doing something smart. You are applying the same idea again you can think of it like applying it recursively but now on the hashes so now you do the. You’re sort of hashing the hashes and you do this. In pairs, so. So, this actually houses the number of hashes, right? So you have like 64 hashes, now you get 32 hashes. Without loss of generality now, or at least with some loss of generality, but nothing significant, let me just assume that The, the, the number of chunks we have is, is a power of 2, so I can do this division um on and on. So, so now you keep doing this. And of course if you keep doing this hashing uh pairs of consecutive uh hashes if you just go, you bubble up at the top and you’re gonna get just a single hash and that’s called the root of the Merkel tree. If you think about it as as a tree, you can think of it as the root is at the top and it’s hanging from from its root, right? and goes down. So, so that’s the that’s the miracle tree. Now, now why is this good? Well, um, the way we’re gonna use a Merkel Tree is that we, we send the data to the server and now the client will create the Merkel tree root. The myrtle tree and the myrtle tree root and is going to only store the myrtle tree root. OK. Uh, so with standard hash function this could be just 32 bytes. Um, now when the clients, uh, request a certain segment or chunk from the server, the server is gonna send that chunk, but also it’s going to send a proof of inclusion. So let’s see how a proof of inclusion works. So, the idea is that, let’s say in this small example, we have um um um a file with 8 segments and the client is interested in the 5th segment, the server responds with a with his version of the 5th segment, which is this capital E and we wanna check whether this is equal to the original, right? Um, so, so remember the client knows only the chop, the Merkel tree root. The server knows all the file. And observe because the Merkel tree is something that you can calculate. Uh, based on the hash function, the server can also calculate the whole Merkel tree, right, if, if it wants. So, so here is how the, the, uh, the, the server behaves. He wants to convince the client that this hash is correct. So what he does. is that he reveals to The clients, the node on the that’s marked red there, so the hash. Um, the hash of um the uh vertex in the tree which is next to capital E, that’s HF and then it also reveals this one, and then it also reveals this one. So Observe now. That what the client can do is like hash those two values to match this one and then hash those two values to match this one and then finally hash the red and the other value to match the Merkel tree root. So it’s like tracing the path from the root to the leaf that he’s interested in. To verify that it is correct. Um, the client only knows the root of the Merkel tree, nothing else, and he’s also presented by the server with a value E for which the client himself can calculate the hash value, right? And now the client can check whether this capital E is equal to the original little E, which is the fifth segment of the file, right, and. And this is the process that uh that does that. So, Repeats what I said. Now, the proof of inclusion is actually. All these red values that you see there, OK, that’s the proof of inclusion, OK? Um, so two questions now. The first one, why is this thing secure? Um, so this is not, this takes a little bit of time to. Um, consider and argue, uh, it’s not gonna be the focus of, of my lecture, but it’s something that I, I would welcome you, those that are interested to think about it. In other words, you can. Ask yourself the question. Could the server cheat on that protocol? It turns out that any server that can cheat a client and make a client accept a segment that is not correct. We’ll have to find again a collision against the has function. There’s no way to to cheat the client with this protocol. So that’s why this protocol is good, uh, from a security perspective. Um, the next question is whether this protocol is efficient. In other words, is this better than checking the whole. File from the client’s perspective, I mean. Remember, like, you know, the whole idea was that we wanted to make sure that the client doesn’t have to remember the whole file or something proportional to the whole file. So the good news is that now he only has to remember the milk tree root, but now he has to be presented also with this proof of inclusion. So now the question for you, how big is this proof of inclusion? If you start, let’s say with a file that has. 64 segments, let’s say, how, how big is that gonna be, um, that proof of inclusion. And you can say approximately. So we have 64 segments and you have to present all those hashes. Maybe another way to just simplify the question is like think about. The length of the size of the file is proportional to the leaves of this tree. Right? The length of the file is proportional to the number of leaves in that tree. Right? Because that’s how I’m building it. And thus the question is what is the relation between the number of leaves of a full binary tree to its height. Anybody, anybody knows that yes 2 to the OK, so n is the length of the right, good, yeah, you’re correct, yeah, so that’s perfect, um, a, a flip and a diff an equivalent way of saying what you just said is that if the file, let’s say is size. Let’s say D, then the length of the evidence is logarithmic in D. Which means it’s really much, much shorter, right? Um, so, in my, in my case, before 64, you would expect to have 6, size 6 being, being the, uh, the proof, right? That’s the logarithm of 64. So, that’s the good news. So this is why the Merkel tree is um is very popular in a lot of implementations and it’s also used very, very widely in the setting of um distributed ledgers as, as we will see. Um, so for instance, uh, BitTorrent uses Merkel trees to verify exchange files. Bitcoin uses Merkel trees to store transactions. Ethereum uses a variation of Merkel trees for both storage of contract state and transactions. So it’s a very, um, it’s a very widely used, uh, data structure, authenticated data structure in the context of, um, distributed systems and peer to peer systems. Um, Now frequently we don’t want to store a um we don’t want to store a um. A file, but we want to store what is known as a key value data structure. So, so essentially we have a set and every set has a label and we want to store as such a set. Now the, the good news is that um we can use the same idea but when you store a set what you’re interested in actually is usually two things. First of all, if you have stored a set of things you want to have a proof of membership to a set, but. It’s also quite important to all have a proof of non-inclusion in the set. Um, so. So that’s not something that we have seen so far, so we will see how we do that. So just to repeat here what we care about is that we have a set we want to store a set of elements then forget about it and then the server can convince us two things one, that let’s say a certain element belongs in the set, so he can give us, let’s say the 5th element and he can say that’s an element in the set so he can convince us about that. But we also want to be convinced that something does not belong in the set, right. So, so that’s what we’re gonna do. Luckily, um, we can repurpose a Merkel tree in a, in a very simple way, uh, to do this. So the verifier is gonna sort all the elements and it’s gonna create a Merkel tree on the sorted set. The proof of inclusion is exactly as the as the. Uh, as the myrtle tree, uh, in, uh, proof of inclusion, and now the proof of non-inclusion. Is the one that deserves a little bit of attention. So the proof of non-inclusion. Just to highlight a little bit, maybe I’ll, I’ll, I’ll show it to you with the diagram. It’s a little bit simpler. So observe what happens in the proof of inclusion. You have a certain element. That you want to prove that is is not in the set. The server wants to prove that, right, so the client says, what about X? Does it belong to the server or not? And The survey wants to say no it’s not in the set, so how does it do that? If it doesn’t belong in the set, observe. That There are 2 elements. In the set that’s sorted, right? So, so the, so the server has done this with a sorted, so he has sorted the set when he puts it in numerical tree, right? So there are two elements that one is strictly smaller and one which is strictly bigger than X, right? That’s because X is not in the list, right? So, basically, X is here. So what the server now can do is open. Those two elements. By doing a proof of inclusion. And demonstrate to the client that these two elements are adjacent in the Merkel tree, so if you follow the path in the Merkel tree, they are just adjacent in the list. And of course one is smaller and the other is bigger, so this demonstrates. That Uh, the element is not in the set, right? Does that make sense? So here is how um how this works. That’s a proof of non-inclusion. Any question? Yes, OK, so the set you’re talking about is like

SPEAKER 3
here an HC, for example, or no, it’s the all the HC.

SPEAKER 0
Say again, the, the set is, yeah, is a set of numbers or labels is anything we can we can sort basically, right?

SPEAKER 3
OK, so when we have, uh, like a case where we only have one element in this set, in this case, how can we.

SPEAKER 0
Well, I mean, If you have only one element in the set, I mean, to be clear, in that case, you, you, you can just show that element and show that it’s not the element the user wants, right? But that’s sort of um the same like logic of the miracle, yeah. We can, we can do, I mean, it’s a clearly that the gene is kind of like a somehow a, a case where, you know, only happens as a corner case. It has to be handled. For sure. But in that case if you only have one element you can just show that element and show that it’s not the element that the user is after, right? So because clearly what I said, it only makes sense once you have two elements like with one element it doesn’t make sense, yeah, yes, could you share more why

SPEAKER 4
it’s strictly true that there needs to be something smaller and greater than X in the set? I mean, maybe I’m misunderstanding what like the less or greater really means. Couldn’t there be, for example, in this case like. H I that is like ends up being bigger or the request is bigger than anything that’s being in the set.

SPEAKER 0
Fair point, yeah. That’s another corner case that that that deserves to be, has to be handled in that case, um. I suppose that corner case is what worries you, right? Not something else, and that’s a very good question. Um, in that case, if the element turns out to be bigger than all the elements in the set, what you can do or what, what the server will do is open the rightmost element in the set and then show that it’s smaller. So because there is a rightmost element in that set.

SPEAKER 4
How would you verify then that it is the rightmost element?

SPEAKER 0
Uh, good point. Um. It’s your question is also the same. How do you verify actually that these two are consecutive, right? So the thing is that the Merkel tree has a very strict structure. So the rightmost set, maybe I, I’ll just demonstrate in the case of a full tree. So I can show you that this element is the rightmost one by opening those two, those two values and you are hashing. This guy with this guy to get this and this guy with this guy to get that. So observe you’re hashing from the right and you go to the top from this side. The reason is that when you verify something in the miracle tree, you’re literally walking along the path of the tree, so you realize you have to know where you are in the tree to do the calculation, so you know you are in the right most. Does that, does that make sense? I in the same way you will know, let’s say these two are consecutive because I’m gonna open, let’s say this guy and you’re gonna do has get this one and then I’m gonna open this guy so you’re gonna have, so you will trace those paths. You always know which path you are verifying when you are in a Merkel tree. Does that, does that help? Yeah. Yeah, can I ask one? Yeah, sure, maybe I’m misunderstanding some piece here too, but

SPEAKER 4
if I, the verifier, only know the root, most of the tree, and let’s say I do that whole walk, and at the end of the walk I compare the two and I say, shoot, these don’t match. Something went wrong, how do I know where in that process it went wrong, meaning in this. In this case it would make sense that I have to know where I am because I, I have to keep going through that process. But if I only know that I’ve messed up or that something is misaligned at the very end of the process because the final, uh, hashes don’t match, then how do I know that it was at this route, which means that I was in misplaced versus somewhere else along the path?

SPEAKER 0
Yeah, perhaps let me say this that maybe it will help clarify when the when the server makes an assertion. Essentially he tells you that’s the path you should follow, so basically he tells you the path. In other words, part of his assertion is not just that’s a bunch of hashes. It makes a specific assertion saying these are the bunch of hashes along that path. There’s no way for you to process an assertion from the server without also the location on the Merkel tree, and the reason is if we go back to the definition of of the Merkel tree is that um. Um, if, if you see here, um, the, the hashing is done taking the order into account. So, so to get the hash at this level I’m hashing first the left and then the right. So you do need the information which path you’re following so you can get the order correctly. So in other words if I give you this value and this value. You’re gonna hash this value first, you’re gonna get there and now you say I know the left and I just calculated the right, so I’m gonna put it together and I calculate the next task. This means that you literally follow the path, a a very specific path, right? So, so the server essentially gives you um. Gives you the, the map, let’s say, of which path to follow on the Merkel tree and it’s either, either you’re gonna accept that and by accepting that you also accept um things like adjacency and right most and left most or you’re gonna reject, right? Does that, does that make sense? Yeah. OK. um, so. So thanks for this, for these good questions and Let me. Now, come to um just a variation, just to finish our conversation here. So, so, this is also called a tree um and uh but the, the, the formal way we call this thing is, is a radix or a prefix tree and it’s a variation of what I said so far. With the main difference being that this applies to a key value um uh store. So, a key value store is basically um a data structure where every object has a key and then when you wanna retrieve something, you give the key and you get the value, right? So, so that’s that. Uh, so, we want an authenticated, um, version of this and this is called the tree. And I’m going to just to give the example directly. I mean this says this with many details, but It’s going to show you how it looks. So this is an example of such um. Uh, of such a, of such a tree. Um, and the main difference with the Merkel tree is that, I mean, Merkel trees were binary trees, right? So you just go left and, and, and right based on. So, you can think left is 0 and right is 1, and, and now, if you think that left is 0 and right is 1, now this is just a generalization, right? So, every, every node can have as many children as the symbols of the alphabet that you care about and, and that’s how it looks. Um, so, why this gives you a key value store is that The labels along the path is the key and the value is what you find at the leaf, OK? So, if I give you a key. Um Now you can just follow the right path, right? And, and you find yourself at the leaf, um, which will give you the value, right? So, so for example, here you have the value DX which gives you the, so you, you have the key DAX which is gives you the value too or The houses, which gives you the value 6. And observe that you can there’s also called prefix 3 because you can have also values in intermediate right? because I don’t know both house and houses. Exists in the key value store, so you can have a note that behaves like this. So, um, and, and what is sometimes called not the prefix tree, but the patricia or radix tree is, is the same thing as the one I just showed you. Um, so, a, a, a, a radix tree is, is basically something like this, and then some a patricia tree is sort of like an optimized version of this. Where um we allow the um edges in the tree to be arbitrary strings, right? So, I mean, as opposed to just, it’s just a straightforward generalization, right? So, but otherwise it looks the same. So, here is again the example uh if we have all these values, so you have this particular key value store, so this is uh a Patricia tree um that uh implements that. So, so far, everything I told you here in the last minute is data structures, right? So, basic data structures, um. And, but now we can get an authenticated version of that, which is what happens in Ethereum, for instance. So Ethereum implements a Merkel Patricia tree. And, and that’s the way, um, basically all transactions and contract smart contract state is, is stored in Ethereum. To be clear, like to use Ethereum, you don’t need necessarily to know, you know, exactly all the details like of how this works, right? So I’m just telling you now how this, how the information is organized. Uh, in, in the system, so they use this. Uh, this, this way that’s, uh, to organize the information. Now a key point is that we do have a proof of inclusion, a proof of non-inclusion. And I’m just gonna. Perhaps finish here by just highlighting a little bit how, how it looks in the case of Ethereum. So this is you can think of it like the glorified version of, of this Merkel tree idea that we were discussing so far. Uh, so you have like 3 types of nodes branch nodes, extension nodes, and leaf nodes. Uh, lymph nodes, um, they have, uh, you can see value, so they store, um, coins. So these are the lymph nodes and um. And you can see now on the upper right hand side of that picture you can see the key value store. So the key value store has 4 keys. And 4 values, and now you can see how this information is organized in the case of Ethereum. So, it just follows this Patriciare logic, um, but it organizes it in the form of uh branch nodes and and extension nodes. Um, so, if you wanna follow, let’s say, one particular, let’s actually try to follow, let’s say the third one, which is A 7. Um, A 7 F 9365, we start from the root. And this is what’s called shared nibble is basically all the keys start with A7, so that’s why we have this here. OK, so we say A7, good. Now, we follow the next node um pointer, and this gives us uh brings us to a branch node. So, now, we are looking for the third one, right? A 7F. In a branch node, we have a bunch of links and we want F, right? So, this brings us to this leaf node and now we check 9365, which is what we have here, and that’s the 1.1, that’s the value of the key value store, right? Does it make sense? So it’s just a generalization of um of this data structure that um we talked about. OK, so that was all about authenticated data structure, how information is organized in these systems. In the next segment, we, we’re gonna go more, um, uh, a little bit, a bit level up and see how all this information comes together in the context of a blockchain system. So 10 minute break.

SPEAKER 1
the Any questions Mhm Hi, yeah, um, I sent you

SPEAKER 3
an email. Yeah, um, oops.

SPEAKER 1
All right. it’s. OK. So, So, let’s get uh uh now to the second

SPEAKER 0
segment, people. Where, uh, I’ll, I’ll tell you how all these things uh fit the storyline. Of um blockchain protocols and distributed ledgers. So first of all, uh, the first important thing is we’re going to define what is a blockchain. So, you hear about blockchain quite, quite a lot. So, a blockchain is, is a is a is a data structure itself um that is actually a a hash chain. So, every object is a chain, um, you can think of it as a linked list, um, but the links are provided via hash functions. So, so it has this authenticated, um, aspect to it. Uh, the reference is, uh, every block refers to the previous block by hash function. And um Beyond those links, every block contained a list of transactions. Uh, the blockchain, in other words, this hash chain, uh, goes all the way back to an initial block. Which is assumed to be known by all participants, so. That’s kind of a setup assumption for the whole system. So, there is one block that all participants know and it’s essentially hard coded in the software. OK, and that’s sometimes it’s called the Genesis block. In principle, and you know, it has happened also that people are hard coding later elements of uh of a blockchain uh into the software, but we’re gonna come to this at a later time. So for now you can say uh the software of the blockchain has this Genesis block, this is this is hard coded in the software, every, every instance of the software knows it, but other than that you have this linked list and um and inside every. Um, inside every node of that list, you have this structure called the block. A block points to the previous block via a hash function, so it contains the hash of the previous block and it also contains a list of transactions, uh, in a form that we will see in a moment. Now, uh, in a, in a little bit more detail, uh, every block has, you can think of it in a, in a simple way, having it as a um Uh, these three basic, basic elements is, is, uh, the first one is called the nonce, um, sometimes also counter denoted by CTR there. There’s some data and then there’s some references. So, the reference is the hash of the previous block, X is the data, and then every block should also satisfy a certain validity condition, um, which now this becomes unique, let’s say, in the case of, of the Bitcoin blockchain. So this validity condition. Um, sometimes. Or usually it’s also referred to as proof of work. And, and the validity condition is uh is basically this relation that you see here that if you take the hash of the block values, the counter, the X value, and S. Uh, and you hash them all together, this is gonna be below some protocol parameter T which is also known as the target. So, CTR is the nonce and um and the value of this hash sometimes is also referred to as the block ID. One reason that CTR has this notation. Uh, is that, uh, miners try to find a solution to this inequality by incrementing this CTR value, um, so that’s why sometimes it’s also, um, called as the counter. So it’s basically, uh, starts from zero and goes up to, up to a certain, uh, up to a certain upper bound, let’s say 232 minus 1, so it’s like a 32 bit register. Uh, this is called the proof of work step, which we mentioned briefly last time. And, um, and that’s needed in order for a block to be valid. So, a block is distributed um as long as it satisfies that condition. So, this gives us, uh, enables us to do another now description of uh how Bitcoin works at a high level. But a slightly less high level than last time. So new transactions are broadcast to all nodes. Every node collects new transactions and puts them in a block data structure. Every node tries to find this proof of work by. You know, playing with this nons value, the counter. When they find the proof of work, they broadcast the block to all the other nodes and nodes accept the block only if all transactions are valid. And if not already spent. I will explain in a bit more detail how what that means. Um, notes express their acceptance of a block now by incorporating that block into their local state and then trying to extend that block, right? So, so these are like the pages of the book that I was talking about. Uh, the last time. So, so, the whole protocol basically just follows that logic, is, is fairly simple. Um, so, it’s very simple what, um, what every node is, is doing. Now, Let’s come a little bit now to the concept of uh transactions, basically this uh item number 5 which says there because that’s the part we haven’t discussed yet. So, and this is a little bit what is the main application of Bitcoin, uh, which is doing this, um, you know, transfers of value. So. We call a digital signature, uh, so, 3 algorithms as we described last time, key generation, signature, and verify. Key generation produces verification key and sign-in key. The signing algorithm gives the sign-in key and the message produces a signature, and the verification algorithm takes the verification key and the message signature pair and says whether that that is true or false. By true, meaning that the signature is accepted and false that it’s not accepted. Um, so, as I said already, the, uh, first, uh, block of uh blockchain is called the Genesis block, and now this is how, now we’re gonna make transactions on the Bitcoin. Blockchain. So, let’s take two parties, let’s say Alice on the right and Bob on the left. And, um, let’s see how these parties can exchange, uh, can, uh, can transfer value. So The address of a party is defined as the hash of the republic. So, so, the address of Bob is the hash of a public key and another public key of Alice, if you hash it, that’s your address. Now, observe that there is no authority here that says Alice has this public key and Bob has this other public key, right? So, these public keys are just selected by the parties themselves, right? How, how, how they are selected, they are selected by just running this key generation algorithm, right? OK. So, so, let’s now take, um, you know, somehow the operation from the middle, let’s say. Um, we will come later on to explain how, how the thing is populated at the beginning, but let’s take it from the middle. Suppose there is a bunch of transactions on the blockchain and there is a certain transaction, let’s say transaction 8 at this block that says Bob. Or specifically address B which belongs to Bob has 50 Bitcoin and, and, and now that’s something that Bob wants to. Um, transfer. So, how does it work? Bob prepares a message which effectively Says something like this, I want to give 50 bitcoins to address A. And then signs that message. With his secret key. So that’s now a signature with the secret key of Bob on that message, OK? And, and now Bob prepares this message together with the sec with the secret key and you can think of it as another transaction which is to be posted in, in, in the ledger. So, let’s say that’s transaction 11, there’s other transactions which are posted, right? Concurrently, possibly, and this goes to the next block, OK? So, um, so now, Um, Alice can look out for that, for the inclusion of this transaction 11 into the blockchain, which basically says that the 50 Bitcoin which once belonged to address B, now they’re transferred to her, to her address, address A, OK? So, that’s, that’s the high-level idea. um, and now I’m just gonna say it again, but in a little bit more detail. Yes, please.

SPEAKER 1
I like a certain number of transactions that can be held within. Wow.

SPEAKER 0
Is there an upper bound? Yes, yes, there is an upper bound. Um and um actually, that’s a very important consideration um in the context of of the protocol. And um Um, and it’s also a major limitation as well. So, so, it turns out that Bitcoin cannot really handle too many transactions. Um, in, in, in every block. And furthermore, Um, because blocks are produced themselves at a specified rate, let’s say in expectation of 10 minutes, you get a block, this gives you a certain number of transactions per second or per unit of time that, that the system can process. And unfortunately that number is pretty low, so let’s say below 10. Transactions per second or or or something of that, of that order. So, so this suggests a major limitation of the Bitcoin blockchain and, and one that has brought a number of developments as well as is a big chapter of this area in general, like how do you scale those systems to Larger number of transactions. Yes, please.

SPEAKER 1
Mhm. It is slide. By which like Alice would go looking for transaction 11 depending on whether the transaction made it into the same block as the I guess like the message like how, how does basically how does Alice know where to look for the transaction that you know Bob has sent from the.

SPEAKER 0
Very good question. So, um, We want to avoid necessarily Alice being, you know, she can download the whole. Blockchain, right? And, and verify. Um, so that’s one option, but we want to give her more efficient options to do that and actually, I mean, if you bear with me, I let’s leave it, I’ll say we will use this Merkelre structures to, to create opportunities for Alice to verify that a certain transaction is included. Um, without downloading, um, the whole set of transactions to

SPEAKER 1
go for it.

SPEAKER 0
Or if she has to go looking for it. Um Well, by go looking for it, meaning asking, well, it depends what what Alice is running, but presumably, Alice could ask a node that looks at the whole blockchain. To convince her that, that that transaction is included, so she has to go looking for it. Um, what she has is basically a transaction ID, so she has an identifier for that transaction. So, this transaction identifier is going to be already determined by this process. It’s not, it’s not explicitly. Perhaps mentioned here, but you can think of just this messages and signature pair determining it, a transaction. I’m not telling the whole story here, it’s a little bit simplified, but you can think of this as a transaction identifier being defined. And Alice will have this transaction identifier and can go look for it. Yeah. More questions? That, yes, uh, is there something like waiting list for

SPEAKER 3
translation?

SPEAKER 0
Is a is a waiting list, yeah, because for example,

SPEAKER 3
uh, one block is full in one moment, and, but I, for example, me to make a new transation, is there anything like waiting list?

SPEAKER 0
There is, yes, so, um, now. What’s happening? So, maybe to, to say the easy case first. When the system is not congested, then there’s no waiting, so you can just transmit your transaction and The miners, the nodes that are running the software are just gonna pick it up and put it in a block and, well, you’re gonna see it in the next block. That’s the nice case where the system is not congested. I mean it’s not my intention now. I have to say this conversation is a little bit more advanced for where we are right now, but I’m just gonna say very quickly that what’s gonna happen is that when your transaction is not when the system is congested. It is most one possibility is that your transaction is gonna be sitting in what’s called the mempool, that’s the term technology used in Bitcoin, so it’s basically memory of minors for things that are pending. And they’re gonna try to put it in a block when they can. Now, this comes with, with a little bit of drama, again, looking ahead. By the fact that they don’t have, they, they don’t have to follow a first in, first out type of logic. In fact, the Bitcoin blockchain is designed in a sort of an auction. Where transaction issuers can. Pay the miners to put their transaction ahead. So I’m gonna come to a bit later how this works, but the key point is that. It’s a, it’s a process and you can try to get, let’s say, ahead of the. Ahead of the queue by paying extra, yes, does that mean technically you could try mining a new block by

SPEAKER 2
picking transactions that help you? Get your proof of work done easier?

SPEAKER 0
Well. It would be nice if that was possible, but proof of work is not affected by in any way that we understand is not affected by the inputs that we give to the blog, so you’re not gonna get an advantage by you putting some transactions over others. Essentially this hash function then that this inequality you try to solve comes and destroys the structure, but a minor could. Revise the set of transactions that they attempt to put in a blog and find proof of work in a way that suits them so that’s true so they’re not gonna gain an advantage but they can easily kick let’s say out your transaction because they see another transaction that that is. Pref that is of their preference because let’s say he pays them more, right? So. Um, so, um, but, let, let’s say, let’s not think of the system as congestion because it’s a little bit more advanced. Uh, it’s, it’s, let’s try just to understand it at the non-congested setting. Um, so, so, in the terminology of, of Bitcoin, um, the Um Transaction in, in the case of Bitcoin, um, basically spends what is called unspent transaction output. So, every transaction, it’s like it has inputs and outputs. So, for a transaction to be valid, it should um receive some inputs and then produce some outputs. The outputs that a transaction produces is called unspent transaction outputs or UTXOs, um. So, that’s the terminology. And so, every transaction you can think of it, getting some inputs. And generating some outputs, right? So, so that the these are the inputs. And these are the outputs. The outputs are called UTXOs. And, and that’s every transaction, right? So, so, for a transaction to be valid, it should come on top of another transaction and basically, or multiple other transactions and spend them, right? So, these are UTXOs of previous transactions. Which are spent by this transaction and um And then that that’s basically the the the way, the way it looks. Um, Now In my example, I, it was a little bit more simplistic because there was only one output that we were spending, that was the 50 Bitcoin of Bob, that would be moving to becoming 50 Bitcoin of Alice. But of course this was a very simple example. Um, in most cases, for instance, if, um, let’s say, um. Bob has 50 Bitcoin, it could be the case that he wants to transfer, let’s say, 10 Bitcoins to, let’s say, Alice, and that creates this UTXO and then he keeps another 40 to himself. So, the way this works for Bitcoin is that he completely spends this UTXO, the 50 Bitcoins that he has, he sends 10 Bitcoins to Alice, which creates a UTXO now that Alice can spend. And then creates another UTXO which has 40 Bitcoin and that’s for himself, right? So this is basically the change. So, Bitcoin follows this UTXR logic which maybe at first you might find it a little bit different from the way you’re thinking about um um transactions and it’s not an account-based like your bank account. It’s not an account-based, um, it’s sometimes is called the UTXO based model, yeah, yes. So So imagine perhaps the best way for me to uh to give you a quick reference to this is that imagine that in your bank, you create a new account every time you make a transaction. You just you just make a new account, you have an account, right, in your bank. So every time you make a transaction, you create a new account or you can create as many accounts as you want. So, so here is an account that has 50 Bitcoin, so we call this account the UTXO. And then you make a transaction and 10 go now to the account of Alice and 40 go to your new account. Again, your account, right? So, so that’s all, it’s not um it basically, this says that every transaction is pushed forward, uh all balances are pushed forward, right? There’s nothing that that remains um in the, in the, in the, in the in the in the previous um

SPEAKER 5
address. So, uh, mhm, uh, supposedly Bob wants to translate the entirety of 50, uh, bitcoins to Alice.

SPEAKER 0
So over there it wouldn’t, it wouldn’t exist. This wouldn’t exist. 50. Yes, exactly. This, this segment would not exist at all, right? Of course. And, or if he wants to send to multiple people, he could also send to multiple people, right. Also, it could be the case that he doesn’t have 50 Bitcoin himself, he, I mean in one UT, so maybe he has 20 here and 30 here, right? So he has to combine them, right? So that’s also possible. What is important for these inputs and outputs is that 50 Bitcoin go in, 50 Bitcoin go up, right? That’s somehow The cartoon somehow property here that we want. Yes.

SPEAKER 1
Council. built Yes, OK, so he’s like wouldn’t be allowed to,

SPEAKER 0
no, you know, just send, send if he only has

SPEAKER 1
20, he wouldn’t be allowed to send, absolutely, yeah, so

SPEAKER 0
basically. If it goes in a block, it has to satisfy this preservation of value, right like you know.

SPEAKER 1
You know, sending Alice 10 and keeping 40 for himself and What we’re saying is like a new bank account kind of what happens to the old bank account? Does it like stay? Does it, is it just like recorded for posterity in that previous, and now everything, every future quote unquote transaction refers to this new.

SPEAKER 0
Yes, so, it can stay as a, as a trace of what happened. Um, but it’s not active in some way.

SPEAKER 1
But does it have to, like if he. And making transactions like say he says that he wants to give Alice 10 and get and. 30 for himself and then that leaves. Like Unaccounted for that’s not possible. That’s not so it has to like add up to the amount that he’s actually exactly right.

SPEAKER 0
So balance is pushed forward necessarily. Um There’s no nothing that’s left behind. OK, so, in a little bit more detail just to include some terminology, uh, in the inputs, um, you have this information which is called a script syn, so that’s what you have to present to spend an output, that’s just Bitcoin technology, and then you have a script pad key, which is what creates a UTXO. The choice of these terms now is just specific to Bitcoin, right? Um, I mean, we, I will give you the examples of what they are, so, they’re very specific. So, Bitcoin transactions are based on a, on a simple script language. So, it’s like a small programming language that, that is, is evaluated using um a stack. Um, so, a script sync, which is what you need in order to, um, Send the UTXO. It’s a signature and a public key. So that’s what you present in in order to um uh spend the UTXO and now to create a UTXO or to create an account you write something like what you see at the bottom here a script pub key. This is like a little program. So, that’s the definition of an account, by the way, for Bitcoin. So, so, a Bitcoin account, let’s say, is such a little program. What you see there is some data like the pub key hash, which is the hash of the public key, that’s the address A, address being my previous example, and, and, and what you see the rest of the little funny things that you see. Um, are script Bitcoin script instructions. It’s basically a program that you have to execute and only if this program. Accepts is a program that either accepts or rejects it outputs one bit, true false, let’s say. So if this program accepts you can spend the UTXO. So, so sort of the logic here is that when you, when you look at this UTXOs, you can think of the state of the ledger as a bunch of UTXOs. That’s the state of the distributed ledger and every UTXO is a little program. That if you know a value that can satisfy that program, you can spend it, you can spend the account, right? So, it’s like you have um Like a bunch of little programs with money, with wallets. And if you know an input that makes the program say yes, you get the money. Um, that the program holds in its purse. So, that’s how you can think about it, right? So, every transaction presents those um those um inputs that are spent, uh, spent those, those programs. Um, and, and that’s an actual example, right? So if you just go to the Bitcoin blocks and you will see things like this, right? So, uh, a pre a a transaction basically has always, as I said, the script seed which spends a UTXO and a script pub key which creates a new UTXO. And the big numbers, the big sequences you see there, they are the um the signatures, the public keys, and the hashes, right? So, these are the big strings there that make no sense, right? So, these are the We’re not diving any deeper in what these things, why these things look the way they look like, right? So, so for example, that’s a hash, that’s a hash value. I mean it looks like this because it’s defined by specific hash function and so forth, right? So. Um, OK. So, so, how do you do the transaction verification? Um, oops. So, so, the transaction verification, sort of at, at the high level, what’s important is, is basically verifying that, that signature um and um. Later on, if we have the time, I’m going to give you a specific. Execution trace of how do these things actually are, are verified. So, how do you run Bitcoin script. But in general, it does something fairly straightforward. That particular Bitcoin script, the main thing that it does is that it takes the public key, hashs it, and then runs the signature verification to make sure it is valid. So, that’s what it does. So, um, so that’s the whole, that’s the whole idea. So, as I mentioned, um, financial data is encoded in the form of um of transactions. And uh every block organizes transactions in an authenticated data structure. And in the case of Bitcoin, uh, so, this is the, the Bitcoin, um, um, we have a Merkel tree, in the case of Ethereum is the Merkel Patricia tree. And every transaction is sent um on the network to everyone else um via uh a gossip protocol. So, now I’m gonna come to this uh in, in a moment. But the key question that’s already highlighted in some of the conversations we had already is that um it’s not necessary now to download the entire block, the header of transactions, uh, the header of transactions in order to verify whether a transaction is included in it. And that’s because all transactions are stored in, in, in the form of, of a, of a Merkel tree. So, so, every transaction So, if you look at the blog, The transactions on, on the block. are stored in a Merkel tree. So if you have a particular transaction that you care about, you can just Uh, someone can just present to you, um, the particular transaction you want with the proof back to the Merkel tree root. OK. I will, I will explain this maybe in a, in a little bit more detail just to make the connection. Um, so, so what you have in a, in a, in the, in the case of the, maybe I’ll put, I put the arrows backwards. So, this is what is the blockchain, sequence of blocks, and now, you can think of every block, you have this little tree. So, that’s how, that’s how it looks. It’s like a, it’s like a chain of trees, OK? And here you have one transaction, OK? So, what, what is one transaction? One transaction is, is like a, a little, um, you can refer to that picture, you can think of this as a As a little segment that is going to be spending some create some UT exhaust. And then it’s spending some UTXOs. So for a transaction to be valid, It has to spend some UTXOs that exist, right? So, that’s how it looks in general, in, in the case of, of Bitcoin. Right? So, you have a transaction here. That creates some UTXOs. These are new accounts, and this transaction goes back and spends some UTXOs of other transactions and so forth, OK? So, so that’s how it looks, yes, what about the

SPEAKER 5
Genesis.

SPEAKER 0
What is on the Genesis block? Very good. So, OK, maybe I’ll collect some questions about this. So, the first question is Well, if this goes back, I mean, where does it stop? Or, I mean, this is equivalent to asking the question, where do Bitcoin come from? Do they come from the sky? Um, that’s a very good question. So there must be also. Some source of those Bitcoins, right? So, where did Bob found this 50 Bitcoins to give to Alice? OK. So, so, let me explain that. Then first. Now. Every block, you remember our discussion last time we said miners or maintainers, they run the blockchain protocol because they’re incentivized to do so they’re incentivized because they receive coins. So when a block is created, A special, I have this in a, in an upcoming slide, but it doesn’t matter. I’ll just say it now. There is a special transaction called a Coinbase. Um, and this is a transaction that creates Bitcoin. This transaction. It’s special because it only has Outputs. It doesn’t have inputs. OK. And, and that solves this, the question, right? So, if you have to go back, you know, where do you stop, right? So, basically, you, everything eventually goes back to some coin-based transaction. Um, yes.

SPEAKER 7
So whenever a new blog is mined. Uh, the, the rewards for the miners comes from new Bitcoin that’s minted during the plug. It’s not existing Bitcoin.

SPEAKER 0
It’s not, well, I mean, it is also a little bit existing Bitcoin. I didn’t wanna go there now, but you can get some extra fees from the transactions themselves.

SPEAKER 7
That’s the gas fees.

SPEAKER 0
Well, Bitcoin doesn’t have gas fees, but yeah, it’s similar to gas fees. Yes.

SPEAKER 7
So essentially every new block that happens, there’s a new coin based, uh. Program that’s run that makes new bitcoin for the miners

SPEAKER 0
exactly and to be clear, it, it gives those bitcoin to the miner that produces the block it’s just one miner, of course it’s up to the miner. To write this transaction. Uh, but of course the norm is that the miner creates this coin-based transaction with the UTI so that he himself can spend, right, uh, because they want that, yes.

SPEAKER 4
If I’m Alice and I’m going into the block to go verify the transaction through the through the tree, yeah, do I, you had mentioned before that, uh, as an artifact of the transaction being initiated, there’s some transaction identifier. Is that the equivalent of what we looked at when we were just talking about the trees of like that’s my, that’s my X that I’m choosing to I’m looking to verify or not.

SPEAKER 0
Yes, that’s the X.

SPEAKER 4
Is that the same information as the actual like bite of information of the transaction itself?

SPEAKER 0
It’s like a hash. It’s like a hash of the transaction. It is a hash of the transaction, to be, to be clear. So, yeah, but basically a hash is like effectively the transaction itself, right? Now, um, yes, OK, we said that the, uh, the

SPEAKER 3
base is created at the creation of a new block, right? So there’s no way UTXOs can be linked between different blocks.

SPEAKER 0
No, no, they, they, they do link across different blocks, right? As I also show in this picture. So, I have a transaction here that, that, that spans some UTXOs from the previous blog and, and this spans some UTXO from previous or even far in the past blog. So, you can go. As far in the past as, as you want. Um, yeah, yes.

SPEAKER 1
When it comes to the creation of the coinbase, is that something that’s automatically generated once the, the block?

SPEAKER 0
It’s part of the validity. It’s part of the validity conditions of what the block is. It should have such a transaction. So it’s created. It’s created with, with the block, yeah.

SPEAKER 1
How does the system determine like how much a block is worth at least good question was that once the block is created, part of that incentive is that the Bitcoins generated by this coin-based transaction then goes to that minor yeah.

SPEAKER 0
So how is determined how much or yeah yeah so there is a schedule um every block has an index let’s say Genesis is 0, that’s 1, that’s 2. So if you are doing the second block, which you know, right, because. When this block is mined, is, is building on this block. So, so, if this is 1, that’s 2, let’s say. Then, then there’s a schedule that says block 2 should produce that much. Bitcoin. So, there is, that’s in another, to put it differently, that’s part of the validity rules of the protocol. So, I will only accept block two if it’s minted. 50 Bitcoin, let’s say. It has to be 50 Bitcoin. It’s part of the code, let’s say, and the validity, and the block validity condition. Does that Does that?

SPEAKER 1
is it Council Yeah.

SPEAKER 0
Why is it 50 is a very good question. Um, the answer is 50 though. Because Satoshi Nakamoto, who designed the Bitcoin blockchain, thought that 50 is, is the number he wants to start with. It’s an arbitrary thing. I mean, of course you could, you could say, I mean, in, I mean, to be clear. If you sum them up all together and you do a little calculation, which again is, is an upcoming slide, but I’m not rushing forward now to this, it turns out that the total number of Bitcoin ever to be produced is gonna be about 21 million. So, so it started with 50. I mean, it’s not clear if it, I mean, I, I don’t suppose that 50 is anything magical about it. But I think what is part of the intention of the designer here is that they want to define its supply. And for whatever reason, they wanted this supply to be about that many million. And, and furthermore, the supply, I mean, going this 21 million. Was meant to be decreasing over time, so about every four years, this, this number changes. So, originally it was 50, then it became 25, then 12, 12.5. Um, then 6.25 and, and so forth, right? So, so these are also the so-called Bitcoin housing events that a lot of people in the investor, Bitcoin, some cryptocurrency investor community consider as important events. Why they consider the important events is that they affect the supply of of Bitcoin, right? So, every Bitcoin So if you are at a particular era of Bitcoin. Let’s say the original era meant that every 10 minutes you got 50 Bitcoin. Um, 4 years later, So, this is the, the rate was divided by 2 was 1 to. 25 bitcoins per 10 minutes, right? So, clearly, that’s a supply adjustment and obviously that may impact the price exactly in the same way that, you know, supply of currency. Um, affects price. Um. I’m just going back to the structural conversation we were having here. I guess what I want to say, maybe to finish this sort of discussion, a little bit of discussion with this is that every block here has a Merkel tree root. Right? And then, if you want to verify. If you want to verify a certain transaction, you may just get everything that’s what let’s say a so-called full note does, but, but there is also a more lightweight version of this where you basically just get so called that part, not the things that are hanging from it, so you just get what’s called the block headers and then you just get that proof. Um, so, so this gives you a, a more lightweight way to Test what is in the protocol, and what is in the blockchain, right. So, so, this gives uh a picture a bit of, of what, what, what’s going on. So, so, to complete the picture, the Bitcoin network, um they, they form a peer to peer network. Every node runs the Bitcoin protocol, um, it’s open source. Um, they continuously exchange the data, nodes enter and leave the network without any permission. So, anybody can do that. Um, and you, when you leave the network, you don’t also need to announce that you’re leaving, you can just leave the network. Um, and, and the key assumption, of course, of Bitcoin is that there should not be any trust placed on any specific node or participant. Anyone, any individual node may lie, so, everything has to be verified. Um Peers are, are discovered actively, every node maintains um a list of peers by IP address. And then, they can also share these peers with each other. So, you can connect to a Bitcoin node and ask it to tell you peers, its own peers. So, you can get that information. The idea here is that it’s a peer to peer network, there’s no authorized set of addresses. Um, there are some addresses that are hard-coded in the software, so when you start the Bitcoin node, you know where to look for some initial nodes, but these are not something that you have to necessarily use, right? So, you can put some other addresses there, um, and once you connect to some nodes, you can also, uh, find more addresses. Um, yes, I said that, I guess, already. Um, and then everything is based on this gossip protocol that whenever Alice generates some new data, Alice will broadcast the data to its own peers and then every peer will, um, multicast the data to its own peers. Uh, if the peers have seen the data before, they ignore it. If they haven’t seen it, they, they download it. Um, and in this way, sometimes this is also, you know, made similar to a sort of epidemic, like, so it’s basically Data are running through the network of peers like an infection, right? So, basically, they hear about it, they, if it’s new, they pick it up and then they push it forward, right? And, and, and this is called peer to peer diffusion and um and we know certain various good properties about it, right? That information in these networks can spread fast uh despite the fact that they’re not they’re not centralized. Of course, it’s not completely foolproof, um, and there are attacks against these peer to peer networks, including the Bitcoin network and uh sometimes these attacks are called eclipse attack. So, an eclipse attack is, is an attack that there is an honest node that tries to connect to the network, but then it doesn’t have any Um, connection to, to an honest node. So, basically, there’s an attacker that you, you may think like completely encircles the target and And that’s a bad situation. So, essentially, when you are completely encircled, you don’t have a fundamental way to know this for sure, right? So, so, actually, Bitcoin doesn’t have a way To tell you, you are encircled. I mean, circumstantially you can perhaps understand that, um, but, but in principle you cannot, you cannot tell 100%, yes. In the sense that network-wise, there is this large population of nodes. Um, that are running Bitcoin. But, but you are here. And the attacker is Somehow all around you and these guys are happily running the Bitcoin protocol. And you would like to, but all your communication channels are essentially controlled by the adversary. So, it could be the case, for instance, that some certain information that floats in the, the network is censored and never reaches you. For instance, someone posted transaction. Everybody in the network knows it, but, but you don’t, let’s say, right? Or someone posts a blog and, you know, you never become, you never realize that. Bitcoin will, will keep working even in this case. With, with, with some Changes in its operation, which I will explain in a future lecture, uh, but you don’t have a An absolute foolproof way of detecting this just to be clear. So, so, so such an eclipse attack is a possibility in, in that, in that protocol. OK, so with this I’ll, I’ll stop and uh you know this lecture here gave you some idea about this authenticated data structures and we’ve seen how these are used in the context of, of the Bitcoin blockchain, um, in the next two lectures we’re gonna. Take, um, we’re gonna focus more on transactions and programming, so we’re gonna start thinking about talking about Ethereum smart contract, smart contract programming, and in the next two lectures they’re gonna be the next two lectures are gonna be also the programming part of the course if you wanna think about it and the one that’s gonna lead to the course, um, project, right, which is programming. OK, thank you and we’ll see you next time.

SPEAKER 5
So I have another doubt. Uh, how do you exactly like estimate the monetary value of like a print card?

SPEAKER 0
How do you estimate the value, um. Well,

Lecture 1:

SPEAKER 0
All right. Let’s, uh, um, hopefully everybody’s comfortable and you’re here for Blockchains and disciplined lasers. So, my name is Agulos Calla, and I am one of the instructors uh for the course. We’re gonna start together. Uh, today, first lecture, I’m gonna start with um short brief overview of administrative details about how the course is organized. And after that, I’m just going to go ahead with an introductory, uh, Overview of what blockchains are, why we study them, uh, and a bit of an overview of how these protocols work. So, as you all know, those who are here, obviously, we meet on Wednesdays. The geography building here 213. Uh, the links for the Uh, courses of those. Hopefully, you know them already or you know already of the open course website. All relevant information about the course can be found there. The assessment is on the basis of a programming. Assignments are 30%. Relevant dates, the ones you see there, it’s also a multiple choice test at the end as a final exam. So we’re going to use Piazza as a forum for questions and answers, so I would encourage you to use that medium. Uh, make sure that you’ve signed up. Probably most of them are signed up already. Um, and, uh, that’s gonna be our main medium of communication. If any of you, however, would like to Reach out to myself. The other instructors and teaching assistants. Uh, the information you need is here. So you can reach out by email and ask for an appointment if that’s necessary for your circumstances. I would certainly though encourage you to use Piazza for questions about. About the course Now, here is a schedule um for the term. I call it tentative because we might have very minor deviations from it, but Probably not much. Uh, I’m not going to go over it now. This is just going to give you the high level terms and Topics that you’ll hear about in the term. Also gives you the dates and how this is going to be organized. Um, over the term until about the end of November. Um, perhaps something to highlight is that the coursework is going to be announced on the lecture 4. Um This um 2nd week of October and. Um It’s going to be you. On the 11th of November, I mean, it’s not visible here, but. That’s when you should expect it. Finally, some links about um what you can study. I should point out, however, that Um, The study uh material that you’re gonna use um are basically the uh presentations from the class. So For the final um exam as well as your whole understanding of the course, um. You, uh, don’t need to study any external sources other than the material provided here. Also, this is not a, um there’s no like an established textbook for this topic, so I cannot assign you one. Nevertheless, If you would like to have a text, uh, this is a somewhat dated text but still quite, quite good. Um, If you would like to find other sources or other topics, I’m going to. Uh, I’m gonna be happy to give more recommendations, uh, if you wanna reach out. By the way, there’s a few tables here in the front, maybe not the most popular. As the current configuration uh reveals, but uh just pointing it out. That they do exist. All right. So, All right. So, uh, perhaps just finish here by Um, maybe I’ll show you the website for. If I can. So here’s the website. And. Um Also have here Cristina Visig and um Jing Xinghao. I mean, you can maybe raise your hands and you can say hi to, to the rest of the class. These are my brilliant teaching assistants and, and uh um and teaching support for the course. So thanks for uh coming here and the first lecture. They might occasionally drop in. Uh, they will also be helping me, uh, managing Piazza as well as, um, getting the course, um, uh, run. Together with my other instructor Damiano Abraham, who is going to pick it up a bit later in the term, and you will meet him later. Um, so, I suppose that’s Hm. OK. Suppose that’s all I had in terms of the administrative bit. Um, all of this not, not working. Mm, OK. Um, any questions now? Comments, concerns, anything you wanna clarify? Yes, please, to lectures uh, it’s not gonna be necessary, um, but I will make available the, uh, lecture, um, the lecture notes, um, which basically in the form of these presentations, so they’re gonna be available shortly before the lecture. You can also see the lecture notes from past term from the previous year which is related, um, but. You wouldn’t have to read it ahead of time. So, it’s fine to come, um, let’s say like this. Nevertheless, you know, I, I probably make it easier for you to follow if you sort of skim through it. Uh, before, before you go, because sometimes you’re gonna have a lot of information, so it will make the conversation, um, you know, flow in a more easy way if we want to make this more interactive, that would definitely help. So I would, I would encourage you to do that, but I would not, it’s not gonna be a requirement though. So see how your time permits, uh, in terms of, uh, all the other things you have to juggle. Any other questions, concerns, comments, remarks? All right. Right, OK, so that’s my lecture one, and that’s an introductory, uh, lecture we’re gonna start asking why we study blockchain systems, gonna make an introduction to blockchain protocols. I’m gonna give you a very high level view of how the protocol works. Uh, I will say a few words why this is a new paradigm for information technology, and then we’re gonna delve into the basic primitives used by the Bitcoin blockchain. Uh, so that’s, that’s the plan for the topics, or at least in. In some order, so I’m going to start first. Why study blockchain systems, so. Um, Clearly blockchain systems is a. Relatively new area in computer science. I mean, computer science itself is uh um in many ways a, a new field of study, if you compare it, let’s say with other more traditional ones like physics, chemistry, and, and so forth, and, and blockchain systems within computer science is also uh a new, uh, a relatively new topic. So why we study them? So This doesn’t look to be very reliable. All right, let’s see how it goes. Um, so, A lot of important topics, um, blockchain systems primarily deal with issues of coordination, um, and. Uh, management of information technology at a large scale and that’s exactly the case where we have a lot. Of cybersecurity concerns. So starting blockchain systems is an excellent way to understand a lot of the challenges that information technology faces from a cybersecurity perspective. So there’s a lot of risks uh that are exist today for information technology. And blockchain systems, uh, uh, give you a way to or and if you want is a vehicle for you to understand a lot of the issues, um, and, um, understand what can be done about them, how is it possible to mitigate them, uh, so it’s a, it’s a very good opportunity to learn about cybersecurity in a fun way. Um Blockchain systems also highlight the importance of this concept called decentralization. Uh, which is a property that has an increasing importance in modern information systems. So traditionally information systems are built around this, uh, centralized paradigm which is like there’s one basically server or, um, computer system and there’s a lot of users that may access it, maybe one user or multiple users, and um this. You know, paradigm has worked for decades, obviously, uh, and it makes a lot of sense, but it also from a cybersecurity risk perspective it carries um um an important downside that if you have a single system that’s responsible for all the things you have to do this then becomes also a single point of failure, um, so, um, decentralization is about. Making sure that such single points of failure do not exist. So in the course of studying blockchains, we’re gonna see also a lot of uh basic concepts that are related to security in computer systems like key management, software security, uh, privacy preserving technologies, public infrastructure, and, and so forth. Um, furthermore, there’s a lot of societal aspects related to blocks and systems to how society, uh, uses, uh, technology, um, and, and, and that’s gonna be also an important, um, uh, dimension that we will, uh, touch from a different, different angles. And hopefully, also you’re gonna find it fun to study, so it’s a fun topic, uh, to understand more about it. OK. Um, so with this, I’m gonna start by asking the question, what is the blockchain? I mean it’s certainly I suppose a term that all of you have heard about it’s on the news or I mean it was. Certainly trendy at some point, um, and still is, I suppose. Um, but what is it? So what is a blockchain? So a blockchain is, is a distributed database. So it is a database, so basically it organizes information, um, and it is distributed, so I, I will come and explain what does that mean, but it’s not, but the only thing that you should keep from this statement is that. Um, it’s not stored in one place, right? So we will come to that later, but that’s the important part of being distributed. And then it’s, it comes with a unique safety and liveness property. So, so these are some, I will, I will explain what what by safety and liveness we mean here, but these are the two fundamental properties in distributed systems are safety and liveness. In a nutshell, safety means that bad things don’t happen. That safety. And liveness is good things eventually happen, right? So these are like these are the two fundamental properties of this of distributed systems, um, or if you want you can think of of them as systems in general, right? So safety, bad things don’t happen, liveness, good things eventually happen right they’re separate, right? So just keep it in mind and I think it’s useful also to understand that these are two separate properties. So it’s possible to be safe and not live. But it’s also possible to be alive and not safe. Right, just Wrap your mind around that statement for a bit. So for instance. If um I take a laptop. I put it on a hole. And I put a hand grenade with it as well and bury it in the ground until I hear a boom. This is going to be a safe laptop, right? So something bad happened to it, but otherwise nothing is gonna happen, right? So no bad things will happen to that IT system. Right past the explosion, right? The explosion was a bad thing to begin with, but you know, basically by destroying liveness, right, because it’s clearly not a live system anymore, right? But it’s definitely safe means that by doing nothing like we’re sure not to do something bad, right? Liveness on the other hand is very accommodating, right? Um, and you can have a system, let’s say that you leave your laptop, you go to a cafe, you leave your laptop, um, you don’t lock your screen, it’s just there with, I don’t know words, you know, just on and you know, basically, and then you go to the bathroom, right? So that’s like liveness pretty high there. I mean your system is there is accessible, anybody can do stuff with it. I mean good things may happen to it. But also bad things may happen to it as well, right? So, that’s kind of the opposite thing. um, and now you can like understand that a lot of issues. In distributed systems, but I would say cybersecurity in general. Revolve around the tension that you get between these two properties safety and liveness. I would say even philosophically speaking this goes well beyond computer systems, right? A lot of the things we do they have a tension between safety and liveness, right? You can even think about things you do, right? For example, it’s more safe to stay at home. But it’s definitely less live in a way, right? It’s more life to go out, but you also expose yourself to dangers. For example, you can, um, you know, grab a cold or get the flu, let’s say, right? By going out, you’re exposing yourself, but you also have potential benefits, like, interacting, let’s say, with other people, right? So safety and liveness, they always have a tension between them in everything we do, um, and they definitely reflect. Um, yeah, they definitely are reflected in the context of computer systems. So, so we’re gonna come back to this theme on and on because, um. It is definitely important in general, but is, is, is, is particularly crucial and in the setting of um of distributed systems and blocks and systems in particular. Um, so a distributed ledger. Uh, is, um, a, um, a way to organize a ledger, so we’re gonna use this term quite a lot. A ledger you can think of it of, um, as a sequence or or as a log of transactions like things that happen. Uh, things that have happened, um, and, and the blockchain protocol is a way to implement it. And, um, this concept of a blockchain protocol was um introduced by, in the context of a bit of the Bitcoin system. So what is a Bitcoin system? It is an information technology system. Um, it, it offers a consistent database of transactions. The transactions are of a specific type. I mean they mostly track one particular asset called Bitcoin which is created and managed by the system. Um, the maintenance of that system is not, is not coming from any specific source, so there’s no Bitcoin company, right, there’s no specific entity, it’s not like Facebook or Google or Amazon that says I’m, you know, responsible for Google services, let’s say, or, um, let’s say if you. Connect to Microsoft Office you have to connect to uh you know some system in a data center right that is managed by Microsoft also so. That’s not the case for Bitcoin. There is no specific entity behind it. Instead, there’s a lot of maintainers. That By themselves they decide to engage with maintenance and they’re incentivized to do so um and by maintenance I mean like servicing new transactions as they come um and making sure the database is consistent so they all of them are incentivized to do so and um. And it has exhibited stability for over a decade, in fact, over let’s say 1615, 1615, 16 years now, um, without actually being centralized organized, so it was never, you know, it doesn’t have an entity behind it now and it didn’t have an entity behind it in the past. Um, and, um, participation in maintenance as well as in, in terms of, um, Engagement grew exponentially at times since since launch. So we’re going to study this. We, we, we, we’re gonna study what is, you know, the, the what is the meaning of this? How did, how did this protocol came about? It is, it is a little bit of a paradox that such a thing even exists, I should point out, um, and, uh. The reason it’s a paradox is that before Bitcoin there was no other system, no other IT system that was launched in the same way, or at least and exhibiting such a, such a degree of, of stability. Um, so for that reason this makes it um very interesting, um. Topic for study and um and that’s um and that’s one of the reasons I’m starting with it. So, um, What are we going to learn from this successful deployment is going to be one of the themes for for the course and certainly for this for this first lecture. So, but first, Before I go to the bigger picture, I would like to go take like a sort of a dive into how the protocol works, but instead of going to the details of how exactly it works, I will give you the details, but I will give them to you in the form of a parable. So I will give you a rendering of the protocol that you can actually explain it to anybody. And you can explain basically to anybody without any background necessarily in computer science or math of how the protocol works. So, so I call this the never ending book parable. So, so what is Bitcoin is or what’s the Bitcoin system is a book of transactions. You can think of it as a book, um, and anyone can be a scribed, uh, in that book of transactions and produce a page. So new pages are produced indefinitely as long as the scribes are interested in doing so, right? So if, if, if there’s no scribes, then the book stops, right? So, so Bitcoin like or the book, let’s say this never ending book, it continues as long as people are interested in doing so. If they’re not interested then then the protocol stops and the book stops as well, right? So, so basically the whole protocol is about maintaining this book. Um, Now How do you make pages in that book? So the making a new page in the book requires some effort. And we will, we will come to see, um, as this as, as, as important, but it’s all algorithmically defined, so it is quite possible to take this um sort of standard like to take this form of a book that Bitcoin creates and you can create your own so anybody can make their own version. Um, so then, there’s no basically someone organizes and says, oh, OK, so it’s just Aguilos is gonna make the right version and you have to listen to him. Nobody does that, so anybody can make their own version if they want, so. So obviously that wouldn’t be that useful. So it will be important to have some consensus about what’s the version that we should refer to if we’re gonna use this book for anything useful, right? because if everybody has their own version then that’s no different than having your own let’s say diary that you keep things right? so it’s not OK. I mean it’s great to have a diary but you know that’s not something groundbreaking. I mean people have been doing this. Uh, for, for centuries, if not thousands and thousands of years, so, um, so if multiple conflicting, obviously books exist, I mean, which is the right one to use? And the mechanism that that Bitcoin has is that it looks at the size of the book so because we said every page itself requires some effort to do so the. Selection mechanism that Bitcoin has if you want to refer to the. Um Like, what’s the Version of the book you have to refer to, you have to take the one with the biggest pages like you, you go to the bookshop and you say you ask the uh the, the clerk there what is the book with the biggest number of pages, right? So there is one book in the whole bookshop, right, that has the most number of pages you wanna go get this one so that’s the one that you should get. Um, so, so that’s the main, that’s, that’s, you know, what the first key mechanism that the protocol has. So let’s see then how, how it works as people are working of of, of, of making more, more pages. So, so every page has a way of referring to the previous one. So, so here, um, you have to, you know, think of every, every possible book that you can construct from a sequence of pages, right? So there’s a 1st page, the 2nd page, the 3rd page, the 4th page. But for example in the in the 4th page it so happened that two scribes created two different versions of page 4. It could happen, right? There’s no coordination, right? The scribes are, you know, doing whatever they want, right? They might also start a new book with an alternative page 1 also fine, um, so it doesn’t matter like the protocol allows anybody to do anything they want. But the convention is that the book that you refer to is the one that has the most pages, so in that case that’s the one, right? So you can see from this picture that it could be the case that you have certain forks along the road. So it could be the case, let’s say that at some point you were looking at this one. But then you realize, oh, but this one is longer. Now, um, It goes without saying by um this explanation I have so far um that communication here is key if you’re sitting yourself not talking to anybody um this will not make too much sense, right? You might as well, I don’t know, be stuck here at page 6 and you have no idea that other people are working and building more pages, right? So one of the preconditions here, uh, for, uh, coordination. Is that people are able to communicate with, with each other. So, so what are the rules in more detail about extending the book? So the first scribe that discovers a page will announce it to everybody else. And uh and and the others um are gonna say oh it’s a new page so they might just get it, put it in their books that they’re working on and start building from that point on. So suppose I’m working on page 7, so I, I hear, let’s say that someone else like here in the classroom, oh I have found page 7, so you just let me know so I can just accept it and start working on page 8. That’s fine. That’s, that’s how the, that’s how the logic is. Now, of course. There’s like two you know, elements here. First of all, effort is needed. I mean this is one of the fundamental aspects of the um of the protocol is that it needs some effort. Now why effort is good here? I mean, obviously if no effort was needed to produce pages and suppose let’s say everybody here in this class started like to say let’s make pages like chances are that we would be just producing too many pages. Flooding our communication, you know, with new pages, and we couldn’t figure out what’s going on just from the sheer bulk of information that is floating, right? Everybody’s gonna be shouting, I found the page, I found the page, I found the page, right, creating like, you know, such confusion. So effort is needed, which means that instead of like I don’t know. 30 pages appearing at the same time like as we’re working on them it’s gonna be just one here then another then another then another right? so that’s why effort is needed. So what is the effort that is done by the protocol? I mean you can think of it actually as, you know, the cartoon version of it is that you have let’s say some dice and then you just throw the dice and then. You actually participate when you get a winning combination. Let’s say you have to get all sixes. So, so what you do to produce a base is that you, you just keep repeating some randomized process like that. And it is important that the protocol uses this probability. For the following reasons, if there was no randomness involved in that process. Then you wouldn’t be able to break ties. So suppose, let’s say there is effort needed. To produce a page, but the same effort is needed for by everyone, absolutely the same effort. So, so then it’s gonna be a bit useless like what I just said that we can coordinate like this in the classroom, right? So suppose it takes 10 minutes to solve the, to, to solve the problem or roll the dice and get a winning combination. Then everybody will start. 10 minutes silence and then suddenly at the 10 minutes mark everybody’s gonna say I found the page. So that’s not good, right? So then again we go to this chaos of everybody announcing. Uh, you know, that they found something new. So What we need is something that you know you can call us symmetry breaking, right? So we want to make this all these people trying to do this at the same time not completely symmetric. I’m trying and you’re trying and we have a chance of producing a page, but it’s not gonna happen simultaneously and now you can see why the dice is a good example, right? You just throw a dice. You might be lucky and get it in the first row, all sixes. Or maybe you’re unlucky and you keep throwing the dice throwing the dice. I mean eventually you’re gonna get it, right? I mean the probability of you not getting a particular combination. It goes to zero very fast, right, so. So it’s not like you’re not gonna get it like we we know we’re gonna get a page, um, but, but we’re not gonna get it uh at the same time if we try to get it so this symmetry breaking is, is, is very important. All right, so. So who are those that are are doing this, you know, dice throwing, producing pages and all that, so anybody can be as scribed, so there’s no need, there’s no authorization, there’s no pre-authorized set. Anybody can start this process and, and furthermore, being a scribed is rewarded. So if you are and, and that’s your motivation doing it because otherwise you could say, OK, I mean that sounds all fine, but why, why am I supposed to be doing this, you know, is there, is there a point? I mean maybe it’s fun and you can do it for I don’t know, just the day, but like why would you keep doing this and so why people are doing this now for more than 15 years. So being a scribe is rewarded. So and what does that mean? as they produce that page, this new page, putting effort, they’re allowed to put on that page a special asterisk entry that says I am this scribe and I’m gonna get that reward so they’re allowed to put that. So now the book, if they manage to get a page will have a special entry that says. This Aguilos, let’s say, got that reward. So, so that’s why I’m getting this recognition. Let’s say, in fact, the way this system works is that it creates digital coins like it mints digital coins in that process, um, and, and this is also how new Bitcoin is minted. Um, of course, um, you have to, you have to be able to, to, to roll those dice. And, and the protocol even doesn’t, doesn’t restrict I mean you can think of it as if you have more dice you can, you can be faster in producing a page. I mean that’s so it can be a race let’s say of some sort like I can get dice and you can get more dice than me and so forth uh so such a race is, is possible. So the book is you can use it I mean that was how Bitcoin was introduced I mean when Bitcoin was introduced was was thought to be like um a replacement for cash. I mean it didn’t turn out to be quite that now the way people view Bitcoin now is more as a as a store of value so basically something that’s like gold, let’s say something that you buy and you hold and it appreciates over time so even though it was presented as cash. Its application as cash hasn’t really manifested itself like there were a few attempts we will later on discuss them and also discuss why, um, but right now and increasingly so it’s being viewed as something like as a substitute for gold or um sometimes we’ll call like digital golds and. And and that’s why people are considering having it um as a long term investment so uh and you have even um you know announcements by. Um, countries, um, considering making it part of their long term reserve. Uh, but, um, I mean, I’m gonna keep here more the logic of using this as a payment just to illustrate a little bit how it works because to be clear. The main reason that Bitcoin makes sense as a long term investment asset is also the fact that you can transmit it digitally, right? So without its ability of being transmitted digitally. Uh, in an effective manner, nobody would consider it, uh, using it as basically a long term investment or digital gold. I mean, part of its attractiveness is the fact that it is scarce like gold or other commodities and but can also be transmitted digitally. Which it’s not the case for any other commodity right? so you cannot digitally transmit gold obviously right? I mean of course you can transmit other. Uh, you know, financial instruments digitally that represent gold, but in that case you’re not transmitting gold itself, right? So you can basically transmit other things. I mean, so this is like a second layer, uh. Uh, type of object, but in the case of Bitcoin you’re actually able to transmit the asset itself. So, so how does that work? Let’s uh take the example of um. There’s a buyer, there’s a seller, and essentially the arrangement is that the seller is going to send a bicycle to the buyer. Uh, and the buyer has to send some Bitcoin. So, so, so what this, the, the buyer does is that it signs a statement that says like I’m going to owner of these coins. I transfer them to the address of the seller. That’s the statement it has to be signed and that signed statement should go in the book. So what the seller does is that it listens to the network, gets the most recent version of the book. And then as long as they are convinced that it’s safely in the book and it’s not gonna change and and the book is not gonna get reconfigured that’s important but let’s say there is a way to be sure about this so that’s the part that says verify the payment is confirmed. Then the seller is happy and then gets the bicycle and puts it in the post, OK, so, so that’s how it works. So, so this completes this, um, sort of parable type of, um, way of, uh, thinking about the Bitcoin blockchain and, and of course I mean maybe some of you are already familiar with Bitcoin. What is the book is is this blockchain, uh, the scribes are the miners. The production of new pages is uh solving this cryptographic puzzles sometimes called also proofs of work and this rolling the dice corresponds to using a computer to test a particular solution for a certain problem um out of a space of um candidate solution. So again this is like a bird’s eye view connection of how things work uh in in this protocol now. What is interesting uh in this in this particle that I should highlight uh now and that’s a topic we’re gonna come back, you know, a few times later on this semester as well is that what I just described to you is a way for parties to coordinate without knowing each other. Now this might seem like an easy sentence to say, but never ever in the history of computer science this was achieved before or even thought to be possible like coordination between entities was always thought in the context of entities knowing each other and then coordinating. Coordination without authentication without knowing each other was unknown prior to the introduction of this protocol. And why this is relevant today is that we are increasingly moving to a setting where information technology has to be global, so we want to build global information technology systems. And to build reliable systems globally, we need coordination. And, and given that we don’t have yet perhaps the global government of Earth that can organize, you know, authentication for everybody, this thing doesn’t exist. It is fascinating that there is a way to solve this problem of coordination without a global organizer, so that’s why this protocol is interesting. All right, so going a little bit more now on the technical side I’m gonna take um. Um, I’m, I’m gonna start and uh going through some of the topics that, um, are related to the cryptographic algorithms and primitives that are useful for this protocol. So the question is how the pages are created, um. And, and, and how let’s say this money are being minted or these digital coins are being minted that I mentioned before, this is based on this proof of work. Uh, which, I, I will explain how to prove ownership of a digital good. This is based on public cryptography. How do you sign something digitally is via digital signatures. And finally, how does a page can refer to a previous page without ambiguity? This is based on hash functions, so. These things highlighted in red are very important cryptographic algorithms that are not unique to the case of the Bitcoin blockchain or distributed systems in general. These are basically the workhorses of cyber security, uh, which, um, I will then in the remaining of this lecture. In the next hour, I will describe very briefly and give you a glimpse of what they are. So perhaps now in the 10 minutes we have till the break, I can tell you about hash functions, um, and then we’re gonna finish the rest in the next bits of the hour so. Um, so, what is a hash function? So, a hash function is an algorithm that produces a fingerprint. So, um, The required properties traditionally is that it’s efficient and has a good spread. So that’s the the the domain and the range and what’s important just to highlight here I’m using this notation 01 to say this function takes any string. Just bit string like you can think of it like this basically any file and it’s gonna produce an output which very importantly it’s again a bit string but has lambda. Length. So So as a function like in a way it gets like an infinite domain and kind of packs it in in in like a range which is small uh and obviously this means that um there will be collisions. So, what is a collision? A collision is two values X and Y, which are different, and they have the same output based on, on, on the hash value. So, um, now. Has functions to be useful in the context of cryptography. And more importantly in the context of Bitcoin, they have to have the property that finding collisions is hard. Then there is another type of attack that we will concern ourselves with, which is the second prima attack that says uh if I give you an X, can you find a Y so that it is a collision, right? So, whereas the collision attack first it just says just find any two X and Y’s that that collide. So these are like two types of collision resistance. So, um. In, um, just to understand a little bit like the concept of collision, it’s an important one, we can, uh, review a little bit the the birthday paradox. How many of you in this classroom have heard of the birthday paradox? you wanna raise your hand? Good, OK, quite, quite a bunch, good. So the birthday paradox asks, How many people should be in a room so that the probability that 2 of them share a birthday becomes larger than 50%. And um. Now why it’s a paradox. So it is a paradox because Usually when people don’t have not heard about it before or don’t don’t know probability, they usually guess a rather high number. There is um and what’s a high number, um, there’s like 365 or let’s say, OK, or 66, let’s say different birthdays that you can get. And Just to explain, like how many, let’s say there are 365, and maybe we can do this a little bit interactively, if it’s 365, how many people should be in a room so that we must have a collision like with a 100% probability? Suppose we only have 365 birthdays. 360, yes please, 366 perfect and this comes from a mathematical concept called the pigeon hole principle, right, that says if you have 365 pigeon holes and 366 pigeons, there must be a hole with two pigeons in it. It’s no way, right? So, so starting with this, you have 366 um. You need 366 people in a room to get 100% probability. Now if I ask you how many for 50%, I mean it has to be less. But how much less? Anybody wants to say Yes, I remember it’s 20-ish because

SPEAKER 1
like the, the probability of not having, not having, uh, two same birthdays among people are, are reduced exponentially like 3365/65 times 364/65 and when you stack it up to around 20.

SPEAKER 0
Yeah. That’s great and this is more or less the correct answer thanks for um sharing it. I say more or less because the exponential part is not not quite right and we will see it’s it’s actually more a square root but um but your your estimate is right but clearly as you can see your colleague here is a well informed person. I mean you won’t get this answer and I hope you agree with me you won’t get this answer from just a random person, right? So a random person in most cases would say OK if it’s like 365 666 maybe about half of them will give you 50% probability and that’s like 180 which is way way way above so. Case in point is that 20 is pretty small. It’s about 23 actually, um. And, and if that doesn’t sit very well with you we can actually demonstrate uh here in the class as we are way above uh way above uh uh 2023 uh but but we’re clearly below 180 in this room, right? And you can see like it’s gonna happen with some good properties so let’s find two people in this room with the same birthday. How about this, right? Can we do that? OK. It’s a small miracle that will be performed. And after this, uh, after you go on a break there’s gonna be two people here that are birthday buddies, so let’s see if that’s gonna happen, all right, so January. Can I hear, can you raise your hand? Yes, if your birthday is January. And I see I have a bunch of people so I’m gonna point and you can tell what day 5-19 108. All right, done. That was quick. Thank you very much. And you’re now birthday buddies. You can celebrate together like in January as it comes. Um, all right. So, as you can see, I mean, I have to say, it doesn’t happen always that fast. But it does happen, as you see, it was more probable, I would bet, especially today, that was faster than what you expected, right? You expect that it’s gonna be some tension, right? But it turns out like it happens more often. Um, and, and this goes back to the point. So, so the math behind this is, um. Is given in this slide which it’s, it’s fairly simple. I’m, I’m not gonna go through with step by step here but basically says what’s the probability of not having a collision and basically what you get there is like the denominator is all possible dates. Let’s say that’s n and then. When you have a denominator is you have this um a following factorial which basically says for the first person I have end dates and then I N minus 1 for the second because I exclude the birthday of the first and so forth so I’m doing this product argument as it is called this gives me this thing which I can bound it from this one, and then you get the key point is that you get this summation here. And the important part about this summation is that this depends on k, that’s the number of people in the room. Divided by N, which is the number of birthdays, and the important point is that this thing on the nominator. It’s K 2 more or less, right? So and that’s where the 20 and the square root dimensions and all that comes into play, right? So, so basically the number of um. Options as you go um grow quadratically. Another way to understand the the math behind this in an intuitive way is think yourself like throwing darts on a wall, but instead of having a target, you just throw the darts on the blank wall. And every time you throw a dart, you go and you know draw a target around where you hit. It’s like, so every time you throw you just create a new target. So now getting two darts on the same spot, I mean, obviously now it’s easier because the more darts you throw, the more targets you get, right? And so this actually has a quadratic increase, right? So, so that’s what you observe in this function here. Um, OK. So, so, so what do we learn about collision finding and I’m I’m gonna stop in a minute, um, is that um that also gives you a general algorithm um about finding collisions. Uh, which basically the algorithm is that you know, do what I said just give make k trials and then see if you hit the same point and by the analysis we we did as k is gonna go to about square root of the total number of options about square root of n, uh, then you’re gonna get some good probability of succeeding. So that’s where the, um, you know, if you wanna do the calculation. It’s gonna be about forn to be 365 uh you’re gonna get about um uh 23 uh people so so you might ask like why is this all that is important it basically tells you if you don’t wanna find collisions this tells you how big lambda should be here right? so so in other words. Say you want to make collisions unlikely this value lambda here, you don’t wanna make it let’s say 80 because then the total number of options is 280, which means square root of this is 240. So which means that after I do 240 trials I’m gonna get a collision and 240 is something that is within, it’s very feasible, right? You can do 240. I mean it’s a lot, but you can do it. So let’s say lambda can be 80, but let’s say or even a 100, but, but if lambda is about 256 let’s say today, uh, this is then sufficiently big to avoid this problem happening. OK, so this gives you a feeling about, uh, you know how this hash functions, you know what, what are the properties. I’m gonna just finish with some few words after we come back, but let’s now take a 10 minute break. Yeah. I have two questions.

SPEAKER 2
So, when the exams are going to be conducted at the end of this, Thank All right, so let’s get

SPEAKER 0
back, um. So, so, um, No Yeah All right, so, a, a, a, a different attack which is relevant in the context of hash functions, uh, is called the primage attack that says if I give you the fingerprint of, of a file, let’s say that you know the file is, uh, tidbits long, can you find, uh, can you find it? So basically this 8 inverse of HM would be a set of values, one of them being being M, and, and, and, and of course um there is an algorithm here that um will try all possible candidates and and find that right but this is not a collision anymore. I mean this is basically brute forcing um essentially uh an input, uh, and finding what’s called like a preimage. Um, So, so this, this, this also relates to this concept of, of a one-way function, uh, which are very important objects in, uh, computer science and specifically cryptography basically says if, if it is easy to go in one direction, uh, so if I give you X you can find F of X, but if I give you FX it is hard to go inverse, right? Find X or another value that is a collision to X. So, so, so this is a one-way function. And whether one-way functions exist or not, this is actually we believe they do exist, um but actually proving that they exist is um is uh is related to this famous uh computer science problem with. I expect some at least some of you have heard about the P not equal NP problem. Does anybody, I mean, have you heard of this before? How many have heard about this? OK, raise your hand, raise your hand, yeah, OK, good, good, good. Does anybody know what it is? Like if you heard about it, can anybody can anybody explain? Yes.

SPEAKER 3
Uh, there are certain algorithms that can be computed in polynomial time on, uh, standard Turing machines, and then there are some algorithms that can only be computed in polynomial time by. Um, Was it the non nondeterministic yeah good alright well

SPEAKER 0
thanks for uh taking a shot at it. um I would just rephrase it a little bit. It is definitely about algorithms, but it’s more importantly about problems, right? So, so here you have problems that you can solve or decide by an algorithm fast and sometimes fast here is in polynomial time. And here you have problems that for for which you don’t have an algorithm that can solve them fast but you have an algorithm that can verify a candidate solution fast um so here is fast solving here is fast verifying. So the question, and that’s one of the, that’s this fundamental question in computer science is whether um fast solving is different from fast verifying. Yes, yeah, so and the and the question is, uh, and the question is, as, as you say, I mean this fast verifying, uh, is, is kind of a very general, uh, problem, uh, and. It has this product called NPple so you can fast verify you can solve any problem here I mean. Um, And uh but the but the the open question here is whether fast verifying is is different than fast solving so basically. To put it differently, what is unknown here in computer science is whether there exist problems that are fast to verify but hard to solve. We don’t know that, but we believe that that’s the case that there do exist problems. These are these problems which are fast to verify. But hard to solve, OK? So, um, um, so this one-way functions actually relate to this question and, and in fact, um, they, they, they wouldn’t exist and all modern cryptography would collapse or most modern cryptography would collapse if actually these two sets are equal and for every problem which is fast to verify, you can also easily solve it. Just to understand how this relates to cybersecurity. Uh, just to give you a feeling why most problems in, in cybersecurity, they’re fast to verify. So if you have a candidate key, um, you can easily test whether it is the correct key. I mean, think of yourself, um, outside the door that, um, you know, you’ve lost the key, but you have like the set of all possible keys like this huge bag of keys, and then you just try one. By one, so if you pick one key from the bag and then you can fast verify whether it works or not in the door by trying to put it in the keyhole, I mean if it turns, great, you found it if it doesn’t, then no, that’s fast verification, but finding the key that that works. Not verifying whether one is working or not, I mean this is presumably hard, so you have to go through the whole bug, let’s say. So, so that’s this class of problems, whereas this class of problems is like somehow a, a type of problem that you can look at it and you can easily find um a a solution so there’s a lot of problems, let’s say that. Belong here, for example, like you can look at an RA and you can sort it. I mean that’s a problem that is easy to Uh, to do Um, so designing this hash functions like some relates also to these questions and um. But I’m not gonna go more into this theoretical, more theoretical, um, uh, you know, underpinnings here. I’ll just give you some, uh, references for hash functions. So these are some hash functions that have been used. They have these code names. The only one I’m gonna highlight here is, uh, shot 256, which is 256 bits output, uh, and that’s the one that is used in Bitcoin. We already have moved on from 256 to 512, like bigger lengths, right? And that’s because the computers are getting better and there is the birthday paradox that we said. Um, That always when you say the output of the hash function is um n number of bits uh you wanna get uh n n over 2 is gonna be the birthday bound so that’s the square root so you have to uh you have to choose these hashes with pretty long outputs but anyway Bitcoin still uses 256 bits. All right, so, uh, let me move on to a bit to another primitive called digital signatures. So a diesel signature is Um, Basically this of fingerprints that can only be produced by one specific entity. I mean you could think of it as a hash function but now not is not a public function. Um, so it can produce by one specific entity only and but can be verified by, by anyone as long as let’s say that that anyone is suitably equipped or or initialized. And cannot be forged on a new message. So, so a digital signature is very different from your real world like standard signature like this is scribbling, let’s say that you have, you know, unique to you presumably, uh, that you put at the end of a document. Also digital signature is not this little like, uh, PNG JPEG file that has your little scribbling and you could you paste it, you know, over a PDF or something. This is not a digital signature. The reason clearly is that. If I, if anyone sees your signature. In a high um resolution image I mean they can make as many copies of it as they want so that doesn’t satisfy this third property I’m saying here that can be forged right so so we want something that if I see your signature digital signature. I’m not able to copy paste it, right? So, so your classic signature is not suitable um as, as a signature. And most importantly, as you perhaps can guess from here, a digital signature has to depend on the file that you’re signing, right? That’s the main difference of digital signatures from real world signatures. So it’s like every time you sign a document you change your signature according to the file you’re signing. I mean that’s not something that’s a human can do. Uh, but a computer can do that, right? And that’s how digital signatures work. Um, so they have 3 algorithms, a key generation algorithm that, uh, takes a simple security parameter and returns the sign-in key and the verification key, the signing algorithm that takes us input the sign-in key and the message to be signed and returns the signature, and there’s a verify algorithm that takes us input the verification key, the message and the signature, and returns, uh, true or false. Now, the important part here is that in order to verify, you need to know the verification key. Right? Without knowing the verification key, um. It’s of course impossible to verify. It’s like You know, going to the passport line and saying oh I have a passport from Slovenia or some you know country nobody ever heard about well I mean you cannot be admitted like nobody knows what it is right? So the verifier has to know who is issuing this document, right? So it has to be initialized uh with this verification key. Now importantly and this is what makes this very powerful. The verification key can’t be public. Anybody can know it. And knowing the verification key should not enable an attacker to forge a signature. So in particular for digital signature security there is this standard called existential unforgeability under a chosen message attack that says if you have an adversary who knows the verification key and even has black box access to the signing algorithm. So he can submit messages of his own design and get signatures. He’s still incapable of producing one more valid message signature pair. By one more I mean he asks for 3 messages and then he produces 4 at the end, right? So if you ask for 3 signed documents, the best you could do at the end is present these 3 documents, right? But you can all do 1 more. Does that make sense? Again, I’m not describing how these things are constructed. This is not the topic of this class, right? But these are important, let’s say, algorithms and primitives and their properties that we’re gonna have to use them. Right? There’s no way to understand how the systems that we discussed here work without understanding uh the properties of these um objects. But knowing these properties is enough, right? So, this is, you know, what I want you to know. Um Any question about this? Alright, so constructing, um, digital signatures, I mean, as you might guess, is not very trivial opera is not a very trivial problem. I mean it’s even a bit paradoxical that it’s solvable, um, but, but it’s possible. The clear challenge is that. What prevents the adversary from learning how to sign by analyzing the verification key so the adversary gets the verification key, puts it under a microscope, and the verification key enables anybody to verify the signature is correct, but somehow doesn’t make it feasible to extract the signing key from it and produce a forgery. So, so that’s kind of the. The the difficult part and this concept of a one-way function that I mentioned comes into play here as well, so. Um, in other words, the verification key, you can think of it as a sort of a one-way function. Of the signing key, that’s how actually a lot of diesel signatures are produced. Um, Now, if you want like a little puzzle, um, you can think on your own time. If you just have a hash function like the ones I described earlier that have these good properties that I mentioned uh in the previous slides, is it possible to make a digital signature that is at least good for um for a one-time signing operation? You can take this as a little exercise. Um, not, it’s an optional thing, right? So, you can, if you want a little puzzle. I mean you, you already know enough, let’s say to be able to um. Uh, answer this, uh, this little exercise, and, um, and actually this one-time signatures that come from this have been used in a number of cases, uh, including in the, in the blockchain setting. Now the most famous digital signature algorithms are the RSA algorithm, the DSA algorithm, and in fact Bitcoin uses a variant of this DSA algorithm or sometimes called the digital signature algorithm. And um and also uses another type of signature called snore signatures. We’re not gonna go into the details of how these things uh things, these things work, but if you’re interested in understanding them more, there is a course, uh, the introduction to Modern cryptography, which is taught in the second term. So if you’re interested to understand how these things work, um, I would encourage you to enroll and take that course. It’s gonna be, it would be quite rewarding. Um, Now, the final algorithm which I will say a few words about is uh this proof of work which uh will give you an idea about this effort um that I was talking about. So, every page to be produced, you have to invest some some time um and uh this based on this proof of work. So, the objective is given some data, ensure that some amount of work has been invested for that data. And this works as follows. It’s a pretty simple thing. It’s based on a hash function. And you get the data, you initialize the counter to zero, and then you increment the counter until you find a hash value which is below the target, uh, which is the, the target you can say some pre-agreed value. So in a way, proof of work is, um, just finding a somewhat small hash value. That’s it. That’s the, that’s the objective of, of this proof of work particular algorithm. So in fact in Bitcoin, the way Bitcoin works, um, when the, uh, miners or scribe work together uh in parallel to find a page that’s actually the. Code that they execute. Basically, they run this loop. Uh, and the data that they use is on all the contents of the page. So in the case of Bitcoin is this transactions, let’s say that you have inside. Um, so, I’m not gonna go to the properties that this thing should have. It’s actually an, an, an area of active research. But there is like a lot of um Um, a lot of properties that we are supposed to, to expect from such a primitive, like, one thing is that verification has to be efficient. So, if you do the proof of work, it shouldn’t take the verifier. The same amount of time to verify it and as you can say, as you can see this is possible here right? so if I do found the counter which makes the hash of data and the counter below the target then it’s very easy for you to verify because you just hash it and you just check the output is below the target so verifying is fast but finding a value is. Should be hard or that’s what we hope. So this is one of these problems that we expect that it is fast to verify but hard to solve, right? So this is again like this this class of problems. Um, obviously, We don’t want to have any shortcuts, so it shouldn’t be the case that there is some other smarter algorithm that finds a small hash value, right? So, so it has to be no shortcuts, no other smart things you can do. Um And um. And also like the the way we organize that we we don’t want everybody to be working on the same thing, right? So if, if everybody is running, so we want we want this independence for symmetry breaking. Luckily, um, in the case of hash functions like we believe we can achieve that and Bitcoin achieves that by doing the following when you form the data which are the contents of the page, you can include some random number there and then the belief and the um and the way that this works in practice is that this randomizes the input to the hash function so this y loop. Is executed on different values by different miners because the data is always different no miner works on the same. Version of the page. Um, this, by the way, it comes a bit in a straightforward way because every minor also, as you remember, includes a special entry for their own reward, so that’s also the point where they can include this randomness. Actually, the address they use for themselves is, is such a random looking number, so it’s easy to get that property. So, there’s a number of proof of work algorithms. I mean, the one in the previous slide called is called Hashcash and it’s the one that used in Bitcoin. But it has been found to have a lot of, a lot of downsides. Um, the main downside is that. It can be, it can be solved very fast by specialized hardware, so-called AIs, application specific integrated circuits. So in the case of Bitcoin, this created a race for building those specialized hardware and then the question was. You can be a more successful miner by buying those specialized hardware and that’s actually the case right now for Bitcoin today as we speak so in other words, in Bitcoin. If you just take your laptop, let’s say, and you start mining, is, uh, well, it’s unthinkable that that you’ll be lucky enough to find, to find the block, uh, given the current difficulty, um, so you would need to invest on a hardware, um, miner which is, you know, thousands and thousands of dollars, so, um, it’s not, I mean. Not all proof of work algorithms though can be easily solved by uh AI uh and and that’s actually led um a few years ago it was popular to uh investigate so called ASIC resistance, so basically algorithms that make it difficult to be solved uh by ASIC hardware, um, and there’s a number of suggestions, uh, uh, for this. Uh, nevertheless, the second downside of this proof of work algorithms is that they create a race for, um, doing more and more computation. And this race can be energy very intensive. And this also creates a lot of um criticism against Bitcoin for being um essentially uh energy inefficient and, and wasting huge amounts of energy. With sort of questionable utility. So, um, and, and, and actually right now Bitcoin consumes a pretty huge amount of energy, perhaps close to, I don’t know, could be like 1% of the total energy expenditure, uh, for everything else, right? So it’s still like is, is, is huge. Um, of course you can make counterarguments and people like make counterarguments that it’s utility is sort of bigger than that or. But that’s a bigger conversation that we won’t, we won’t have now, but we can have later on. Uh, but in more recent years, there was much more attention to other types of algorithms that don’t do proof of work at all and basically just going back to this, um, book, uh, parable, we can find different ways to do this, extending the book, etc. that don’t require this proof of work, right? And they’re more energy efficient. The class of this algorithms is proof of stake. Um, and we will cover them later on. OK. So, this uh completes my first uh round of how Bitcoin works, what is the cryptography behind um Um, uh, some of the cryptography behind Bitcoin, etc. so now I’m gonna take a step back and tell you, go back to the bigger picture. And tell you and and go back to the conversation OK I mean this may all sounded interesting um but why is this a topic for um general information technology and education, right? So why, why we’re starting this? what is the interesting, what is interesting beyond that particular system? I mean the fact that this system works, perhaps it’s interesting, perhaps it uses some uh interesting cryptography. But the question is like, do we learn something bigger from it or is it something to, you know, what’s the bigger takeaway point? So I would like to expand a little bit on this, on this, on this element. So in this, uh, goes back to my question how can what do we learn from the Bitcoin blockchain and um and I’ll I will make a case that here um. Uh, this is, um, something that, um, it, it gives uh, an interesting angle, and something that is a very important problem in computer science and information technology, which is answering the question, how do we scale an IT service or an IT system globally. So And then I’ll, I’ll, I’ll just say that so far, or let’s say before Bitcoin, um there were two approaches you could, you could think of about an IT system if you wanted to, to scale it, um, to scale it uh globally. Do you recognize these individuals? Like, hopefully at least one you recognize unless you. And Um, OK, so the right one, I think probably everybody should know, I suppose. What about the left one? Anybody recognizes this, this one? So, the left one is Vint Cerf. So, by many accounted as one of the fathers or the father of the internet. Um, so, he’s, he’s one of the pioneers of basically creating internet. Um, so, and a lot of the other things that we do are essentially preconditions on the Internet working and existing and connecting us, uh, together. So, the Internet and Facebook are. 2 systems. Not of the same layer, but there are two systems you can think of them that are global, like no question about it, right? Um. They, they, they enable you uh to engage um and they’re open to people from. In principle, at least. Like excluding any type of um I don’t know governmental interference and restriction but let’s say aside of that. Uh, because of course someone could cut off the Internet or, or, or cut off Facebook. But let’s say Excluding any such. Interference, um, these are global systems and accessible by anybody in in the world and they’re organized in a very different way. I mean the Facebook system clearly is a centralized system. It was created by a company it was led by Mark Zuckerberg and, and, and that’s a company that runs data centers and and runs the algorithms and and on the hardware that they. Uh, they, they maintain and, and provides that service. So, and it works, right? So Facebook is, is a globally, it has like I don’t know, more than a billion users, uh, so it’s a global system and then the Internet, the Internet is not, is not centralized as you most likely you all know. So, so what kind of thing it is, um, it is, it is mostly is better described as a, as a type of a federated system. So, it’s a patchwork of different networks and different providers that they have come into a sort of federation. So, basically, they have, they decided to allow their systems to interoperate. Right, so and by interoperating they connect. Different areas by the fact that they allow this interoperability between them, right? So, so, federation here means that the entities are different, but they agree to standardize, they they agree to, to speak the same language and they agree to have the same sort of norms and rules, um, and, um. And exactly uh and because of that they can scale globally right? so you so we can have a certain um network provider in this country or in this area and then they use the same protocol so they all connect together uh and then it looks from your perspective it looks like the same thing but it could be the case let’s say that when you send the packets, uh, let’s say an instant message to a friend of yours that is traveling, let’s say. In Japan, um, you know, your message is gonna go through a number of different networks. It’s gonna travel like via satellite. It’s gonna travel under, under the ocean like you don’t know any of that, right? So you just rely on this thing that connecting different networks to leave from your bedroom and and go to their office. And um and, and have this um sort of instant messaging happen without worrying about all this translation and and uh ping pong that happens underneath. So, so these two approaches, they do work. But They’re also preconditioned on on the fact that here we do have a company that basically makes it happen so without the company like it doesn’t work so and and importantly um this also generates like a risk that um. You know you’re bound to the rules and regulation and the will of that particular company and their shareholders, right? So, so there is sort of a single point of failure here, right? And then the problem with federation is that it’s not a very easy model to make it work like it works for some things like basic infrastructure like networking. But it’s very hard to imagine it for other services, right? There’s no federated Facebook or federated Google or anything like this. There’s no examples of systems, so there’s no, we haven’t seen this paradigm for scaling to be to be repeated for for other things instead, like the main paradigm for scaling follows the centralized approach, and that’s why we have the big tech companies like Amazon, Google, Facebook, and so forth. So, so there is a question like is there a, is there another way with, with the recognition that this is hard to pull and this exhibits a single point of failure, is there a different way to organize a, a globally scalable system and, and this is, and this is what um is achieved by or is is the example of this, um, decentralization paradigm that comes with with the Bitcoin blockchain. So, so what the Bitcoin did, which also you can have it as a takeaway point now from this first lecture, is that it achieved this so-called. What, what I call the software only launch. So a software only launch is, is basically the following. Suppose you want to launch, you want to create the new Facebook or the new X Twitter or the new whatever, like, so, but then I tell you that the only thing you can do is write the software and that’s it. So you cannot create a company. You cannot, um, you know, get the servers. You, you can, the only thing you can do is like write the software and just make it available. And then somehow for some reason like your whole system, the way you imagined it will be created just because people want to run it. So this is like the software only launch. So, this thing has happened before Bitcoin. There were like glimpses of that. Those of you that have read the um uh you know, about it, in the end of the 90s, there was this proliferation of peer to peer networks. I mean, some of them still running like BitTorrent, etc. So, these are, this is software that does this software only launch. So it’s a network that is created by peers. Um, but these systems are nowhere near the level of reliability and precision that Bitcoin has. So, uh, in other words, what, what I’m saying here is that Bitcoin, perhaps it’s slow, perhaps it has limited capacity, but for 15 years now it puts out a block as programmed about every 10 minutes, and that’s a block of transactions and it does the same thing without any downtime. Basically. So which is pretty remarkable if you think about it, right? I mean, OK, it does perhaps little, but think about a system that is backed by nothing basically there’s no company, there’s no like major stakeholder, uh, there’s no infrastructure, uh, that was invested to run the system, and there’s a system that’s basically run by anybody who wants to go run it and despite that fact it has this reliable. Uh, operation that goes on for 15 years, um, and it was just created, um, in this bottom up fashion. So, so this actually this is the part that’s interesting so this basically opens up the possibility that you can have bottom up change if we want to scale systems globally. Yes, we can have limited companies we can have perhaps a global government at some point but probably unlikely. Uh, but it’s also possible to scale systems globally, so as, as computer scientists we have now another avenue to explore about creating IT systems that can have a global reach, and this is this bottom up approach like it is possible to write the software. And the software itself will make people want to run it. And the software itself will create the conditions so that the system is going to work as designed in a reliable and predictable manner. So such a thing didn’t exist before, right? So, so this is the new thing and this is sort of the um the piece of knowledge that I’m, I’m hoping to transfer. Um, in this, in, in this course. So, so then in the, in the remaining 15 minutes, I’ll tell you a bit about. So this Bitcoin’s approach uh for um uh scaling I IT systems and just to give you an example of course I mean you might say OK Bitcoin is about transferring this this these coins or this digital assets but there is this other thing called smart contracts which is is much more useful than just digital coins so in fact. Um, since we can now create this book, right? And this is what people thought about early on in the history of blockchain systems, we can encode in the book’s pages arbitrary relations between persons. Um, and, and describes themselves, they cannot just record, you know, transfers of coins, but they can actually, um, do tasks like verifying that the different stakeholders in a certain relation. Are doing the right thing subject to a certain contract and they they can even take actions if they do not and by actions here I mean for example uh transferring funds or or imposing penalties and and so forth so there’s a much richer landscape of what can be achieved. By the same techniques and systems going beyond Bitcoin like Ethereum etc. they did those things and now we have things like decentralized finance and so forth so basically things that probably you’ve heard about in the news but we will be covering much more, uh, in the coming lectures. So there’s more things that, uh, that can be done so. So with, so with this, let me give you like a general recipe uh for um you know, thinking about these systems from in this bottom up fashion. So a system like Bitcoin, I call this a resource-based system. Um, it has 4 important, um, dimensions. The first one is resource-based participation. The second one is to economics. The third is the centralized service provision, and the final one is reward sharing. So I’m just gonna cover, um, each 4 of them. And in order for you to launch anything in this bottom up fashion, you have to think about these 4 different dimensions. So I will explain first what what they are. So starting with resource-based participation. So resource-based participation. Basically says that in order for someone to maintain the system or engage in the system in some way. They have to have some type of resource. And this is fundamental to achieve this bottom up effect. In other words, this bottom up effect that scales globally is not preconditioned or or some special permission, right? Nobody’s giving you permission to be part of the network. You do it because you get the software and perhaps whatever else needed to initialize the software and then you just, you just run it. Now in order to run it you need some resources so for example in the in the case of uh the Bitcoin blockchain you just put computational cycles, right? So you let your computer uh do the work but there’s other other things that you can think about here and this is a big area of investigation. I’m not gonna go into it in in a lot of detail, but all of these systems they’re based on this resources, right? So in order to be a maintainer of the system you have to acquire the resources and if you have the resources you can just play, right? So you are introducing yourself to the system by getting the right type of resource. So, so, essentially the key point is that the system is not run by any parties or whatever number is there, but all those entities that are capable of doing this proof of X where X is the resource um that, that is relevant to the particular to the particular system instantiation. Right? This also means that the number of parties that are Are capable of doing that can change over time very dramatically also, right, as it happened also in Bitcoin, right? So you may start with just a handful and then suddenly you may have thousands and then you may have millions and so forth, right? So, so the design should be able to accommodate that. There’s a lot of examples of that. Computational power is obviously the, the first one, but now a lot of it is based on stake, which we will cover, but there’s also other examples like storage, for instance. So there’s a number of different resources that have been used. Now let me come to token economics. This is about the digital coins now the Bitcoin blockchain as well as other systems, they’re based on this fundamental market cycle. So I will explain this market cycle which is the core idea behind how the Bitcoin blockchain works and any other system designed like Bitcoin should work in the same way. On the right hand side you have the maintainers. The maintainers, they just want to participate and do the maintenance, right? So they, they get the resources. So this means that they spend something they spend something to get the resources so, so they incur cost. What are they given? For that cost that they put for for for their efforts, they get some digital coins now why these digital coins are desirable? The digital coins are desirable because they can sell them to other users of the system that would like to gain access to the system to do whatever the system does, so post the transaction, let’s say. So, so this means, and that’s the key point is that. The maintainers, they put effort, but they can’t get paid for that effort because they can sell the coins. So this means that this digital token economy that you might call tokenomics as a as a portmanteau word is a is is fundamental for this thing to work and actually this cycle system means coins gives it as rewards. They are sold to users. The users actually then use the coins to post transactions, use the service goes on and on and on and on. So this is how, uh, basically Bitcoin’s organized. Ethereum is organized. Carana is organized. All these systems are organized in this fashion, and, uh, they work exactly because there is a market. That there is this kind of market cycle that makes it feasible for the maintainers to generate profit. And offset the costs they have for maintenance um if the system has no utility then uh of course this whole thing will collapse because the coins will lose value because nobody wants to do transactions and thus they’re not gonna pay for those coins and thus the maintainers will stop maintaining. Because they’re not gonna have any monetary incentive for um investing resources to do so, right? So this market cycle is fundamental to understand how these systems are organized. OK, um, so the example I gave you is, um, is what I would call market based token economics. And of course it’s preconditioned that all the maintainers they should make enough dollars to to justify the maintenance costs, but you can assume, I mean this market-based economics like you can you you can also think of something else, right? So if you want to think about it from first principles, you don’t have to restrict yourself in that setting so people and maintenance may do things for different reasons, right? So making money is one thing. But they, there’s other things that that people are are are might be sensitive to what’s important is that you should understand what is the incentives of maintainers to engage and then make sure that the way the system works influences their utility sufficiently so that they keep doing it, right? That’s, that’s the key point. All right, so now I’m going to this decentralized service provision. So the centralized service provision is basically how the system does its thing, right? For example, in the case of Bitcoin is a database of transactions. The most tricky part here is that of course you want these properties like safety liveness that I was talking about in the beginning. Uh, or safety or consistency as it’s written here, um, but the other important aspect is that we wanna make sure also, um, perhaps related to liveness that we want to have a denial of service mitigation, um, mechanism. Um, so that’s quite important because it’s an open system, right? Everybody talks to everybody in the network so if the network is flooded, the system doesn’t work, right? So it’s very important that denial of service attacks are are mitigated. So that’s one element and another element is that we should have some way to record how the system maintainers, um. Perform so if they don’t perform well we should be able to know it and by we I mean the system so that it adjusts the rewards accordingly. So basically they shouldn’t be rewarded if they don’t perform well, right? And now the system has to do this. It can be that you as the designer can say, oh, OK, end of the month. I realized Agulos had down time 10 days, so I’m gonna cut his rewards, but there’s no way to do this based on a committee, right? The software has to do this automatically like so it’d be an algorithm that is written and does this automatically and Bitcoin tries to do that as we’re gonna see it doesn’t do it very, it, it doesn’t do it in the most robust way, but it still does it. Um, and this brings me to the last point, this reward sharing. So, The thing is that you have a set of self-organizing resource holders. And you know they are engaged in the system out of their own self interest, right? They don’t care necessarily about the others they’re just there because it’s beneficial to them only to them they don’t care about I mean maybe some of them may have this, you know, idealistic perspective that they wanna do it for the good of humanity but the the line we go with is that they do it out of their own self interest so. So we have to figure out a way to distribute the rewards in a way that is fair. And it should be the case that all the desired properties of the system like safety, liveness, and whatever else we want to achieve. They should come at an equilibrium of incentives. So there should be a game theoretic analysis that says the system working well is the equilibrium of the incentives of the different participants. So, so this will bring us uh at some point in this lectures, uh, the topic of game theory and incentives analysis. OK, so with this, um, I gave you a hopefully a good high level view of how all, all these things work and how they relate to the things we’re gonna talk about the rest of the term. Thank you very much for your attention. Um, we’re done for today. We continue next week and if you have any questions or any, any concerns, please do not hesitate to either post on Piazza or if needed, send an email to me and the teaching assistants. Thank you very much.