ZKPodcast: Blockchain 101 - Blocks & Block Headers

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] in this episode and I sit down to talk about the fundamentals of a blockchain what's a block what's buck headers state history we hope you learn something new so today we're kicking off with another

blockchain 101 episode we're planning to make this into a little bit of a series trying to explain things sort of from the ground up first principles kind of way and then let people draw their own conclusions from this knowledge and we're digging into the actual blockchain today so what are blocks what our headers block bodies blockchain history and state all these terms kind of get thrown around a lot and it's not necessarily entirely clear what it actually is so let's see if we can explain it today so the inspiration for this is also we've actually had

questions from some of our listeners there's some episodes where we definitely just kind of like assumed the knowledge and just sort of said yeah blockhead or etc storage and here we with this episode we actually decided why don't we just like dig into this create that intro so that people can reference back to it if they get a little bit confused as to what we're talking about so maybe to kick off we could start by explaining what a block is so I think there's a lot of different ways to approach this explanation and through my experience of trying to explain this to people it's a varying degree of success

depending on a choose I choose to not go into too much detail because it usually just distract from the overall concept so I like to break a block down into two pieces the block header and the block body because this is functionally what we deal with in a blockchain client code and they're sort of the two pieces of data that usually gets sent around over the network so a block header is essentially like a fingerprint of a block in the blockchain so it has a hash it has a parent hash so essentially a hash that is linking to the previous

header or to the previous block and it has a bunch of metadata around what this block contains and what it does so it might have merkel roots sort of as fingerprints of what is in the block it has authors it has a block number things like this that just kind of metadata and fingerprints of the block itself in thinking about this I kind of get this idea of when you had libraries and you had those index cards and you had sort of just the basic information that you needed to be able to find the book and get the full information so it's a little bit like the index card

that can be easily you know you can have a lot of them you can look through them really quickly and not have to dig into each book or block yeah I think that's a good description yeah if you're just curious of like what the blockchain like how long it is what's the latest number or like what's the Merkel route of this block then you don't really need the block body and you only need this index card of the block another question that just kept coming up and this is a this is a word that we're gonna be used I think you've already used it twice so I had my mother asked me after listening to one of these episodes what's a hash and I think we definitely assume that everyone knows what a hash

is I believe back when we did it we did an episode on proof of work versus proof of steak we did actually go through a little bit of a definition but I think it's worth it today to kind of redefine what a hash is because we are gonna be talking about them a lot yeah so I mean like you said earlier we assume a lot of knowledge and a lot of our episodes but the point of this series is to try to not assume so much knowledge so I think that's a fair point to try to dig into and hash is I feel like they're relatively hard to explain because they're actually there's not that much analogy to be made in like the natural world you take a bunch of

data and run it through an algorithm to spit out a finite number of bytes so in a 256-bit hash you have 256 bit representation of what the input data was and of course with 256 bit bits available that's a hell of a lot of different sets of data that you can represent uniquely with this hash but I think that the hard thing to get intuitively is how do you get from like a big chunk of data to a tune limited 256 bit size data and maybe one other feature though like to me it's partly

this like large piece of data turned into a smaller piece of data that references back to that big piece of data and the other is that that is unique yeah or that it is not something we're running other pieces of data through that same algorithm will result in the same hash right so the way I usually just say it if I'm trying to explain a hash to someone that isn't interested in knowing what it is as I say it's a fingerprint so it's a fingerprint of the data and a fingerprint is unique to the extent that you know probabilistically unique and with hashes you have the same problem you have this thing called a hash

collision that can happen and sometimes researchers even find ways of exploiting like finding deliberately these hash collisions so that's happened for like somehow older hashing algorithms like md5 and this is actually a really big security vulnerability in cryptographic hash functions is finding hash collisions and with the better ones today like sha-3 there are no known collisions and the better we get at writing these functions the less likely it is that there will be a collision and bike collision you mean two hashes or two two pieces of different data resulting in the same

hash exactly cool in our podcast on proof of work versus proof of stake we talked a little bit about how to create a hash you basically take a piece of data run it through an algorithm and this results in a new piece of data but I think the question here is is there a way to go backwards to get back to that original piece of data from just looking at the hash no so now we're talking encryption and I think that's the key distinction here that is usually overlooked and it can be confusing so a cryptographic hash function is a one-way function there is no way to extract the original data out of it so I mean if you

