BDL Transcripts

Lecture 10:

SPEAKER 0
Work? Oh yeah. Maybe to pro. Yeah, OK. Should be fine. All right. So, uh, welcome to the last lecture of the course. Um, the last time, uh, I was on strike, I thought, I thought about it like for quite some time and I think it was the right idea to protest about the situation. Otherwise, uh, nothing changes. However, I knew that it was also unfair for you to just skip the lecture. Uh, so I wrote some notes that you can find on OpenCourse about at least half of the material that I wanted to, uh, present in that lecture. Today we finish off with everything. Uh, I don’t think I have time to do any Q&A or like uh revision. However, like if you send me an email, I will reply. We can also organise a meeting in person to discuss anything you need, OK? So, I’m sorry for the silence, let’s say. OK. Um, today, we do not talk, uh, about security or stuff so much related with computer science. Instead, we explore the more, uh, economics and financial aspects of, uh, blockchains and distributed ledgers. So let’s start by uh recording what finance is. It’s essentially this discipline that deals with uh the creation of management and uh uh exchange of money and what are called financial assets. So financial assets are non-physical assets, so it’s not a building, it’s not a plot of land, um, whose value is defined by a contract. For instance, stocks and bonds and loans and uh bank deposits are all uh financial assets. Indeed, if you consider uh stock that is a contract that says that you own a fraction of some uh company and Such you have right to receive a part of the profit this uh uh company makes for bonds is slightly different. Like it’s a contract that says that you have lended money to a company or institution, so you have, you have right to receive back that money plus some interest, OK? So the value is given by this contract essentially. And yeah, a financial marketplace is just like a market where you exchange and trade these financial assets. Now, uh, in this course we care about a particular type of finance that is called decentralised finance. So usually in traditional finance when you want to, I don’t know, trade or exchange or create a financial asset, um, you need to rely on intermediaries. This could be banks, it could be brokers, it could be the stock exchange, but you cannot do stuff like directly without talking with somebody else. In decentralised finance you don’t have this, uh, you have no intermediaries, it’s just you dealing with uh the market and the, uh, platform that ensures that this runs smoothly and without anybody cheating is, uh, the blockchain. OK, so essentially here the only trust you are putting is in the blockchain running smoothly, meaning either the majority of computational power is held by honest participants or the majority of stake or whatever, like depending on how the system is designed. OK. Um Now it’s easy to think that you can either classify a system as centralised finance, therefore like the standard, uh, one, in the traditional one or decentralised. Actually it’s not really the case. It’s more like a spectrum where at the two ends you have centralised finance and at the other end you have decentralised finance and you can. Place yourself somewhere in the middle, depending on whether there exists some sort of authority that can enforce some level of censorship in the system. OK. Um Now I’m going to talk about the first sort of application of decentralised finance, namely exchanges and marketplaces. So these are systems whose goal is to match buyer and sellers so that as many of them as possible are happy. In decentralised exchanges, we do not rely on any intermediary, so the whole system, the whole marketplace runs on the blockchain in a decentralised way. Typically we trade between the native cryptocurrency of that blockchain, typically Ethereum, and. And unchained tokens, OK? This could represent anything, OK. And uh uh yeah, what decentralised uh finance buys you is um The fact that you have guarantee that there is no censorship because if I engage with the market through an intermediary and this intermediary doesn’t like me, it could be that they can just prevent me from participating in the market like I want to buy something and they never met my request with any seller, OK. Instead, in decentralised finance, anybody can join the market as long as the blockchains run honestly, so as long as there is an honest majority. OK, uh, other differences between, uh, centralised finance and decentralised finance in terms of exchange, um, so in decentralised, uh, finance, typically you pay a fee for every order you make to the exchange and for every cancellation you make in, uh, to the exchange. Whereas in, uh, uh, centralised finance, typically you pay a fee when there is the match. Another issue is that decentralised finance is somewhat slower because like it needs to run on the blockchain, like, uh, essentially security and has a cost and, uh, also, uh, decentralised finance is less regulated from a legal point of view, so there are no, know your customer or anti-money laundering provisions, which is also what some people want. Um, OK, so how can we build a, uh, an exchange on the blockchain? So, in, uh, um, traditional finance this is typically done through an intermediary that, uh, runs this order book, uh, um. Algorithm, let’s say, essentially they keep track of all the uh offers of sellers and all the requests of buyers and they order them in this book according to their value. So typically you end up with a structure like the one you see on the slide. So uh the uh value that the sellers request is higher than the value the buyers are willing to pay. So the uh proposal of the uh sellers are typically more on the right and the uh request of the buyers are more on the left. The gap in between the max bid of a buyer and the mean ask of a seller is called the spread. And the value in the middle is the price. Now, in this example, you have this positive spread, but sometimes it could be that the two halves overlap so the spread becomes negative. In that case, you have a mat. Meaning you can remove the max bid and the minus from the book and you say, OK, this is a transaction that can happen because in that transaction like uh the uh seller is happy to receive uh what uh the buyer proposes, OK? Now, in the centralised finance, you can uh create a smart contract that does exactly this. Like, it’s a smart contract that receives uh requests and offers from buyers and sellers and then it runs this algorithm to match them like uh to uh do the exchange. There is, however, another uh interesting uh solution that is uh faster probably in uh making uh matches. And this is called automated market makers. So essentially this is a smart contract that keeps a pool of money from various cryptocurrencies. So in this example, there are just two, it’s cryptocurrency A and cryptocurrency B. Now, um, what it, how it works is the follow wing, so If I want to convert some amount of cryptocurrency A into cryptocurrency B, I’m going to send my money into the smart contract. It will join the pool of cryptocurrency A, and the smart contract will automatically send the corresponding amount of cryptocurrency B to my account, OK, so it takes it from the pool and sends it to my account. Um, There are of course two questions that are interesting here. The first one is, how is this money set up in the smart contract. In the first place, The answer here is that people like any of us can contribute to this. Like we can give our cryptocurrency to uh the automated money maker, uh, market maker, and the uh. Like in exchange, we get a cut of the exchange fees that like it makes from this uh sort of service. Um, the other question is how does this smart contract set the prices, because of course the exchange rate is not fixed. Like it needs to go up and down depending on the law of supply and demand in the market. However, this is a decentralised solution, so there is nobody that can say, OK, the exchange rate is this one, so everything should be determined algorithmically by the uh uh by the smart contract. So how Can we do this? And this is probably the most interesting idea of this system, namely we keep uh the product between the amount of cryptocurrency A and amount of cryptocurrency B constant. Why essentially here the idea is that if the amount of cryptocurrency in the pool is very low. It must be that cryptocurrency is worth a lot. Like, and also if I see it decreasing, it must be that I’m selling A for a lower value that it actually is worth, right? So, I need to increase like uh like the exchange rate. Accordingly, and yeah, with this particular choice you preserve that. You see, if one of the two values goes very uh. High, essentially, the other one becomes more. And now I will explain how like the values are really computed. I will do it using the board and let’s do it this way. So So suppose we have uh oh well. That’s good. So we have our smart contract, the automated money maker. Uh, market maker, sorry, and we have pool A. And pull beat And at first there is amount of cryptocurrency X in A and amount of cryptocurrency Y in B. Imagine I want to convert an amount of cryptocurrency X of A. And this will join. The pool A and from pool B, the smart contracts will give me an amount Y of cryptocurrency B. And the goal for the smart contract is to keep X times Y constant. So this is the goal. This means that. When I do this conversion, the amount of cryptocurrency in the two pools changes. Now, the amount of cryptocurrency in pool A is going to become X + X because this amount was added in. The amount of cryptocurrency in pool B is gonna be minus Y because I took Y out of it. And yeah, we want this product to remain constant, so this is gonna be equal to x times Y as before, right? Now, do all the math, so you can uh compute this product. You have XY, you have XY, and then you have essentially um Y times, sorry, minus Y times X + X. Equal to xy That this kind of resolved. And you end up with Y prime, which is the amount we get out. Being equal to um. X Y divided by X + X. This is the formula. That uh the automated market maker uses to uh compute essentially how much we need to send to the other. Like, uh, to back to the account. Now, a crucial observation. What happens if X is much smaller than X. So essentially we are trying to convert an amount that is very small compared to the amount of cryptocurrency in the pool. Well, in that case, You end up having that Y is roughly X times Y divided by X, right? Which is exactly what I was saying at the beginning. Like the conversion rate essentially set depending on the ratio between the amounts of the two cryptocurrencies. And yeah, this X here is added because essentially um we want to increase the price as like you uh like convert money. If you convert a small amount, you get a rate that should be roughly divided by X, but like if you increase this amount like uh the rate should increase as like uh you increase the amount of money that you uh like uh try to convert. OK, Question, yeah, so let’s say like a new token

SPEAKER 1
is launching, for example, and let’s say it’s E and I set up a liquidity pool, uh, allocating one E for like 10 USEs or something like that.

SPEAKER 0
Instead of allocating, sorry, I’m allocating, let’s say 1 be

SPEAKER 1
for, uh, that’s one token. Another token is 10 USDC, let’s say. So let’s say there are no other liquidity pools on the market. Does that mean that, um, people will be forced to trade, uh, one need just for 10, even though the real market value is something?

SPEAKER 0
Yeah, at the beginning, yes, like then probably people, so unless people add more, uh, liquidity on each side, it

SPEAKER 1
won’t change the price, yeah, yeah.

SPEAKER 0
But like uh the idea is that then at some point the market will balance itself like. Uh, let me go back to the slide, yeah. Sorry, can you please explain that once again, the last one. This one, yeah. So if X is much smaller than X, take this formula, you have that X + X is roughly X, right? Yeah. Like, so I’m just taking this formula and replacing X + X with X, right? Yeah.

SPEAKER 2
Do that. Check, is it like find the amount of So the smart contract, is there like a certain point at which like becomes considered like much smaller than that.

SPEAKER 0
No, no, I mean the smart contract doesn’t do this check of X. The smart contract just executes this formula. What I’m saying is that if X is very small compared to the total amount of, uh, cryptocurrency in the pool, then you end up having that the, it’s as if like, uh, you have a fixed, uh, like conversion rate, OK.

SPEAKER 2
But this keeps it like proportional I guess to the amount it uses the amount of cryptocurrency that’s in in

SPEAKER 0
the pool, yeah, to determine to like adjust this formula that gets affected by. And this is indeed what is happening, right? X and Y are the current amount of cryptocurrency in the pool, and when I want to convert some amount x like the uh smart contract, like uh calculates how much uh of cryptocurrency I have to give you depending on the current values of uh cryptocurrency in the pool, right? OK. Yeah OK. um Now, there are some attacks that we need to pay attention to in decentralised exchanges. And the main one is called front-running. This is actually something that can happen in centralised exchanges, especially those that are uh unregulated. So, uh, here the attacker, uh, exploits, uh, how the blockchain works. So remember like when we make a transaction, first we sign it and we broadcast it to the miners and then, uh, the miners will take care of organising all transactions in a block and then the blocks are added to the chain. Now what an attacker can do is they wait to see what transaction I want to make. Then depending on what they see, they may want to issue as a transaction and they put like the gas fees higher so that miners are incentivized to put their transaction on the chain before mine. OK, this is front running and it can be problematic for the following, uh, sandwich attack. Essentially imagine that I’m, for instance, trying to, um, convert a large amount of bitcoins into ether, OK? Or I think that in the slide it says vice versa to convert a large amount of ether into bitcoins. I broadcast my transaction. An attacker sees it and decides and essentially can infer that if I’m buying a lot of bitcoins, the price of bitcoins is going to rise. So what they can try to do is they Issue a transaction with high gas fees so that it gets added to the chain before mine that buys a lot of uh bitcoins. This increases the price of Bitcoin. My transaction gets validated. I buy these bitcoins at a higher price. And the price keeps going up. And after this transaction has been put on the chain, the adversary can resell whatever uh they bought like uh earlier at a higher price than the one they spent earlier, OK? So essentially what is happening is that the attacker is making a profit through this attack. Um, and who is losing is actually me. The victim of the attack. Um, OK. The second type of application on decentralised finance are loans. So how do they work in the real world? Imagine we have Alice that is a customer and Bob is the lender like a a bank. Um, Alice ask, uh, sends an application to Bob for a loan of $10.Typicallywhathappensisthatthebankchecksuhthisrequest,ituhassessestheriskofdefault,uh,maybeuhitasksforsomecollateral.Andthenproposessomeinterestrate.Essentially,uh,Alicecanthen,uh,choosewhethertoacceptornot.Ifsheagreeswiththis,sheobtains$10 from the bank. And at a later point in time, she either sends back uh the money X plus the interest Y to the bank and she receives the collateral um or uh she declares default and she pays back less than X plus Y and like at that point, the lender would need to figure out like uh how to use the collateral or like a part of the collateral to, to get back that money. So in the centralised finance, you can kind of do the same thing but While previously in real world loans, like the borrower essentially needs to trust the lender that they won’t run away with the collateral and that they will do everything honestly in the centralised finance, you don’t have that. So now you will have a smart contract that deals with everything. The only thing this smart contract needs is some sort of oracle that tells them the value of any assets on. That could be on the chain. This is essentially to estimate the value of the collateral. So, uh, to get a, a loan in a decentralised finance setting, um, the lender starts by putting, uh, the money on into smart contract. Um, the borrower can take this money. Potentially doesn’t even need to know who the lender is. They just put the, uh, they just retrieve the money from the smart contract in exchange for a collateral that is owned by the smart contract at that point. And then at a later point in time, they can give back the money plus interest and in exchange they receive back the collateral. When this happens, the lender can also retrieve the money. Like they invested plus the interest. The only thing to pay attention is, uh, what if the value of the collateral drops too much. In that case, the smart contract automatically uh liquidates the loan. That means that, uh, the borrower uh pays back the, uh, money, uh, they borrowed plus some small amount of interest, like essentially a discount on the interest and they get back the uh uh collateral, OK. There is another very interesting um type of loan you can do in decentralised finance, and these are called flash loans. Essentially flash loans are loans that can be taken and paid back all within one transaction, like essentially having no risk of default. They work like this. First, in the same transaction, you take some amount of money x from the lender. In the same transaction you use this money x as you want potentially making a profit from it and then again still in the same transaction you pay back x plus uh interest like uh you agreed upon. If for some reason this fails and when you try to spend the money x, you don’t make enough profit to pay the interest and also the money back, uh, simply the transaction doesn’t get validated, so you have absolutely no risk. Yeah, like, I, I didn’t, I didn’t get like how

SPEAKER 3
does it happen in a single atomic transaction because, uh, operationally speaking, why would you take a loan and then pay directly with the fees? What, what sort of real world application does that apply

SPEAKER 0
to? Like what kind of, can you repeat the question? I understood that here you, you take the loan and

SPEAKER 3
then you directly pay the fees in one in one transaction, but did you use it actually? Did you use it? Did you have time to use that?

SPEAKER 0
It’s just a block of transactions. Like, yeah, you like as a second transaction, as a second part of the transaction, sorry, you use that money. Like what I can do is like this. I borrow the money, I spend it in some way and like this, I don’t know, like immediately gives me back the money. And because it could be a smart contract, I don’t know, like, and uh uh I spend immediately that money to give back like uh x plus interest to the uh lender, yeah, yeah, so let’s say the transaction, uh,

SPEAKER 1
let’s say the borrower after they borrow the x amount of money from the lender and they’re not able to pay it back, the transaction does not get, so if

SPEAKER 0
it fails, does that mean the money is sent back

SPEAKER 1
to the lender again?

SPEAKER 0
No, it’s not even like, like, uh, borrowed like it’s a transaction like there’s one like, uh, whoever validates like uh the transaction and add it to the chain can check whether everything goes smoothly or not. If it does not, it’s never that never gets, yeah, it doesn’t even because it’s all part of one.

SPEAKER 4
Yeah, and how exactly does this happen, like one single transaction, because if you want to. Like send money to another contract. Like you have to call the function of this contract and it’s like it’s all transaction.

SPEAKER 0
I do not know exactly the details. I guess it depends a lot on the uh exact instantiation of this, but like uh these things exist. Yeah.

SPEAKER 5
A general question on all of the finance applications. Why do we put so much trust into the blockchain to actually work if we cannot like figure out how it actually works or like have some form of actually making sure that the contract does exactly I mean, as

SPEAKER 0
long as the majority of computational power or stake or whatever is that is not my question.

SPEAKER 5
My question is, is there a way to actually check whether the contract has no bugs at all?

SPEAKER 0
Everything is public, right, like in the blockchain.

SPEAKER 5
But is there an actual like way to do that unless you have to do it by hand?

SPEAKER 0
Oh yeah, of course, like some degree, like if you do by hand, like you can be sure, but like if you don’t want to deal with that, you just need to trust like like this idea of complete trustlessness like it doesn’t work. Like you need to. Like the trust is that if you, you have the possibility to check that uh there are no bugs, that uh, that there is no issue. Uh, I agree that like uh most of the people will use this object without like uh in some way trusting something, but that becomes a little bit philosophical as a, a question, right?

SPEAKER 5
But in that case, do we not just transfer the risk from like or maybe the person doesn’t like me to, or maybe the contract or like something in the system of the translation from the higher or the language into the actual byte code is faulty and that’s why they can run away with everything, yeah, I got exactly

SPEAKER 0
like it’s kind of like you put the you put the trust all onto the user, like all the responsibilities are onto the user. Like that is more or less what is happening, uh, here. So for concern, I, I agree with what you’re saying, yeah.

SPEAKER 6
I guess I have a question that relates to both of these types of decentralised loans where I think I’m struggling to understand what what collateral means in a blockchain context when if it’s kind of all, I mean liquidatable assets normally, you know, you might have collateral for your I mean you’re not willing to liquidate your house in order to spend the money so you can make a loan for it. But in this case, like if you’re putting in more collateral than the the size of the loan, but the collateral itself is just. A liquidable asset and why don’t you just spend the liquid asset?

SPEAKER 0
It’s not true that like all assets are really liquidatable because like you can for instance imagine a token that, I mean, of course this is not happening happening today, but a token could represent the ownership of your house, right? Like, uh, it’s not happening today, but in principle you can have something like this, and you can generalise this. Like tokens sometimes are, uh, indeed like non-fungible tokens like, uh, and like there may be a reason why you would need to do that. Yeah. So is, is that, is that how the loans are

SPEAKER 6
playing out actually on the blockchain where the, the nature of the collateral is an NFT or something?

SPEAKER 0
I think that a lot of this, I. Not entirely sure because I don’t deal exactly with this action. My, my intuition is that loans is not really like what why people invest in blockchains today, OK? Like, uh, we’ll discuss it like uh towards the end of the lecture, yeah.

SPEAKER 7
Because there’s like no risk of defaulting one of these flash loans, yeah, could you just not, could you just take out loads of these loans and make really like risky moves until one of them pays off.

SPEAKER 0
Yeah, because, yeah, kind of, yes. I mean, of course, a lot of other people will try to do it like. Yeah. Yes, yeah, for some context on the loans, like lots

SPEAKER 8
of loans are issued, uh, against ETS. If you expect there’s going to be a positive ES price increase, it makes sense to take out a loan and use money to do stuff now, because then you can like liquidate the loan yourself and you get back way more. to a positive price increase in.

SPEAKER 0
Yep. OK. OK, we need to talk also about attacks in these systems. Uh, the first one is through this oracle that essentially uh estimates the value of any asset that you have on the chain like, uh, how is this implemented? Usually it’s centralised or partially centralised. So you have a kind of like single point of failure there if that, uh, guy, company, whatever that like this with uh providing the chain with an estimation of values. colludes with one of the two, like the borrower or the lender, there could be stuff that goes wrong. Another thing that 1 may need to pay attention to is risk-free arbitrate. So essentially it could be that there could be at some point in time two exchanges that have the same. convert the same pair of cryptocurrencies at different rates. And so what one could do is you buy a lot of cryptocurrency from uh the um The exchange that sell it for cheaper. And you sell it to the other exchange at a higher price. And if you don’t have enough money to do that, you can just take one of these flash loans to make a huge profit out of it. Does it make sense? It’s risk free. Like, uh, you get a lot of money, of course many other people will try to do it, but like, uh, yeah, in this case my question would be why

SPEAKER 5
would you even do the decentralised finance because you, the only one, the only advantage is that the entire responsibility is on yourself, but you get the same problems that you anyways have and stand or you have the same issues that you have in standard finance, plus lots of additional issues. Why would you even there is one thing that it

SPEAKER 0
buys you like the fact that there is no censorship. Like, uh, that it’s decentralised. So I agree with this, uh, statement, like, uh, indeed I’m quite critical myself to the world, this world, but, um, Yeah, like for some people the fact that there is no censorship is important. Like, uh, if you are, I don’t know, in the country in which like, uh, your government doesn’t allow you to like essentially. Do any sort of uh active like economical activity because I don’t know like political reasons like sometimes blockchains can uh provide a solution and there are examples of this but like I agree that for our world Western world I don’t think like they really buy much to us yeah.

SPEAKER 5
In the case that you are in a country where you cannot do those economical actions, how do you even get access to a blockchain in the first place, which means you anyways did do stuff like you need to have a computer, you need to have internal access, and you need to get to the blockchain. You are a country that already senses your economical.

SPEAKER 0
Yeah, I agree. Just, I mean, in, in practise this is happening. So like, uh, there is Thor that like can hide like, uh, the fact that like you are dealing with the blockchain, uh. But then I don’t have exactly an answer like, uh, it’s probably easier to find a computer than like to like, uh, I guess my question is more like what

SPEAKER 5
does it have to do with the overall rest of the course, like the entire finance part. Sorry, I can, I can see that the basic foundations of like blockchain that they are taught here, but like what does this have to do with the rest of the course of that’s like overall connect to it because it just feels like somet topic or I agree like

SPEAKER 0
uh but this is a such. The issue is that this is what blockchains are today. OK. Like there is all the part we discussed about security and the computer science that I find in my opinion, more interesting. But like, this is also what is happening in blockchains today and I think that as part of a course on blockchains, we need to talk also about this, OK? OK, final, uh, kind of attack, it’s was trading. Essentially here the idea is you take a flash loan to artificially increase like the, um, trading volume like, uh, especially towards some new coins that enter the market. What is the goal here? Just, uh, artificially increase the market capitalization, um, fake, uh. The uh demand like artificially increase it so that like you attract other investors and potentially run a scam against them, OK? Like uh first attract people and then just leave everything and run away with the money.

SPEAKER 1
Yeah, uh, so you don’t how you mentioned you can use a flash loan to let’s say buy a one deck and so on the other, right, um, so my question is, in order to buy the, uh, buy a token one deck first, you would need the loan to come to your account or your address, right? Sorry, like, for example, if you’re using a flash loan and you’re planning on buying a token with that flash loan, you would first need the, uh, money to come to your address, let’s say, right. But you said also that it would fail if, uh, you weren’t able to pay it back, right? Essentially, how would you know if it was even uh like profitable in the first without the money coming into your account in the first place?

SPEAKER 0
No, but like. I do not know exactly how each platform implements these flash loans, but what is happening essentially is you take the flash loan in one transaction with that inside of that transaction you borrow the like you convert that money uh from the decentralised exchange. Inside the same transaction you sell it to the cycle and decentralised exchange and then again still part of the transaction you send back the money. OK, so if any of these steps, no, this is one step. Like it either all goes through or it all fails. If it all fails, it’s not even added to the chain, so you have zero risk. If it gets on the chain, you, you get the profit, yeah, I think I’m, I’m close to understanding, but

SPEAKER 6
why is WS trading a more like a more, uh, conservative way to like pump a stock rather than just directly spending the money on the cryptocurrency for WAS trading

SPEAKER 0
because typically you don’t have like the cryptocurrency amount like, like you just need to. I, I didn’t understand. Like what you’re saying is like I come up with my new token and I just pump in money like uh but maybe I don’t have it. I need to take a loan like uh to just fake.

SPEAKER 6
But you need that money anyways yeah, but you, you’re

SPEAKER 0
gonna use the flash, yeah, but yeah, sure, but you just like, uh, have money that gets in and gets out like, uh, like through the flash loan essentially you kind of simulate like a lot of flow of capital that goes in and out of that token and that attracts like, uh, investors. If if it’s in the same transaction where you’re in

SPEAKER 6
the same transaction repaying the loan that you just took out and some fees. And in the in between that step you’re, you’re basically you’re pumping a lower value for a new coin. How is that not just the same thing as just

SPEAKER 0
pumping you can take multiple, you can take multiple flash loans like you repay like one through another like uh like so you can do some more sophisticated stuff than just like uh like take and send back, right, yeah.

SPEAKER 5
Yeah, a question on the flash loans, I suppose it is very implementation specific, but are they implemented in a way that if you take a loan, you know exactly which Bitcoins or if it’s bitcoins, which coins you gave out in that loan and send back, like which loans, like which coins you put into the AMM and which coins you get out of the AMM, or is it anonymized.

SPEAKER 0
I don’t think that in Bitcoin is like this works because it doesn’t have yeah what you’re saying is repeat the question is it anonymized like we have seen it that depends on the platform like uh and the, the

SPEAKER 5
second question is the watch trading if we have like some form of privacy and we anonymize, like is there something that can like catch you for was trading if it’s illegal, for example, in most parts I assume it’s not only illegal in the US to do things like that. But you like you can just do it without any legal consequences.

