ZKPodcast: Merklize this! Merkle Trees & Patricia Tries

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 Anna and I hope to teach you a little bit about Merkel trees what they are and what they're used for [Music] hey Frederick hello today we're gonna

talk about Merkel trees yes we are it's a challenge we're going to make an attempt to describe Merkel trees without a whiteboard without any graphics without any videos would you consider this to be blockchain 101 still or have we like graduated into Park Jane 1 or 2 at this stage I think this is definitely a step up I mean even doing the prep work for this I almost feel like if you really think about it this is like this is into computer science 101 102 I imagine yeah I I never like I didn't take computer science at school I took physics so I don't actually know

when you introduce data structures yeah like 101 102 I would imagine something like that and this is coming too right around the holidays the Christmas merkel 3 episode we figured we would use this time to tell a story about a tree it seemed kind of relevant so to start off this episode we want to dig it a little bit into the history of Merkle trees and who is mr. Merkle a lot of you may know that Merkle trees were originally conceived of by a guy named ralph merkle when you're looking up this original paper what you end up with is you get two

dates you have 1979-1989 so ralph merkle was a PhD student at stanford in 1979 and as far as I can tell submitted this paper in 1979 which outlined was for the first time what we now know as a Merkel tree it wasn't he didn't name it a Merkel tree for himself think that's what actually came after now this paper wasn't actually published for a full ten years until 1989 and there's a little bit of a backstory I mean this is on Wikipedia there was some guy named Ron Rivest who didn't do what he was supposed to do and then or he

passed it to somebody else and that person went to his startup and then you know it just sat there for a long time now since then ralph merkle has also gone on he's created all sorts of other things he's quite well known I would say in cryptography and also in general tech he's worked at like singularity University and he's involved in all these different associations in the valley now but that's a little bit of a story of yeah of where this came from and one other thing to note is ralph merkle worked at somewhere called Xerox PARC when this actually came out and I had never heard of Xerox PARC but in doing a little bit of digging it looks

almost like this was a branch of Xerox that had a similar format to something like Bell Labs Bell Labs has come up in previous episodes as this is I think especially nowadays we look back on that these laboratories which were very well funded where research could be done that spanned a very long period of time there was a bit less pressure and yeah this is definitely this research is coming out of that era now fast forward today Merkle trees are being used in blockchain technology and that's what we're going to talk about today so maybe to start on that Frederick do you want to give do you want to try to describe

verbally what a Merkle tree is any pun intended with a give it a try oh yes that will come in handy later yes so it's like like it's a hard topic to try to explain without graphics obviously when you talk about trees you want to be able to draw these trees and it's also hard for me to really try to explain such a fundamental thing that I sort of think about a lot or I've dealt with a lot in my life and like a lot of these things seem obvious and even like tree oh it's just a tree that you put in hashes and you're done like as a concept I think it's very simple but when you actually try to dig into the details it can get a little bit hairy and

especially something talked about in blockchain a lot it's Merkel proofs and and that sort of the the reason that we use Merkel trees everywhere to be able to have these kind of lights proofing improving structure of proof of inclusions but let's start on that on the fundamental level of what a tree is and we'll start with the same example that almost everyone does a binary tree and if we draw a tree with the root at the top that means there's a node there and I guess the terminology is you know nodes and branches and leaves I would say so a node is like one you know square or circle in your tree that

contains some information a branch is something that leads to another node and a leaf is this a node that is at the end at the bottom of this tree it's almost like would you say that like from the root you have branches off the root so you're starting with this one entity and then it branches off into two and in the case of a binary Merkle tree it branches off into two and then those two branch off into four and then for a branch off into it's indeed so that's where the binary tree concept comes from is when you always branch off into two or you know if you're allowed out numbered leaves in your tree then it will be able to branch off into one other node as

well but or one leaf what I noticed in looking online for Merkle tree explanations or videos this is almost always the starting point so you will see a very symmetrical tree in front of you and that will be basically the basis of this example yeah and this actually does exist in in a blockchain system it's the basis of the Bitcoin Merkle tree yeah and I think something important in notes is if you just if you come from a computer science II background or I've looked at binary trees before I think that the difference in the Merkel tree is that we really like we only have data at the Leafs there's no

data in the tree itself so when you talk about a binary tree you might talk about a sordid or an unsorted binary tree and then then you talk about in certain when you insert data into this tree you actually like insert it in such a way that you balance your tree and the root node will have your middle value and you're you know rightmost leaf will have the extreme upper value and so then you have a sordid binary tree and you can use this to easily do binary search across all of your data and things like this and it has a bunch of properties that a lot of these kinds of things in a Merkel tree we don't have any of that I mean it's not what it's for it's the data is only at the leaves and the nodes