just think about it it's obvious because you could go from a gigabyte of data to 256 bits there's no possible way that you could reconstruct a gigabyte gigabyte of data from 256 bits so it's a one-way function and the way you then use the hash say I want to prove that this piece of data is the same as the one that was hashed to produce this hash then you need to rehash your original data and compare the results you can't go from one end to the other and then like compare the resulting data so then I I think your metaphor of a fingerprint

is perfect because by looking at a fingerprint it is unique maybe to that individual but it doesn't it from that fingerprint you cannot reconstruct the individual however if you have that same individual like maybe the same exact DNA exact everything they will have the same fingerprint I mean that's like kind of it may be a bit of a stretch but yeah yeah so the two pieces that I mentioned asked the block is the block header and the block body now the block body actually contains all the try actions that were interested in so a blockchain it consists of blocks of transactions and really like the block

body could contain any data and it would still be a blockchain but the useful way to think of it as transactions into this chain so for Bitcoin it would be a normal like you TXO type transaction and in aetherium it could be anything from deploying a contract to interacting with one or just simple value transfers maybe we can talk a little bit more about the transactions you just mentioned that in Bitcoin transactions tend to be a transaction of value which I think we all conceptually can understand but in aetherium you can do transactions that maybe have no value you see that sometimes you see like a

transaction with like zero ether and there you say it could be a deployment of a smart contract it could also be as far as I understand sort of storage of data or something like that and I'm wondering a little bit what that looks like right so I think it's useful to think of a transaction as just any arbitrary amount like any arbitrary data that you want to include in a blockchain this data can obviously be interpreted in different ways so this is what we build into a client is you know we might have a transaction type aetherium transaction set a gas price a set of maximum gas to

be used it has the value like you said you can have a 0 value transaction but that would still got cost gas so it still cost you some amount of ether to you know get this transaction included in a block but it might have no actual value transfer so what you're paying for then is simply the data and the data and a transaction is just that it's string of bytes there's not necessarily any interpretation put on it so if I want to publish a picture to the boxing I can I can just include that in my data for transaction but I might also include like a function signature and the

parameters of a function call to a contract and then that will get interpreted by the client as saying hey this transaction wants to do this with that contract you should have mentioned we could you could put a small file or something like that is there a limit to this like can you I mean are you able to put a song like in a transaction and then it lives on the blockchain forever yes you are absolutely able to do that and a lot of people have so the only there is a max code size on ethereum and I believe it's 24 kilobytes and this is a configurable value so if you're

running your own chain you might have a different max code size but essentially means that you can put any 24 kilobyte blob of data on the blockchain it might cost a lot of money depending on when and how you do this but it's absolutely possible to put a picture or a song or whatever you want on the blockchain I feel like I also heard just as a small anecdote I feel like I was I was watching like a Z cash interview with Zuko and he mentioned something similar where like there had been like a love letter written and put into the blockchain and I guess that would be that it would basically just be a like a small essay yeah a small letter yeah

there's there's a lot of examples of that there's a lot of fun creative cool uses of doing that we've actually a parody have received job applications through the data field of a transaction wow that is so cool definitely creative I hope they got an interview suite so we've kind of covered a few things so we've covered what a hash is what a header is what the body's made up of and kind of some of the nuances of transactions one other word that comes up a lot is the nonce and the nonce as I understand it really becomes relevant when you talk about mining but I think it's worth explaining here

for us to like understand really what a block is right so any proof of work blockchain to prove that you have done work there's some hashing algorithm so we're back to the hashes and you take and one constant which is the block and then you have the nonce and actually we checked on Wikipedia earlier to find out what nonce means like I only know it in the context of programming and and this kind of stuff but it's actually like a one one-time placeholder word type thing so when you're studying infants and you like try

to see if they've learned plurals you might say like here's one wag you know these are two and you ask them to complete it and if they say wags then they you know that they've learned and not like memorize this specific word anyway as an aside the nonce is just a number so it's just an integer and you take this fixed constants block and you take the integer and then you hash both of these together and out pops a hash and then according to your proof-of-work algorithm there's a difficulty requirement of this output hash and usually that's just the resulting hash