SPEAKER 0
I mean like that is a bit like the issue with all this cryptocurrency that they are in a very blurry like state like even I don’t know like a country has a legal system that. Works within a certain like uh I don’t know, part of land, like where does this transaction take? like uh where is this made? Like it’s just on the internet, it’s everywhere like uh so which legal system would take care of like uh this? It’s all a blurry line, so. That is the issue, yeah. No, I agree, like, uh, totally agree. In my opinion, this is like, uh, the, uh, lecture in which, I don’t know, in principle, this is an amazing technology and then this is the lecture in which you see that in the world stuff is quite disappointing in my opinion, but like, then it’s up to you. OK. Uh, next we need to talk about market capitalization. So market capitalization is essentially something that tries to measure the amount of wealth and assets in a particular system. In particular, we will care about cryptocurrencies. And this is equal to uh the total amount of cryptocurrency in the system which is easily quantifiable uh times the price of a single unit of uh cryptocurrency. Now, The difficult part is estimating what is the value of a single unit of cryptocurrency because this is defined by the market itself. There is no centralised authority that can say this is worth this amount of money, right? And uh this keeps fluctuating depending on the uh law of like supply and demand in the market. So, one possible way we can uh estimate this is through um essentially the latest price for which that a unit of cryptocurrency has been sold for something else uh in the market, OK? Let’s give an example. Imagine we have again Alice and Bob. Um, Bob has some, uh, uh, standard cryp uh currency, for instance, dollars, and Alice comes up with this new revolutionary idea of a new, uh, coin, uh, she called Bitcoin. So of course this is just an example. Now in the Bitcoin system, uh, there is only one circulating token owned by Alice, but the price is still undefined because that token has never been traded so far, so the value could be whatever. And as a consequence, the market capitalization of market cap for short, is still undefined. But now, imagine we see that Alice sells the Bitcoin to Bob for $1.Nowwehavesomeinformationtoestimatehowmuchthissystemvaluesthattoken,namelyroughly$1 because if both parties agree to exchange this, it means that 1 Bitcoin is roughly worth $1right?Whywouldtheotherpartyhaveagreedonthisotherwise?Andyeah,sothepriceissetto$1 market capitalization, that is the product of the two is $1.OK.Nowle{t}^{\prime }scomplicatestuffandintroduceanewuhparty,Charlie,thatalsohadthisamazingideaofcomingupwithanewcryptocurrency,uh,hecalledituhetherandthewholesystemiscalledEero.SointhetheoremsystemnowthereisonlyonetokenownedbyCharlie.Thepriceisstillnotsetbecauseinthisexample,thisetherhasjustbeeninventedandithasneverbeentradedsofar,OK.Butnow,ifweseethatCharliesellstheethertoBobinexchangefortheBitcoin,wecanconcludethatroughlythevalueof1etherisequaltothevalueof1BitcoinandfromthepreviousexchangebetweenAliceandBob,wehadthatuhaBitcoinisworthuhroughly$1 so we can estimate that the value of 1 ether is $1.ThecapitalizationoftheISAsystemisgonnabe$1 product of these two. And then the total market capitalization is the sum of these two, therefore 2, like total meaning of the two cryptocurrencies together, OK? The important thing that you need to know is that these two values are not fixed in time so they can change. So imagine that now Charlie buys back half an ISA uh uh from Bob um in in exchange for one bitcoin. What’s happened here is that the value of Ither with respect to Bitcoin went up, right? Earlier, with one Bitcoin, you could buy one ISA. That was the exchange between Charlie and Bob earlier. Now with 1 Bitcoin, you can buy only half an ISA. So, essentially this means one ether is worth 2 bitcoins. But based on the previous estimation, a Bitcoin is $1sothatmeansthatthepriceofEtheris$2. And the market capitalization grew to 2. The other one remained unchanged. Next, imagine that you see Alice that buys half a Bitcoin for $1.WhatwecanconcludeisThevalueofBitcoinwentupwithrespecttothedollar.Atthebeginning,Alicetraded1Bitcoinfor$1. Now, um, with $1shecanonlybuyhalfaBitcoin.So,youunderstand,oneBitcoinnowisworth$2. So the price grows to 2, but also the price of ether changes because remember the price of ether was only defined through in relation to Bitcoin, right? We never saw like an exchange between ether and Bitcoin, uh, ether and dollars. So, one ether is equal to 2 bitcoins. This is because of the previous transaction between Charlie and Bob. One bitcoin is $2itmeansthatoneetheris$4. And yeah, the capitalization grows to 42, and in total 6. Now imagine that we pump in new coins in the system without spending them so far. So now imagine there are 1000 bitcoins and 1000 ether. No, uh, transaction has happened so far. What happens is that the market capitalization, uh, becomes 1000 times as much and then it grows to 2000, 4000, 6000. Of course, like when we inject so much, uh, money in the system, there will be consequences. Like it means that probably, uh, in the next transactions these two prices will go down, but like this is just inflation. But in the moment in which this transaction hasn’t yet happened, like this is the situation. OK. Is that, no, OK. Um Yeah, of course this is a very simple system with the participants like the world is much more complicated, but there are websites that compute the market capitalization of the various, uh, cryptocurrencies. This was from 2022 and you see like this is the ranking of all, uh, um, cryptocurrencies by amount of capitalization which is this, uh, column here and you saw like Bitcoin had like 318. A billion dollars capitalization. Ethereum was roughly half of this and like it goes down quite quickly. In 2024, uh, this had increased like crazy. Uh, Bitcoin had $2000roughlyalittlebitlessthan$2000 billion of capitalization, uh, Ethereum like uh 375, roughly $1000375billiondollarscapitalization.So,thereisonethingthatyouneedtopayattentiontobecausethismarketcapitalizationisjustanestimate,OK?I{t}^{\prime }snotnecessarilyuhthegroundtruth,le{t}^{\prime }ssay,uh,maybebecausethereisnogroundtruth.Um.Firstofall,marketcapitalizationcanbeincreasedartificially.WeexplainedthisforflashloansandthishappensespeciallyforlikeuhshadycoinsthatareaddedtothemarketjusttolikeuhumTrytolikeerattractlikeinvestors.TheotherissueisthatThemarketcapitalizationdoes{n}^{\prime }tnecessarilyrepresenttheamountofrealworld.Likewealththatisinthesystem.Um,thisisespeciallythecaseinmyopinionforcryptocurrenciesbecauseliketypicallycryptocurrenciesarenotboughttoexchangetobuyassetsandgoods.Liketypicallytheyareusedasacommodity.Youbuytodayandyouhopethatthevaluegoesupsothatyoucansellittomorrowforagreateramount.Soessentiallythisvalue,uh,thatisassociatedliketomarketcapitalizationisalotbasedonhopethatthiskeepsgrowingupandIcanmakeaprofitoutofit,buthopeisnotreallyreliable,OK?Likeuhitcouldbethatliketomorrow.Like,uh,um,Ido{n}^{\prime }tknow,maybeithasjustalreadystartedlikepeoplewanttolikemoveawayfromcryptoandinsteadtheywanttoinvestinAI,uh,andthe,youcouldstartseeinglikethethecurvestartgoingdown,peoplepanic,theystartsellingandstuffcancrash,so.Marketcapitalizationtellsyouhowmuchlikeuhthesetokensareworthtoday.Tomorrow,thingscanchangequitequickly,OK?OK,um,thisissueoflikepricesgoingupanddown,um,isproblematicingeneralfor,uh,theeconomy.Becauselikethemoreunstableaneconomyis,themoreinefficientessentiallyitbecomes.Thatiswhysomepeopletrytocomeup,uh,withwhatarecalledstablecoins.Thesearecoinsthatintheoryshould,uh,remain,um,whosevalueshouldremainmoreorlessconstant,OK?Thisintheory,inpractise,uh,le{t}^{\prime }ssee,thefirsttype,uh,arecalledfiat-based,uh,sorry,fiat-backed,uh,stablecoins,andessentiallyarestablecoinswhosevalueis,um,tiedtothatofatraditional,uh,currencylikeUSdollarsorBritishpoundsorwhateveryouwant.Essentially,uh,thereisa,um,centralisedexchangethatissuesthesecoinsinexchange,uh,fordollars.Likeforevery$1 you get one of these, uh, stable coins, and, uh, the promise is that at any point in time you want to, um. Like, uh, convert back your stablecoin to, uh, US dollars, they will do it. Like, uh, the rate is fixed, is still one coin for $1andum.Theyessentiallyguaranteethatwhatevercoin,whateverdollaryouputintothesystemwhenyouboughtthecoinwillbekeptthereandisreadyforyoutobetakenbacklaterwhenyouwanttoretrieveyourdollars.So,firstofall,whywouldanybodywantthis,uh,liketousestablecoinsinsteadofdollars?I{t}^{\prime }sessentiallytheyarekindofthesamething.Andthereasonis,uh,onepossibilitytoengagewithdecentralisedfinancelikeonthechain.Um,theotherreasonisbecauseyouwanttobenefitfromthefactthatthesesystemsaresomewhatderegulated.Soyoucanbypasscapitalcontrolsandyoucanavoidknowyourcustomeruhanti-moneylaundryuhrequirements,OK?UmWhyarethesestablecoinsproblematic?Um,well,becausesometimesthispromisethatforeverystablecoininthesystem,thereisa$1 ready to be given to you, uh, breaks, and when that happens, of course, they try to keep it secret because otherwise it can generate panic. Typically what uh this uh centralised exchanges do is they try to issue loans so that they can get back some of this money through like their interest or uh they can insert uh liquidity artificially into the market like to pump up investment like in uh that stablecoin and like uh for instance using um like flash loans. Or no, sorry, in this case it does not work because like it’s dollars to stable. Uh, anyway, um, the issue is that if regulation tightens and the break of this promise becomes uh uh public knowledge. It really starts a panic in the market. Like people will try to sell their their stablecoin for dollars and at some point somebody will remain without anything and the whole system collapses. Um, the main stablecoin of this kind is tether. That is by far the largest stablecoin in general. It’s rather murky, so we don’t know exactly what is happening there. There have been some accusation of misleading behaviour. Uh, it’s known that De Tether doesn’t own $1foritsamountof,uh,stablecoininthesystem.Andthisisespeciallyworryinggiventheamountofcapitalizationinthissystemlikeyouseelikein2024itwas$132 billion and even more worryingly, um, the daily trading volume of uh this uh cryptocurrency is huge. Like it’s even this was 2024. I checked yesterday how it is in 2025. Actually the capitalization is bigger than uh the daily trading volume, but, uh, you know, like uh there is the risk that at some point like this is very unbalanced and like uh you’re not able to like uh like like the promise essentially breaks completely, yeah.

SPEAKER 5
Just a question. Does that not effectively make it the same thing as the US dollar with the like it’s the same as any physical currency with the exception that you can’t trace it, so it’s better to do illegal things with it.

SPEAKER 0
Uh, no, there is also like that you can do decentralised finance like, uh, like it goes back to this thing that if you want like some port of decentralised

SPEAKER 5
finance with an actual US dollar, you would not need the token in between like you could do it with the actual.

SPEAKER 7
Yeah.

SPEAKER 0
decentralised finance with the actual currency like with the, no, I mean like uh if you have, you want to send some money like from here to another country like you need to rely on some intermediaries, right? Like uh with decentralised finance, you do not necessarily do that. Like uh it could be like legitimate, it could be shady, like I agree, but uh. That is the idea, the fact that like you have no intermediaries like there are some cases of people like uh that uh would benefit from that uh for reasons that morally I would consider OK like uh and yeah, there is also like all the people that do it to avoid like uh like to bypass essentially checks and like uh anti-money laundering like uh. Yes.

SPEAKER 2
Like it’s known that Tether doesn’t have $1 for every

SPEAKER 0
yeah, amount of stablecoin.

SPEAKER 2
How is that not more problematic? I mean, I thought that we said earlier that like that broken 1 to 1 promise could like cause.

SPEAKER 0
Oh, indeed it is. It is like problematic. It’s just that. I don’t know. I don’t think that the market is so smart. Like, uh, maybe some people know that, yeah, yeah, it happens. Like there is also, I don’t know, like you take Dogecoin, like, uh, like cryptographically speaking, it’s completely broken, but still people invest in it because, like, uh, Elon Musk says, uh, it’s a good idea, like, uh, that happened. Like, uh, it’s not that the market is necessarily smart, yeah.

SPEAKER 6
And just to clarify as well, it’s not saying that Tether has no total assets which equal to at least $1 per.

SPEAKER 0
No, that is what I’m saying. Like if it takes it cash or is it total

SPEAKER 6
actually total assets it basically has been massively mismanaged such that they’ve lost money. I do, it’s murky.

SPEAKER 0
So, but like what is, I do not know the details, but what is known is that Tesla doesn’t, like it’s not able to to have this promise if everybody now decides to. Convert Tesla into like dollars, but that would be because

SPEAKER 6
of the amount of cash they have on hand, not because of total assets.

SPEAKER 0
I do not know. I do not know. It’s like a bank doesn’t do that. Yeah, yeah, yeah, I agree. I agree, but like my, I think that it’s more like the total amount of assets. Like there was some sort of mismanagement, probably it’s difficult to tell.

SPEAKER 5
Why is the EU 1 to 1 promise such a big problem when it breaks, because technically that holds for any physical currency as well, and 1 to 1 promise is known to not work exactly because this is a

SPEAKER 0
lot based on like real world economy is based on something like, uh, here like there is less stability essentially like, uh, it’s more easy to lose trust in this like, uh. Yeah, um, another type of, uh, stablecoins are those that are crypto-backed. Essentially they try to keep the value of the coin stable, uh, by relying on another cryptocurrency as some sort of middle ground. Essentially, uh, these do not, do not need this centralised exchange, like, uh, it’s more decentralised. Essentially, you have a smart contract that has access to this oracle that, uh, tells prices and typically the oracle is centralised, but it’s less, uh, centralised than the previous solution, let’s say. Um, and yeah, the smart contrast gives you, um, Uh, um, like a stable coin, if you, uh, put a collateral in the smart contract of, uh, let’s say 2 ethers, assuming that one ether is $1essentiallyyouovercollateralizelike,uh,whateveryouputintothesmartcontract.Andwhenyouhavethe,onceyouhavethestablecoin,youcandowhateveryouwant,andifyouwanttoconvertitbackintodollars,youfirstgivethestablecoinbacktothesmartcontractthatreleasesthetoether,andthenyoucanturnitintodollarsagain.Theonlythingyouneedtopayattentioniswhatifuhthevalueofthecollateraldropsbelow$1 that is the value you want the uh The stablecoin to have. In that case, uh, the stablecoin is immediately liquidated and you receive uh two ISA, OK? And examples of this sort of stable coin is called dye. OK, uh, there are some issues with this, uh, solution. First of all, it doesn’t take into account the fact that, uh, the value of the collateral can increase over time, right? And so one can make a profit out of it. Um, the idea is the following. You, let’s start with one coin, but of course you can scale it up like to any amount you want. Um. You, uh, mint one coin, uh, putting like 2, ISA on the smart contract. Then as soon as you get, uh, the coin, you, uh, sell it for ISA, but not like with the collateral, the value of the market, right? And then you hope that uh the value of ISA goes up or you try to actively engage with it so that it goes up. And uh when this happens, you can rebuy a stablecoin like uh for a fraction of what like you have spent uh earlier. And you, out of the stablecoin, you can get back the two eSOs. So, do all the math, you get a profit. And the reason is because essentially, the value of the stablecoin remains the same, like it’s $1thatisthewholegoal,right?Instead,like,uh,etherhasgoneup,right?TheotherissueiswhenthevalueofISAgoesdown,like,becauseifitgoesdownitcouldbethatsomeoftheseumum.Um,collateralsthatareputonthesmartcontractdropsbelow$1. So those uh stable coins are immediately uh liquidised. Whoever ends up like so who’s uh stablecoin um gets liquidated like had some losses because of the drop of value in ether, so they are incentivized to sell ether like to uh cut losses. But that drops the value of etherism even further. So more stablecoins get, uh, liquidated and so it becomes some sort of a positive feedback like uh loop that may lead to essentially a spiral of death. And yeah, this is uh what actually happened in March 2020, so it was also the beginning of COVID, so that is what probably created instability in the market. Essentially, this happened for D, like uh the value dropped and the, I don’t know, company behind it, maker Dow had to like intervene and inject like liquidity in the uh system to prevent it from collapsing. Finally, there are algorithmic stablecoins. These are stable coins that trade. What? Hello? Oh. Um, they try to use, uh, the laws of, uh, supply and demand to keep like the value stable, essentially when the value of the coin goes above $1theytryto,um,uh,stimulatinginflationbylikemintingnewcoinsinthemarketsothatthevaluegoesdown.Uh,wheninsteadthevalueofthecoindropsbelow,uh,$1 they issue bonds that sell. They essentially say, OK, uh, you buy this bond at a fraction of $1and,uh,uh,inthefuture,uh,youcanexchangeitfor1stablecoin,OK.Sotheideabeingthatum.Ifpeoplebuybonds,thecoinsupplydecreasesandsothepriceshouldgoup.Andifyoubuyabond,whatyouhopeisthatthevalueofthecoinsgoesabove$1 and then you sell the bonds and you make a profit for the difference of prices. Well, nice in theory than in practise is not like there are uh several experiments of this kind of stablecoins and you see what is the value today, uh. Uh, new bits like, uh, has value 12 cents basis 4 cents, tera 2 cents, like essentially they should be around 1, all of them collapse like um are essentially 0. what is the issue? The issue is that as long as the price is above 1, it’s OK. When it goes below 1. Sure, people can take these loans, these bonds. However, uh, if the price doesn’t go up quickly, like, uh, there is no reason you should keep the bond because you lose also money just in the fact that for lost opportunities, right? Like your money, your, your assets are there in the bond like, uh, and you cannot use it in other ways, so. Like, uh, if the price doesn’t go up like, uh, soon enough. It’s better to just give up on that like money that there is no reason like you should invest into like uh uh this sort of bonds. And yeah, that is why all this system collapsed. OK. OK, uh, let’s take 10 minute break and then we can discuss, uh, applications. Does it work? Yeah. Uh, OK. Last part of the course, applications. Here I just discussed. Essentially what people have So, like application that uh have been proposed for blockchains and distributed letters. Again, I find them somewhat uh disappointing, uh, and I think they do not do right for like uh the technology underneath it. It could be quite interesting and cool. Uh, so I would say that the main, um, message here is we need to find something better and my hope is also that. Like, new generations like you may come up with some better idea of how to use this tool, OK? OK, um, let’s start, um, imagine for the moment that you already know how to, uh, how to use these tools. Um, the first choice that you need to, uh, take when you want to realise this idea you have is whether to build something on top of the pre-existing, uh, blockchains or whether to come up with your own blockchain. So both choices have um both options have some advantages and disadvantages uh if you opt for piggybacking, namely building on top of preexisting systems, um, you have like, first of all, uh, guar like some uh Potential for higher assurance meaning that you can trust that this system is already working and um and also you have the guarantee that there are already people using it, so maybe the usability of your application is better. Uh the disadvantages is that of course you need to uh give up on potentially some parts of your uh ideas because they are simply incompatible uh uh on with what like the blockchain is doing. If you instead opt for an independent uh blockchain you design, um, there is the advantage that is you can do whatever you want. You have total freedom of how like to design it so that it fits your application. Uh, the disadvantage is that typically at the beginning there are very few people that will use it. Uh, and maybe if the idea is good, people at some point will recognise it and will start like, uh, using your tool. Otherwise, It could be that it never gets discovered. And, here, of course, like not all, if you opt for building on top of pre-existing blockchains, not all of them are the same. Uh, some of them differ depending on whether they are proof of work, proof of stake, or this proof of history that is essentially fancy proof of stake like um. Uh, Bitcoins is proof of work. Ethereum and Cardano are proof of stake, even if Ethereum at the beginning was proof of work too. Uh, Solana is this proof of history. Um, they also differ in terms of, uh, the, uh, capability for smart contracts. Uh, Bitcoin has very limited capability. Uh, despite that, it’s still like uh the one with the largest market, largest market capitalization. Uh, Ethereum has a general smart contract, uh, capabilities, say, for Cardano. Uh, they have different types of language that are used. Um, Solana is, uh, compatible with, uh, the Ethereum virtual machine. Um, was the account model, uh, differs like, uh, Bitcoin and to some extent Cardano use this UTXO model. Uh, uh, Ethereum and Solanni that have, uh, an account-based system. And then they also differ in terms of, uh, fees and like energy cost. Of course, the energy costs are mostly dictated by whether they are proof of work or proof of state. Proof of history has some in-between, uh, energy consumption. And yeah, in terms of fees like uh Bitcoin works like in, in auction uh made system like uh when you made the transaction you propose like some fees and like uh who has the highest is put like in the blocks first. Um, Ethereum has these variable fees, Cardano instead has fixed one and Solana allows for priority fees in which essentially you can pay more to, to get your uh transaction validated first. So essentially which one is best uh for you up to you like it depends on the application hm I do not know it, yeah. Um, yeah, um. Yeah, when this application on the chain, there are two layers, um, uh, which they can build. There is layer one that is essentially like what we have discussed in this, uh, whole like a course, and typically these are, uh, quite inefficient, like they don’t scale very well. The throughput meaning the number of transactions per second is low and the latency, meaning how long you have to wait until the transaction is, uh, validated is, uh, like. Quite long. Um, so that is why typically people build, uh, layer two solutions, meaning stuff that, uh, runs on top of the chain and, um, gives up on some of the availability and safety characteristics, uh, that the layer one provides. When there are issues, essentially, they resort to layer one for uh disputes and uh like uh any sort of other uh problematic situations. Finally, there is the possibility to do something that is um uh like a bit mix uh essentially a layer two solution that works across several like blockchains. I don’t know work across essentially Ethereum and Bitcoin or like Ethereum and Cardano, um. Yeah, these are called the hybrid tops. Um Yeah, and, finally, uh, I want to discuss this, um, uh, application that have been considered so far. The first one is, of course, the one for which blockchains are famous for, uh, often they are seen as, as synonymous, um, synonyms. Meaning, uh, running an economy in a decentralised way. Uh, in theory here, everything is very nice. In practise, as we’re seeing today, there are a lot of, uh, issues. Uh, the main one I would say is that, um, these blockchas are not really used to, uh, exchange goods or assets unless it’s shady ones. Um. They are more used as a commodity, so it’s what I was saying earlier, right? Like, uh, you buy Bitcoin or Ether because you’ve seen that the graph of the value has been going up like, uh, recently, so why shouldn’t it go up also in the next future. So I buy today for $1tomorrowIsellfor$10. And yeah, like. In real-world economy, like uh The values, so The issue with this is that essentially it creates a lot of instability like the values of the cryptocurrency go up and down and like they make the economy really bad for exchanging goods and assets. That is actually what we would like to have here. Um, In the real world, this, like in the real economy, this does not really happen because what we are exchanges are real world goods, right? Something that everybody needs like something that has a value that is more intrinsic, right? I don’t know. Take a, imagine that I have a coin valuing like a 1 pound, OK? This is just a piece of metal that is not particularly useful for anything, right? Why is it worth £1 then and not 10 cents, that is the value of the metal? The reason is because I have some sort of assurance that I can go and use this uh coin to satisfy whatever needs I have, like basic needs like food, having a roof over the head, like uh electricity, like clothing, like not being cold, and I can be certain that everybody around here cares about this, OK? So, uh, this keeps the value somewhat stable. Instead for blockchains. The reason why one associates a certain value to Bitcoin is because they hope this is a ticket for more money tomorrow, but it’s based on this hope only, right? Like if this hope like disappears, like, uh, you could see like the the market collapses and like the values go down and depending on the moods of the system, like if these prices fluctuate a lot and Essentially, they hurt really the usability of this uh uh uh uh solutions. Yeah, um, so let’s consider another possible application of uh blockchains that has been considered. This one in my opinion, is a little bit more interesting and namely it’s running some uh decentralised domain name uh registry. Essentially, the idea is If we want to add a node on the internet like we just publish uh our uh IP address on this blockchain so that anybody that wants to contact me just need to check like uh the chain, they look for my name and then they contact me at the IP address that I put there. Why is this interesting? Well, because it prevents, uh, censorship. In the DNS, uh, system that is used at the moment, it could be the DNS server doesn’t like me. Um, I don’t know how likely this is, but, uh, maybe they do not like me and, uh, when somebody tries to contact me, like, uh, they don’t tell them my IP address, so I’m isolated. that with this uh blockchain system, like, uh, you cannot be censored, like as long as the majority of participants are uh like honest. Or like the majority of computational power, like is in the hands of the honest participant, whatever. Um, and indeed like these ideas have been implemented. Some of them use, uh, uh, independent blockchain. Some of them are built on top of Bitcoin or Ethereum. There are, however, some issues. Uh, the first one is that this system is not really compatible with the current, uh, internet infrastructure. It’s not that it cannot be changed, but like this is not really happening. And, uh, the other potential issue is that sometimes domains need to be taken down and how do you do it like uh on a blockchain like uh whatever is there is there forever, right? You cannot, uh, and it’s everywhere, right. Um, another, uh, idea. is to use the blockchain for like register or to record all properties. I don’t know, land property for instance, but it could be any other like physical asset or I don’t know URLs for websites. Uh, essentially, uh, you, for every real world asset, you associate some unique identifier and like you put it on the chain to get linking it to, uh, the owner of that item, right? And so I don’t know if you want to take ownership of a plot of land, you can check the blockchain and you can see, oh, it belongs to these people, like, uh, and you can also of course trade it. Like uh if I want to like uh like sell my plot of land to somebody else, I just need to like uh issue a transaction that says, OK, now this, uh, plot of land belongs to this other particular person, OK? Um, what is, uh, the issue here? Well, in some cases this like abstract link between the digital, like, uh, asset and the real-world asset may break. It’s not really the case for a plot of land as long as you have some government that like, uh, guarantees this uniqueness of the link and um. Uh, it’s more the issue, for instance, if you have URLs that can break, right? Uh, can be taken down. Um, the main issue in my opinion is the legal system that really doesn’t recognise this form of property, right? Um, other application, uh, one that in my opinion is a bit interesting, uh, local economies. Here, the idea is that some small community could try to, I don’t know, protect like, uh, their sovereignty or economical independence by Essentially running a small blockchain like uh locally, so they don’t have to rely on somebody that controls the whole uh like economy, like checking who owns what and like how the money is sent around. And the idea is that this in principle could strengthen like uh this community because it prevents like erosion of like, I don’t know, like instead of investing in like the general economy, they invest in the community itself. What are the issues here? Well, uh, the small economies often like struggle to sustain themselves, like, uh, meaning, I don’t know, if you are in Scotland and you try to do that, like you cannot really grow tomatoes here or like, uh, you would need to, to some extent, like to connect to the global market because like it gives stuff that otherwise would, other, otherwise your life could be just miserable. Um. The other issue is that the global market is much more efficient usually and so it can easily outcompete anything that happens in these small economies. Um, other, uh, ideas that, uh, have been proposed is to use the blockchain to track the, uh, supply chain. Essentially, um, here the idea is that every item in the market is associated with some unique identifier and whatever happens to this item, uh, through the production, uh, process is recorded on the chain. And so anybody can See this item and track like what happened to it. I don’t know. I buy a pair of socks, I see that the wool was taken from, I don’t know, New Zealand, it was dyed in India and like I have a bit like some assurance about it being made in an ethical way. What is the issue here? Well, the issue is that, uh, how can we make sure that like, uh, whoever records the information does it like in a, in the proper way. Like I always, I can always claim that the socks were made with pure wool from the highlands that’s like, I don’t know, uh, but maybe like it’s wool was coming, that came from the other side of the world like uh with terrible like working conditions and a lot of exploitation. So. Yeah, this is uh one issue that would need to be solved. Um, other things like, uh, philanthropy, like the idea here is to use the blockchain to collect funds for any philanthropic like, uh, goal, uh, while at the same time have some form of like assurance against the people collecting the money just running away with it. Uh, essentially we would use a smart contract that pulls like, uh, the money and keeps it in a scroll. When like the project like uh whatever like this money should have been used for like uh is done like some oracle like should provide some proof of this like to the same to the smart contract so the smart contract releases uh the uh the funds. What is the issue here? Well, the issue is always the same, like how do you link the digital world to the real world? Like, who is this oracle that tells like this, uh, like a project has been, uh, completed successfully, right? And I don’t know, like uh this is the main thing, like the smart contract would need to find to. We need a way to verify that claim, and how do you do that? Like, uh, you would need to rely on some centralised authority. Then why to use a blockchain like maybe you can just use like a simpler solution. As the option would be, uh, crowdfunding, um, essentially, here, imagine, uh, there is somebody that’s like, uh, has some idea to improve the world, but they don’t have enough money so they can propose the idea on the chain using a smart contract. People that believe in this idea can send, uh. Assets like uh to this uh smart contract and in exchange the smart contract releases some newly minted token that represent the fact that You have invested in that solution. And uh yeah, the idea here is that maybe in the future like you will be able to give back this coin in exchange from a cut of any profit like uh uh that came from this idea like for instance this could be given automatically by the smart contract or something. Uh, what is the issue here is that this is perfect for scams. Uh, I claim some crazy, like, I don’t know, I say this idea will be fantastic, like, uh, I fake also, uh, like, uh, I artificially increased, like, uh, the Volume of like uh um cryptocurrency that comes into this to attract other investors and then I just run away like with the money and uh I abandoned completely the project like uh. Uh yeah. Other things, there are these prediction markets, uh, which in some sense could be used for stuff like insurances. Essentially here it looks a little bit like gambling, uh, but essentially you can have a smart contract that, uh, says, OK, like uh. And suppose, like, let’s make, they make a statement like 10 tornadoes will hit USA in 2020 and people can bet yes or no and like then there will be some oracle that says, yes, this happened, no, this, this did not happen and who won the, the bet essentially splits like whatever money has been put there like uh equally. This looks like, I don’t know, like pretty evil, like it’s like how to make money from gambling but uh in principle you can change this mechanism to have some form of like uh something that looks more like an insurance policy. Essentially you say if um I don’t know my house burned down this year like uh I will receive the money like uh essentially everybody bets yes my house will burn uh meaning that means. That means like I take the policy, yes, I take this uh insurance policy and uh uh whoever says no like uh doesn’t contribute with any money. And uh then if I’m right and my house burns down, like uh I like get some of the money of the other people that like bet it yes. Uh What are the issues here, like, uh, once again, there is this oracle that needs to tell like what is happening in the real world, like, uh, how do you implement that? You need to rely, like you, you once again have this uh centralised like uh System that like can like Like change the outcomes of whatever is happening here. And other ideas that I think these are really getting like worse and worse is the IOP. The micropayments, essentially. The idea is that you could have a fridge that has some sort of subscription model like that you pay based on how much like you, uh, you use it or like the same is for electricity or water consumption like uh essentially there is the smart contract based on uh like the fridge, whatever like tells the Saying like, I’ve been using this and the smart contractor immediately pays like uh the company proportionately to that. Why would one decide to do this? I do not know. Uh, the other reason why this could be interesting is that maybe you can, uh, get, uh, money from selling, uh, your private, private data like uh IOT like devices typically steal a lot of data and send it to the company. Maybe with this system you can set up some sort of, uh, payment system based on how much you, you contribute. Um. Issues. Well, first of all, is why would you sell your private data? Maybe that is better that it stays in your hands. Uh, and then also like the pure scale of this because the amount of, uh, personal data that is sent over the internet like would really like, uh, be a lot. Um, and finally, that, I don’t know that. Craziest one for me, like, uh, that is gaming. Uh, some people have tried to like, uh, run, I don’t know, there are these games that have like some like virtual economy going inside and I said, why don’t you use it like on the blockchain, like, uh, do you implement it on the blockchain? And I really do not understand why this would be interesting, like, uh, because typically these are centralised solutions. Why would like the company benefit in any way from having a decentralised solution for those particular economies. And also like, what if like the company stops running all of it and like you cannot play your video game anymore, like it’s, I don’t know. I think it’s just like uh people in the market trying to sell something when blockchain is a fancy word, you attract money. And yeah, this is it for the course, uh, really the main thing that I want to take from all of it is that blockchain in theory is amazing. It allows us to solve something that is important in my opinion, and the issue that is where we struggle and where we need to put more thought. Is like application. How can we use this tool, OK? Because at the moment it’s a bit disappointing. OK. Uh, if you have any questions, uh, before the exam but also after. Send an email to me, like, uh, we can also organise an in-person meeting like I care that like uh like I can help in any way I can.