above the leaves are all hashes and we can get into what the point of these hashes are but I've we've debated different ways of like explaining this of trying to like find a way of figuring out what the point of this is and what it comes down to for me is to be able to construct a Merkel proof so a Merkel proof is a proof of inclusion of some data in this data set so let's say we have four values a B C and D and we have this data sets we want to prove that C is in this you know how do we do this well we can provide the person with the

entire data set and let them search through the data set to find seed themselves but this has obvious downsides we need to send them the whole data set maybe we for privacy reasons or bandwidth reasons we can't do that or it's super costly to search through the entire data sets so let's construct an imaginary tree where we at the leaf nodes we have a B C and E we combine a and B together to form a node above it that has the value a B and then for C D we combine those two together to form a node above it that has the value C D and then we combine those two together to form the root node that has the value a B

and of course now we can send this root note to someone and say that you know here's the root note of this tree you can check yourself that C is included this is the exact same thing as saying we just send the entire dataset don't let them search through it so obviously this is basically the exact same thing as just sending the person the entire dataset and letting them search through it so we need to do better than this but now we have this sort of structure this tree in place that we can do something with so what we can do is that instead of just concatenating the values up we actually take hashes of the leaf nodes and produce those upwards so the layer

above the leaf nodes a B C and D would be the hashes of a B C and D and so we have our sort of one link up that is you know we have a and then we have the hash of a and then above those are the hashes of the hashes so we concatenate those two hashes together and we hash that and then at the layer above that we hash you know so second layers hash of a B and hash of C D and then at the top layer we have the hash of those two hashes so now at the roots we have a hash that is the fingerprint of the entire data sets what if you are just given value C and you're asked to verify that that's actually in

the data set right now all you have is this root hash which doesn't actually have the C value and you were in it right so if everyone has the entire tree then there's no not much point in proving that some data is in that tree because they've constructed it and there's better ways of doing this but the points that we're trying to achieve here is to be able to prove this data inclusion to have this merkel proof and prove to someone that only has the root hash so if person a only has the root hash and person B wants to prove to them that C is indeed in the data set what they would have to provide then is the hash of hash of a and B and the hash of

C and the hash of D and the value C because with all of this data called the Merkel path the prover the verifier the the person who actually only has a root hash they can combine all of these hashes together and they can compare to the root hash that they already have and you know if they're equaled and yes indeed C must be in this data set that's interesting so like the pieces of data that they're getting it's it's not you don't need a single line you're not you don't need to see hash of C hash of CD and then root hash you actually need C hash of D hash of a B and the root and the hash interesting so it's kind of

like because if you have a B if you have the hash of a B you don't need any data underneath that because you know that you can just assume this is this is not part of what we're trying to prove the inclusion of so here's just that hash and yeah so you can in a very you know large data set when there's only four nodes we're now still like providing 2/3 of the data of this tree but in a very large tree then you're you're really only providing a quite a narrow path here and yeah it saves a lot of data and being able to prove this inclusion and what you're really looking for is you're you're basically going to run this system again and if the route that you

get at the end matches to the route that you are originally looking at then you know that that value C is correct yeah one example that I found online and I don't know if this will translate just on podcast but it was this example that Dan Finley from Mehta Matthews which was about colors so if what he used in those leave examples were different colors and you're combining these colors as you kind of move up the tree and so if you were to alter one of those leaf colors that would inevitably at the end alter the route color I'm definitely going to put that video in the show notes it's a very short video he just touches on

Merkle trees for about five minutes but I definitely liked thinking about it that way yeah and so I think for anyone who it's familiar with hash functions and it's worked with that I think it's natural light because we have we're hashing all of the data at the leaf nodes and then hashing and rehashing all the way up then of course changing any leaf any data at all will change a bunch of the hashes along the way all the way up and yeah I think the the color example is a pretty natural way to think about this and if you don't have this sort of natural intuition of hash functions then I think that's a really good way to think about it's a good example but like now let's imagine we had thousands or millions of leaves and

you've changed one color slightly it may be pretty much unrecognizable at the end whereas with hash functions you will always like it will be a distinct change it will be a traceable change no matter how small that distinction is at the leaf level yeah so maybe we should look at an example here and just talk about use cases of Merkle trees a little bit and when sort of it exists in Bitcoin and obviously in etherium but we can talk about Bitcoin first because it has this very sort of simple binary tree structure and Merkle tree so in Bitcoin Merkle trees are used for transactions