needs a set number of prefixed like zeros so it can be really be any arbitrary like you have six ones at the start of your hash but usually it's just a number of zeros that determines your difficulty so if you take the block and then on C you hash them both and you get a hash out if it has six zeros then you're good and you can submit this block to be like it is now mind and you can submit it to the network and you'd be actually given a reward if you achieve that mm-hmm but if you don't get six zeroes in your output hash the only thing that you can do because your block is fixed is increase the nonce

so you just iterate through you know you try one you try to he tries three and then eventually you'll find a number such that this piece of data is hashed to something that results in six zeroes at the start so it is really just like it's a number that that's like the the number that's gonna change is gonna maybe just go up by one each time you do the hash and I think that's sort of when you you mentioned that it's like probabilistic it's the idea is that you'll you'll actually do this like the idea that you have you try the the header and one nonce and down that first try you get it is very unlikely what's

more likely is that you're going to be doing that hashing process hundreds maybe I mean maybe thousands I actually don't know how many times millions of times you're doing it millions of times and out of that million one nonce one version of the nonce will actually result in what you're looking for which is that six six zeroes at the beginning this is like all theoretical but like you want some qualifier to that resulting hash and one of the nonces are one of the versions of the nonce will actually result in that hash but it won't it's very unlikely that it's just like first time and then you win it's a bit like and I think this has been a bit compared to lottery where you're just supposed to like play and play and play

and play and play and play and there's a probability that you're gonna win at some point yeah so it's definitely probabilistic game except that the difficulties adjusted such that on average you will always find the solution within the BOK time so for a theory and that's what fifteen seconds or something and all numbers are equally probable of being the number that you want to get the right nonce the right hash and so like what mining polls do for instance that are like a conglomerate of individual miners they will you know start miner number one on the number one and then miner number two

starts at number one hundred thousand or something then number minor number three starts at three hundred thousand and then they just go individually from there and so together they're like paralyzing the search and therefore you know it goes faster you would do the same thing like if you have multiple GPUs mining for instance you start each GPU at different places in this search space so now we have we I think we've covered like an individual block we know what a block is you sort of know how they deal with each other we kind of mentioned that you're hashing the previous blocks header or a previous block and that's being brought

into the new block so that there's a record of like what what came before and there will be a record of what came after so there there's only a reference in one direction if you have all the data then you could construct a reference in both directions okay in these in this block chain this is where you could have things like history or those little pieces of data and all of that stuff that all can exist in the blockchain but you hear like people talking about the state database or this other piece of the puzzle to actually access this stuff so let's start talking a little bit about what a state database

is yeah so I think just talking about the blockchain in itself is useful to understand what the chain is what gives it its properties of immutability and all that good stuff but the blockchain itself is usually called block chain history because it has all of the data and it has all of the transactions that have ever happened on the chain and this can't change if you changed any of this then the hash would turn out different and you can prove that you know this block is invalid because it's changed and it would break the whole chain but to make this chain useful you actually need to do some optimizations because

let's say you want to know what the state of a contract is in now you need to play through all of the transactions in all of the blocks to find where it was deployed and then like find all the transactions that modify this contract in some way and then eventually you'll have what the state of this contract is in so you can construct that from the blockchain alone but it's incredibly slow obviously to didn't like iterate through all the blocks in the chain and replay all the transactions all the time so what you do is when a blockchain node is synching is that it's downloading the blocks and it starts with an empty state database and then as it's downloading

the blocks it's playing all the transactions and storing all of this states in the state database then it goes on to the next block you know plays all those transactions on that same state database and then at the end you have a current state of you know what what the state of all the contracts are in and everything but you have no history in there so it's just a it's like a snapshot of that very moment it's not gonna say like as I understand it you can go backwards and look at the state at different times but the state database as we're discussing it will only show the latest meaning if a change has been implemented somewhere you won't