Lecture 9:

SPEAKER 0
I guess we can start. Uh, first of all, like an announcement, like the last time I noticed that some of you probably got lost a little bit with the lecture and like, uh, they were speaking during like when I was, uh, uh, explaining like the topics of the course. It’s fine, but please go out of the room like, uh, because first of all, you distract like the other people here, but also you distract me. Like it’s totally fine. It’s not something that is unheard of, and I did it too at some point, uh, but like please like use like, uh, I don’t know, some other room, not this one. OK. Um Today, I’m gonna, uh, say a few things, uh, first of all, uh, about the lecture of the last time, uh, in particular, one thing I got confused, uh, about, uh, Chang’s e-cash, and I need to explain it better. Uh, then I will finish the topics, uh, of that, uh, slides, and then later we will start with the slides of today. You can find them on the website. The issue is that I don’t have access to open course, so I did not update the website. However, if you click on any of the links of the previous weeks and you go on the GitHub repository, you find also lecture 9, OK? But like it will be important for later. Now we do some stuff on the slides of the last time. OK. So the first thing I wanted to talk about is Tums eCash because some of you asked like how do, does the user like authenticate with the bank, like to uh essentially uh show that they have right to receive one of these ecoins and Like there was the issue that like it seemed like the user had to preserve their anonymity. Actually, no, that is not an issue. Like the user can tell the bank who they are. All the bank gets to know is that some ecoin was given to them, but they do not know which ecoin was given to them. So later the user can spend this ecoin. This ecoin will be given back to the bank, but the bank has no idea of who received that ecoin at the beginning. So it’s totally fine for the user to send their identity to the bank. The whole anonymity is ensured by the blind signature, by the fact that the ecoin and the corresponding Nuns are unknown to the bank, OK. All right, now I move on to the other thing. Um, that is network security, um, in, uh, distributed ledgers. Because when we think about this sort of uh settings, it’s easy to think about the case in which like all participants are connected by some sort of channel, so everybody can speak to everybody else. But this is actually not the case, first of all, because this infrastructure run over the internet, so like we have, we run on top of TCP IP. So like there are of course like, like routing and nodes in between, and generally you don’t have like a direct channel to everybody else, but also for the fact that since these distributed ledgers are permissionless, you don’t even know who is part of the system, so you don’t know even who you can talk to. Today, I’m gonna explain how like um Bitcoin deals with this aspect. And Bitcoin essentially runs on a peer to peer network that runs on top of TCP IP. Every node of the system is going to connect it with only a few other nodes of a few other participants. In particular, there is a cap on the number of outgoing connections that is set to 8, so a very low value, and there is a cap on the number of incoming connections that for Bitcoin is set to 117. And the idea is, if these connections are sufficiently random, by spreading messages, like as soon as I receive something that I’ve never heard before, I spread it to all my outgoing connections, I can reach everybody. That is the underlying assumption. Does it make sense? So I don’t know if you’ve ever seen like this statement about the Facebook graph of like that essentially you check like the graph of old people on Facebook and you connect them if they are friends, and you can see that if you pick any two people in the world, like they’re going to connect it by a path of length 4. Like this is more or less what is happening here with Bitcoin. Like if these connections are few but sufficiently random. I can spread like the messages every time I receive something, I spread it to everybody else that I’m connected to, and I can be confident that everybody obtains soon like that information. OK. Now, I would like to go more into the details of how these uh connections are uh set up. So imagine you are a new node that like uh joins the system. How do you get to know who else is there? So the first thing you would do is you connect to a server that is called a DNS seeder, and this is a server that essentially stores lists of nodes that are active in the system, and this is done through crawling, essentially. They have this list, every time somebody connects, they select a random sample, a random number of these addresses, and they send them to the new participant. What happens, however, if We are not able to reach this DNS server. It could be for instance because there is an attacker that does some denial of service on the network and doesn’t allow us to reach the DNS server, or it could be simply that the DNS server doesn’t like us, like they don’t want us to join the network. In that case, there is a table of like default addresses that is hardcoded into the code of the Bitcoin protocol. And so if you are not able to reach the DNS theta, you are gonna adopt this hardcoded table. OK. Now The addresses are maintained in two different tables. There is a table of tried addresses. These are the people we have talked to. We know that these people are active over the chain, so they are more reliable participants. Then there is a table of new addresses. These are people we have heard the existence of, but we haven’t yet spoken to them. We haven’t yet talked to them, so. Like these may be parties that like may not exist even, like we’ve just heard they are there, but are they really? Are, are they, is somebody trying to fool us, maybe like uh an attacker is trying to tell us there is this node, but actually that node doesn’t exist. How do we get these new addresses? Essentially, in Bitcoin, everybody can send unsolicited address messages. It’s essentially you pick a subset of your tried addresses and you send it to somebody else and you say these are other participants in the system. Every time you receive such a message, you store all the addresses you didn’t know already in the newer the table of new addresses, OK? All right. Um, As I said, There are at most 8 outgoing connections you can create. How are these picked? And yeah, first of all, we need to select whether we pick an address in the try table or an address in the new table. The choice is randomised, and which one is more likely depends on the number of addresses in the, on the two tables, and also on the index of the connection. If it is the first connection I’m opening, I’m more likely to pick like a connection from an address from the try table. Because I want to be sure that I can talk at least with somebody. Like if instead it’s the 8th 1, maybe I try some new uh. Address because I don’t know, maybe I want to connect to people that newly joined the system, OK? OK, now suppose you decided to pick from the. A table of tried addresses. How do you choose exactly the address for this connection? Essentially you bias the choice towards people that have been active more recently. Essentially, for every entry of the try table you store a timestamp of the last time you’ve heard from them, and so you have a biassed choice towards people that have been active recently. OK. Instead, for the new table, you just pick some something at random. OK. OK. Um, now, We need to discuss some problems of this particular design because an attacker can try to perform what is called an eclipse attack. Essentially they want to isolate a node from communicating with the rest of the system. In that way, essentially those parties will have. Like their chain essentially will diverge totally from whatever is happening on the main system because they don’t see new blocks and the only blocks they see is the one that passed through the adversary. How can an attacker do this? Um, first of all, the attacker starts, um, creating connections with the, uh, The target of this attack. And they keep speaking to them so that they have so that their address is on the victim try table and the time stamp for their address is very recent because they keep talking. Then they send a lot of unsolicited address messages with a lot of bogus addresses, like. Run to my P addresses where nobody responds essentially. And then we just wait. Why? Because essentially that node has already probably some outgoing connection and some incoming connections, and throughout the Bitcoin execution, these are never dropped. Once they are established at the beginning, they are never dropped. So what the attacker needs to wait for is for some like node reboot, for instance, because of some software update or I don’t know what. In that case, all these connections are dropped. And the node we’ll have to open new ones. But now What will this note do? Well, it will pick either from the try table or from the new table. For the try table, it will be biassed towards the addresses with the freshest time time stamp. And these are ours like because we kept chatting to these people like we have very fresh time stamp, so there is a high chance we are gonna be selected as an outgoing connection. If instead the node. Decides to open a connection from the new table. They are very likely to select one of the bogus ones we sent earlier. Like, as I said earlier, we send unsolicited address messages with a lot of bogus IP addresses. Like now their table is full of these fake IP addresses. And so when the victim will select to open a new connection from the table of new addresses, they will most likely pick one that is just some random IP where nobody responds. So when they try to reach out and nobody responds, they drop the connection and they retry. And so maybe again they pick from the try table and they will select something with a fresh time stamp, so we are more likely that we are selected. So you understand, if we have a lot of Addresses in the trial table of the victim. We have a high chance that all 8 connections that the victim opens are towards us, the adversary. What about incoming connections? That is also very easy to deal with. As soon as the victim reboots, the attacker will send a lot of incoming connections to the victim. How many? 117 because it’s the total number. Like if any other connection comes, like the victim rejects them because they already reached the limit of 170. And even funny thing, like all these 117 connections can all come from the same IP address. Like Bitcoin doesn’t even sex like that this is different parties, like they couldn’t all be the same. Anyway, Once we manage to do this, we have a party that has all outgoing connection to that pass through the adversary and all incoming connection that come from the adversary, so it’s totally isolated and their chain can diverge, uh, arbitrarily from the main chain. Yeah, the two tables that we have for the new

SPEAKER 1
and the connections, are they like infinitely growing, or do we also throw things out once they’re in.

SPEAKER 0
Yeah, like there is like uh what is called, wait a second that I find the slide, um, so there is this is terrible like uh function that essentially like drops every element in the new table like if they don’t speak for 30 days or so like uh so essentially you have a big window to perform an attack. So some countermeasures you can take um is to first of all, like ban unsolicited like uh address messages and you can just rely on the uh DNS seeders to get your addresses. Um, the other thing is, of course, valid, uh, divide, diversify and validate like the incoming connections. Like if we see that it’s always the same participants, maybe like drop it and try to like diversify the set of people you talk to. OK. Yeah. Yeah. That is only like, those are only adopted when you join the protocol and you are not able to communicate with any DNS either.

SPEAKER 2
Do they exist or what’s their purpose?

SPEAKER 0
Their purpose is that like you joined the protocol, you need to talk to somebody, otherwise you are already totally isolated like so uh if you’re not able to talk to the DNSC there and like nobody sends you an address message because they didn’t don’t even know you’re part of the system, like how do you start? You start with these hard coded addresses.

SPEAKER 2
Sorry, symbol like you would start with the new table

SPEAKER 0
because you haven’t tried each of them, but now like the try table has zero elements, so when you open a connection you pick it from that one, yeah, and

SPEAKER 1
those IP addresses like the hard coded ones, we assume they are always like available and they are like never malicious because that would be like if you I agree

SPEAKER 0
if if the malicious party like is those hard coded

SPEAKER 1
messages there’s yeah I agree.

SPEAKER 0
I agree, but like, uh, I, I do not know exactly the details, but I imagine there are a lot of addresses, so that like uh you have some sort of sufficiently high chance that you pick somebody that is honest, OK. OK. Uh, next, we need to talk about wallets. So what is a blockchain wallet? Essentially it’s this tool for end users like me and you, so people that want some sort of nice user friendly interface for whatever happens in the chain. In particular, they provide services like secure storage and management of keys, um. Like generated transactions, so they translate the nice visual user-friendly like transaction into the actual thing that is signed and broadcast to the minors so that they can validate it and add it to the chain. And then they also check the chain for any incoming transaction you should be notified about, OK? Now, first of all, it’s extremely rare that these wallets do any mining because this is software that runs on a computer or on a phone, so it’s very little computational power. It’s extremely unlikely they will ever win this computational lottery. So if you just try to mine, you just waste a lot of energy, OK. What these wallets usually differ is How they implement these services, in particular how we check for incoming transactions. So some wallets, and I hope that today very few of these do actually this, do the naive solution, the naive solution, namely they store the whole chain every time they receive a new chain, like they check all the transactions and they check all the blocks, whether the proof of work is satisfied, and then they check like which one is the longest, and at that point they store the whole of it like locally on your device and The issue with this solution is that the size of the chain is huge. Like, as of 2022 when like this graph was taken for the slides, it was like more than 180 gigabytes. So if you run this like on your phone, you waste a lot of power. Like you would run out of battery immediately. That is why Usually wallets are what we call SPV wallet, it means simplified payment verification wallet. Instead of storing the whole chain, they store the headers. What are the headers because I think that maybe some of you don’t know it. To understand it, we need to go back to our proof of work function. Remember like a a block was added to the chain. If the hash of the counter together with the hash of the content x and the pointer s is smaller than the hardness parameter t, OK? So this is the content. Of the block and this is the pointer to the previous one. Now, this holds for generic proof of work distributed letters. What is this X exactly depends on The particular blockchain we are analysing for Bitcoin, this X is not the full list of transactions. Actually, this X is going to be a Merkel hash to the whole set of transactions. In that particular block. To Let’s call them capital X. So the block that you add to the chain is going to be made of two parts. First, the header made of the counter, the Merkel hash x that is small. And the pointer to the previous blocks and then we have the big part that is going to be the actual transactions. In the In an SPV wallet we just store the headers, the chains of headers, but not the big part, namely the transactions. So Our wallet will receive from the network a new chain of headers. And When they do that, They check like whether this is a valid chain of headers by verifying that like this formula is satisfied for every block in this smaller chain. And then if the new chain they receive is longer than the previous one, or in general the hardness of generating it is larger than the previous one, they adopt it. Why is this still secure? Well, if the majority of miners out there are honest, or at least if the majority of computational power among the miners that are those that count in terms of computational power. is controlled by honest participants, then the longest chain. of headers will be the main one. It doesn’t matter what this X is. An adversary can overtake the chain of headers only if it has a majority of computational power, except potentially for the last few blocks like we need to wait, of course. So what I’m saying is the wallet may not have. Like it could be that the last few blocks in this chain are not validated. We need to wait that sufficiently many are added to the system until we are sure that those are final. The question is, of course, if the wallet doesn’t check the transactions, how do they know that we received money? Or how do they know that our transaction has been added to the chain? For that, they rely on external help. There are these SPV servers. These are nodes that keep the whole chain, including the transactions. Every time we set up a wallet, our wallet will communicate to them our public keys, so our addresses. The secret key remains secret, are not revealed. And yet, every time there is an incoming transaction or our or one of our transactions gets validated on the chain, the er SPV server will notify us. And we’ll give a proof that The transaction happened through. And Merkel has proof, right? When you have a Merkel hash, you can provide a proof of inclusion. Right, if there is some transaction inside this capital X, I can give you a proof that can be efficiently verified that that transaction like is inside this X, like, and this is binded to the lowercase x that is part of the headers. Does it make sense? Yeah, yeah, yeah, it’s essentially a tool like uh some sort of service that is provided to end users like to do all kind of uh stuff on the chain adminis like manage keys and Like storing keys. Yeah, servers are also some sort of, the SPV servers are like servers, like the wallet is some sort of a client. The server is just one that provides an incoming transaction to it tells the wallet, look. On this account you’re managing, like there was an incoming transaction, and here is a proof that that happened, like you give a Merkel proof that like that transaction was included in that particular block. OK.

SPEAKER 2
Are the addresses of these servers hardcoded in their wallets?

SPEAKER 0
In, no, like what you. I do not know like whether they are coded in the wallet. I guess it depends on from system to system, like there are multiple wallet systems, um, but what you have is, what you have to do is you connect to multiple, uh, SPV servers because if you connect only to one, they can censor like uh an incoming transaction, for instance, like. You connect to many, as long as one of them is honest, like when they tell you like an incoming transaction has happened and they give you this Merkel proof that indeed it is consistent with the headers you have stored, you are sure that the transaction is actually on the main chain. Yeah Sorry? Which has the headers. The Merkel The Merkel hash, so the Merkel hash, this one is part of the headers, so we already have them locally, right? Like we keep a chain of all these headers, so for each block, like in this chain of headers, we have a Merkel hash. Then when there is an incoming transaction, a known as SPV server will tell us, look, in this block there is this incoming transaction, this transaction to your account, but of course like you need to prove that that is indeed the case. How do you do that? You already have a Merkel hash of that block, so all you need to do is to add the proof of inclusion. Right? I think they explained it in the first lecture, how to do that, right? OK. So In SPV. Like wallet. Usually also general wallets provide another service that is secure storage and management of keys. And based on how they do that, they can be split into two main categories. There are hot wallets that are wallets that store your secret key on a device that is connected connected to the internet, for instance, my phone or my computer, and these are less secure wallets because I don’t know, maybe there is some malware that manages to, to get my keys. So hot wallets should be used for. Accounts that have small amounts of money that I use on a daily basis. I don’t know, like I don’t own any Bitcoin, but like if I wanted to pay for coffee, like I would use a hot wallet, right? It’s fine if that key gets stolen. All I lose is the money for coffee. OK, then there are cold wallets. These are cold wallets that usually contain a lot of like your savings, let’s say. And these are stored offline. It could be on a hard drive. That you keep at home and you connect it to computers that are not connected to the internet. At that particular time you use them to sign the transaction and then like. Like you publish it on the chain after or it could be just a piece of paper where you store your password and your er Like secret key is gonna be the hash of this password, of course you need to choose a proper password. Uh, uh, another thing could be the specialised hardware. There are some sort of, they look like pen drives. It’s specialised hardware that stores the key, and it has some chip that performs transactions that signs transactions and send them. And essentially, the chip is plugged in in the computer, but it never like uh transferred the information about your key to the computer itself. It doesn’t trust the computer. So essentially, all the computation is done within this pen drive and all is communicated to the computer. It’s just like design transactions. OK. Um, what else did I want to say? Uh, one classical thing that people do not understand, if you lose your secret key, you lost it forever. There is no key recovery like password recovery mechanism, like a password reset mechanism. That key is stored Nova. You are the only one having it. If you lose it, it’s lost forever. There are people that have like several, I don’t know, huge amounts of money on their accounts and they are not able to retrieve them because they lost the key. And uh they pay people to break the cryptography to try to recover it, like throwing away a lot of money because like it’s pointless, OK? So, The keys need to be stored like in a way that you don’t lose it, OK. And Now, one issue with um This approach of hot and cold wallets is that you’re gonna have a lot of accounts, right? So it seems that you would need to keep track of a lot of passwords and a lot of keys. Actually, most wallets have a solution for this. Essentially there’s going to be a master secret key that should be stored in a cold like a wallet. From which we deterministically derive many other keys that can be used for a hot or cold wallets as you prefer. If any of these keys we derive from the main master key is leaked to an attacker, it’s all going to be fine. We just lose that account. Like the adversary, of course, can steal all the money that is on that account, but all other keys that are derived from the master seeker key and the master seeker key itself remain secure. OK. This is called a hierarchical deterministic wallet. Yeah, OK, so basically it’s some sort of function from

SPEAKER 1
the master private key, yeah, that is not invertible. So for example, a PRF some randomness or not a randomness, but something else in it, a PRF, it’s deterministic

SPEAKER 0
like, uh, you view like the master seeker key as the PRF key, and then like I don’t know, the first key is gonna PRF evaluation on, uh, 0 PRF evaluation on 1 PRF evaluation on 2. OK. Now I would, would move on to the other lecture. Um Just a second that they recovered the slides. Um Uh, not this one. Where is it?

SPEAKER 3
And?

SPEAKER 0
Um. OK, so now we’re gonna talk about the main topic of today that should be multi-party computation protocols or NPC for short. Um, this is essentially a tool that is extremely important for distributed ledger for two reasons. First of all, for the, for the application they enable to run on top of the chain. But also for the blockchain itself because they enable. stronger form of privacy, security, and decentralisation in the system. What is the setting we are considering? Imagine we have n participants P1 to PN. Uh, let’s call it PI and PN, and each of these participants holds some private input. Let’s call it XI. You can think, uh, for instance, about some sensitive information like, uh, your medical records. These are protocols that have 2 goals. The first one is to compute. Some function f of the sensitive information x1 to XN. And yeah, we can imagine that the output here is split into unsungs, one for its participants we call them. Uh, Y1 to YN. And yeah, the first goal is to compute this function first of all and then to uh distribute. Like YI to party PI for every eye, OK? So you’re just performing a computation. So essentially the parties will start sending messages back and forth following the instruction of the protocol, and at the end of this interaction, everybody derives their own output Y1, Y2, Y3, Y1, and Y. So far so good I guess. The output of the computation like you perform some function and then you can split like the output into chunks like and you say, OK, the first part is for party P1 for party P2 is this one, and so if everybody has the same output, just you can assume that the function output is the same thing at each of these entry like just. Without loss of general uh general uh generalisation, you can assume that. OK, The second property is maybe the more interesting one that is called privacy. Um And it says that Even Does everybody, can everybody see what I’m writing? Yes, yes. No? OK. Let’s write it here. The second property, privacy. Sense that Even If uh er. Subset Of Strictly less than tea parties. Collude All day. They learn From From the other participants’ input. It’s just their own output. What am I saying here? What I’m saying is that, imagine that a subset of these participants, in particular, are strictly less than T where T is the parameter of our protocol. Imagine that these collude and they pull together whatever information they have seen in this interaction. Hoping to recover information about whatever these two parties’ inputs are, right? Well, what that property is saying is that these participants will learn nothing except their own output Y N Y I. Let’s make an example. Suppose that this end participants is just the population of Scotland, and these excise are their medical records. And then F here is just some statistic that checks the medical records and tries to detect whether there exists a new epidemic, and you can imagine that YI is uh whether it’s reasonable that that party PI has been like uh infected by this new unknown disease, and so they should stay home instead of going around, OK? Well, if we use a multi-party computation protocol for this computation, it means that everybody gets to know whether they have been infected likely or not. And furthermore, even if a subset of participants up to T Collue They do not learn anything else about The like er health of everybody else. So if you’re party P1, these three parties do not get to know like whether you have been infected, whatever health symptoms you have, whether you have another disease, like all they can learn is whatever can be inferred from their output. If somebody has been infected, most likely there is somebody else that has been infected, but I have no idea about who. So it sounds like magic, but building this protocol is actually possible. Now there are 2 broad categories for this kind of protocols. There are those that are called passively secure and those that are called actively secure. A passively secure protocol is one. In which privacy. is guaranteed as long as the colluding parties. Still follow the protocols. They don’t misbehave, OK? Passive, uh, privacy. As long As a colluding set Does not misbehave. There are active protocols instead that achieve the privacy even if the colluding parties misbehave. So today, I’m gonna explain to you how, or at least sketch, how we can build a passively secure multi-party computation protocol for any computation you want. OK. The main tool we need. It’s called secret sharing. Let me maybe move on with this like. Essentially. The problem is the following we have our end participants. B1 uh. Um Is it better if I write here, like the people in that side, can you see it like if I write here? OK. P1, P2, P3. PIN. And imagine now like we are some external party that knows some secret texts. The secret sharing scheme allows us to split this eggs into chunks. X1 to XN 1 for each of these participants. So that If these chunks are pulled together, We can reconstruct tax. Think as like some sort of puzzle. But if even one of these chunks is missing, it’s as if we have no chunk at all. We get no information about X. So if we have xi for i in a subset. Uh, Like Then it’s impossible to reconstruct X unless we are extremely lucky and we guess it correctly. Maybe to understand how this works, I should make an example. So first of all, let’s make an assumption. Suppose that this secret X belongs to the set ZP. Do we all know what ZP is? Maybe I should explain it. ZP. It’s simply the set of integers modular P. so it’s gonna be 01 and so on till P minus 1. So simplest examples. Z2, this is gonna be 01, so just bits, OK. Here P can be anything you want, any positive integer. Greater than 2. To secret share these eggs. We are going to just provide these participants. With random elements of that. Whose sum modular p is equal to x. So Essentially, we will have the, the sum of the Xi modular P. is equal to x. And apart from this property, these xi are random. So formally, you can generate them as follows. First, you sample X1 to XM minus 1. Uniformly at random over ZP. And then you set the lux one xn to be. The difference between x and the sum of the other excise. And you reduced modular P. Now, it’s clear that if you manage to pull together all these excise, you can reconstruct X, right? You just add together, reduce module P, that is X. But if even one of them is missing, you have no, you have no idea about the sum. Because that piece you’re missing like is uniformly distributed, right? Like, you erase all information. Having M minus 1 pieces is the same as having none. Yeah, essentially.

SPEAKER 4
reconstructed if all of the parties are.

SPEAKER 0
All of the parties, it depends. Like if all the parties agree to reconstruct, the secret can be recovered. If one refuses, exactly. Exactly, correct. And that like has like some positive things and some negative things, because if we are honest participants and like we want X to remain secret. That guarantees us that even if a subset of parties collude, they will not recover the secret as long as we are honest and we keep our chunk secret, right? But there is the other issue that what if we are all honest except one person and we want to reconstruct. That person can say, no, I will not give it to you. And so you’re stuck That is why we use often a generalisation of this secret sharing. This is called N out of N secret sharing. Because Like to reconstruct, you need n out of n chunks. But in general, you can build t out of any secret sharing where T is any number you want. So what does it mean? It means that if you pull together at least The shares, t chunks, you’re able to reconstruct the secret, otherwise you have no information at all. So if you have xi for i ins, where the size of s is greater or equal than t, then from this you can reconstruct x. But if you have a smaller number, Let’s say S now is strictly smaller than t. It’s impossible for you to recover X. How do we build this sort of secret sharing? The idea is to use a basic mathematical fact. That says If the P is prime, and this is important. Like we’re working over that p where P is prime Z 2 it’s OK, like except like suff suppose it’s sufficiently big I’d say if P is prime given. Um Um T point. In the plane ZP 2. There exist. Only one. Polynomial Uh P Of degree Um Oh, sorry. Degree T minus 1 that passes through those points. So Such that um P of Xi is equal to Yi. Where X I Y I are like uh all these points. Yeah, this is going back for a second. Oh, sorry, yeah, to, to analogize this to the Scotland