in a block so every block has an Associated Merkle tree that is constructed from all the transactions in that block so your leaf nodes are transactions and so you take the hashes of those transactions and propagate them upwards and what this provides is a simple way to prove transaction inclusion in a block so I can convince a light client for instance that only holds this Merkle tree roots that transaction X which you know let's say is I move money to you is actually in that block so I can prove to you hey I've sent you the money it's in this block and can send you that proof and

you can be convinced that is actually what's happening in that block without downloading and executing the entire block yourself and so I think you already mentioned this but like there's no data in these higher-level hashes but the actual data in the Bitcoin example is a transaction yeah and like now my question is actually like where does that it's like a side question where does it live what would that look like what is the leaf in Bitcoin yeah it's it's a transaction data like a binary blob of transaction data all right and once it gets hashed though then it will be a distinct number of characters and that will be uniform like all the way up even though you're combining them you're

combining these hashes it's always gonna do hell how long is it actually in Bitcoin I don't know which hash function to use for this actually okay but I think this is an important note that I forgot to mention earlier actually we're talking about this example of just propagating the concatenate the data upwards and that sort of leads to larger and larger nodes and like with larger data size and nodes and higher up and that's obviously not how we want this to work and so if we have this hashing structure then indeed all of the nodes above the leaf nodes will have the same size they will all be the like exact same thing except different hashes in them and yeah this

gives us some nice properties in terms of constraining or controlling the size of this tree we just covered the basics the Bitcoin binary Merkel tree in aetherium Merkel trees are often cited but the way that they're built is quite different yeah and even the way that they're spelt is quite different yeah indeed and this is this is actually pretty funny because there seems to be no consensus in the world on how you pronounce this other thing so the other thing is a prefix tree so the example we talked about before was the binary tree there are obviously all sorts of trees and tree structures and with different

properties different efficiencies etc a prefix tree is a tree where you have both a key and a value so in a normal like in the binary tree we talked about before there's no key you can't you're not you know that it doesn't exist to try to search for data in this tree there are only values and in the Bitcoin example transactions are the values in this tree and also the hashes of those transactions that's the only thing that's propagated up but in a prefix tree we have a key as well so the prefix part of it is referring to this key so instead of having this binary structure where every node branches off

into two other nodes you have an sort of an index of what I call it an index of possible key values that you can move to from this node so yeah that's a prefix tree we can dig into a little bit more about this key value structure later but a prefix tree is usually called a try or I pronounce a tree still because it's TR ie and that name comes from that it's a retrieval tree it's optimized for retrieval of data over sort of sort of searching of data in this tree and

that's why you have this key value structure and so yeah in retrieval it's still pronounced tree and therefore like it should be pronounced tree and - Yin but for the sake of actually making this somewhat clear I like I will pronounce a try for this podcast so this is the merkel pretty non binary prefix merkel try right spelt TR IE and an aetherium there aren't Merkle trees there are merkel tries so and if they're in the etherium example the key that we have is it's actually I think that hash of the address but for the sake of clarity we

can call it the address it's functionally the same the address you're ethereum account address is the key and the value is your account state so let's let's for the sake of simplicity call your account so if you have one either we want to find out how much ether you have we look in this try for your address and we look for this address one what's called nibble at a time and a nibble is one hexadecimal character of your address and so at each node in an aetherium try there are 16 of these indexes that I was

talking about before so in every node it branches off into 16 other nodes depending on what the hexadecimal nibble is that you're looking at so you take the first nibble and then you move down the tree based on what that was then you take the second nibble move down another step and with sha 3 being 256 bits that's 32 layers before you reach our accounts data and this actually sort of brings us to another part and we lied a little bit a theorem doesn't use Merkel try so uses Merkel Petra she tries but that's just for optimization purposes so

we don't really need to think about it for the purpose of understanding what this is about I don't think the Patricia part actually matters I sort of want to go over this again because I know that you know we before this before we started recording this we definitely went over it a couple times and I just sort of look at this tree from this try sorry from a few different angles before it made a lot of sense what I took away was that at every node at every level there'll be two distinct pieces of information one is a hash it's basically a hash of the node underneath it and the other is something that we've been sort of referring to as an index which can