know that there's been a change and you won't know what existed before you will only see the latest state of the blockchain that's right so when you talk about that snapshot maybe let's go back to set up some of the block fundamentals that we just talked about so can you help me understand where exactly the snapshot is happening like what is it a snapshot of the latest transaction is it a snapshot of only the latest block header like which parts of what we just discussed is being captured by the snapshot and which parts are not right so I think it is a snapshot of the entire state of the entire blockchain

and it is a point in time thing and the time is like between each block so you you'll never like have a state database that is you know this state of you know this particular transaction or anything like that it's after or before this particular block it doesn't dig into like transaction level things really so you play all of the transactions of a block and then produce this state database point in time view and I think a useful way to think about it and describe it is if you think of the a blockchain it has one smart

contract on it all of the only thing this smart contract does is store a number and let's say it's deployed with storing the number 0 after this block where we deployed this contract and we store a 0 in this contract the state database has a key to this contract and it has a value that is 0 now we send a transaction that updates this number through the smart contracts we send this transaction it contains the function signature and it contains a 1 which is the number that we want to change it to now after this transaction has been mined included in a block the state

database after this block gets updated to the same key holding the value 1 instead of 0 now we send another transaction changing it back to 0 and you know same thing we create a transaction and gets mined included in unblock the state database after this block will now contain a 0 again and if we just look at the state database we have no no way at all of knowing what the value of this contract has been in the past we just know that it's 0 right now we don't know if it's changed if it was once this or that we only know that right now after this block it's 0 so

that changed from 0 to 1 and 1 to 0 is completely lost in in the state database right which is why we called the blockchain itself history because there all the transactions are obviously all still there they're all still in the blockchain so if we actually want to go back and look at you know what was this state of this contract at this point in time we can either go back and replay all the transactions again up to that block that we're asking for which is slow or we can run what's called an archive node which saves all of the states between all of the blocks so that way we can easily say okay give me what the state was for

block 1 or for block 10 because we're saving all of them and that query would be a lot faster right so the state database is the purpose of it just speed of accessing data is it really just like use this database so that you're not kind of going through the entire blockchain every time you want to actually see what's going on yeah pretty much I mean it would be prohibitively expensive without it like you basically wouldn't be able to run a network without a state data and like because creating a transaction would be both creating and validating a transaction would be so incredibly slow that like

you would not be able to process almost anything was the state database created and deployed at the same time as like a Genesis block does that always come in tandem or is that something that's built afterwards no it was thought of in advance like it wouldn't because it would not really be possible to have an aetherium like blockchain without a state database it's it was something that was designed for from scratch so now let's think about some some ways that you know nodes or clients kind of are interacting with this we talked about this in our previous blockchain 101 episode how the full node has the full blockchain that means the full

nodes and kind of in reference to what we've just spoken about the full nodes will actually have the body and the header and they will have all of them in a row yeah there's a difference there with a light client we talked about it last time but we hadn't really explained the headers and that distinction yeah so I think there's three useful types of clients to talk about the one I just mentioned which is the archive node there's a prune node and there's light client and we've talked in the previous episode a little bit about light clients and they only have the header chain so

it's only this chain of headers they don't have block bodies the prune node has the full blockchain history so it has all of the blocks like you said and it has a couple of the latest states the reason you'd want more than one state's database just for the latest block is to be able to like rollback in case of a reorg or like technical reasons and yeah so it's a full or prune node we'll save a couple of state databases as well in an archive node you would really only run for research purposes because then you are storing every single state ever and obviously this takes a lot of space this

is just to sort of have a backup of everything I guess yeah I mean all of the data exists there anyway so there's really no benefit to the network that you're serving or anything like that the only reason that you would keep it if you're looking at these old States a lot and it's too expensive to keep reconstructing them all the time so a few weeks ago we interviewed Phil Diane about storage rent and there I know that the question about state and history came up a lot about pruning where like so say you were trying to get rid of I mean I think we actually I don't think we defined pruning exactly but I maybe

we can talk about it in the context of this storage rent and like the fact that there's actually data sitting on the blockchain using up space making those block chains just bigger and bigger and so every node is have a bigger and bigger chain to download right so so in this discussion there's two useful things to think about it's the blockchain history and it's the blockchain state and so like we said the blockchain history is mutable we can't really change anything without destroying the the chain and that's kind of a reality we have to accept there there's things that we could do there as well like snapshotting and recomputing