SPEAKER 5
example, yeah, how could it be? How, how would that example, for example, make it such that they could have X’s that are taken from a distribution like this? Sorry. How What, what would this mean in this case in Scotland example, better phrase we are gonna show like we

SPEAKER 0
use this tool to build like that protocol.

SPEAKER 5
So we don’t know. It’s not like the, the, the distribution.

SPEAKER 0
It depends a lot on the function you are tackling, but like if the input is a bit, like you can work over, like it’s a bit string, you can work over that too and you secret share its bit singularly. If you want. Does it make sense? Yeah, yeah. Ah good. Q So essentially what I’m seeing here, like basic mathematical fact, if you have t points on the plane, there exists only one polynomial degree t minus 1 that passes through all those points. So how do we generate a a the out of fan secret sharing of some value, let’s say A. Essentially, we are going to encode our A as the 0.0 A, so on the y axis, and then we pick a random polynomial of degree T minus 1 that passes through this point. OK. The share of the parties are going to be Random points on this curve. All distinct and all different from this. OK. So, So this is gonna be X1, this is gonna be X2, X3, and so on, OK? Now if the participants. Pull together their points. They can interpolate the only curve that passes through those points. They can recover essentially this polynomial and then they can check where it hits the axis y x equals to 0. And they recovery If, however, less than tea parties pull together their points, They cannot recover it. Why? Because they are missing some information, right? If I have T minus 1 point. There exists a polynomial of degree T minus 1 that passes through all of those, and any other point you want here, so they are all equally as likely. Questions I see. ZP are the integers modular p. So Z 012 until p minus 1, yeah. Uh, mass, it’s math. It comes from math. ZP is uh. I don’t know, like, uh, historical reasons, like, uh, yeah.

SPEAKER 1
Because this is just the natural numbers like from 0 to 3 minus 1.

SPEAKER 0
Uh, it’s just that you do the computation over that, that has, uh, what is called a group structure and, and it’s not a group structure like, uh, it’s math reasons. OK, let’s take a 10 minute break. So 1214. Uh, we can restart. One question I had about the exam, um. Whether like uh how much you have to rely on what I say during class and how much you have to rely on uh like the slides. In general, this is for my part. I do not know who taught the lectures before me. Like all I’m gonna ask at the exam about this lecture is gonna be talked about in the class, OK? Like I do not ask like crazy details like uh tell me the formula that with, with like uh Bitcoin selects like the tri table or the new table, OK? It’s like multiple options, uh, questions. And the Yeah, essentially some of them like requires you to know a little bit like uh what are the principles and like to think. And some of them are more like uh knowing the general problems and the general solutions of uh the stuff we discussed during the lecture, OK? All right. Um Now, I want to show to you how we can build this passively secure multi-party computation protocol using this tool called secret sharing. And the idea is the following. We take our function F we want to compute and we convert it into a circuit, OK? So we assume that this is a function that is efficiently computable. It has some circuit representation. And we don’t know, we don’t want. Uh, any circuit, we want one with a very particular structure, namely we want the gate to be, um, basic arithmetic modulo P. OK. What do I mean with this? Essentially there will be 4 types of gates. There’s gonna be Two unary gates, meaning one input to one output. So one takes its input X and it outputs X plus some constant K modular P. So this is Like addition of a constant, for instance, if P is 2, this can be viewed as a 0, right? Like you add 1 modular 2 means like uh computing a node. Other gate that is unary takes its input x and it outputs k times x modular p. Well, K is like some constant like uh hardcoded into the gate, right? This makes no sense, modular 2, because like if you multiply by 0, it means like you have 0, if you multiply by 1, like, it’s like doing nothing, right? But like if P is greater than 2, this can be something interesting. And then we have the two binary gates. So two inputs X and Y. 1 output. And this is going to be x + y modular p. And finally, we have the multiplication gate. Uh, which I will squeeze here, takes us input X and Y and it outputs uh. X times Y modular P. So I’ll call it malt, add. So this is moult K. And this is a Right, it turns out any function can be represented as a circuit of this form where the gates are addition of a constant multiplication of a constant addition and multiplication of module P. Our goal will be to evaluate each of these gates one after another on the secret shared values. I’m gonna explain Essentially We will have a way to move from a secret sharing of the input of each of the gates to a secret sharing of the output. So in the protocol we are going to start with everybody, every participants secret sharing their input with everybody else. If we use a t out of n secret sharing, it means that even if t of the less than t participants collude, they get to know nothing about our input. And then we evaluate the gate one after another, starting from the one at the top corresponding to the input. Like we will have a secret sharing of the input to this game because it’s the input to the whole circuit. From this we derive a secret sharing of whatever output of this gate we have. We do the same with this one, so we have a secret sharing of whatever value this wire have. And now we can apply this as a gate and obtain a secret sharing of the output of this as a gate. And so on until we end up with the secret sharing of the output. At that point, the honest participants can pull together. Their shares. And they have the output. Does it make sense? No. OK. Essentially, I repeat There will be a way, and I’m gonna explain it soon, to move from a secret sharing of the input of any of the circuit, of the, sorry, of any of these gates. To a secret sharing of the corresponding output, meaning if I get a secret sharing, if I start from a secret sharing of X. I end up with a secret sharing of X plus the constant K. Or if we evaluate an addition gate, we start from a secret sharing of X and Y, and after performing some operations, the parties end up with a secret sharing of x + y module. Yes, so with secret sharing you mean X1 X2, sorry

SPEAKER 6
for it.

SPEAKER 0
Yeah, what we have, like that was a secret sharing of some value of x, right? So a secret sharing of x is like means everybody owns a share xi. And if you pull together all this excise, you’re going to recover x.

SPEAKER 6
X is actually the actual.

SPEAKER 0
X is actually the secret. OK. So essentially what I say, we have a secret sharing of X, I mean that nobody knows X. The parties, all parties own a share of this X, and if they want, they can reconstruct it, but in this protocol we won’t do it unless we are talking about the output. OK, but for the moment ignore it. We imagine that we have a secret sharing of X and the parties also a secret sharing of Y, meaning everybody has their own tongue. Well, from there, doing some operations, we are going to derive a secret sharing of this value, meaning at the end, without anybody disclosing anything to anybody else, everybody will end up with. Like a secret sharing that when reconstructed. Gives this But again, we won’t reconstruct unless it’s the output. What we are gonna do is we are going to evaluate the next gate on it, yeah.

SPEAKER 1
So essentially what you’re saying is that we have a way of having a function of X1 to XN. And like this because everybody just knows the one of the XI’s like we can evaluate it with just a single one of them to get like the next secret where we don’t know what everybody else does because we

SPEAKER 0
don’t know their secrets. Like even if we do not know the secret but we just have chunks, we are gonna derive chunks of the next value in the circuit evaluate.

SPEAKER 1
You don’t need x1 to XN to evaluate the functions enough if you have one of them and then you only get like the partial result for that thing.

SPEAKER 0
Yeah, kind of like you will see like uh how this is done in a second. This is just the general idea. OK. So for simplicity, now I’m going to just use this n out of n secret sharing. So imagine that. The reconstruction is just the addition modular P, OK, no polynomials, but actually what I’m gonna describe works also for this. It’s just a little bit more complicated to see it. All right. Um, let’s show, uh, how to Evaluate each of these gates. So, we have our end participants, P1, P2, P3. PI and PN And they will hold a secret sharing of some value x meaning everybody has a sun x1 x2x3 xi xn. So sum of the excise modular p. It’s gonna be equal to x. So, I will use this notation. Like this double square X to represent the secret sharing of X. Meaning You can view it as the top of X1 XN or you can view it like more abstractly as like a I don’t know, like uh this combination, like everybody has a chun XI. Uh, who some like it’s gonna be exmo, OK. Now when I say that we can evaluate. Each of these gates, I mean that we can move from. This state to one in which the participants hold a secret sharing of the value Y, where Y is whatever like the cir gate outputs, like, let’s start from the first one, this is gonna be, um, sorry, Y is gonna be X + k modular Q. Module P, sorry. Applying this gate is actually very simple. All the parties need to do is the following. Party P1 will set Y1 to be x1 + k module P. And then everybody else sets. Yi equal to Xi. Do you see why this is a secret sharing of X + k? Add together these values, now there is a shift of k that is added to the first share. Add everything to k together you end up with a shift of k, yeah, only one, because if everybody does it like you have n shift of k, right, so the output would be n times k instead of. OK. Yeah Like what you do to derive a secret sharing of x + k module P given a secret sharing of X is the following. Party P1 sets each share of the y to be. X1 plus K module P. Everybody else sets their share to be their exile. Now if you sum all this YI What do you get the sum of all excise plus k. This homophoi is X, so it’s X plus K module P. Yeah.

SPEAKER 5
And this all gets done because one programme is divvied up into the circuit, and then basically everyone of these parties say, OK, you take this X as part of the circuit, you take this X as part of the circuit, you take this X as a part of the circuit, and then for the first party to set X plus K mod P, they just basically do the computation of that gate.

SPEAKER 0
I’m not entirely sure I understood the question, but what is happening is that at the beginning of the protocol, the participants will secret share their input with everybody else, so we can assume that our initial situation is that this X is going to be, I don’t know, the input, the input of some of these participants. And then imagine that I don’t know, it’s this input. Like, imagine that this is an addition of K modulo P. So from a secret sharing of whatever input we had here. We derive a secret sharing of whatever value this wire has, right? But now we have a secret sharing of the value of this wire. Because like we probably have done the same with this gate, we end up with a secret sharing of the value of this other wire, but now we can from a secret sharing of the value of the input wires can derive the secret sharing of the output wire of that gate. Does it answer the question?

SPEAKER 5
When we say they get their, they set their input, that input is just a subcomponent of the function once it’s been turned into a circuit. And then distribute it to everyone or when we say set their input, what does that mean?

SPEAKER 0
Set their input, yeah, what the input itself is just

SPEAKER 5
a some broken like remember like at the beginning every

SPEAKER 0
participants had their own private input XI, right? This was the medical uh records like in the example I gave. That is a string of bits of some sort or like you can encode it in some particular way modulo P and you just secret share it. I see so it’s inputs into the entire function itself, not inputs to the entire function itself, yeah, like you start by secret sharing the inputs to the entire function. And then you evaluate gate by gate, like on the secret shared like uh bits.

SPEAKER 1
Just to make sure that I’m not getting lost, we’re doing like passive secret sharing, passive, passive like active is the obvious like way of breaking this would be just somebody else does it who is malicious does it as well shift, yeah, like for active, like actually for active

SPEAKER 0
it’s all fine as long as you do these three. The issue will be multiplication, but like, uh, essentially as long as like everything doesn’t require interaction like here the parties didn’t speak to each other, right. Like nobody can see it, right? Yes, but like what happens like in that case if

SPEAKER 1
they don’t actually speak to each other and agree on who like does the shift by k for his person’s secrets or the entire thing shifts by k, how do we ensure that it actually shift that the final output

SPEAKER 0
is correct. Is that what you’re asking, or yeah, like how do

SPEAKER 1
we know that that actually works out if they don’t talk to each other? I think I’m the person to shift and then you shift by the wrong amount.

SPEAKER 0
Yeah, yeah, yeah, yeah, sure, yeah. Yeah, you need like an actively secure NPC protocol. They exist. Like there is a way to sort of authenticate the shares, but like, uh, uh, it’s not something I can talk about like in this lecture. It’s, you can make a course of its own on that, yeah. Sorry, can you just remind me what you mean when

SPEAKER 5
you say the secret.

SPEAKER 0
What I mean is that every party has their medical files, like in my example, this is just a string of beats or like you can encode it as a string of values modular P, whatever, like pick any like representation you have, you secret share with everybody else each of the bits of this string. Does it make sense? Huh? Like you do it bit by bit, like, uh, in this case, but it depends. Maybe like the computation you perform is just one element module P like, uh, so in that case you just you could share that value like it depends a lot of uh on the function you are evaluating, yes.

SPEAKER 7
The person who chooses to, the person that adds the K. How is that determined who adds which one has the tag here we just pick one.

SPEAKER 0
We said P1 like uh is our selected guy, but in practise that would be done by some protocol. No, it’s like one of the participants. You just select one to be like uh the, the special one. I don’t know. Right, huh, knows who that is. Yeah, you need to assume that, or at least it’s sufficient that that know that guy knows it and everybody else knows that they are not the ones, yeah.

SPEAKER 4
So is it Understand. So is it like P1 kind of like hosts the computation and then everybody sends their.

SPEAKER 0
Uh, the computation here is distributed, right? Uh, I know that it’s hard to see it in this example, but we are gonna see it with the other gate that is indeed distributed here like randomly select no, k is not selected. That is hard coded as part of the function we are gonna evaluate.

SPEAKER 4
Basically contributes their portion of the secret into the function and then the output is the entire thing. Yeah, correct.

SPEAKER 0
Let’s move on to uh the next uh unary gate, namely the multiplication by a constant modular p. So the setting, the initial setting is the same as before. So, the party is gonna have the secret sharing of X. And our goal now has changed. It’s to obtain a secret sharing of Y where Y is X times k module P, where K is something everybody knows because it’s hardcoded into the circuit we are evaluating, right? It’s part of the gate. What these parties do is the following. Party P1 sets Y1 to be K times X1 module P. Party 2 does the same, it’s gonna be K times x2 module P. And so on. So Yi is K times Xi modular P. And so on. Now if you sum all of these YIs. They’re gonna obtain the sum of K times Xi modular P. The k can be taken out of the sum. Because essentially modular P operation keep commuting with any like uh additional multiplication you perform. And so this is gonna be K times the sum of all excise and this is X. I dropped the modular Q modulo P sorry, but. Like So essentially we move from a secret sharing of X to a secret sharing of X times K modular P. Without ever sending any message. No information has been revealed this in this uh operation because there was no communication sent around, right? OK. Next gate addition modular P. Now we have two inputs, so. We are gonna assume that the parties have a secret sharing of X and also a secret sharing of the other input y. So, it’s gonna be also Y 1 Y 2. Y 3 Y I Y N And the goal is to obtain. A secret sharing of Z. Where Z is equal to X + Y module P. Does anybody see how we’re going to do that? No. Yeah. Doesn’t work Yes. So, T1 will set Z1, his share of Z to be X1 + Y1 modular. Peter was gonna say the same. X2 + Y2 modular P. And so on. So that I is gonna be XI + YI modular P. So now, sum over i is that I, what do you obtain? It’s gonna be the sum over i of Xi plus yi. But essentially you see like we are adding all the chunks of X and all the chunks of Y means that. Like we end up with the sum effect and Y. Does it make sense questions. Confusing Yes, so the secrets X I Y I, they

SPEAKER 6
should always stay secret and only known to the party.

SPEAKER 0
Yeah, the chunks are known so far only to the parties. The only, uh, like we will start sending messages only with the multiplication. And to reconstruct the output.

SPEAKER 1
What happened to the modular commute No, it does commute

SPEAKER 0
with the summation. When you reduce modular P, yeah. This is a general thing always true. Like uh if you add two numbers modular P, it’s the same thing as adding the first number module P with the second number module P and reducing the result modulo P. Like, essentially, you can do all the computations over the integers and you reduce modular P at the end like. Yeah.

SPEAKER 8
1 Y 2 and Y. All the wires are the ones which you’ve got in the previous iteration, yeah, like it’s gonna be some wire

SPEAKER 0
like uh that we obtain like by evaluating as a gate above. And at some point, at some point we obtain, we reach an addition gate where we hold the secret sharing of both the input X and Y and by simply adding locally. Their shares module P. The parties end up with the secret sharing of like the sun. Yes.

SPEAKER 4
It sounds like. Um All of the secrets are sort of pulled together for the first two gates to come up with specific. Wise, and then the sum of those two are then passed into the next two gates.

SPEAKER 0
Like, are we talking about like the circuit on the left? This one? What uh.

SPEAKER 4
Like I, I thought that, you know, the, the X’s would be passed into the first gate, or, yeah, the Xs would be passed into the first gate and the second gate, and then those results were then summed. Where is the gate like?

SPEAKER 0
I, I’m confused.

SPEAKER 1
I think I know what the question is. Like if I understand it correctly, like you read the gate as we need the entire X to compute the x + k model P and then we distribute again.

SPEAKER 0
Or So you reconstruct, you add K, and then you, like, you reconstruct the secret, you add the two values, and then you rese share. Is that what? No. No, no, no, no, no, no, maybe there are other people that have the same question. Like, don’t worry diagram that you had.

SPEAKER 4
about like who’s contributing what to this function? Is everybody doing the function on their own?

SPEAKER 0
No, like, this is, everybody is doing the function, the computation of the function in a distributed way. Like, what is happening is that. Imagine I am one of these participants. Like, I secret share, I have some medical records that I want to provide, like to perform this computation, right? But I want to keep them secret at the same time, right? So what do I do? I secret share them with all of you, OK, as long as Less than 2 of you collude, my medical records will remain private. OK. This is the initial state. Now this is a circuit describing the computation. At the moment we have secret sharing of the value of some of these wires, right, for the competition, which wires? Only the inputs, the thing at the very top. Because what you give as input to the circuit here are the initial input to the whole circuit, so the medical records. If I secret shared mine and you have secret shared yours and so on. Each of us has a secret sharing of each of the inputs here. Does it make sense? Now, I take. Like the gates at the top, it could be one of these 4. Ignore for the moment the multiplication gates that I have not explained. But essentially, Given that we have a secret sharing of the input wire of whatever gate we need to evaluate. We can perform the operation I described like not long ago and obtain a secret sharing of the value of this wire, right? The same we can do for this gate and this gate. But now we have a secret sharing of the inputs to this gate, right? And so we can derive the secret sharing of the output of the gate. And the same is for this one. We know the secret sharing of we have a secret. US jointly have a secret sharing. Of the value of this wire. So we can evaluate the gate and arrive jointly. Like a secret sharing of the value of this wire and so on until we end up with a secret sharing of the output. And at that point we can reconstruct it. Yes, I think what’s causing the confusion might have caused

SPEAKER 1
some confusion here is that like It looks like we have to construct, like we, everybody has a part of the secret. We build the secret, we do a sequence and everybody gets a part of the sequence, but it’s like the other way around, you don’t have to build the secret. You come with the parts of the secret.

SPEAKER 0
Yeah, you know with this part of the secret for

SPEAKER 1
the next part, next, like for like after the gate without having to actually build the secret and look at what the gate does to the secret.

SPEAKER 0
Like you never reconstruct in this uh like uh if you evaluate these three. Gate So far, like in all the operations I described, nobody sends any message to anybody, right? It’s just a local computation. I started with the secret sharing of facts. Nobody pulled together any share. I just perform some local computation of whatever I already know. Yes How do we know how many like gates? Like, you assume that everybody agrees on the function and that they agree on a representation.

SPEAKER 5
I think I’m still trying to understand better how the inputs work. Maybe I think I’m lost also notation. If the input, the initial input is like, let’s say that health record example, then where is the normal distribution of X coming from?

SPEAKER 0
The normal distribution like you mentioned that it was just

SPEAKER 5
a random distribution of X.

SPEAKER 0
Like, like, no, I mean like you distribute the input meaning like you secret share it probably that is yeah this is what I mean with distributing the input.

SPEAKER 5
Then where, where did the ZP? Where does that play out here that maybe I’m lost in that sense?

SPEAKER 0
Like, it depends essentially the choice of P depends on the function you are evaluating. OK? Like if it is a boolean circuit, you’re gonna set P equal to 2. And you’re going to see a share module 2, so your P is going to be equal to 2. That’s it. Like the P is essentially fixed for the whole like uh execution of the protocol. Like, I don’t know if I have answer.

SPEAKER 5
I think that if part of the, the purpose of what we’re talking about here is that you never know the initial input secret to begin with, and part of the strength of how that’s true is because even one piece of information missing makes it impossible to know what any person’s input was, how. I guess I’m still trying to get diffused. How can that, how can that figure if the input is deterministic from another person? Like in the health records example, you know, everyone there, we know there’s 10 people sick, but we don’t know who.

SPEAKER 0
I mean, of course that participants, the one that provides the input, will always know their input, right, but everybody else does not. Because all they see is a tank that is random. No.

SPEAKER 5
Sorry, take everyone’s time, but that when they only see the chunk that is random, if they’re, if they need to sum up the inputs of everyone else’s, those inputs are not random chunks, right? They’re just the secret sharing of the actual original non-random input. Like I think that phase is the part that I’m,

SPEAKER 0
I’m asking about. If you need to sum, sorry, like uh I did we’re summing all of the secret shared inputs in the

SPEAKER 5
very first step in general, then there’s nothing. Where is the randomness there.

SPEAKER 0
I mean, like, uh, the one of the secret sharing to start with, like, uh, I’m not sure. Like, what I’m saying is that if I give a secret sharing of some value X to each of you and all you see is something random, and I now give a secret sharing of another value Y and all you see is random, it’s not that by adding them together, you get to know something new, right?

SPEAKER 1
You want to do, like if you sum up the X, you know the secret because the secret is the sum of all X. The point is everybody knows their own stuff and you don’t know what the other person has. Obviously if you know what everybody has, you know the secret, but as long as you don’t know every single X, you don’t know how to construct a secret because you don’t know what that value is. Like if you have the sum of Xi’s and the Xi’s are sum numbers, you don’t know the, the actual value of the sum until you know every single number in the sum.

SPEAKER 5
So thank you that. That’s my, that’s exactly my question, which is that you’re right, if the, the output, the secret here is the sum of all that is, is what the functional output. But if you’re still receiving all the sums, then you are given all the sums. So I think my confusion, maybe there’s two pieces of here that are like.

SPEAKER 0
Like if you give all the sums of, so what you’re saying is, what if I reveal there’s a dice. Sure, yeah, is that the question? You’re asking, like I start the secret sharing of X and the secret sharing of Y. I derive a secret sharing of the sum Z, and what you’re saying is that the shares of this Z can leak information. Is that what you are saying?

SPEAKER 5
I, I don’t really know at this point.

SPEAKER 0
Yeah.

SPEAKER 5
I think I’m just, I think I’m somewhat confused about how the inputs are kept. I understand that the secret sharing, when we say secret sharing, that means that it is not revealing the thing itself. It’s just sharing representation of it, which appears random to, yeah. And I understand that the objective is to get the output without leaking any additional any of those initial inputs. Yeah, I think I’m just confused. The process from which we go from a function to a circuit and everyone having their own input into that circuit. That originates from. They’re like actual information that they’re sharing secretly. I think that part of the process, I mean like

SPEAKER 0
going from the function to the circuit is something that you can do like always right like then what is the circuit it’s not just any circuit right circuit is the circuit for this function but like the inputs are not hard coded right. The circuit is just like a bunch of gates, but like then you have these input wires that have not a fixed value. You just input the, the values and like uh you compute its gates at the time until you reach the output, right? No, right, I’m, I think I’m just asking my question

SPEAKER 5
poorly. We can, I’m happy to ask as well out here.

SPEAKER 0
Uh, OK, we can do it later. Yeah. Um, Yeah, uh, I lost track of what I was saying. Yeah, the last gate. But I’m not sure now like if I feel like maybe not many people have understood like what is, what we are doing here. So I wonder like if I should reexplain something or not.

SPEAKER 1
Just one thing that I find what confused me in the beginning is like on the slide we compute F of X1 to XN and in our example our secret is X1 like our secret like oh like the fact

SPEAKER 0
that it looks you need every single secret share to

SPEAKER 1
compute the function like calling it like xyz because it’s the secret of X, the secret of Y, the secret of z, and you have the, the partitioned ones have

SPEAKER 0
like there is a collision of notation, is that what they’re saying. I’m sorry about that. Like that is my fault, uh, when I talk about. Yeah, there is a collision of notation. So earlier I called the inputs to the whole circuit Xi, right? Like this, there are two XIs that like uh I’m dealing with. There is the Xi that is the share of some value x. That is not necessarily an input, and then there are the excise that are the input to the whole circuit. OK, sorry. OK, these are two different things. Like if you want to call, like from now on I can call the inputs to the whole circuit, uh, input I for party I, OK? All I’ve said, like after we started talking about secret sharing. Is like the Xi is not input I, OK. That xi is going to be the share of some value x. OK, this random looking sun. So what is happening here is the following. For the multi-party computation protocol, the participants start by secret sharing their input I. With everybody else, OK? It means that we end up with a secret sharing of all the wires at the top of the circuit because these are the inputs to the whole function. OK. Now we pick the gates at the top of this circuit. We already have a secret sharing of their input wires. And from there, during the operation I described, we derived a secret sharing of the corresponding output wire, of the value of the corresponding output wire. So in this way we obtain these three values in a secret shared form. Nobody knows the actual value. Everybody holds a chunk of that value. If the parties want, they can pull it together and reconstruct. We don’t do that. We move on instead to the next gate. Because now we hold a secret sharing of the values of the two input wires of that new gate. And so we can repeat the operation I described earlier and derive a secret sharing of the value of the output wire. Again. Nobody knows the actual value of this wire. We have just a chunk of it. But we don’t reconstruct it. Same for this wire. And then I evaluate this as a gate and so on until I reach. Like the final gate and we end up with the secret sharing of the final output of the whole circuit. OK? At that point we can reconstruct that because that’s the whole point of the competition, yeah.

SPEAKER 1
I have a question. Why do we not just share the secret to begin with? Because we know the circuit, and we get that secret from the output, like we get the, everybody gets told like what the output is, like the secret that is the output. You can completely reconstruct every single thing. From that, can you not because that is the deterministic function up to modular P.

SPEAKER 0
I mean, like, it’s not that, if, take for instance an end gate, like if you have the output and the output is 0, you have no idea about the inputs, right? They could be 0 and 1 or both 0, right? So like uh the output doesn’t leak necessarily information about uh the inputs, like, or at least it doesn’t allow to fully reconstruct that. It depends of course on the function. If you are computing some trivial function. Usually, yes, that is the case, but in general you cannot invert. All right. OK. Finally, I can explain like the multiplication gates that these are, I’m sorry, like I did not move like the slides, uh, but anyway, like all you see, the all I described essentially can be uh like it’s written on the slides. Anyway, um. The more complicated gate is the multiplication gate, because it would be tempted to say, OK, if we want to multiply X and Y, the parties just multiply their shares locally modular P. This does not work, OK? In general, to evaluate the multiplication gate, we need to interact. And furthermore, like the parties will need to send some information. And furthermore, we need some auxiliary material that for the moment we assume is thrown to us by some oracle. Imagine, I don’t know. Some gods provides us with a secret sharing of some values that are random but they satisfy some particular properties. Um, I’m gonna explain. Now we are gonna have a secret sharing of the input X and Y, as before. The goal is to derive a secret sharing of the product Z. Yeah, yeah, yeah. So we have this. And we want to derive a secret sharing of Z. Well said is going to be X times Y module. OK. As I said, we need this auxiliary material. This is called a beaver triple, but like it doesn’t matter really the name. It’s a triple of secret shared elements, OK? So imagine that. God provides like each of these participants with a chunk of these values, so nobody knows the actual values, but, like, uh if you add them together, you obtain A, B, and C. What are the properties of these three elements? A and B are random. Modulo P. And C is equal to their product. OK, so essentially we have a random secret sharing of 3 values where the last one is the product of the 1st 2 module. OK. What happens is the following.