also be described as the address the index is more like reference to the other branches that comes after this one as it relates to that particular nibble so the address is the key it's the whole thing that we're trying to look for in this radix trees prefix tree that we're trying to search to go back to the earlier example the Bitcoin example the hashing and the sort of hashing upwards this would actually be happening in a similar fashion from what I understand it's not binary so it's not always two by two but you are hashing upwards level to level and the hash will always be the

same size no matter what where you are on the node so the difference is that you can use like if you'd like to actually go from the root to the leaf you can use the index and the nibble of the key to move from a root node to the nodes underneath that all the way down to the leaf yeah so if you wanted to build the simplest possible implementation of an aetherium client you would only have this try and you would yeah use it to actually find the account balances and things for efficiency reasons it's better to like have two separate data stores one for the trying one for the data and use a

key value database and implementation details as we call it yeah so I think that's an important distinction we're in the Bitcoin example if we wanted to find a particular transaction say we're looking for a transaction with some hash we have no means of finding it other than a linear search through all of the transactions in that block and like if a block contains 100 transactions that's actually not that bad and that's a totally viable way to find particular transaction you're looking for when you're talking about like the state try in aetherium where there's millions of accounts and you're looking for one particular accounts then doing a linear

search through all of them to find one with this particular account number is not a reasonable way to find that account so then finding it by this prefix tree is a relatively simple process you follow 32 steps down and then you have you you found it so you never really need to look in more than 32 places whereas if you did a binary search you know might be less might be more depends on what the structure of the data looks like etc and then you'd have a bunch of other overheads of trying to sort this data etcetera so it is actually a useful way to find the accounts data of a particular address and so it does serve

those two purposes you can find it but you can also the exact same thing as in Bitcoin if we have a like client that only has the merkel route of like what we call the stake roots so the merkel routes of the entire state database then we can say you know I have five ether and I can prove it to you by providing you the path to my account so if you want to think about this path the way you think about it normally as you go okay the route and then you kind of follow a line down directly to one leaf but when you're trying to prove these things you don't actually get each hash on that path like if it branches out

into two you will get the hash of the branch that your transaction is not on exactly so you you need to like for someone that knows like tree pruning algorithms it's it looks like a pruning algorithm where you take the hashes of all of the branches that indeed like you said my account is not on because I can reconstruct the one that I'm on and that's the entire point so the purpose of this proof is to provide all the information needed to reconstruct the roots so to reconstruct the root hash I you know I need to provide the data itself and then I can reconstruct all of

all of the hashes above there but I don't necessarily have the data of all my sibling nodes so I need to provide the hashes of those and they are then used to construct the hash above and so indeed you need to provide all the data necessary to be able to construct the root hash and usually again this is a relatively narrow like set of data of the entire database so if at the top level you prune away everything below a branch that isn't so if you have sixteen branches at the top then you prune away 15 of them by providing the hashes at that level and then not anything below

so indeed you like basically prune 15 out of the 16 at every level and I think you can do that because if you think about this structure whatever hash sits above other hashes takes them into account exists so you no longer need those individual hashes underneath it you only need the top hash in that part of the try that's relevant to you we've sort of hinted at what we can include in the leaves of the Merkel try in aetherium so like in the Bitcoin Merkel tree you can include transactions but

you can also include balances so in aetherium we have three tries one is the states try that is for the global states of all accounts and balances and contracts and stuff like that the second is for transactions so the same is Bitcoin this is a per block try that just is used to prove the inclusion of some transaction and the third is the receipts try so a receipt is the result of a transaction you know who sends what to whom and kind of if it was successful or not and some logs are output from

that and things like that so it is these three tries that exist in the Tyrian and they like each they're distinct they don't interact with one another no do you like are you getting cuz like where where does the merkel route live I feel like we touched on this when we were explaining block headers and blah and stuff so if if you have three are you are there three Merkel roots in every block yes oh nice cool I didn't know that you don't Merc you don't Merkel eyes all of them huh you don't want to make a Eber Merkel rude you could not much point in doing it for

three maybe if we had you know hundreds of Merkel tries then we would want to do that but I don't know it's just those three stored in the header and they're actually stored in the header not in the block yeah okay how long are each of those so with three muses catch act 256 so it's 256 bits and but yeah it depends on what shash watching use so I think an interesting part of Merkle trees and everything here is you can use it with any like it's not tied to absolutely where hash function obviously like you can hash it in whatever way you want if you want something super secure then use the super secure hash function if you