things whatever but the state database is something that we can do quite a lot with because it's kind of outside of the blockchain the only thing we have to reference this state is the Merkel route in the header so we can sort of modify this state to whatever we want and then include that Merkel route in the header and things are still fine so one thing that we could do is actually remove things from the state database so right now all the contracts ever deployed are in the state database all of their data that is in these contracts are all in the state database I think this data is a couple months old but I got this from

Peter from the guest team he has like a breakdown of all the contracts and how much storage they have the top storage heavy contract is crypto kitties and it's storing something like 250 megabytes on the blockchain so if we like if no if everyone stopped using crypto kiddies today and then in ten years you know it's still there but no one is using it it's 250 megabytes of like garbage data because no one uses it no one values it anymore should we just let that sit there forever or should we remove it or force someone to pay to keep it around and that's what the whole

storage rent discussion is about and we can actually remove it and things are fine because you can always go back into blockchain history and resurrect all that data it's just a lot of work to do so and it's funny the the number you just mentioned 250 megabytes is not a big number when you just think about like data storage but I guess to give some context it's like that's 250 megabytes they would have to live on every single full node forever and this is just one contract and the goal is to have millions of contracts that are as popular or more popular than crypto kitties so how do we deal with millions of contracts wanting to store 250 megabytes each yeah I think

that actually that's great because it gives a little bit more context to what we the problem that we were trying to discuss in that in that previous episode one thing that we've mentioned a couple times throughout this episode is the Merkel tree or the Merkel root we didn't want to necessarily define it right at the beginning of this episode because it sort of is a topic in in and of itself but I think it would be worth our while to sort of come back to it now and try to give you our listeners a little bit of a sense of what that actually is so why don't we talk a little bit about the Merkel tree what's the Merkel tree so a Merkel tree is a data structure very general data structure and is a tree and the computer science term of a tree

without knowing what that already is I guess it's pretty hard to explain but if you imagine like a tree where there's like a tree trunk that's usually called the root and then it branches out from there into different branches and that sort of bottom or top layer depending on how you orient your tree there are there's pieces of data and these are called the leaves so let's say we organize 10 numbers into a Merkel tree we'd have the numbers 1 through 10 at the leaves and then we'd hash number 1 into and make that a branch above that and so the hash of those are stored

there and we do this for all of them so then we go up on level we have much fewer nodes and in these nodes we just store the hashes of the children and then we go up that way until we're at its where we have one root hash that represents the hash of all the other data so if we change any one leaf in this system that the root hash will change but if we change number ten then it's just that particular branch of the tree that has hash is changing so to prove that we've only changed the number ten we can actually skip a lot of the data and only provide data for that

branch of the tree and then the hash of the rest of the tree so then we can kind of skip having to share we share the entire tree and can just reshare sort of the path that we've changed the reason you would use a hash tree like a Merkel tree is that it would provide a means of proving the integrity and validity of the data contained and yet it would require very little memory or disk space or information because all you're really getting is that last root hash and that's still proving that all of the other data is valid but I gotta say this is only the tip of the iceberg when it

comes to Merkel trees this is actually like a huge topic it's an it's a really interesting topic and you can dig into more of like how Merkel proofs work and this is how you can sort of confirm that a given state is correct and that kind of stuff and it's it's a very fundamental piece of any blockchain really and it's definitely something that's worth learning about but it's definitely a deeper topic like it's actually quite hard to explain especially without drawing things and even being able to draw things it's pretty hard to grasp the implications of these various properties of this tree I

think that we've covered a lot of ground with this episode we've looked at these blocks we've looked at the way that they work together we've hopefully shed some light on what people mean when they say like like clients pruning and history and state and what actually can exist in a transaction I hope that our listeners liked it Frederick do you have any last thoughts if you liked it or didn't like it please give us feedback we're on Twitter Email hello at zero knowledge FM or Twitter at zero knowledge fm and especially with this series I'm really keen on on hearing any feedback and what do you think we should dig into next and and what did we explain well or not so well

and thank you very much for listening thanks for listening [Music]