SPEAKER 9
Yes, participant a chunk of.

SPEAKER 0
Correct. Correct. The parties. Compute A sharing. Of um. Yeah, X minus a modular P. We call it E. Oh sorry, And then a secret sharing. Of Y minus B. We can compute this because these are just additions and multiplication by -1, so like we can perform the operation I described earlier. So the parties can derive a secret sharing of these two values, and what we are going to do is we are going to reconstruct these two values. So now they become public. What do I mean? I mean that these parties will send to everybody else their share of the IEI of D and E. And then when everybody has them, you can add them together module P and reconstruct the actual difference. One question, why does this not leak any information to the participants? The reason is because this A and this B are random, known to nobody, so I’m just adding something random to some fixed value, but adding something random to a fixed value is still a random value. So what the parties will see is some random looking. OK. So I haven’t leaked any information about the inputs to the gate. Next I do some basic algebra or math like. I would say, I don’t know, very simple, like high school math. That, uh, where do I write? Uh, that’s right here. Or maybe, let’s use the, the board here. So, It turns out That X times Y. It can be written as essentially uh D + A. Times E plus a beep. This is just because E is the difference between Y and B. And the same for like a D X and A and from this you can rewrite it as D times Z plus E times A + B times D + A times B. But now, this is C. And this is something everybody can compute because DNE are public. We have reconstructed them, so public. For this, we have a secret sharing. So, if you want, we have this secret sharing of C, it’s given by God. For this tool. We can also derive them because this is E times A for which we have a secret sharing. E is a constant. We know how to multiply a secret shared value by constant. He is known to everybody. A is a shared, like we have it here, given by God. Like, you can multiply E by A locally. You don’t even need to speak. Same for this guy, so it’s gonna be D, which is public, a constant no to everybody, and then we have the secret sharing of B that is given by God. So, conclusion, add all these values, what you’re gonna obtain is a secret sharing of X times Y. Yes, so basically these God-given values.

SPEAKER 2
There are also some contains multiple chunks in it and God distributes chunks, yeah, yeah, yeah, yeah, I mean, yes,

SPEAKER 0
so there are like two caveats. First of all, these three secret share values are only used once, like they can only be used once. Because this C and E and D look random as long as A and B have never been used before. If A and B have been used before, then you cannot argue that E and D look random. So essentially every multiplication you perform, you need a different triple of random values to satisfy this. So God needs to make a lot of work. The second thing is Like we don’t believe in God. Like how do we actually generate this? This is something that is quite complicated. Like there are multiple ways of doing it, but one possible way is to use a thing that is called fully homomorphic encryption or like. Like it doesn’t matter. Like I will not ask you how to generate this during the exam, but like you just need to know that there are ways in which we can generate many of these random looking triple of products in a way that like the values are actually secret to the parties, OK.

SPEAKER 9
When you say that AB, A and B are Yeah.

SPEAKER 0
Every multiplication we perform in a circuit, we need to rely on a different triple. One freshly generated like one, like uh that has never been used before. So, yeah, it’s a lot of material essentially, the circuit is big. OK. This ends like uh this passive multi-party computation construction, uh. And for the next time I will restart from here. Probably I will need to use like part of the last, like a lecture to explain like er the last few things like Like the last lecture I think was er like. Q&A like in preparation for the exam, I probably need to use some of that like to. Finish up like all the content. OK.

SPEAKER 3
Just a second. Why were we talking about the 3 guide, and the final equation, there’s no mark here.

Lecture 8:

SPEAKER 0
Tech, OK, yeah, it works. So I guess we can start. So, hi everybody, and welcome to this lecture. Um, today we’re gonna investigate like the anonymity aspects of uh distributed ledgers. And before we start with all the technical details, it’s convenient that I define the three main categories we are going to use to describe these properties. The first one is uh eponymous systems. These are systems in which each action you see like can be publicly attributed to uh some physical uh identity, somebody that performed that action. And to give examples, uh, Facebook is an eponymous system because when you make a post, like it will appear under your name and so everybody can link the post itself to who wrote it, like to the physical, uh, identity of that person. Another example is Twitter before Elon Musk bought it. Um, it had these blue ticks. Those represented like accounts that were linked to physical people like there was some, I don’t know, documents checks like to make sure that everything was going through like that nobody was trying to cheat, but like essentially when you saw the post, like you could link it to the actual person. Another example is the UK, uh, parliament elections like, uh, in which like in the UK votes are uh uh public and so you can, uh, link each vote to the actual MP that like casted it. OK. The second big category is pseudonymous systems, and here is like we’re dealing with systems where um it’s physical person is associated with tags, potentially multiple ones. And yeah, its action in the system can be publicly attributed to a tag, but not necessarily to the person behind it. Essentially, the link between action and tag is public, but the link between tag and the actual person behind it like remains private. And it could be also that the person has more than one tag. Examples X and Reddit, where essentially posts and comments appear under a username and not the actual person, like, so, like, if you see a post, you know the username of the person that like uh wrote that, but you don’t know necessarily who that person is, right? As an example, emails. When you get an email, you can associate it with the address, the email address that sent it, but you don’t know exactly necessarily who is behind that email address, right? And as a person you can have multiple email addresses. So the email address acts as a tag, right? As an example, graffiti, like if you see a Banksy, you’re able to link that piece of art with Banksy, but Banksy is just a pseudonym. Like it’s not the artist himself. Like you do not know who is the real person that like made that, just know the pseudonym. And maybe that artist has other pseudonyms. I mean, in general these kind of systems are uh vulnerable to civil attacks. That is what something that we discussed uh a few times ago essentially it’s the setting in which like some uh maliciously acting uh um entity like impersonates many different people like it generates many different tags and you’re not able to tell whether it’s actually the same person behind it or many different people, OK. Finally, we have the last category that is the aim of this lecture, namely anonymous systems. Essentially, in this system it’s action is not associated with a person. It’s not publicly linkable to the actual person that performed that action, but instead it’s publicly associated with a set of people that could have performed that action, but you don’t have enough information to tell exactly which of these people like performed it, and this set is called the anonymity set. Classical example voting like uh UK elections, for instance, uh, in 2024, 20,000 people out of roughly 78,000 voted for Labour like in North Edinburgh and Leith. Essentially, Each vote can be associated with the anonymity side, which one? The set of all voters of Edinburgh North and Leith. But you are not able to tell exactly which person casted that that specific vote, OK. OK, now question. Where does the system of blockchain transaction uh lie in these three categories? Which one is it eponymous? Is it anonymous? Is it pseudonymous? And he takes Yeah, correct.

SPEAKER 1
High dens, but you cannot Lean back on It’s correct.

SPEAKER 0
So despite what people generally believe, like Bitcoin is not anonymous, it’s actually pseudonymous, uh, because, yes, the tag would be the account. You see money that is moved from accounts to other accounts, right? And a person can have multiple accounts, right? Indeed it’s vulnerable to civil attacks, right? Like vulnerable, like through like a proof of work it’s not, but like uh potentially one person can have a lot of accounts, right? Um Yeah. So Yeah, um. If we check the blockchain, We see something of this kind, right? Imagine we have TX1, that is a transaction that is already published on the chain, and TX2 is a freshly published, uh, transaction. And yet this tx2 will point to like a previous transaction tx1, that is where the money was moved to the sender address. And yeah, in T2 it specifies other two like accounts. One will be most likely the recipient of the money, and the other account will be where we send the change most likely, because in Bitcoins, like if you have, you cannot just use a part of the money of the transaction TX1, you need to use all of it. So essentially you need to also send the change to like your account, OK. And yet we can represent this movement of a cryptocurrency through a graph. Essentially you see the point there is whoever sends the money to account A, so the 50 bitcoins, and then you have the split like 25 bitcoins goes to account C, and then 24.9999 goes to account B. Why 24.99999, the rest goes in transaction fees. And yet, now imagine you take the whole blockchain, you can draw this giant graph of all movements of er resources throughout the system, and you would see a lot of patterns like these ones. Like the first one is the peeling chain. Namely, this is the action of somebody that like does the following. Like first it pays one bitcoin to somebody and it sends all the saints to some other account they own. Then they pay somebody else, so they send another bitcoin to somebody else and they send all the remaining saints like to like the remaining cryptocurrency to another account they own or potentially the same one. And so on. The other example is the star um uh design. This is essentially when I don’t know, you want to pay like, uh, somebody like I don’t know, you have a group of people that does some work in your home and you want to pay them equally, you would do something like this or like that account represents a group and you want to split like uh whatever money you have there equally among participants, yeah. He Like you have an, like an amount and bitcoins that are sent to the, the block, um, the second one, you see, like, then you want to pay somebody, like you are the owner of the block, you want to pay somebody, so you send. Like, uh, in a transaction, one Bitcoin to the account of whoever is the recipient of that transaction, and that then minus 1, the remaining, is sent to, uh, an account I own, like it’s the change. I keep it for myself. Like this is because in Bitcoin, like you need to spend all the money that is in a transaction, right? So like, uh, you cannot like spend one Bitcoin out of the end. Like to do it you would need to exactly, yeah,

SPEAKER 2
just like you just split like whatever is the balance

SPEAKER 0
there and you divide it among those accounts. Potentially transaction at a time, yeah, yeah, yeah, yeah, that is definitely one possible, uh, reason why you have the bidding same because like you don’t know which transaction you will do in the future. So first you do one, you send one bitcoin, then another transaction like, uh, you, you realise that you, you realise that you need to do another transaction. So you continue this way instead. Star is more like, OK, all of a sudden I want to split this money. It could be that I split it between several people. It could be that I split them between accounts I own. That is also a possibility, right? And you would rely on that, uh, particular design. But anyway, Now you can imagine you do the following experiment, as I said, you take the whole blockchain, you draw this giant graph of all how the resources moved around, and that would allow, like, you can pick any Satoshi in the system and you can trace the history of this s Satoshi. How do you do that? You just pick the address, like the transaction where this big, this Satoshi is at the moment, and you go back like er in the graph. Like following the arrows in the opposite direction till you end up with uh essentially coin-based transactions, the one where like uh the Satoshi was minted. OK. And this kind of contradicts one of the basic, a little bit contradicts one of the basic principles of like economy systems in which that is called fungibility. It says that essentially every coin is uh interchangeable like with the others. But here in Bitcoin, every Satoshi is not really fully interchangeable because It comes with a history that links you owning it now to whatever happens before, right? If somebody pay for, I don’t know, drugs with that, you’re linked somehow, right? So that, yes. Meaning that, like, uh, I don’t know if I give you 1 pound like I have 2. Coins like of 1 pound like which one do you choose? You don’t care, they are the same, right? Like uh one or the other like uh they have the same value they can be spent in the same way but like in. Like with uh Satoshi’s, like, uh, each of them comes with a different history. Maybe you care about keeping like whatever, like, uh, is their secret, so you may prefer to spend one compared to the other. OK. So often like you hear in news, uh, Bitcoin is anonymous and in some sense it’s also true like it provides some sort of anonymity. Imagine we are in the following world. We have two transactions, TX1 and TX2. And both of them send 50 bitcoins to some address, different addresses, A and B, right? There are two possibilities that explain what you’re seeing. It could be that both addresses belong to Alice, so in the end she gets like 100 bitcoins. Or it could be that one address belongs to Alice and the other address belongs to Charlie. And so what you’re seeing would be like both Alice and Party gets 50 bitcoins. And you’re not able to tell which of the two cases you are in. So this sort of anonymity is guaranteed by Bitcoin, but we need to pay attention because this is not full anonymity, because what happens now if you see the following transaction that is to the system TX3. You see that the money from the previous two transactions, TX1 and TX2, is spent like in a multi-input transaction to send 75 bitcoins to an account C and the rest is sent to some other account D. If I look at this. I can, like, I’m pretty sure that like. The two transactions I saw earlier were both towards Alice because why would Charlie contribute to Alice like uh like purchase of whatever she purchased, right? So what is happening here most likely is that Alice uh controlled the accounts, uh, the output accounts of TX1 and TX2. She didn’t have enough money to pay 75 directly to the recipient, so she did a multi, uh, input transaction. She pulled together these 50 bitcoins from the two sides. She sent 75 to whoever, uh, she needed to pay, um, and the remaining part minus transaction fees is sent to another address Alice owns. So we can also infer that address the. Like er belongs to Alice. So if one is smart, you can make analysis of this kind and you can get information about who owns like the various accounts. Questions OK. So how do we get better anonymity? And yeah, one possible solution could be to Anonymize my transaction with the transaction that you all are making. Specifically, we could do the following like we can coordinate, we decide to send all the money that we want to send to a leader, for instance me. And then you tell me where this money should go, right? Like I, like, first the money comes to me and then I distribute like to the various recipients that you told me to like, uh, uh, send it to. So what would you see in this system? You would see these. Uh, essentially transaction. The first one moves all your money to my account. And then you will see that I send another transaction in which this money is sent to. Many different accounts, but you don’t know like where like how this cryptocurrencies is routed throughout uh me essentially it could be that this money goes to this. Uh, recipient, it could be actually that this goes through like to this other one. You are not able to tell, right? It could be also that these outputs are the contribution of multiple people, right? Like this money goes a little bit here, a little bit here, and there is also this sack of money that goes a little bit here, right? So. You have this sort of anonymity, like anonymity 1 out of and transactions that are happening in this room, yes.

SPEAKER 2
This would be very insecure if you’re just. Yeah, why would you need to trust me?

SPEAKER 0
Correct, yeah. Yeah, like you send me the money, I disappear with it. Like, why would I distribute it to other people? Like, uh, do you think you can trust me? No. So there is a better solution to this, and it’s the following. It’s called coino, and it’s a system that allows to do this in a secure way so that there is nobody that can run away like with all the money. How does it work? Essentially we still select a leader. Let me go to the right slide. We still select a leader, for instance, me. You all tell me where you want to send the money. Like you say from this account that I own, I want to send the money to this other account. So far it’s all safe because you’re not signing anything, so this information cannot be put on the chain, right? Just tell me what your intention is. Then I create this multi-input transaction. That’s like summarises all these movements and I send it to all of you. At that point you check, you check that indeed, like what you asked me to do is like in this transaction, you say, OK, I want to send this amount of money to this person and you see that that amount of money like uh is spent and is given to that person and the rest is sent to an address you own, like the change is sent to an address you own. And if that is OK, you sign it. You sign it with which key, the key of your input address, right? And everybody does this when we have all the keys, this transaction can be put on the ledger, right? This is how multi-input transactions work. If there are multiple inputs, you want the transaction to be signed by all the input accounts. Does it make sense? And you won’t end up essentially with not two transactions in this example, but a single one, where there are these inputs that come in. And outputs can come out, but you are not able to trace exactly how this money moved throughout, right? This is done by me, the leader. Now of course one needs to pay a little bit of attention like because one like it feels weird, right? Like you sign something like what happens if like this transaction doesn’t end up on the chain, it feels like weird, right? Actually, it’s not an issue. Because there are two possibilities. Either everybody else agrees, like, uh, with this transaction and everybody signs, so we put it on the chain and it’s exactly what we wanted. Or it could be that there is somebody that refuses to sign. At that point, you cannot put like that transaction on the chain. Nobody would accept it because there are not enough signatures, right? You need all the input accounts like signed. And so, like, what does it mean? It means that whatever, like, imagine this is me. Like this money is still unspent. So if this doesn’t go through, I can decide to spend this money in another way. Like I can issue another transaction that for instance, uh, spends this money in some other way that is added to the chain. At that point this cannot be added anymore because it would like use money that is already spent. OK. So this guarantees that I never lose my money. There are some other concerns that we should pay attention to. First of all, what happens if somebody first agrees to sign this and then never does it? Like they would manage to hold the whole uh protocol. So in that case, what we can do is if within a certain amount of time they haven’t like signed, we kick them out and we say OK we do without them like they are just trying to disrupt the whole thing, OK? There are still other potential attacks. Like if I really want you to not send this anonymous transaction. I can join the set of participants, and I can inject some transaction that you would never sign. For instance, I can say, oh yeah, send this money from her address to mine. Like she never agreed to that, but like I claim, add this transaction. Then when the leader sends this transaction to her to be signed, she would never agree to do that. Like, and so the whole protocol would stall. Other er issues, um, privacy. Because here, Like, uh, all the balances, all the amounts that are transferred are public, right? Like they are there on the same, so that sometimes can be problematic. For instance, let’s make an example of bad ideas. What happens if when I participate in this, uh, protocol, I give as a a change address for all the remaining money that should remain to me, I give the same address that I use here. This is a bad idea for anonymity because you would be able to tell that like this is where the change was sent, like where my change was sent. And by subtracting these two values, you would also be able to tell how much money I spent in this transaction, right? Does it make sense? And imagine now this is like, I don’t know, 3. like you end up with that I spent 3.743 like some weird number, bitcoins, and there is here a transaction that has exactly that value you are pretty sure that I was the one sending that money, right? So you’re able to like understand exactly where I send that amount. There’s another issue. Yes, uh, I have a question on that.

SPEAKER 1
Can we not technically also eliminate certain transactions from happening because you know how much money I send into the transaction? So I know any transaction that anyway sends out more Bitcoins that I’ve ever put into the transaction cannot be mine and you can like start eliminating options and reverse

SPEAKER 0
engineer. Uh, you, you consider yourself part of the like you are a participant to this protocol or you’re trying to infer information about everybody else. Is that what that or somebody who’s just looking at

SPEAKER 1
the transaction afterwards he sees how much money you send

SPEAKER 0
the transaction. Oh yeah, you definitely, yeah, yeah, yeah, yeah, this coin joint gives some version of anonymity, but it doesn’t give full anonymity. That is the whole point like, uh, it gives anonymity within that set. Like if the set, the anonymity set is not good enough, like, uh, you cannot do much, right?

SPEAKER 3
Presumably I could put multiple inputs in so I could have, could I, so if I had 3 addresses, and I wanted to split the money that I put in in some way, yeah, yeah, then then I can hide it as it goes in as well.

SPEAKER 0
Yeah, you can do that. You can split like the chains among several addresses, like definitely you, you can.

SPEAKER 3
Could you, when you, when you put the money into these vehicles, are you choosing the vehicle, could you ensure that those 3 addresses that I’m paying from go into the same one?

SPEAKER 0
What do you mean? Yeah, yeah, yeah, like you would tell me as the leader that you want a multi-input transaction that takes like this money from these 3, like, and it sends this amount like uh to this other, and then of course you need to sign using this 3 like uh but

SPEAKER 3
it’s not I think it’s not like the leader picks the track because as I understand it, when you’re building your transaction list, yeah, you, you can select the, you can select the transactions you want to put on others in this case it’s not.

SPEAKER 0
Like I, as a, as the leader, I do not have free, like, I just get the instruction from you and I get like I create a transaction that summarises like all these movements, OK? But I follow like what you instruct me to do if I am an honest leader. But this connects to the other question like why should you trust me? like uh why like maybe I am the one that is trying to understand where you are sending the money, like the one that is trying to break anonymity, yeah.

SPEAKER 1
I also like do you get the entire list of uh actions that are supposed to be taken in that transaction because then technically if you’re just an adversarial that is joining the transaction to like find out what other people are doing.

SPEAKER 0
No, you don’t know. Like you can create a private channel to with me like the leader, and I’m the only one seeing like exactly yeah, yeah, like you only reveal the information only to the people that really need that information, namely the leader. But yeah, still there is an issue because. Like, usually we end up in this, uh, pitfall that is we think that the attacker is just somebody external like passively observing to anything that happens, but like if there is a lot of money involved, like the attacker, usually it’s more proactive like it’s calling it an active adversary. It’s somebody that engages with the protocol trying to assume roles that are convenient for them like to perform the attack to break the anonymity. OK, so we can assume that the leader is actually malicious, and that leader would see where you send all that money. It would say all the information. And you would, it would be also able to link. Your, uh, like message with an IP address, meaning like I connect like the Bitcoin address to an IP address, right? Also that is concerning. So There is a way to avoid this, and it’s by using this tool called Mixnet. It’s a particular tool that is the one that inspired like uh Thor, like the onion browser. And essentially this allows us to send messages anonymously to the leader. So the leader will see multiple messages coming, like for instance, in this example M1, M2. But it won’t be able to tell exactly who sent what. How is this done, as you see in the slide? I do not contact the leader directly and send directly the information to them. I instead route like my messages throughout the network, like with multiple intermediate parties selected at random. Usually And as long as one of these participants like uh is honest so he doesn’t collude with the leader, the leader cannot tell like uh who sent which message. Because essentially this party will shuffle like the order of the messages they come they receive. So you’re not able to trace exactly. What, how the thing that comes in like goes out. And what else? Um, yeah, it could be here, for instance, that A colludes with the leader and that would allow R to know who is sending the messages in the first place. It would know that S1 and S2 send the messages if the server colludes with A. But as long as either B or C are honest and they don’t collude with R, it wouldn’t be able to tell whether it was S1 that sent them 1 or maybe it was S2. Does it make sense? How does this work? The idea is we, yeah. Sorry.

SPEAKER 2
Oh, I guess, oh, sorry, I just remembered it. So is this sort of going back to. Blockchain is sort of based on it, all the participants, the majority of the participants being honest, that like as long as this is this sort of a similar situation where like even if A and B are dishonest and C is honest, then you still have like uh some

SPEAKER 0
security. Yeah, this is how in general cryptography in this multi-party setting works. Like this is actually better than what you see in consensus. In consensus, like you want the honest majority here, one person is sufficient. Yeah, yeah, so all the entire network of this message

SPEAKER 2
or transaction is passed through would have to be malicious for the for you to be able to trace, yeah,

SPEAKER 0
yeah, and they need to collude also. Hm And that, so the assumption here is that the

SPEAKER 1
like the messages go through the described uh like path that the input gives and they are not like it’s not possible for someone in collusion with like the receiver are by just sending the message straightforward to them like shortcutting the path from the network.

SPEAKER 0
It’s not as yeah, you, yeah, exactly, and we will see how this is done like this is done through cryptography essentially. Let’s do it here on the board, in the, on the board first. So I imagine this is me, so this is the sender. And then we have here the recipient R. So this is gonna be the leader for the coin joint protocol. OK, I have my message and. What I’m gonna do is first I select like a 3 or whichever number like 3 is just example parties that are intermediate ones, so let’s call them A B. That’s it. And in this setting, we are assuming that everybody has. A public key, uh, that is public, as the name says, so. Everybody here will have this key like uh PKC for party C, PKB for party B, and PKA. For party A, OK, of course each party knows the private counterpart of this public key. OK. What I’m going to do is I’m going to encrypt this message then multiple times in a layered way. OK, I first encrypt N under the public key of party C. Then I take the ciphertext I obtained in this way and I encrypt it under the public key of Part B. Then again I get what I just obtained in this way and I encrypt it under the public key of RT A and I continue this way until I’m done with all the intermediate parties. And then I send this message to the first party, the outermost layer of this onion of encryption. Can be decrypted by this party because they know the secret key for that utmost layer so they can peel off a layer and they can send it on to Party B. Like you can imagine that when you peel off the layer you are able to tell who you need to send the message to. Now Party B receives this onion like with one layer peeled, so it turns out that the outermost layer is encrypted under the public key of this party, so they can peel it off. Like by peeling off they also discover who they need to send it to, namely C. If they send it. Party C now has another onion with like a one, the last the outmost layer encrypted under PKC so they can decrypt it and finally they can send it to the recipient. This is the idea. And if like connecting to your question, you cannot move like directly the message from A to C because there is the encryption using PKB in the meantime like in between so they would just obtain something that looks random. They are not able to it’s some garbage for them, right? With the help of PKB they wouldn’t have one question

SPEAKER 1
on that if you have a malicious actor who’s just in the network. Uh, to like disrupt, uh, the fact that the sender can send some message to the recipient, can you just refuse to like decrypt the thing and just like do it or like send it but like still encrypt it?

SPEAKER 0
Yeah, yeah, you can, but in that case, like after if after some time the message has not arrived, retry with another, uh, set of end points, right. OK, let’s be more formal, um. We take, how do we generate this onion? Yeah.

SPEAKER 2
Work that we saw in the last slide is that.

SPEAKER 0
You can pick it as you want. It depends on the application, uh, as we will see for coin join, it’s predetermined. In general, it can be picked at random, so you can assume that the participants in between do not know exactly what is the, the path that is chosen, but

SPEAKER 2
like you.

SPEAKER 0
You are able to do the encrypted onion because you are the sender like you know the path like you pick it at random and you generate this onion like

SPEAKER 2
pick at random oh yeah, yeah, yeah.

SPEAKER 0
No, no, this is all done locally before you generate the message you pick like the path you schedule like uh the path and you generate the onion using the public keys of the parties like uh in between. So how is the onion generated? As I was saying, Essentially, you take the message, what is called the payload. And you encrypt it under the public key of party C, but this is done in a special way, specifically, first, I sample a random symmetric key and I encrypt the payload like the message. And then I encrypt. This symmetric key along with the identity of uh where this message should be sent, so the recipient using the public key of uh uh. Partii Do you know what is the difference between symmetric key and public key? Yes, OK, why do we split this thing between symmetric key and public key? Because the payload is big and public key encryption is usually inefficient. Like it takes more computation. It’s much faster to encrypt using a symmetric key, but also the other issue is that every time you use encryption with the public key, typically the size of the ciphertext increases. Like, usually by a factor, uh, quite large, right? So if you have this onion and every time you encrypt, like the, like there is this, uh, large multiplicative factor that is added to the size of the ciphertext, you end up with something that is too big soon, right? So you use this trick like in a way that when you use symmetric key encryption, the size of the ciphertext is equal to the size, roughly equal to the size of the um. Payload and so like you don’t have this explosion of dimensions.

SPEAKER 3
Yeah sorry it’s not secure it’s secure like as long

SPEAKER 0
as the symmetric key is private like the the big rectangle is uh private like. And the symmetric key is hidden by the public key of party C. So if you are party C, you’re able to recover the symmetric key, and then you’re able to recover the, the, the thing here. But if you are somebody else, this looks like garbage, so you’re not able to retrieve the symmetric key and so this thing will like still remain like uh looking random, yeah.

SPEAKER 1
Why is the innermost encryption that we sent to the last participant that sends the network already giving us the payload information? Shouldn’t I agree.

SPEAKER 0
I, I agree. Like, uh, the slides were not made by me when I was checking it yesterday. I was like, yeah, but this is not how I would have done it, but it was too much effort to like change it. But like I agree, it’s just the detail. OK, so this is the innermost layer of the onion. Now we need to encrypt it again. Using the public key of Party B and we do the same thing as before. First we sample another random symmetric key. We encrypt the green part, both the big square and this tiny one, using that symmetric key. And then we encrypt this symmetric key and who this green stuff needs to be sent to, namely party C. Using the public key of Party B. OK. Why Party B? Because like it’s gonna be like the second last party we have in our network we have chosen. And then we repeat again. So we encrypt everything under the public key of part A again using this thing of symmetric encryption first and then we encrypt the sym these other random symmetric key we have chosen. And the identity of who A needs to send a message to, namely B, using the public key of A. Important. The symmetric keys I’m using in this layer are all different, OK. Because if it is the same, like the first party that gets the first is able to peel the whole onion, right? Yep. Sorry?