are just trying to do some you know kind of simple data proof thing maybe internally then you can use like these super fast hash functions that are less secure but can process like gigabytes per second kind of it's it's an interesting like knob to tweak in in a Merkle tree I think he sort of goes back to the history as well and like what hash functions were available in 70 1901 Ralph Merkle wrote about this it would be curious to see I looked quickly at the paper and the hash output was a hundred bits which is it's quite a lot like I'm not sure how practical it was

for computers to produce those hashes but I really don't know what kind of hash function in this so and I'd be curious to see in general like I think that was something that also dawned on me as I was reading about it and we were talking about this that back then a lot of this was very theoretical this wasn't necessarily going to be used immediately in production now we can see it it seems completely usable not creating things that are too big or too intensive for the machines that we have at all and it kind of reminded me a little bit of some of our previous episodes where we've interviewed people who are talking about more theoretical stuff that at this point is still has one foot in academia

and even though there's maybe some very fresh use cases in practice real implementations but they're still so very much demos or just sort of you know to show that it's possible at all but not they're not yet ready to be used in in large-scale production this is quite this makes me quite hopeful I'm just thinking wow it's possible that's you know some of the stuff that we're talking about that seems almost impossible now will very soon be used you can see kind of that like other things need to come into play before these things can actually be used in the real world sometimes like the machines have to catch up or some additional research on specific parts need to come into the fray yeah I think it might be

useful again to like summarize a little bit and we can look at trees versus trice you know what are their differences and why are we you know bothering with both so an obvious thing with a try as we talked about is to be able to have this index to actually have a key and a value and be able to search through it but obviously well maybe not so obviously it depends how much programming you've done a prefix tree is smaller I mean depending on what your key space looks like it will be smaller than a binary tree so in a binary tree like you said you're always pairing up

so you're you're always just you know two branches so in every node which produces a very large tree if you have a lot of leaf nodes but in a prefix tree or a try you can actually you know have ten or twenty branches off of a single node so you don't need to necessarily pair those up so you'd have like a whole pyramid you can just go down narrow line and exclude many more branches at every layer so it's it's essentially a more efficient data structure especially for the the key space that we're looking at in the theory as I've understood even though you can go in both directions often even

the merkel tries and aetherium are still being used in a similar way to those in Bitcoin in that you're verifying that specific leaves are indeed correct by proving upwards to having to merkel roots and comparing them and making sure that they're identical and if they're identical then we know that the leave the information the leaves are correct um I I think we talked a little bit about this but like I still have it stumped on what use cases are for going from the top down it doesn't actually get used ever like you know like this goes into database design and I like we use rocks DB rocks DB has some algorithm to go from that key to the value and I

think it's more efficient than a radix tree but how much more efficient I I don't know and you know this is I think using a radix tree to find this data is actually a valuable it is a real way to try to find data on disk like if you have a value stored on disk you need a way to find it like there there's no magic here we can't just say give me the data corresponding to this key we need to somehow translate that key into something that we can store on disk that references another location on disk and

so how you do that is you know up to you but a radix tree is one way to do it so you store this alright x-ray you you know that the disk address of the root is this you can kind of get that from the operating system from the whatever or hard-coded in Co program and then you can go one nibble at a time until you find the right place on disk to find this value so it get some it is a legitimate way to do this search and I just think you know database engineers have invented better ways to search for data since then so we might not use that but I think yeah you

just mentioned a term that we I don't think it fully defined and that's this radix do you say radix tria radix try well I would normally say you write extry but for the purposes of this podcast that was a big strike from now on I think I suppose yeah just apologies to anyone it's been a little mixed up we're trying our best to use this lingo just for this podcast obviously everything that we're sharing and we think of we always think of the podcast is sort of an addition to study so if you are studying this sorry if we got it wrong a couple times and we also think of it maybe is like it's an introduction so if you want to dig in we're gonna share a lot of especially for this episode we're gonna share a lot

of show notes a lot of diagrams papers other videos for you to dive in but now back to this question of a radix try this radix as far as I understand those are related to the patrícia try so what what are these these are words that we hear specifically in the context of aetherium how does this relate to what we've talked about yeah so radix I actually know that I think about it I don't know if you do say radix tree or radix try because you would say prefix like a prefix tree is a try and erratic tree is a prefix tree with some optimizations yeah but that's basically what a radix let's call it tri is so

it's it's a prefix tree that has this index structure but instead of you know naively taking one nibble at a time let's say that there are two following nodes that don't branch off so if in the theorem example there are two addresses that share a common structure and there are no other addresses that share any of this structure so basically we can take two nibbles and put them together into one node so it's a it's an optimization step that we can kind of squash this tree together a bit if there's a shared indexed structure between different values or

isn't shared key structure it's the shared key structure it's not shared hash shared key structure it's the right way to think about it because the other thing is sort of a fall out of having a shared key structure yeah if it's share it's like several nibbles of the key then you might as well just bunch them together in OneNote and I think for our purposes we can just think of it like it's an it's a way to optimize these these tries it's a way to make them I guess less heavy because you're sharing smaller and faster to search through and so yeah Patricia try which is you know the theorem tries are called Merkel Patricia tries or even modified Merkel Patricia tries and Patricia stands for

practical algorithm to retrieve information coded in alphanumeric I thought it was maybe Ralf Michael's wife but her name is Carol oh yes it's just an optimization on how to retrieve information and how to optimize search in this tree so that in a way kind of brings us to the end of our explanation part of this podcast which will be the majority of it we've covered this Merkel tree concept we've covered the prefix tree or try we've described the different pieces of data that would be used in the etherium version of the prefix tree or Merkel try and how these

exist in the blocks we've gone kind of up and down through these to try to help to describe them but now why don't we cover a little bit of like how does this work in the world well it's been created to be able to have like clients and so that does indeed work I mean it serves its perfect purpose for that but these tries are very expensive to produce actually so I think that's that's the problem that we have with state bloat it's not that the state takes up eight gigs of you know who cares about eight gigs it's not that much but the fact that this tri is so large and if we execute in a transaction

especially like a smart contract it might touch ten different accounts so we need them to update not only the values on all this places but we also need to update all of the hashes going all the way up so you know if you touch just a few addresses then that produces a ton of changes in this try and it can actually if you introduce a new address that kind of splits off a previously shared key space then you now might need to rearrange and like reorganize this try a bit and yeah so making all of these modifications to the try is really

hard and they happen at like two 300 modifications per second when processing and block and this try still needs to be saved to disk so you know all of these hashes all of the structure everything needs to be saved to disk so the question is how do you do that and we use rocks DB for it and it's not the best to do that what we would ideally want is like a try database that is specific for storing the structure and so when you you know have 200 updates that you want to make to this try you don't go and touch the disk in 200 disparate places and cause a bunch of I ops you want to you know be able to

flush it in a linear fashion or whatever you know one could dream up of but this is a super hard problem you know designing a database from scratch specifically tailored to this use case and you know it's something that we apparently have an open job position for but you know we'll we'll see if we can actually get anything done there but it's a big problem and that that's led to a lot of the experiments behind turbo death and trying to find like try less data structures to be able to do the same thing to be able to provide the same proofs and like in the future maybe ckase narcs or Starks or other approving structures

come into place where we can provide the same like line proofs without having to maintain this trying yeah I think that's I mean that's definitely an interesting idea of like how these tries are not fixed things that you know these are not static entities any any change in one piece of it will inevitably need changes all through it I guess I don't I don't fully get what kind of weight or what kind of effort space computational power this really takes but do you see it truly as like a strain on the system so it takes almost no computation power but

it's limited in your hard drive so the reason you can't sync aetherium on a normal hard drive anymore is because you need to update this try so much and a normal hard drive just can't skip around on disk and update these hashes all over the place that fast and so we need an SSD to be able to have random access fast enough to do this if they're in a very large way is IO bound it's bound by the hard drive speed that you have and if we if we didn't have this try then we could remove that IO bound and being computationally bound would be a huge improvement well I think this is this has been a really intense truly

blockchain 102 experience I always have a hard time figuring out if this is useful or not like with the feedback we get it sort of like yeah that's cool and some people really like it but I have no idea if I did a good job at explaining any of this so if you want to get feedback check out our web page Twitter Email we have things to provide feedback I would love to hear it yeah definitely we also have a telegram group you can join and like immediately ping us I want to say a little shoutout to a project that sort of inspired this at least it inspired the timing of the according of this and that's this event that Robbie been kicked off last year in

Toronto called marry Merkel which isn't it's like a charity event it's focused on it's basically coming out of the etherium ecosystem and they did it again this year in Africa where they went and built a school and I like the name and I thought it was quite merry so yeah we decided we would just do an episode on on merry Merkle trees so I hope that you guys enjoyed it and like Fredrik said please please do share some share some feedback with us about this if you want us to keep doing episodes like this if there are other topics you'd like us to cover we really really like to hear from you and to our listeners thanks for listening thanks for listening

[Music]