SPEAKER 4
2 and on this side it’s fixed side.

SPEAKER 0
Fixed size block one. I’m confused. Like it means that it doesn’t increase as like uh you encrypt it’s isn’t this image that image.

SPEAKER 4
Uh, are these two representing the same?

SPEAKER 0
Did this thing at the bottom on the left and the one on the right? No, I mean, uh, they are kind of the same, but like the difference is that the content is different. One is the payload. The other one is like an encryption of, uh, uh, the recipient and like the symmetric key. And also you need to distinguish like the big block, it’s the big green block is a symmetric key encryption. This one, like the green block is a public key encryption under PKC like, so they are slightly different. They’re similar but they’re slightly different. Like, let’s maybe try to see how the decryption works. Like we have now our onion, we send it through the network. This is us. We send it to A. A can peel off the pink like layer, because she knows the secret key. Like you can, she can decrypt first of all the block on the top left, she gets the symmetric key that allows to decrypt all the rest and so she can get all the blue stuff with the green hidden inside. When she decrypt the upper left um block, she also gets to know who she needs to send the result to, namely Party B. Does it make sense? And yeah, so she sent this message to Party B. If you see there is this noise added to the top. What is this noise? It’s just that as you decrypt, like the size of the onion would decrease. But often you don’t want to, like that size of the message would tell you like how long like the, the ciphertext has travelled, how many layers has been peeled so far. So usually, if you care about hiding like also the path, you add this noise to make sure that you’re not able to tell like uh how many steps are, have been, like how many times this message has been passed around, OK. And yet public uh Bob, when he received Bob, Barty B, whatever. When he receives this message, can tell uh which one is what noise and which one is not, like, uh, this is simply, they will try to decrypt the noise and if it ends up that it has like just some random structure, you’re pretty sure that it’s uh like uh it’s like uh some noise. If you end up like with a structure string that says send this message to like C, then you know that like that is actually like uh. Like the actual ciphertext, yes, and two questions.

SPEAKER 1
The first one, so the noise is just there, so someone who is observing it doesn’t know that the message has to decrypted that many times, because obviously that like the way you just described, it says B still knows there has been B knows, yeah, knows that it has

SPEAKER 0
been, but somebody is seeing from outside like cannot tell like the issue is the following. You can imagine something like this, like, uh, you have two centres. So sender 1 and sender 2. And they send these messages. But sender one sends directly to this guy. Sender two instead first sends to this guy and then to this guy. And then you see two things going out, right? If you want anonymity, you would like that you’re not able to tell whether. The things travel like this and this, so they make a cross or whether it is more like this and like this. But if like you don’t have the noise, you will be able to tell where they go because when you decrypt. Like this method here, you get, without the noise, you get something that is smaller, like because you peel two layers, and the other one you just peel one layer, so you would be able to tell where, which one goes, right?

SPEAKER 1
And the second one that uh the noise is always assumed to be like created in a way that it cannot randomly actually create some action.

SPEAKER 0
Yeah, what typically you would do like you just had a tag like a hash of the plain text like to like if you want to send a message first you hash you add that. Tag and then you encrypt everything and when you decrypt, you can check that the hash like verifies like if you want, but like there are many other examples you can just add zeros like if the first like sufficiently many entries are zeros, you know it’s the message otherwise not like it’s up to you to about how you implement it, OK. But yeah Going back to the example, Bob now decrypted the blue layer. It has the green layer that to him it looks random because it’s encrypted under the key of C. It gets to know where this whole thing needs to be sent, namely C, and so it can pass it on and then C can remove the last layer and send it to R. So how do we use this tool for like anonymity uh in coinjoin like anonymity against the leader like the leader is corrupted, you want to hide where you send the money. The is you’re gonna send all these transactions through MixNet. The leader will get all like, like the information about how this where this money needs to be sent. But it cannot tell like, OK, this money was sent by this person, this money was like this transaction was the one chosen by this person, this transaction is the one that this other person wants to perform. Does it make sense? And of course, when you tell like the transaction to the leader, you need to separate like inputs and outputs, otherwise they can be linked. It’s not like you send a message that says send money from this account to this account. You send first a message on Mixnet that says, Like, uh, send this amount of money from this account and then a second message that says give this amount of money to this other account. In this way you don’t know like whether I sent both of them or if I sent only the first one and the second one was sent by somebody else, right? Does it make sense? I see puzzled faces. Yeah, that means that basically the leader would have to

SPEAKER 1
check that like I mean I guess the transaction wouldn’t go through if you have more people sending, oh yeah, send the money to someone and less people send actually

SPEAKER 0
you just need to check that the balance like, uh, like if there are more, uh, outputs than inputs if like first of all like you can also do it but like that transaction wouldn’t be accepted by the team right? like. OK Yeah, so formally you’re gonna do something like this where is. OK. You organise all the participants in a scene. So here actually the network of the mixed net is not chosen at random, it’s fixed. So we have P1, P2 ta ta ta ta PN. And then we have the leader R. And we will start with P1. B1 will create the onion using the public keys of all other parties, right? And then it sends on the onion to Parti P2. P2 peels the utmost layer. And before sending anything to anybody else, it generates an encryption of their message for the leader using the public keys of all other parting in between, not P1, just the parties in between, right? This is gonna be, yeah, like another onion. Then it shuffles the two onions, the one received from P with one layer removed and the one it has just generated and sends everything to P3. P3 does the same. It receives two onions. It peels a layer from each of them because the utmost layer is encrypted under the public key. It generates another encryption encryption of their message for the leader. Again, using the onion with the keys of the parties in between, shuffle and pass on to party before, and so on. It’s important to shuffle, otherwise you are able to tell, like you say, OK, the first one is the one that comes from P1. OK. Perfect. And yeah, this allows us to get some sort of anonymity towards uh against the leader, but there are still other issues. For instance, the balances of this transaction is still public, right? Like you can still perform that attack that I described. So how, what can you do if you want to make them private? This is what uh this other blockchain tries to do. I’m sorry for the name, it’s called Mimble Wimble. Like, uh, I would say that the blockchain community doesn’t have good taste in terms of names. Uh, essentially, in this, um, system, You don’t send directly, like, the values that are transferred are not public, they’re actually committed to. Do you know what a commitment is? Like a commitment scheme is this uh randomised algorithm. That takes us in the methods X you want to commit to like this would be for instance like the value like the of your transaction. Or the money on your account, whatever. And some random string R, so R is random. So this symbol means random like it’s random coins, by the way, but yeah. Uh And the output is what is called a commitment. This commitment hides this x. But at the same time kind of binds you to X, meaning that at a later stage you can reveal the R that you have used to everybody else and everybody else can extract from DC you have published X. Exactly x you input here, nothing else. OK. Yeah.

SPEAKER 2
Yeah, yeah, it’s hash the value plus randomness that would

SPEAKER 0
work that would give a commitment, yeah, that is because you want to hide like, uh, whatever is in the commitment without the randomness. Like you can check whether like this is it’s not even brute force and it’s also the fact that if I think that probably you want to commit to some value I can just test it, right. Like if I have the suspicion, probably she like committed to this value I can just check like you don’t want that you with the randomness you even this attack wouldn’t work right.

SPEAKER 2
It’s still To everybody else to then determine how much X was given. Yeah, but like prove that you. Actually submitted that.

SPEAKER 0
Like with the random value, like given the commitment and the random value, you can extract X.

SPEAKER 2
Yeah, the responsibility of that extraction.

SPEAKER 0
Oh yeah, OK, sure, this is a simplification. I, I like with the particular hash construction you would need also to give x together with r like, uh, yeah, yeah, like, uh, in that case like uh you wouldn’t be able to extract x directly from the commitment and r. But uh you can still like send arc x to together with R and everybody can check that indeed that X is the one you committed to earlier like that is not an issue. Does it make sense? Mhm Anyway, uh, what happens in Mimble Wimble is that instead of like, uh, Sending the actual values like as part of the transaction you put commitments of these values. The issue is, however, that how can you verify then that the outputs like are less than the inputs, right? So maybe you are uh minting money like in the transaction. If everything is hidden but these commitments, you are not able to tell, right? Uh, by the way, like, how do you move like ownership of the money? You would need if I want to send money to him, I would create a primate sun with it, and I would like to send the opening R of this commitment to him so he knows how to open it, right? OK, so going back to the issue that I was describing, you don’t want the participants to like create money out of thin air. Like the sum of the output should be always smaller than the sum of the inputs. So how do you verify this if the commitments like hide all the information that is there? That is why Mimble Wimble doesn’t use like commitments like the one she was describing with the hash functions. It uses commitments that are called homomorphic. These essentially are commitments so that when you add two commitments, you get the commitment to the addition of the two values. OK. You have a commitment to 1 and a commitment to 2. You add together this addition is actually Not the addition as you imagine it like over integers. It’s addition over a more complicated like algebraic structure and you end up with a commitment to 3.

SPEAKER 2
Yeah, this is not a hash this.

SPEAKER 0
It’s just a string that has a particular structure. Like I can go into the details of like the math behind it, but I’m not even sure that like you have enough background, some output, yeah, and all you need to know is that there is a particular operation that you can perform between these strings so that you can add them. And get a commitment to like uh the sun and it turns out that. Uh, the opening like these are like for the uh sum of the two commitments is gonna be the sum of the openings of like uh like the two original commitments. Does it make sense? Like, like if you ever see this stuff, it’s called Peters and commitments. Like this is the most typical example of this sort of commit. But yeah What you can do to check like the balance that you are not creating like more money that like that essentially the sum of the inputs is equal to the sum of the outputs ignoring like transaction fees is that you add together the commitment to the inputs you subtract the sum of the commitment to the outputs and by these homomorphic properties you would end up with a commitment to zero if everything is fine, right? All you need to know to show is that this commitment you have obtained is a commitment to 0. How do you do that? You just provide an opening. An opening for debt-like commitment there. That leaks that in that commitment is hidden zero, but you have no information about what is hidden in all other commitments. OK. And this would give anonymity of the values. All right. What is the issue? The issues that are left, uh, one of them is that we’re still, uh, vulnerable to this, uh, those attacks. Like denial of service as I described earlier, like one can refuse to sign. Um, The other issue is that all of these uh solutions require a lot of coordination, right? Like you need to agree like uh it’s complicated like it’s often not easy. So Now, I’m gonna explain to you other ways we can get anonymity using some stronger cryptographic tool. In particular, it’s a tool called blind signatures. So blind signatures are between a signer, somebody that has a signature secret key. And a user that has a message that wants to be signed. Essentially these two entities like start talking to each other through the protocols back and forth of messages. And at the end, the user will be provided with a signature on the messages they want it to be signed. With the following guarantees. First of all, the user will learn nothing about the secret key of the signer, otherwise they can go around and sign on their behalf. And secondly, the signer has no idea about what the user has just received. It has no idea about what it has signed. And it has no idea about which signature it was generated. Sounds like something that is terrible because like you sign something that you don’t know but like we’ll see how this can be used like to to get anonymity. And this is through something that was like invented in the 90s by Chaum. It’s called Chaw’s eCash. Here we have a trusted bank. So we assume this bank is honest. If the bank misbehaved like we are fucked, but like let’s assume that like this bank is reliable. Imagine we are a user and for some reason we have some right to receive a coin, let’s say of 1 or $5 right? What we are going to do is we sample a random string of bits, what is called the nuns. Don’t laugh, but yeah, it’s. You take the nuns. And you start a blind signature algorithm like a protocol with the bank so that you’re given a signature on this nonsense. And in this way You get the signature while at the same time preventing the bank from knowing these nouns and also like the signature it has generated. That will be your ecoin. OK. Now, if you want to pay a shop, you would just send this signature to them. And at that point, the shop can check that this is actually a valid coin with the bank. First of all, it can verify the, like the signature of the bank. And secondly, you can ask the bank, like, has this coin already been used? Like, is this a valid coin? The bank will keep a list of all coins that have been spent. Like it contains all these nons. The bank checks whether that Nancy has received from the shop is within that list. If it is, it means that that coin has already been spent, and so the shop should not accept that payment. If not, then it adds distance to the list. That coin is considered spent. And the shop can accept the payment. Like you can send like a. Like, uh, whatever good like we purchased. Why is this anonymous? The bank has no idea about the identity of the person that gave the coin to the shop, right? All it is is this nonsense like the signature it verifies it knows that for some reason it issued this signature because they are the only people that could have signed with that secret key. But they have no idea of who exactly was like that sent the money. So it’s an anonymous payment. If now the shop like wants to spend their money, they, I mean they need to ask the bank to issue another coin. Like they have the right, they have received money, so they have the right to to receive another ecoin and they would need to go through all the steps that we described, yeah.

SPEAKER 5
If what the user sends to the bank is just the coin, the nonce and an ID, no, it doesn’t

SPEAKER 0
send it like it’s send it in a blinded way like uh so where there is the information that says

SPEAKER 5
I have, I’ve previously received a coin, now I have the right, you would need to authenticate like the connection.

SPEAKER 0
Like I don’t know, like you need to assume that like the bank has a list of people. Like have a right to a coin first of all. Then there is some sort of setup that says that identifies the user to the bank and says like actually it’s me, and then all the communications are going to be signed like with some like you’re running this protocol, so you’re exchanging messages. You sign all these messages using the secret key that identifies you like to the bank like. In this way, the bank, I know that is actually a bad idea, sorry, like because then you would like, uh, not have anonymity anymore, yeah, I was gonna say

SPEAKER 5
like does that happen in the blind is it assumed that happens in the blind signature or is it assumed that authentication happens before the user tries to initiate?

SPEAKER 0
Yeah, like I guess like in Tom’s construction it just assumed there was some private channel like, uh, or like some sort of way to anonymous like. Sorry, maybe, oh, it’s a bit tricky. I, I agree with the question. There are some tools we could use. I’m gonna explain them later. Like what we would need probably is a group signature here, like, uh, but the, yeah, I’m sorry, like the point of this is a bit like, uh, like it doesn’t matter that particular thing. Yeah, blinded blinded means that they run the protocol I described earlier in a way that the bank never gets to know like whatever it is signing, OK. OK. So we can use this scheme to anonymize Bitcoin transactions. Like now we, the bank will be substituted with this trustee, so somebody that like uh we assume they’re honest, like uh What we’re going to do is the user will send one bitcoin to this trustee. The trust is through some sort of er A fair exchange like it will send this ecoin to the user. Like, so it doesn’t know who the user is. But like he knows like they have the right to like uh receive the ecoin because they paid one Bitcoin. This ecoin can be exchanged with the shop, and then the shop can check the validity to the trustee like it says like, is this, uh, a valid ecoin? Has it already been spent? The trustee can say yes or no. If no, like. Uh, the shop can send like the purchase goods to the user if it has already been spent like it should not instead like accept the transaction and yeah, in exchange for this ecoin, the trustee sends like one bitcoin back to the shop.

SPEAKER 3
And that new bitcoin is then clean of the history

SPEAKER 0
like the trustee will have a pool of all bitcoins that it has received every time it has issued. Yeah, it was like you’re not able to tell it’s some bitcoin they had like in the pool, but like yeah. Yeah.

SPEAKER 1
Is it like randomly you just randomly get one bitcoin, so it could technically happen that the actual bitcoin that the user gave the trustee is the one that ends up on, yeah, yeah, yeah, sure, like, uh, but that

SPEAKER 0
is equally as likely as like any other bitcoin so like. You still get no information about who like uh like yeah sure there is also that possibility but uh it’s not constant like it could be that I mean I

SPEAKER 1
guess the trustee would then know the user because like that it just had like a bunch of bitcoins and bitcoins that I’ve been asked like sent to them too recently will not be used to like limit the probability that the one that they actually.

SPEAKER 0
Like you, you would have even like if you are given like the coin that was spent initially by the user, you would have no information about like you have no way to tell that it was exactly them that sent the money. Yeah No, OK. Yeah, is there like a, a time mapping attack that

SPEAKER 5
can happen here where you need to pay attention to,

SPEAKER 0
to these sort of things anyway, like, uh, here we are dealing with more the abstract things like I assume that everything is like, uh, you see like immediate communication that like, uh, that like there are many other people that are doing the same thing simultaneously but like, uh, yeah, like you need to pay attention to those things. OK. Another example where this can be used instead of coins you can issue credentials, essentially like Uh, I imagine, for instance, there is some stuff that can be only accessed if you are, uh, I don’t know, 18 years old, voting, uh, for instance. Um, but you want to do it in, uh, in an anonymous way like, uh, so what you can do is like you check with the authority like, uh, like if you have the right to be given this credential, like, uh, you would need to run some complicated protocol like to, to show that without revealing it, but yeah, um. You would get uh issued this credential, a signed credential, and the authority wouldn’t know exactly what it has signed. Just know that it signed something you have the right for, right? Then when you reach the gateway for whatever you want to do, you can just give this credential like they will need to talk to the authority and check that this was not already been used. Like if it has never been used, like it should accept like uh what the user claim. Otherwise, like, uh, it should not. Why it should not? Because maybe the user is just somebody that received the credential from the actual honest user, like, uh, so like you don’t want that sort of attack to, to happen. So the credentials should only be used once. And yeah in this way like uh the authority would still not be able to to tell like uh who accessed this uh service yeah if we have the credentials

SPEAKER 1
do we not somehow have to authenticate that the user who initiates to the authority getting the credentials is actually somebody who’s supposed to have yeah, yeah, that is uh

SPEAKER 0
connected with his question.

SPEAKER 1
In the Bitcoin case I can see, OK, cool, we get a Bitcoin so we can just issue something back, but here’s like nothing there.

SPEAKER 0
I agree, I agree, um, like there are the tools to do this. Like it’s more advanced cryptographic tools like we are gonna discuss about it like, uh, like for his case we, it’s sufficient to have what, uh, like, uh, we have like a. You would need to run a protocol that is called multi-party computation that essentially it’s uh encrypted computation like uh between several participants. Yeah Like show blinded. It means simply that you run the protocol that I described earlier like in the blind signatures like the input of the user is gonna be like the credential and some ID like uh and the input of the authority is gonna be their secret key. They exchange messages back and forth. Conclusion, the user ends up with a signature on this uh credential. While the authority does not have any idea about what it has just signed. OK So when they receive the signature later, they are not able to link that to that specific execution of the blind signature protocol. OK, Other issue, um, swaps, like, uh, earlier, like with this anonymity of, uh, um. Um, like, a Bitcoin. There was this first swap step like in which, like, because it could happen the following. I send the bitcoins, but the trustee never like uh gives me the blind signature or like uh vice versa, like uh the trustee like sends the blind signature, but I never send the Bitcoin uh yeah, so you would like some sort of fair swap protocol, meaning that one receives the output only if the other person receives the output. Um, how can you do that? Actually, this is a pretty tricky problem like that has been studied for many years. The issue is that if you use normal models of secure computation, like there is always one party that has the upper hand. However, there are some ways to go around it. One is you rely on a trusted third party like that deals with the exchange. But often it’s hard to find somebody that is fully trusted like, uh, also it’s difficult to agree on who is trusted and who is not, right? Because, uh, me and him can say, OK, uh, I say I trust her, but he says I don’t trust her, like, uh. So it’s always tricky to rely on these trusted third parties. What you can do is some sort of um resource-based fair exchange that essentially uses tools similar to what we have seen with proof of work. And there is actually a way to make it work, but actually the most interesting thing, especially in the context of this work, is to use fair swaps with penalties. So what we would do is you create a smart contract, you put some deposit there like before, uh, doing this, and if like one party um. I don’t know. I signed the Bitcoin and the authority like uh doesn’t send back the signature, like they would lose the deposit. So like they are disincentivized from uh like uh uh cheating. Right. And uh yeah, like this is a bit like what why blockchains are interesting also in the real world because they would allow this sort of like scenarios in which you don’t trust anybody but you trust the the blockchain so you trust that your like a smart contract is gonna be executed like and so you can use this uh deposit and financial penalties like to like prevent people from cheating. And yeah, let’s have 10 minute break. OK. Maybe we can restart. OK uh. Yeah, so, so far in all the schemes we have seen today, like there are a lot of signatures, and all the signatures uniquely identify the signer. I mean, of course, the physical identity the physical persona behind the like signer may remain secret, but you’re still able to link like the signature with the public key of uh whoever signed, right? And yeah, it would be actually cool to have like some signature that preserves the anonymity of the signer. Like you receive the signature, you can tell like this is a valid signature, but you are not able to tell exactly who signed it. Like you have some sort of anonymity set of possible signers, but no additional information about who these people are. And why would that be interesting? because essentially this would allow for anonymous transactions like I can send money to you without you knowing who sent it, right? Like, uh, the transaction was sent by somebody like in an anonymity set like it’s a set of possible sinus, but like, uh, which one? And this is a little bit uh what like uh some blockchains do in particular Monaro. We need particular types of uh signatures, like they come in different uh variants. Like, uh, maybe, I’m sorry, like, uh, I’m explaining what we are doing. Like, here we are trying to design signatures in which, like, they preserve the anonymity of the signer. You receive the signature. You can check it verifies but you have no idea about who signed it like you have an anonymity set and this can be used to like um. Anonymized transactions. I can send money to you without you knowing who actually sent the money. OK. As I was saying, there are several variants of this kind of schemes, um, One of them is called group signatures. Essentially we have a set of participants, it’s with their own, uh, public key and secret key. And they can sign any messages they want and send it around, but when you get the signature. You have no idea About who of these people signed it, you can say that somebody of that group signed it and it’s a valid signature, but you are not able to tell who exactly. There is only one entity that can tell that. This is called the group manager, and it can do it because it knows essentially some secret key that is associated with the group, and using that secret key, they are able to track exactly who signed a specific signature. There is another variant of these signatures that is called uh. Uh, traceable signatures. These are similar to group signatures, like you still have this set of possible signers. When you receive a signature, you have no idea who signed it. You can tell it’s a valid signature, it’s somebody in the group, but you don’t know exactly who. But the tracing mechanism is a little bit different. Essentially, the group manager can issue like some uh uh tracing keys associated with some of these participants. And using that tracing key. You can tell whether a particular signature was signed by them or by somebody else. I can give you the tracing key for Charlie. Given any signature generated by this group, you’re able to tell whether that signature was generated by Charlie or it was generated by somebody else, but you’re not able to tell who is this somebody else, OK? You’re just able to tell Charlie, yes or no. Yeah.

SPEAKER 2
Like, check all the tracing signatures, I guess, for everybody to figure out who it was and like.

SPEAKER 0
If you want to like break the anonymity like uh why do we have this tracing mechanism? It’s essentially to deal with misbehaviour, right? Like uh if somebody does something wrong, you should like you would like either the group manager to figure out who misbehaved and like maybe punish them or I do not know, take some like um like a countermeasures. Um, or like maybe there is somebody that like uh has misbehaved multiple times, so you would like to release the tracey’s signature like uh for them so that you’re able to spot like actually this is like this always misbehaving participant misbehaves.

SPEAKER 2
Yeah, yeah, no, it’s somebody of the group that continues

SPEAKER 0
misbehaving, so the group decides, OK, like, uh, nobody should accept signatures from this guy. Like, so let’s give a trace, uh, a tracing signature for this guy so that you’re able to tell whether that was signed by them or like, uh, by them.

SPEAKER 2
Say like you know, Bob, Charlie, they be like members of different groups and they would have different signature, different

SPEAKER 0
keys like they can of course because they can have multiple signatures account, but in this setting, no. What you would like for that is called a blind, a ring signature. Like, essentially here there is no trusted authority. Everybody has their own public key and secret key, and when you sign the message, you select an anonymity set, right? And when somebody receives this signature, they can check that it verifies, but they are not able to tell exactly who among these people in the anonymity set generated it. Like, so it’s essentially anonymity within a subset of all these participants, and you can select that. And there is no central authority essentially yeah they don’t

SPEAKER 3
know they don’t know which among these anonymity sets you

SPEAKER 0
select like it could be a subset of all participants, OK. Like I can imagine I am Alice and I select as anonymity said Charlie and David. Like I generate the signature, you receive it, you’re not able to tell whether I signed it, Alice, or Charlie or David signed it.

SPEAKER 3
Yeah, like you can have like that you participate in

SPEAKER 0
multiple like subgroups, right? Like you can choose adaptively like uh how this is

SPEAKER 1
how do you verify.

SPEAKER 0
Like, uh, the message will be verified against the list of like, uh I have the list of all public

SPEAKER 1
keys. I know which public key was used to decode the message, uh, to verify the message, and I know who signed it.

SPEAKER 0
Do I not? Like, no, like when you verify the signature, you verify it against like, uh, the list of all public keys like in the case of like you can like if

SPEAKER 1
you have the list, you can just check them one by one and one of them is gonna work and verify it and then you know that no, like if

SPEAKER 0
the like. What I’m saying is that it’s the anonymity set is public, right? So when you verify against like when I send this signature with anonymity set Alice Charlie and Bob, you will verify it using the list of PKA PKC, or PKD. Like if you remove one, it doesn’t verify anymore.

SPEAKER 1
So you It is like in the functionality that you have to give it the entire set and it will

SPEAKER 0
not, yeah, and you will do work proportional to the amount of parties in that so that is an issue, yeah. Yeah.

SPEAKER 2
gender or the member’s best interest to like. I guess sign the message putting them in like the largest subset of yeah in general yes but you pay

SPEAKER 0
with the the size of the anonymity set in general. Like, uh, the larger the anonymity set, the more computation you have to do, like, uh, and the more computation, like, uh, who verifies needs to do so like that

SPEAKER 2
would be the trade-off between us and correct, it would be more part of a larger yeah, correct, yeah.

SPEAKER 0
Correct. So These ring signatures are the ones used in Monaro to uh have anonymous like uh transactions. How do they work? Essentially, when you want to send a transaction, you pick like a, a bunch of addresses that have the same amount of money as you and uh you sign your transaction using this set of accounts as an anonymity set, right? Like the amounts are public in Monaro, like, uh, but you’re so, but all these uh accounts have the same amount of money, so you’re not able to tell like which of them was the one that sent the money. There is one thing that we need to pay attention to what prevents like double spending because if the signatures are anonymous, like what prevents me from issuing another transaction that like spent against that money like you’re only just able to tell it’s somebody in this group, but maybe somebody else, it’s not necessarily me. And that is why Monero uses very particular ring signatures. Essentially, if you sign a message twice with the same secret key, you’re able to trace, like you’re able to see it, like, and so you would not accept the second signature. Essentially, if you issue two signatures like uh with the same secret key, you will be able to like tell like uh that I did that. Correct, you need to, yeah. Yeah And uh yeah.

SPEAKER 1
If we have the groups with accounts of same monetary value, the moment we do a transaction where one of the accounts loses monetary value, does it not have to change its monetary value, and you know that they were the ones who did the transaction. Repeat, sorry, uh, it says that the anonymity set is the set of like accounts with the same monetary value. If now one person wants to do a transaction without being identified, it would use that ring signature, but then it loses its like its monetary value changes.

SPEAKER 0
Yeah, sure, no, but like this is just a transaction, right? Like it’s not that like, uh, it’s like Bitcoin, right? Like you just see a transaction that says like uh money of like one of these accounts was sent, like was spent, like, uh, and, uh, now we have like, uh, these addresses that have this money, right? Like so you wouldn’t see anything. Changing, right? So it’s, it’s not like Ethereum or, it’s not you

SPEAKER 3
don’t have an account, you’re just passing on.

SPEAKER 0
Yeah, yeah, yeah, you’re passing on like that amount of cryptocurrency like the account would be like the, the, the key that like uh yeah. Yeah OK. Uh, Monero gives also like anonymity for the recipient. This is done through this, uh, stealth, uh, addresses. Essentially what you can do is, you know, every party has like a secret key and the public key, and the public key can be viewed as like their account. What you can do is that you can re-randomize the public key. You obtain another public key that. You cannot link to the original one of that party, but this new public key has still the same secret key as that party. Like you just re-randomize it. And so when you make a payment, an anonymous payment, you’re going to use this re-randomized key. So everybody else, an external observer that sees this key is not able to tell exactly. What was the original key that was randomised like you’re not able to trace exactly what is the account that received the money, but the person that owns that account is still able to tell like this is my account and actually I own a secret key like I know the secret key for this uh account, like the one that I already have like is a secret key for this account and so that money belongs to me and I can spend it the next time. Does it make sense? Confused So, essentially, there is a way to re-randomize the public keys of the participants, like from the original public key, the one that everybody knows, you derived another public key. That looks random like if you just see that you are not able to tell like. What was the original public key that I re-randomized? But the secret key of that public key is still gonna be the same one like of that original party, so that party will be able to tell that that transaction was sent to them because they have a secret key that can allow them to check it, right? And they will be able to re-spend this money in the future because they know a secret key for that public key, right? Everybody else, however, is not able to tell who is the recipient. They just say like this public key, but they do not know like how this was derived, which was the original public key.

SPEAKER 2
impeccable double spending.

SPEAKER 0
This is OK for double spending. You are like double spending is like when you issue two signatures like from the same account and we saw it like uh signatures.

SPEAKER 2
So this doesn’t impact.

SPEAKER 0
This doesn’t impact the. This is just a way of anonymizing like, uh, OK,

SPEAKER 2
so it will basically look like it’s going to a different person to the rest of the chain, but you know that it’s yours because you have the exactly.

SPEAKER 0
You are able to detect whether that account belongs to you or not. And then you have a secret key that allows you to spend that money. Like it’s actually the secret key you already had.

SPEAKER 5
Yeah, I made a more just a high level applied question in a crypto system with, for example, a tracing authority, if I’m a vendor trying to like is willing to accept cryptocurrency, it makes sense to me that I would accept a system that’s anonymous but with a tracing authority because it, for example, allows the ability to audit, that, you know, audit the ability like that actors can pinpoint transaction and and uncover its own. Yeah, but why would a like in a, in an actual like real world crypto system, why would there be vendors who would accept a Monaro type of system? Because it’s completely on like anonymous, I agree.

SPEAKER 0
Like, uh, indeed like this, it’s not like I deal more with the technical part of the cost, but it’s a good question. Like, do we really want anonymity like, uh, in a system like, uh, yeah, it’s a fair question. It depends a lot like, uh, of what is your goal. Like there are some people that like really care about anonymity of transactions because like, uh. I don’t know. There are like, uh, not so democratic countries like where like they can trace like where you send money and based on that like, uh, they can, I don’t know, I don’t know, send you to jail or uh whatever right? like so in the situation you care a lot about anonymity in some other countries like uh. Especially the more democratic ones like uh anonymity like uh often can be problematic because like uh it becomes less clear what is happening in the system. It mines a little bit like trust and everything like it’s a complicated question and I don’t have an answer to that. OK. Said that it is Monero anonymous. It’s more anonymous than Bitcoin, but it’s not fully anonymous. Uh, the reason is because the anonymity set like the accounts with the same amount of money may not be so many. So potentially if I am an attacker, I create a lot of these accounts like in the system and so when you try to anonymize your transaction you’re gonna pick an anonymity set that is made only by accounts that I control and so I can tell like uh so how feasible is this? I don’t know it depends on the scale of the whole thing. Uh, but in principle one could try something like this. Uh, yeah, this is a funny story. Like, uh, people that try, they thought they were anonymous because they use Thor, but actually they were the only people like in the that context using Thor in that particular moment like they send a bomb threat like, uh, but. Like to the university, the university just checked who connected to Thor, like, uh, in at that particular time, and there was only one person, so they got caught. Why? What is the issue here? Yes, sure, Thor gives anonymity, but like if the anonymity set has one person, it’s a bit pointless, right? That is why you want an anonymity set that is as big as possible. And to expand it, we would like that the amounts like in the various accounts like the the amount of money that are moved around are kept private and this way the anonymity set can be the whole set of unspent transactions, for instance. OK, um, Let’s try to, like, er, with the following approach. Now, um, Instead of, um, like we represent every coin through a pair of values, like one is the value itself of the coin, like 5 pounds, 5 bitcoins, whatever you want. The other one is a serial number. This is just gonna be a random string of bits that is sufficiently long so that if it is random, you’re almost certain that it’s gonna be unique in the system, right? When the coin is not spent, this serial number will be private. So we are the only, if we own this coin, we are the only ones knowing it. If instead, like the coin has been spent, the serial number will become public. In particular, there will be a list of all serial numbers of spent coins, so when somebody decides to spend their money and publishes the serial number of that coin. We would need to check that this serial number is not already on the list. If it is, it must be that somebody has already spent it, otherwise, uh, it’s a new coin, so we can accept the transaction.

SPEAKER 2
But in that case, like if, if I. coin with a serial number. I want to send it to somebody. I’m spending it, but then the other person that I’m sending, sending it to hasn’t sent it yet. So how is that? Like an identifier for like who currently belongs to yeah,

SPEAKER 0
like you will need to at the time you will need to create another coin for that person like, uh, the coin like, uh, but we’ll see how this is done. I, I totally agree to this but at the same time a new coin for them for the person that

SPEAKER 2
you’re, yeah.

SPEAKER 0
Like, but we’ll see how this is done. Um, yeah. The important thing is that all this information like serial number and value must remain private. So how do we store these coins on the chain? We do it through a commitment, right? We commit to this value so that nobody knows like what is hidden in there. And when I spun the coin, I just reveal the serial number and I prove to everybody else that yeah, there in the chain there is this commitment that hides this serial number and this value, OK. But we need to pay attention because this is not anonymous, right? Because you can link the action of me spending the money now to the action that created that coin on the chain in the first place. You can link the transaction that gave me that coin and the transaction that I’m making now, right? So you would need a tool that allows you to. Like to prove to everybody else that there is this commitment in the chain hiding this serial number, but you don’t want to tell them where this like commitment is. Right, it’s somewhere there. It’s all you need to know. But I do not tell exactly which one it is. In this way you’re not able to link like where this money comes from. The other issue is the one she described, like how do you transfer ownership of this coin, because sure, like I can tell the recipient like this is the opening information, but you wouldn’t do anything with that because like that coin has already been spent, right? Like the serial number is now on the like on the list of spent coins like you wouldn’t be able to spend it again. So let’s start from the first tool we need, namely the one we use to fix the first problem. How do I convince everybody that there is this commitment on the chain without revealing where it is? And to do so we use what is called a ZK S NAC. Like this is an acronym. It stands for this long string zero Knowledge, succinct non-interactive argument of Knowledge. And I’m going to explain what all of these terms mean. Let’s start from what a non-interactive argument of knowledge is. We tackle what is called the NMP relation. This is just a pair of strings X and W. A set of strings of sorry, a set of pairs xw where X is called the statement and W is called the witness. And not all pairs are in this set like we put in this set, only those that are accepted by this. Polynomial time algorithm are, so you run R on input X and W if the output is 1, like you put this pair in the set, otherwise you don’t. And yet, Non-interactive argument of knowledge allows a prover holding this pair xw in this set. To convince a verifier that indeed they know a witness for an X. Specifically, what is happening here is that the prover sends the statement X to the verifier along with the claim, I know a witness for this X. I know aw such that xw belongs to the set. And together with it, it sends what is called the proof pi. And after this, the verifier performs some computation based on what it received, and it either accepts the claim or it rejects it. You have two properties. The first one is if the prover is honest and indeed it has this witness for x, the verifier accepts the claim. The second property is what is called computational soundness. Essentially it says that if the statement is actually false, like the prover doesn’t know any weakness for that x. Then The verifier will not accept it. Like unless there is a caveat, unless the prover runs in super polynomial time, meaning like it will run forever until like it manages to to generate the proof that convinces the verifier, like meaning 100 years, like long enough that the verifier dies in between. By itself it’s not a super interesting primitive because there is a trivial way to convince the verifier. You just send the witness, right? Is and the witness, of course, like uh the claimant, the claim is true, like uh you can check whether the algorithm are outputs 1 and input X and W like uh and you’re sure that like uh the prover didn’t sit. That is why usually we want additional properties in this primitive. The first one is called zero knowledge, and essentially it says that the proof pi doesn’t leak any information about the witness. Essentially, this is exactly what we want, like, in the example I said, like you send, like you want to prove that there exists a commitment somewhere like in the chain that satisfies the property I described. But you don’t want to reveal exactly where this commitment is. Right? So we want zero knowledge. You want to prove a claim, like convince a verifier like that is anybody else about the validity of this claim, but you don’t want to reveal like the witness that proves this claim. There is another property we want, succinctness, because usually these zero-knowledge proofs are big, as big as the witness, and verifying them requires computation proportional to run in this algorithm R. So in the example of the blockchain, it means that you would need to run the algorithm that checks all like entries of the blockchain and checks is this like the right commitment and like it would be too expensive. So when the argument is succinct, it means that the proof is very small and the verification algorithm is also very efficient. In particular, both complexities are independent of the size of the witness. And they are independent on the running time of this r. So essentially these ZK snags are a tool that allows me to prove some statement to you without revealing why this statement is actually true. And this verification is extremely quick. I can tell you, I don’t know, like this blockchain has this very complicated, like like a property that it would be extremely hard to verify, but like I generate this small proof and you can check it quickly and you are sure that actually I’m telling the truth. So, it’s a very powerful tool, like, uh, I think I need to wrap up because it’s almost one. So, um, essentially, using this, you would be able to spend your coin without revealing like a Where like your commitment lied and the chain. There is still the other issue that needs to be fixed, that is how you transfer like uh ownership of this coin. And what you’re going to do is essentially Like, um, you generate like two other coins, like, uh, one with the money you want to send and one with the changes, so that will still belong to you, and then you generate this ZK snag, like you. Like you generate a ZK snarc that proves that indeed what you did is a valid computation. In particular, you haven’t minted more money or like uh you, you prove that like the serial number you have revealed is exactly the one like uh um. Like that is hidden in the commitment on the chain, right? And Everybody in the chain can verify this snark, and so if that happens they can put these two commitments on the chain, right? There is one issue only um. Like we need to still tell like the recipients all the information they need about like the opening of these commitments and where they are. We do it through a private channel. If you want, we can also make it anonymous using MixNet. Like, uh, so they do not know who I am. It’s just like this is a coin, it belongs to you. The main issue is that we need to pay attention a little bit how the serial numbers are generated, because you don’t want that you as a, like the serial number of the coin you have just received is known to me that is the, the sender. Right, otherwise like I can spend it before you even can do it, right? And so that is why there is a bit of a more complicated way to deal with it, and I don’t think I have time to explain it today, but it’s essentially what this particular blockchain called zero cash do. So zero cash is essentially The blockchain among all the big world of blockchain, uh, the one that provides the strongest anonymity. Like it’s not anonymous by default. Like you would need, there is anonymity levels of zero cash you can choose, but if you choose the highest level of anonymity, you would have like uh this form of guarantees. OK, so I think that’s the end of the lecture. I’m here for other questions for the next 15 minutes. Uh, the next time I think I need to finish like, uh, what is, uh, the last part of this lecture of today, but yeah, OK, bye.

Lecture 7:

SPEAKER 0
Can you hear me? Oh yeah, it works. Uh, I’m really sorry for today, like, uh, the reason why the room has been changed is because, like, uh, apparently the recording wasn’t capturing what I was writing on the board. So I asked like the university administration to deal with it and what they did is they moved the room without even telling me, so I went to, to the old infirmary. Uh, then I realized that it wasn’t there, so I came here and, uh, essentially also I couldn’t even write to you because I still have not access to Piazza because of university like not being super efficient. And so I think I will use the 1st 5 minutes like uh of the break to wait for everybody to come here and uh yeah, like uh now it was sent an email by Cristina to everybody and hopefully people have read it and they will come here. Can you hear my microphone? Well, maybe not so well. Like, uh, well. Start. So again, I’m sorry for the situation, the change of room, like I was also not notified about it, so I went to the old infirmary like this morning and realized when I went there. Uh, from now on, apparently the lectures, uh, will be all here except for the last one which I think is again in the old infirmary, but I need to check again. Um, well, I used the 1st 5 or so minutes of the break like to make sure that everybody can read, uh, here in time for the lecture. So, let’s start with today’s topic. First of all, can you all hear me? Because I feel that like the uh microphone is not, OK, perfect. So what did we do the last time and the time before? Essentially we analyzed the security of our distributed ledgers using this particular model in which we split the participants into two broad categories. On one hand, people that are fully honest, meaning people that follow the protocol, they run the code we wrote for them. And on the other hand, we have malicious participants that misbehave like they maybe collude with each other trying to profit the most out of this what happens in the chain. But this is a bit of a simplistic model because in the real world actually it’s not that parties are either fully honest or fully malicious. Usually people are just rational. They are just people that try to maximize their profit. So Today we are going to study the security of our distributed ledgers from this perspective. We no longer think about parties as either fully honest or fully malicious. We think of them as rational participants that just try to maximize their utility. And in order to understand a little bit how we do this, we start with the general philosophy that um is at the base of this um uh discipline and it all starts with Adam Smith. In his work he writes about this invisible hand that essentially redistributes wealth, and the key theory that he proposes is that in a society if everybody behaves egotistically they do well for the whole population in general. I think this is quite a, I don’t know, controversial theory. I personally have some doubts about it, but I think that nonetheless there is an important message we need to listen to. And in some cases society indeed behaves as Adam Smith proposes. OK, to give an example, imagine that we are in a village and we have a baker that is extremely good at making bread. And this baker behaves egotistically, he was, he just wants to make a lot of money. So he bakes a lot of bread. He sells it to the other people in the village. In this way, he becomes rich, but like simultaneously through some sort of invisible hand, he makes also some good for the whole village because now the families in the community have good bread to eat. There is another philosophy we need to talk about, namely utilitarianism of Jeremy Bentham. So in his works he defines what utility is, which you see on the slide is essentially this property of object that tends to create like good wealth, advantage, pleasure. And, according to Bentham, human behavior can be explained in utilitarian terms, meaning each of us is trying to maximize their utility. Of course each of us has a different definition of utility. This could be anything. More the capitalist ideology, let’s say, would say that the utility that we all try to maximize is profit. But like there could be also other kinds of utility. It could be fame like social status, or it could be pleasure or in a religious setting it could be also the probability that I don’t know, you do well according to your god. I don’t know the probability that you go to paradise. Anyway, um, today, we will study like the security of our er Blockchains, the distributed ledger as we described in the past lectures, um, From this point of view, like imagining that the parties are neither fully honest or fully malicious, but they are instead rational, um, somewhat naive capitalist, um, rational in the sense that these are parties that try to maximize their utility, and in my opinion this is a quite a weak assumption because each of us is trying to maximize some utility. It could be arbitrarily weird, but like we try to maximize something. Capitalist and somewhat naive because here we assume that the utility function the participants are trying to maximize is profit, and they do it in a somewhat naive way in our examples, but it’s nevertheless something that is interesting to do. Um, what else I wanted to say, yeah, um, if we want to design a system for which that remains secure that when all participants behave rationally, we need to include some sort of mechanism that incentivize honest behavior. And how is this done? Let’s start by seeing what Bitcoin does in this setting. So Bitcoin incentivize participation or in particular incentivize mining through two mechanisms. The first one is via transaction fees. The second one is through a fixed block reward. So let’s start by discussing what a transaction fee is. So you know, like in each block there is a series of transactions. Each transaction has an input and an output. Input is the incoming cryptocurrency like the output is the cryptocurrency that is sent to the recipient. And yet, there is a conservation of law. In particular we require that the sum of all inputs is at least as big as the sum of all outputs, right? But despite what 1 may think, actually, the sum of the inputs is usually strictly bigger than the size of the the sum of the outputs. Where does the remaining money go? It’s claimed by the miner as transaction fees. OK, this is a reward for the miner for having done the work of creating the block, OK. And this incentivizes essentially miners to put as much as many transactions as they can in a block to be as efficient as possible. How is this money claimed? Well, the miner just adds an additional transaction. It’s put in the first position. It’s called the Coinbase, and in this transaction, it sends the transaction fees, the differences between the sum of the inputs and the sum of the outputs to their account. That is why the last time I said that every block contains some information that depends on the minor, like it’s the account in which the money will be sent. There is another type of reward, namely this fixed reward that is given for every block. This is money that is created out of thin air. It’s how bitcoins are mined. Like it’s how new bitcoins are introduced in the system. And the amount the miner claims. It’s going to be fixed. You cannot choose, of course, like how much money it gets. Otherwise, like, I don’t know if I am the miner, I would claim, give 1 billion to me, 1 billion pounds or something. Like it’s fixed by the protocol and the value depends on the index of the block we are creating, meaning if we are creating one of the first blocks on the chain, the reward will be higher than if we. I don’t know, uh, create a block like far into the future, OK? We will see how this is done. OK, let’s talk more about this coin-based transaction in which both the fixed block reward and the transaction fees are claimed by the miner. This is a special transaction first of all because it’s not broadcast to the participants and put in the man pool. Like, you know, when you want to send some money, you create, you say to the system, I want to send this money to this person. And then somebody will put it in the block. With the Coinbase. This is not done. Like the Coinbase is created on the fly by the miner and put it in the first position of the block. Secondly, this Coinbase has no input. Like there is no incoming transaction. What we are taking is just the the transaction fees that are already described by the transaction in the rest of the block. And the, the fixed reward that comes out of thin air. Um, so, actually, um, There is some space left in the block. Like the space that was previously used by the inputs and so this space is used for metadata, metadata, for instance, the index of block, also called height. Um, the name of the miner that created that block, um, some entropy, meaning some random string of bits. And it could be also used to signal some protocol updates or like some general communication about the functioning of the whole system. OK. Um Let me, uh, One important thing, of course, like a minor cannot claim more than the transaction fees and the block reward. If you create a block in which you claim more money than you are supposed to, nobody will accept it, right? Like Every time I mine a block, I broadcast it to everybody, but the people will check that this block is a valid block, meaning the sum of the inputs is greater or equal than the sum of the outputs. And then you also need to check that whatever is claimed in the coinbase is at most the difference between inputs and outputs, plus this fixed reward. Anybody can check that if this block doesn’t pass this check. Nobody accepts it. All right. Now, I would like to talk a little bit of how this um fixed block reward is computed. Essentially, uh, this was fixed at the beginning of the blockchain, uh, of the Bitcoin blockchain to 50 bitcoins. So something that back then wasn’t worth a lot, but today it’s worth a lot of money, OK. So whoever mined the first block on the chain got 50 bitcoins as a reward plus transaction fees. Then this reward is halved every 210,000 blocks that are added on the team, which usually happens every 4 years. And we call these periods in which the reward is constant an era. Now, you understand, like if we keep having the um reward every fixed number of blocks. It means that the reward decreases exponentially in time, right? And it also means that the total amount of bitcoins that will ever be produced is cut. Because like the curve of number of bitcoins in the system will grow as a like a Like E to the minus x essentially like an exponential with negative um like coefficient in the exponent. OK. That is why often Bitcoin is called the digital gold, because as in the world there is a fixed amount of gold that can be ever mined. Like for bitcoins, there is a fixed amount of bitcoins that can never be minted. And here is like a graph of like um. Like the total amount of cryptocurrency that is in the system. Like it’s the red line, um. You see, like there is this vertical line like roughly before 840,000 blocks and that is The state of the chain when this slide was made, so last year. And you see the vast majority of bitcoins have already been minted. The blue line instead corresponds to the reward. You see like the scale you need to look at is the one on the right. At the beginning it was 50 bitcoin, then after the first era, it became 25, then 12.5, and so on. OK. So, soon it will become essentially 0. Any questions? Yeah. Future, what happens to the whole system No incentives. There are still the incentives that are the transaction fees. So what was the idea here? The idea was that Like at the beginning, like they created a system and like essentially Bitcoins were like had no value, right? Like I create my own system today and I said, oh yeah, would you pay £1000 for my new cryptocurrency? No, because it’s just like some abstract concept that nobody agrees upon their value. So in order to incentivize this system, like they had to give a lot of reward, right? Like as the system grows instead, like you need to give less reward because there will be more people that use the system and therefore more transaction fees. That was a little bit irrational. Yeah, There are however some negative consequences of this design choice, namely the level of inequalities on the whole blockchain, because the first miners in the system got a lot of the reward. So if they didn’t spend those 50 bitcoins today, they have a lot of money, right? that people that joined recently don’t have as much money and don’t have the possibility to earning so quickly. That is why if you check like the level of inequality you see there are 2000 addresses that corresponding to roughly 0.05% of the whole number of addresses that controls 41% of all tokens. And in today’s world, according to these estimations, like you have the 0.01% of the population, so more than that 0.05% controls 11% of all wealth. And it’s not that today’s world is very equal. Like the blockchain is a totally different level, yeah.

SPEAKER 1
V Going down exponentially and we said that like people can still make money off of the the transaction fees but like I guess I’m wondering, like, do we know what the Average, I guess ratio is between like, I

SPEAKER 0
mean, of course it changes from era to era, right? Yeah, because I’m just wondering like is it, is it

SPEAKER 1
sustainable to assume that the, the transaction fees will, I guess, compensate for.

SPEAKER 0
Uh, it depends. Like, uh, like in general, like if the transaction fees are not sufficient like to incentivize mining, what happens is that mining becomes less, uh, like common. Like there are fewer minors, so you have to wait a longer time, like, uh, for the system to validate your block. So maybe if you want to immediately have your transaction validated, you give higher transaction fees, right? Like, so. It might, yeah, that, that is what that is what Adam Smith would say like there is this invisible hand like uh that manages, yeah Adam Smith that is a

SPEAKER 2
system of infinite growth that is not I agree.

SPEAKER 0
I agree with that like uh. Like, um, it’s not that like you need to understand that all these analysis were analysis that were made after like the Bitcoin paper was published. Like the Bitcoin paper never Like it’s never formally have an analysis of the whole system. It just proposes it. And then in the following years there have been like scholars and like resources that have analyzed the system. So like it’s not necessarily like the optimal, uh, it’s not even clear whether like all of this was studied by who designed the system.

SPEAKER 3
Relatedly, is there, uh, a world in which when the block reward becomes functionally zero, the cost in compute to mine a new block exceeds the average transaction, the average, uh, value in?

SPEAKER 0
Yeah, there is a possibility like, uh, but it’s a bit like. So what happens if like. Mining would not be like so um profitable. There would be fewer miners. It takes longer for the block to be put on the chain, so like you’re incentivized to increase your transaction fees in order to make sure that your transaction is put on the chain, right? Like, so it depends. Like uh it’s again it’s. It’s a complex system, so I’m not able to give you an answer to this, but like there is a possibility that that auto fix systems like uh the market like kind of reaches like uh an equilibrium, OK. It’s like I don’t know if all of a sudden there are fewer houses, like what will happen is that the price of rent will increase, right? Like if you have fewer minor, like the cost of having your block, like your transaction put on the chain will increase. But sorry just fell out in in that world though,

SPEAKER 3
wouldn’t that mean, you know, if I usually mine a block and suddenly the cost for me to mine a new block is higher than the benefit that I’m getting from that block, my incentive actually is not to try and raise transaction fees, it’s to cut off new supply entirely because the Bitcoin that I previously owned is just gonna go up in price like repeat again. So you’re saying that that. Minor people will still be incentivized to raise transaction fees so that they can have their own transactions of Bitcoin put onto the ledger, but because supply is, you know, suddenly cut off, new, new supply is cut off completely, wouldn’t they be incentivized to have no transaction fees, no transactions at all for a while, because as long as there’s no supply, the value of the Bitcoin they already own is just going up.

SPEAKER 0
I see what you’re saying. You’re saying essentially. What do you mean with supply? Maybe if like the miners, like the house example, right?

SPEAKER 3
Yeah, we’re saying that we have new, you know, if we have no more houses being made, then I just want to live in my house and wait 2 years till someone else solve the problem and my prices go up. Yeah. Similarly, if suddenly there’s no incentive to mine a block because of transaction fees as they are, the current market price for transaction fees is less than the cost of compute to mine a new block, then I would just say, why would I raise a transaction fee. I can just wait for someone else to solve that problem. And in the meantime, the value of my Bitcoin skyrocketing because no one else, yeah, but maybe like you can

SPEAKER 0
assume that like you have like pressure to like maybe you want your transaction to be added to the chain, right? Like you don’t have the possibility of waiting, right? Like, so in that case if you really need like that transaction to go through, like you are forced to increase the transaction fee, right. follow-up question on that.

SPEAKER 2
Isn’t the only value you get out of Bitcoin the fact that you have the chain that is continuously like going on, so the moment you stop doing something, wouldn’t that immediately destroy the market value of Bitcoin because that’s

SPEAKER 0
the only. Yeah, sure, sure, but like it’s not that you should not imagine that all of a sudden you are in that reality. Like what happens is that, OK, like the price of mining, like mining is not so profitable, so transactions slowly grow and you never reach this halting situation, right? But I agree, like these are complex questions. Like, to be fair, it’s, I’m not able to answer, give a definitive answer because it’s such a complex system that I’m not able to give an analysis of this, right? OK, um, Yeah, moving on, um. Yeah, this is a slide that essentially tells you that. Bitcoins like have also some sort of um bitcoins are divisible in a smaller unit called satoshi. Satoshis are essentially what 4 pounds are pens, like 100 pence makes a pound, 108 satoshis make a bitcoin, and as for pounds, you cannot. Like send to somebody, at least if you use cash, a fraction of a pen. Like in the system you cannot give a fraction of a satoshi. Like satoshi is the minimum, like one satoshi is the minimum amount you can give to a person or receive, OK. OK. Now, uh We go back kind of to the question that some of you have been asking, namely, is mining really like uh profitable? And first of all, we need to Understand a little bit how mining works. Because there are many ways you can try to solve this complex puzzle. You can either use a CPU that is maybe the first thing that comes to mind. Uh, and actually this is not the best option. Another option you can try is to use a graphic card that has a lot of uh uh hyper, it has high parallelization, so it would be very good for this kind of problem because like Finding like a value for the counter that satisfies like uh for which the hash is smaller than the uh target, it’s a highly parallelizable uh task, right? Like you can do try many counters simultaneously. And finally, what most people do is, or at least the vast majority of miners do is using this highly specialized, uh, hardware called ASIC. And here is a little bit like the situation with uh like mining, like in 2024 when these lights were made. You see, like if you try to like uh mine a block using your, the CPU of your computer. Like, OK, you have a pretty low initial cost, $170butthenyoueventuallylosemoneyeveryday.EssentiallyinenergyconsumptionbecausetheprobabilitythatyousuccessfullyYouarethefirstonetosuccessfullyminetheblockisextremelylowbecauseyouarecompetingwithpeoplethathavesuperspecializedhardware.YoumaytrytodoitwiththeGPUagainprettylowuhhardwarecost.Butagainyouloseevenmoremoney.Why?Because,uh,essentiallyyouwouldconsumemoreenergy,buttheprobabilitythatyouarethefirstto,uh,mindtheblockisstilltoolowtomakeaprofitofit.Thenthereissomespecializedhardwarethatprobablyisnottopquality.Youhaveaprettyhighinitialcostof1500.Butstillyoulosemoney.Why?Becausemostofotherminersinthesystemhavehardwarethatisbetterthanyours.Solikeoverall,youhaveanunlikelyprobabilityofbeingthefirstonethatminestheblock.Andyouseehowthecostincreasebyfar.Likethespecializedhardwareisextremelylikeenergy.Itconsumesalotofenergy.Finally,thereisthisAntMiner9,inaveryhighcost.I{t}^{\prime }s$8000 just to buy the piece of hardware, and this profits like $17 a day. It means that if you want us to get on track like and like res like have a positive like a profit if you subtract like the hardware cost, you need to run it for more than a year. And you need to hope that in the meantime, like uh there is no other um faster hardware that Ends up in the market because then the probability that uh you win the lottery is even lower, right? Because everybody will switch like to this new hardware that is faster and essentially your machine will get uh obsolete pretty fast. So in general, there are still people that are mining, so like, uh, probably if you have a lot of initial money to buy like all the hardware and set up like some sort of infrastructure, it’s still profitable, but like it’s not so profitable as my 1 may like hope. Yeah. Change from I mean, a lot of, indeed like uh most like a cryptocurrency, the general trend is to move away from proof of work and go into proof of stake, but who administered Bitcoin? There is nobody. It’s not, Satoshi Nakamoto published a paper like or not even published like it was just a white paper, like it was just put on the internet, designed this system like it shared the code with everybody. He stayed like uh I don’t know like in contact on a blog like writing some like I don’t know that I don’t know the full history like he was around like on the internet for a few years and then disappeared so there is no central authority that dictates. How the system is evolving. This is just code that is run through in the machine of several people around the world. But there is no central authority that says like oh we go in this direction, we switch to proof of stake. The theorem is slightly different. In a theorem there is uh the theorem foundation. Like we know who is the. The person that created the chain, like you can contact him like and he’s some sort of figure that can say, OK, now the plan is to switch from proof of work to proof of stake. And yeah, in some sense this is a form of centralization like there is somebody that has more influence on the whole system and can dictate how this evolves. And yes, some people may say that the theorem is not fully decentralized because of this. With Bitcoin, this is not possible. Like there is nobody that like tells where the system should, uh, how the system should evolve, right? OK. At this point of the lecture, it’s fundamental that I introduce maybe the most important concept that we will need to analyze the security of our, um, blockchains in this new setting where parties are are fully honest or fully malicious but they are just rational and this is called Nash equilibrium, a concept that takes the name from the person that first studied it, namely John Nash. OK, first of all, we need to understand the setting we are studying. Imagine we have a system of rational participants, so participants that try to maximize some utility. Of course, everybody may have a different definition of utility. Some people maximize for profit. Some people maximize for fame. Some people maximize for pleasure. I do not know. So we represent each of these utility by means of a function. Like you see um, uh, it’s F1, F2 to F5. Each party has a different function. Now imagine that these participants are free to behave as they want. And Depending on how the system evolves as a whole, parties are more or less happy about the current situation. How we describe this. So first of all, we call the the behavior adopted by some parties, uh, a strategy and we denote it by some uh red font letter like uh Xi for party PI. And we essentially model the degree to which each party is happy about the system as a whole by evaluating their utility function on the combination of all the strategies X1 to XN. Does it make sense? OK. What is a Nash equilibrium? A Nash equilibrium is a combination of strategies, so one strategy for each participants. That is in some sense locally optimal. What do I mean with this? I mean that if any participant decides to move away from this strategy described by the Nash equilibrium, whereas everybody else still remains with the strategy of the Nash equilibrium. The profit of this party that decides to move away. Like decreases it cannot increase. Essentially, by changing your strategy while everybody else remains like with the uh Nash equilibrium strategy. You lose profit. You are disincentivized from moving away from the main uh strategy. Any questions? Yeah Functions and functions.

SPEAKER 1
No sort of Like it’s not that you are happy

SPEAKER 0
or either happy or not happy, you are to some degree happy like so.

SPEAKER 1
Achieving their utility by like It depends.

SPEAKER 0
Like, like it depends how you model this utility. Usually the utility is not like 01. It’s not either you achieved it or you didn’t achieve it. Like if utilities profit, you are happy the higher it is. Like, so it’s a bit of a continuous spectrum, like, uh, so like it depends a little bit on the game. OK. Yeah Sorry? Like, repeat what I described. Like, OK. So what is a Nash equilibrium? A Nash equilibrium is a combination of strategies. It’s one strategy for each participant that is locally optimal. It means that. If everybody sticks to the strategy described by the Nash equilibrium, right, but you decide to move away from it, your profit decreases. You’re less happy about that situation, whatever you choose to do. So you’re disincentivized from moving away from the equilibrium. So you are being Uh, I mean you can still move away but it would hurt you, OK? You will be less happy. Sorry. Oh, definitely not, yeah. Definitely not. Let’s make an, oh One changes To From X1 to

SPEAKER 1
Y1, then all of the, all five parties in this picture are.

SPEAKER 0
No, we are talking just about like uh the profit of uh the party that moves away from the strategy.

SPEAKER 1
where no party can. Like their specific behavior or like their specific behavior. OK, I thought I meant yeah.

SPEAKER 0
No, no, like, uh, we are talking just about their specific behavior, their, their specific behavior, yeah. It’s local optimum for them like uh. Yeah, good question. Let’s make an example. So this is called the prisoner’s dilemma, and probably it’s the most common like a textbook example of game theory. So imagine we have two members of a criminal gang that are caught by the police and put into different cells so that they cannot talk to each other. And the police doesn’t have full proof to give a full conviction to these criminals, so they offered them a deal. So If they get a partial conviction, they get only to spend one year in prison. If they get a full conviction, they get to spend 3 years in prison. However, if they decide to testify against the other criminal, they would get a 1 year reduction from their sentence. And the other criminal will get a full sentence because now there is somebody testifying against him. So what is happening is described on the slide. So if both criminals decide to stay silent and not collaborate with the police, then they would get both a partial sentence or both one year in prison. If instead they both decide to testify, they will both get 2 years in prison. 3 years because somebody testified against them, so they get a full conviction. But then they have this discount of a sentence because they testify against the other. Finally, if one of the criminals testifies and the other does not. The guy that testified is immediately released because there is a partial sentence of 1 year minus 1 year because of the deal. And the other guy instead gets 3 years in prison because somebody testified against them, but they did not take the deal. So the situation is summarized by this table. So you see the roles corresponds to the strategies that the first criminal, uh, Mr. Ray, can choose between. So either staying silent or testifying against the pal. And on the other side, like the columns, you see the possible strategy of the second criminal, Mr. B. Again, silent or testify. And in the 4 cells you would see like what happens like uh when those particular combination of strategies are taken for instance, top left corner, both parties get 1 year sentence. I use the same minus because. The more years you spend in prison, the less happy you are, right? So we can assume that their utility decreases by one. Bottom right corner, they both testify, they both get 2 year sentence, so -2 is the utility for both. In just two cases, one party. I immediately released, so it gets uh utility 0. The other party gets to stay 3 years in prison, so utility minus 3. Now in this setting, what is the Nash equilibrium? Yes.

SPEAKER 2
Both testify because it’s always better to testify.

SPEAKER 0
Yeah, that is correct. So You see, it’s the first line. If both parties testify, like they are in a Nash equilibrium because take for instance the perspective of Mr. A. If they switch strategy, they decide to remain silent, but Mr. B still testifies. Then they would get to stay 3 years in prison instead of 2. So the situation will get worse. The same thing happens for Mr. B. If Mr. B decides to move from the strategy of testifying to the strategy of staying silent, they will get 3 years in prison because Mr. A would still testify against them. And uh that would like make their situation worse. And yeah, essentially what’s happening here is that testifying is it’s always worth testifying. You always improve your situation if you testify. So that is why we call testifying the dominance strategy. But it’s funny because if you look at the table, like the Nash equilibrium is not necessarily the optimal. Like if you take the strategy in which both remains, both parties remain silent, it would be more convenient. Like it would get both. 1 year sentence instead of 2 years, right? But that one is not a Nash equilibrium. Look at the second line. And imagine now you are Mr. A. If you decide to switch strategy and you decide to testify. You’re immediately released. Because if the other party sticks to silent, silent. They would not testify against you. So it would be convenient for Mr. A to move away to betray the partner. And they testify against them. OK, now we saw this definition of Nash equilibrium in the context in which we take the perspective of a single party. What if, however, these participants decide to collude. Well, we can generalize the concept by saying that a Nash equilibrium is some combination of strategy for which no coalition can increase their aggregate utility by changing their own strategy. Like everybody else still stick to the same strategy. The members of the coalition can change, but in doing that. They just decrease their profit. They would be less happy OK. Now, what time is it? Um, let’s have a 5 minute break. Uh, Cristina is here, like, uh, she’s on top of the, uh, the top row. So if you have any questions about the projects, you are welcome to go to her and talk. Yeah OK, uh, let’s start again. Uh Oh, I see. Um, Why do we care about Nash equilibria? The reason is that when we design a system. We would like that. The incentives in the system make the owner’s behavior in a Nash equilibrium. That means that people are incentivized to be honest. If they try to move away from the honest like strategy, they would only lower their profit. They would become less happy, OK. So the big question is, is Bitcoin in a Nash equilibrium? And here the answer depends on how we model the utilities of the participants and also how we model the whole system. Let’s consider the following experiment. Imagine that we consider an execution of the Bitcoin protocol up to a certain time limit. We assume the number of participants is fixed. And we assume that the harness parameter is fixed. It doesn’t change throughout this experiment. OK, there are 2 ways, 2 main ways we can define the utility. The first one is in terms of absolute rewards, meaning The amount of money that the miners make in this experiment by publishing blogs on the main chain. OK. And here we are only considering Like transaction fees and the fixed block reward. OK. Not anything that happens inside the chain. OK. The other way we can Coni like another possibility for the utility function of the participants is uh based on relative rewards, meaning the fraction of all rewards that is assigned to that particular party. You sum all the rewards that that party gets in the experiment and you divide by the total amount of rewards assigned to the system in the experiment. Why do we care about relative rewards, or at least, why would it be a good assumption to assume that some participants care about relative rewards? The issue is that in general you don’t want somebody in the system to become too strong because then they can essentially modify the uh The game theoretic landscape, let’s say, like, uh, what it means is essentially they can um. Modify. Your utility function for instance through blackmailing, coercion, or bribery, and we will see an example later. Before continuing, there is a bit of a caveat, uh, because, you know, the execution of this experiment is randomized, right? Like, uh, there is randomness in the execution of the Bitcoin, uh, system. So how do we define the utility of, uh, the participants given that this depends on the randomness of the whole system, right? So the solution for this is to restrict our analysis to the expectation of utility. Or to events that happen with high probability. And yet It turns out that this experiment is in this experiment, the Bitcoin protocol is in a Nash equilibrium. If we model utilities according to absolute rewards. If instead we model utilities according to relative rewards, it’s not. Actually there is a better strategy that is called selfish mining. And actually this is an attack that we have already discussed uh two lectures ago when we talked about uh chain quality. What is the attack essentially. Imagine that we have a privileged position in the network, so we are able to reach everybody very quickly. We send a message and it reaches very quickly everybody. We have reliable channels and also we can detect when somebody is about to send a message or at least like we have a proxy there like ready to capture any message that is sent there. The attack works as follows. We try to create a new block. If we manage to do it, we keep it secret. We wait for other participants to create a new blog. As soon as they. Like broadcast it We immediately send the blog that we have in mind uh to everybody and we rely on our privileged position in the chain. Like we use our privileged position in the chain to send it to everybody before the block mined by some other party arrives. OK, so everybody will adapt adopt our version of the chain. And so by doing that we censored. The block of some other participants. OK. Our block is on the same. The block was put in a fork that will not be adopted by anybody. OK, let’s analyze um. Wait a second. Yeah, let’s analyze this strategy. To see How it compares with the Ho behavior. Now let’s make an assumption. Let’s make an assumption that we have a constant like computational power. So, um, if we take, I don’t know, a sufficiently large window, like let’s say, uh, a window in which the system has a whole manages to create and blocks. We create a fraction alpha of them. So this window of time we produce alpha times n uh blocks. If we follow the strategy. What happens is that the old blocks mined by the system end up in the main chain, so there will be n blocks that are added. Alpha timesn of them are created by us, so the absolute reward will scale proportionally to alpha times n. Right? Like the more blocks we add, The more reward we get. In terms of relative reward, we get a fraction alpha of all rewards. Everybody Like, understand, any questions? Good. Now let’s look at selfish mining. The attack. So in that attack, every time we managed to mine a block, we pushed the block of somebody else off the chain. Right? So The main chain in this window of time will increase only by N minus alpha N blocks, right? Because we mined alpha and blocks and for each of them we pushed another block off the chain of the main chain. OK. But all our blocks are still in the main chain because we use this privileged position we have in the system, in the network, right? So the absolute reward is the same as before because we have alpha times n blocks, so the total reward we get is proportional to that. But in terms of relative reward, we are doing much better now. We have alpha divided by 1 minus alpha fraction of all reward. So, if we care about relative rewards, selfish mining is better than behaving honestly. Yeah.

SPEAKER 4
hiding Like keeping it secret because like you want uh

SPEAKER 0
other people to waste resources.

SPEAKER 4
More time to work on the next block. Compared to the honest part And they only start working

SPEAKER 0
Uh, yeah, if you want also that like, uh, that is also true. But like the main reason is that here like uh you just want, essentially if you manage to like uh If you manage to create a blog, You don’t want to compete like with the others like uh for the next one, right? Like, so you let them waste their resources like in creating a block that will never go in the chain. Right. Yeah. You can also do that, yes. Yeah, you can also do that, yeah. OK. What happens if, because so far in this experiment we consider like a fixed hardness parameter. What if we allow this to change like as we described two lectures ago? Remember, like if the system detected that there was more computational power like then the. The hardness parameter would decrease so that it’s harder to create new blocks. If instead the system detected a decrease of computational power, then the hardness parameter would increase, meaning it’s easier to create new blocks. Now in selfish mining. Like we decrease the amount of blogs that are published on the main scene, right? Because for every blog that we mine, we push one block of other participants of the scene. So if the system now checks like the rate at which blocks are added to the chain, it seems that there is less computational power in the system. So the harness parameter would increase, meaning it becomes easier to mine new blocks. And so in this way, Even the absolute reward of the attacker would increase, right? Because it’s suddenly easier to to to make new blogs. Like they will create more. They will get more reward. So that is why like selfish mining can be actually a better strategy than being honest, even when we rely on. Absolute rewards Like, assuming that this mechanism is working. Like the Changing the harness parameter. There are also, oh yeah.

SPEAKER 5
Even if you have like this chance alpha, that’s our block. If you get the same if you get a block, uh, still it won’t count for anything if like the longest chain is not gonna include our block, right?

SPEAKER 0
Like, uh, yeah, but like what is happening is remember like if you have If you receive two chains of the same length, which one do you adopt?

SPEAKER 5
Uh, the one that is like more difficult and it’s longer.

SPEAKER 0
Yeah, but what if they are the same? What happens if they are the same? Like you receive two chains, same hardness, same, same length, um. Which one do you pick? The first one that arrives So here the crucial part is that we are taking advantage. Like we have an advanced position in the network. So that like whatever we send arize before anything else. Right? So in this attack, imagine that I, you suppose I am the attacker, you are an honest participant. And I have some proxy around you. As soon as you like get a block, you will send it. I will detect. I know that you have found it, so I use my advantage, my position in the network to immediately send to everybody else. And so everybody else will stick to mine because I’m just faster. Right That is the general idea. OK, other attacks that are not captured by our experiments. These are attacks essentially that relate to the fact that in our experiment we ignore whatever was happening in like this blockchain, like all the other transactions. We cared about the rewards and nothing else. So the first tax works when the fixed block reward becomes zero and so we will be totally reliant on the transaction fees to incentivize participation. So in this system, um, imagine you are a non participant or like a rational participant and you receive two chains of the same length like as I described in this example with him. Which one do you pick? The protocol description would say you should pick the first one that comes. Right? But here you can actually try to do something smarter. You pick the one that leaves the most transactions fees in the in the mempool unclaimed. Why? Because you hope that you are the next that uh manage manages to create a block and so you can claim more transaction fees when you do that, right? And so an attacker can. Exploit this potentially irrational behavior of the participants. By incentivizing them to adopt a particular fork and maybe do some double spending attack, right? I can sacrifice some of the transaction fees in the hope that more participants will actually accept my block instead of somebody else’s block. Right? Hoping to create some sort of fork in the system. This attack can become even worse, it can become a bribery attack. Imagine that as an attacker I create a parallel chain in which the first transaction gives to a good fraction of you all like a lot of money. A lot of you would be tempted to make this new fork like the main chain because in that way you have a lot of money, right? So essentially this is a problematic attack when you have a lot of like uh inequalities on the chain. If I have a lot of money, maybe bribing you for me like it’s something that like doesn’t cost so much. It’s just I don’t know, little money compared to the one I have. So I can use this to make perhaps a double spending attack against somebody else, right? So Why do we talk about these attacks? First of all, because if you ever work in this area like either in a company or in research, it’s important to know that there are these potential pitfalls. These are attacks that you consider. But also from a more theoretical perspective, you need always to pay attention with this game theory because it often relies on somewhat simplicistic assumption on the utility of participants. Like often they are this blind, uh, maximize profit like, uh, um, models. Like I do not care exactly what is happening in the like in the transactions that are added to the block. I just care about rewards like we have described that one and Actually, stuff can become quite complicated if one wants to analyze all possible strategies one can uh take, OK? OK. Finally, uh, for this lecture, I want to explain a little bit how mining pools work. Because we have seen mining is, if you manage to publish a blog, you get a lot of Money and a lot of reward, especially today in which like the reward is still sufficiently high, OK? However, successfully mining a block is a very low probability event, right? So This is a bit problematic for whoever does this for a living because what usually we would like as humans is like a not so high but reliable and regular source of income instead of one that like yeah, eventually it will come and it will be a huge amount of money, but who knows when it comes, right? That is why mining is usually organized in these pools, meaning that multiple people collaborate into creating the new block. All the reward is put into an account, the account of the mining pool which is controlled by some trusted pool leader. And the rewards of this mining operation is split to all participants of the pool based on how much they collaborated. But the question is, how do we know how much you have collaborated. How do you prove? Like I claim, oh yeah, like I tried so many counters, how do I claim to you that I did that? One option would be, I just give you all the counters and you check that what I’m saying is true, too expensive. So how do we do that? Well, The pool will keep a harness parameter, an internal harness parameter that is higher than the one of the whole system. So it will be easier to find blocks that satisfy like the equation we described with that particular hardness parameter. And while I try to create this new block for the pool, I will find some counters that are not good enough for the whole for the Bitcoin system as a whole, but they are good with respect to this higher threshold of the pool, right? This is a proof that I’m putting some effort into it. Right? So if I want to prove to you that I put effort into creating this blog, I just give you this. Solutions that are good but not sufficiently good to be put in the system. And we assume we have to trust the pool leader that they will give us a reward proportional to how much uh effort we put into the uh into the task, OK? Now there is one thing that may be is a bit confusing because 1 may think, what if a pool member actually tries to mine using their own address, right? And maybe like when they manage to like maybe they mind using their own address and then they claim the reward or maybe they um Mine for the pool, but then when they find the solution, they change the address to their own. This does not work. Why? Because when we try to mine a block, there is always like the address where the reward is sent. So if you change that address, you switch it from that of the pool to mine or from mine to that of the pool, the hash changes, right? Does it make sense? So, of course, you can mine using your uh like your own addresses like the, like the recipient of the reward. But if you, like, you are not able to claim the reward of the pool using that competition you’ve done, right? You change the address, like the value of the hash would change completely. OK, finally, um, I mean, There are a lot of questions of like how to Like organized, like mining, like whether it’s convenient to, sorry, one question if you somehow

SPEAKER 2
manage to not find a single thing that satisfies the tea pool, but you find the tea chain, you technically have no shares in the pool. Except the one that I did a, yeah, it’s a

SPEAKER 0
very unlikely event in the case that happens, is there

SPEAKER 2
some kind of system that you still get it’s so

SPEAKER 0
such a low probability event that it’s not considered by the system like. Yeah, it’s unlikely that the first try you get the, you find you try a lot, yeah, you never find

SPEAKER 2
one that actually satisfies Tpool. The only one you ever find is the one that actually satisfies T chain, so you put a lot of work into it.

SPEAKER 0
Yeah, but then it’s very unlikely. Like then of course you need to set the parameter of T-pool that is, I don’t know if T-pool is just T Bitcoin plus 1. I agree, like, uh, but usually it’s. Set in a way that like uh like it’s sufficiently easy to find something that satisfies it, but not too easy because otherwise when they give the proof they give you like a terabyte of like solutions, yeah.

SPEAKER 3
Is it not possible to use the same physical computational resources for multiple addresses where you could do the physical computational work and then just, you know, tie it to

SPEAKER 0
the address? No, this is how hash functions are. It depends, of course, like how which hash functions is used in the system, but like hash functions are. Made in a way that usually if you change a little bit like uh the whole output changes and also you cannot reuse part of the computation like uh if you change it a little bit the whole computation changes right because the the the computation itself is not amortizable. Yeah This is how, like, it depends how good the hash function is, but like the one that are currently in use, they are designed like, uh, there are of course people that have checked that like this property as a whole, OK. OK, um. Now I would like to talk a little bit about uh uh pool games like uh how like pools can try to work against each other like trying to maximize their utility. Once again there are two ways, like the two simplest like utility functions we can consider, namely total um. Uh, reward or like relative reward, like the fraction of all rewards that we get. So If, um, like one way I can attack like a, a pool if I care about relative rewards is as follows. I could Imagine that my pool A controls a fraction alpha of all resources, whereas the other pool, the one that is going to be my target. controls a fraction beta of all resources. If we behave honestly, Like the total fraction of Of blocks that our pool will mine will be proportional to alpha times and where n is like the number of blocks like putting the system on the chain uh during our time window, OK. And similar for uh pool B, it’s gonna be beta times zone. OK. Now imagine that I take a fraction of my resources, alpha. And with this, I joined. The second pool, the target of our attack pool B. And I do the following. I contribute With all like solutions I found, I find that are not sufficiently Good to be accepted by the whole chain. Like, essentially, I will mind using T-pool as a target. And I give this to the leader of the pool A. And if I find any solution, I keep it secret. I do not share it with the members of Boule. What happens is that. My total reward in terms of absolute values. Does not increase, actually decreases, right? Because I’m sacrificing um. Like a computational power, I will get a fraction of all like a profit of pool A, but like the probability that I successfully mine the new block decreases. What increases, however, is the relative utility. So there is the analysis, so. Um, yeah, a member of pool A. Like after this change. Um. Oh yeah, sorry, the members of pool A that like enter into pool B. We get a fraction of all shares of profit of pool B that is equal to alpha divided by beta alpha plus alpha, right, more or less. Because The computational power of pool B now increases by alpha. Originally it was beta. Beta plus plus alpha is like uh the new computational fraction controlled by uh pool B. And yeah, alpha of this is controlled by us. Right? So we will get a fraction of profit proportional to that. OK So the probability, sorry, the number of blocks that we can assume will be to produce is still bitfm. Because This fraction alpha prime the joint will be never like reveals like any block that is good for the chain, just reveals like shells like these blocks, these solutions that are not sufficiently good to be put on the chain. And so We end up with an expected fraction of profit that is going to be beta times n times alpha divided by beta plus alpha. To this we need to add the profit. We make, uh, with the remaining fraction of our pool that just tries to mine for a and this is gonna be uh alpha minus alpha 1. Sum of this together, you see that the total reward decreases. But if you take the relative reward, this is going to increase. Any questions? Good Finally Some last points. So far we have considered utility that is based on cryptocurrency, but actually, The actors in the real world do not really care about cryptocurrency. They care more about the actual fiat currency, pounds, euros, like, uh, dollars, depending on the part of the world in which they are. Why do they care about that? Because the energy they pay uh for mining like is essentially it costs like in the currency of that particular place, not in Bitcoins, right? So sometimes there can be some weird situations where like uh. The er exchange fees like and create some weird like uh um. Nash equilibrium, let’s say, or like uh there could be. Strategies that can become optimal because of these changes in transaction fees and like uh how like um sorry, exchange fees like between currencies and uh cryptocurrencies. Second, there is also a possibility that the behavior of the participants is also influenced by reputation. For instance, if attacks can be detectable in the system. I could be incentivized from misbehaving because I lose reputation or also people like the like. Like the trust in the cryptocurrency in the distributed letter as a whole, would decrease, and so the value of the cryptocurrency would also decrease consequently. In practice this uh has not really happened. Like there are cases of attacks happening to Ethereum or like uh Bitcoin that hasn’t really affected like uh the value of the cryptocurrency like uh in general, so. And yeah, if you want, there is an attack like against Ethereum Classic. I don’t know if you know the story of Ethereum Classic. Um, essentially at some point in the last decade, um, they proposed an update of the software like, uh, of the protocol of Ethereum and actually there was a bug, and this bug, uh, it’s called the Dow, uh, attack. This attack essentially led to like uh several million or maybe billion being stolen. And so, what uh the Ethereum, like uh the erium Foundation proposed was to essentially go back to the past and create a new fork like uh with the updated software as if like In on this version of the chain this attack existed please like let’s say converge onto this like fork in which like it did not. And this created a lot of, um, I don’t know, drama in the community, so some people decided to stick to the original. Uh, maintain and this gave rise to this Etherium classic, whereas most of us, uh, of the community, uh, stick to like what the Ethereum Foundation proposed and this is what you call theium today like the serum you call is the one that like essentially said this attack never happened, we go to this other folk, OK. And this could happen only in Ethereum because there is this centralized sort of like uh like or this particular association that has some influence over the whole community. OK. In Bitcoin there is no such thing, so Bitcoin is the same since uh 2013 or so. OK, I finished the slides for today, so maybe we can use this time if there are any questions also about like the previous lectures. Otherwise, we can end the lecture in advance. Yeah.

SPEAKER 4
Um, isn’t that like usually. A lot of real world change right whenever there’s a Bitcoin hard.

SPEAKER 0
Can you repeat? You know how you said like every 4 years or

SPEAKER 4
so, the, the era changes, like the, the reward changes. Um, I’ve heard people talk about like how that also has a big effect on. Mm. Right.

SPEAKER 0
Why is that? I’m not sure I know the answer to this. I’m like, uh, like. I guess like There are of course like uh all the companies that do mining that like would like be less profitable like so that would impact like uh the, the economy but like uh and as a consequence also a lot of the energy industry because have we seen the last time like uh all this mining like uh requires a lot of energy like if all of a sudden like uh It’s less profitable. They will like decrease the amount of mining they do like, uh, so like I imagine that debt is the consequence, but like Let’s say I’m Less knowledgeable of the economic aspect of blockchains. Any other questions? OK. Then if you want, Cristina is there if you want to talk about the projects. Otherwise, I remain here for any other questions you might have.

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.