 Hi Yeah, excellent, so yeah, I'm going to talk about vocal trees I've been making a few presentation about those already, but they tended to be a bit too Deep technically speaking So because this is DevCon and we're trying to onboard more people This one is going to be a bit more high level. So hopefully enough to raise your interest in vocal trees So, yeah, what do we what do we? Why are we considering vocal trees? It's basically a big change in the in the way theorem functions So what do we want to risk this? Well, there are several reasons the the first one is we want to be able to build blocks as self-contained execution units at the moment if there may has a bit of a problem That's when you want to join the network or if you haven't followed the network for a while You need to go through a process. That's called a sink synchronization You cannot access the state directly. It's like you cannot just download the state I mean you can download the state, but it's It's a fairly convoluted process So the idea is that if you include in the block everything that you need you can just Download the block and execute it and see if you're interested like even before you even if before you Execute the block you can even know if it's going to be of interest to you or not And if it's of interest to you you can Execute it. Otherwise, you don't even have to to care So it's something that is it's to build something that is in between the full client and like a full node and a light client In the sense that you are still supposed to follow blocks But you don't have to hold the entire state and it's nice because It paves the way for other upgrades or it makes other upgrades a bit simpler. For example, if you want to Shuffle committees between between shards in the future You want shards. You don't want shards to fall shard the validators to keep following the chain at all times Several chains at all time. So it's something that's going to help them get up to speed a bit faster And of course, there's the the idea of state expiry like the state of Ethereum is quite large So we want to be able to delete some of the state But we don't want to delete and forget forever if your state has been deleted But you want to use it again. You need a you you need to provide a proof to resurrect your state and The idea is that Vercal trees make your proofs smaller so it will be cheaper for you to resurrect the state. So Because it's a fairly like deeply technical Topic I have tried to to make a simpler explanation with pirates So imagine you have four pirates and they they bury a treasure somewhere and they plot the directions to get to the Treasure on the map and then they want to go their separate ways so if they adopt the method like the metaphorical method that we We we currently use in in the in the theorems to store the ethereum state What they would do is they would split the the map in four bits and then each of the pirates would get their own bit and when they want to get when they want to access the The treasure they need to to put all the the pieces of the map together The problem is inheritance if one of the pirate wants to retire and for example wants to to sell you his bit of the of the map How do you know he's not selling you a fake map a fake piece of the map? He's a pirate after all so you should be careful Well, the problem was this the method that was chosen to figure that out You need at least the other two pirates to check that the the pattern matches the proof size is quite Involved it requires you to take the siblings the The sibling pieces now if we use the very the proof the proving technique that is That is suggested by a vocal trees, which is called like it's based on something called vector commitments Hence the name vocal what you do is you like cut out something at the center some little stub and You make this little stub as hard to reproduce as possible. Ideally cryptographically impossible to fake and then everybody goes their separate ways and When you want to buy the when you want to buy the your part of the map All you have to do is make sure that Your piece fits into that that proof that little stub so of course we don't use Pieces of paper we we use cryptography as stronger cryptography than this and now this is your proof size And so how do you transpose this to? Vocal trees Well the current ethereum state is stored in a tree where all the data of ethereum is at the bottom of the tree and Then you group them the parent is a commitment the parent node is a commitment And then the parent of that parent is also a commitment all the way to the top and the root of the tree is And ending up in the block so if you want to prove in the tree for example the purple square here if you use the current method it's the same thing as with the pirates for each level you have to pass the siblings and Here this is a very simple representation But in in ethereum each parent node has 16 children and the consequence of this is that you need to pass 16 sorry 15 other value for each value at each level for each value you want to prove So there are thousands of values per that get touched per block. That's that's a thousand times 15 values per level and if I remember correctly The depth the tip the average depth of the MPT is between 10 and 15. I don't remember exactly So that's a lot of data. That's roughly if you want to pass the data in a block That's three megabytes. We are in Bitcoin territory. So yeah, it's a bit too big to pass Around the network in a reasonable time if you use the Vocal commitment, so you have the equivalent like you still have the oops Yes, you have the The little cryptographic proof, but all you all you have to pass as as your proof is the the nodes Along the way to your value and that is much smaller first of all Because you don't pass the siblings But on top of that because you don't pass the siblings There's a virtual cycle that allows you to widen the tree you can have more children per tree and Per node and as a result the tree gets shallower. So your path is even smaller Even shorter and as a result your proof is is that much smaller. So there's a Unfortunately, it's not that simple. There's a quite a few changes to to introduce at the same time Like the first one is putting the proofs in the block. That's that's that's the whole point But we also need to change the tree structure and I'm not gonna get too deep into the details because Once again, it's quite involved. There's any IP. There are other talks about it Look at them. Look them up if you're interested But the idea is that all the data ends up in a single tree So currently accounts have their own tree and for each account you have The another tree that encodes the storage for this account. Well here everything is kind of Yeah, hashed or mixed together and spread over the tree each item like each account item for example the balance the nonce The code the any any slot like for example, if you're thinking of crypto kitty each cat is Accessed independently because we don't want to add more to the proof that is Required so if I'm sending funds to to a new address Well, I just need the address the target address balance. I don't need to know how many how much code they have I'm only interested in the funds Right and like I was saying the data is spread all over the tree But we are trying to group Things that belong together a little bit so that you don't spend your time jumping all over the tree all the time so it's grouped in batches of 256 and I'm going to go over that in just Just a bit. So this is a picture that comes from the EIP itself I'm going to describe on the left side You've got what's called a stem tree and it's the basically the top of the tree So the tree is flipped to the side is rotated 90 degrees to the to the left and the root let's read the the stem tree only has Branch nodes so that means every node in that tree has at least two children when the When you take your key and you follow the you follow the The past trace by the key at some point you will reach a moment where there's only one group that is group of 256 that is Pointed out by this key. So there's this intermediate Like what's called an extension? Yeah, I don't quite see the pointer here. Sorry, but the blue the blue box That extension says this is The prefix the 31 byte prefix that every key below me Have like our keyed by so That means that if when when you go through the tree and you You have to compare the key that you're using with the the encoding that the key encoded in that blue box And if it's the same that means your data is In the group below it. Otherwise, your your data is not present in the tree and then There's the suffix tree so that corresponds to the 256 values and there's a force column that we're not going to cover It's not really important for this talk So like I said every every piece of data is broken into chunk that means for example the code is broken into bits into 31 byte pieces that are fitted in a 32 byte piece the Storage slots are also have their own of their own data the the balance as its own value and each of these values Each of these chunks is given an offset and for example the the balance is always an offset one the non-set offset to and then a bit further you have the beginning of where the code is supposed to start and Then even further you have the the bits where the all the data slots are supposed to to be and the way You find them in the tree is you take the address of So you have a key that is made of two Two parts the the first the 31st bytes are called a stem and the suffix It's just a bite that indexes in the group that we saw before I'm talking about the the third column here, so the the last byte is the index in there and And so to build the stem what you do is you take the address of the account and you take the first 31 bytes of The the offset of that chunk and you you hash them using what's called a Patterson hash So it's like it's like catch hack, but it's much more friendly for for ZK applications and it's also much slower, but you get so you get a 32 byte values you take the 31st bytes of this value and That gives you the stem and the way you use it when you compare it to the tree The stem will give you the pass through the stem tree and the extension and when you you found that you use the suffix to Select the the value in the group. So Like I said, just a recap Vocal trees are nice because you can make the tree much larger much smaller much more shallow, sorry you can also experiment with with ideas like You could sing so I know that this is very interesting to that developers You can just download the blockchain not care about the state and when you look at the When you look at the proof in the block at the witness you can you can figure out if you're if that block is Accessing something you're interested. It's right. Excuse me interested in so for example If yeah, if you're crypto kitty You want to see if the crypto kitty contract is accessed if so you just Execute that block to update your internal state. If not, you don't care Yeah, and I was There was just a recap for the rest of the slide. So what is the current states of vertical tree implementations? We have one and a half running test nets The we have one test net that is fully working. It's a proof-of-work test net called country I'll give the address at the end and so proof-in blocks It works it works. It's been working for a while and then There's a proof-of-stake test net that is currently in bring-up phase So unfortunately, I wasn't able to get it to to work for for DEF CON but it's going to happen shortly when we do performance We currently have like performance testing We see that is currently five times slower than the regular main net So when we replay blocks from main net main net on a translated vertical tree layer, it's five times slower We have been we took it down used to be 40x. So it's it's a bit faster already We have another avenue to to Make it faster, but it's I mean in my opinion It's always going to be a bit slower than the current method But it offers some opportunities to to build the interesting application So I think it's worth it and there are there are like three implementations and there's a fourth one ongoing with with Beisu so I wanted so I don't know if it's quite readable But I wanted to give an example of what you can do with vertical trees so there's a block explorer on on that test net on the running test net and There's a piece of software that is able to read the block and reconstruct a view of the network Sorry of the tree that is everything you know to re-execute the block on top of it So I don't know if it's quite visible. I still don't see the pointer But basically you can see that the the leftmost branch here is an account The the next brand the branch right the right of it is another account. I mean I can tell because because of the way the the last level looks like and You have the the other two branches from the root these do not have a very deep tree and that's because This is a proof of absence. So that means This is the way you signal that those Branches those locations did not exist before the execution of the block and what definitely happened here Is that those two accounts on the left? Probably sent funds to those two accounts on the right that did not exist yet And that they will exist after the the execution of the block So it's quite interesting because you you can see what's going on and you can visualize it this way without loading the whole tree Right. So this is the current state. What are the challenges? We still have to overcome One of them is the transition Converting a miracle tree to a vertical tree is no is no walk in the park It requires a lot of RAM it requires a lot of this space and Yeah, it's it's it's quite difficult. So There are two methods really to avenues to do this this translation either you entrust the conversion to very powerful machines I have a test the machine that that is a Xeon. It takes it six days I know every gun is able to do it in like less than a day, but even even for every gun. It's it's not instant and Where was I yes? So that's the first avenue the second avenue We have to do the translation is simply to pace it to the slowest machine on the network So that would be to do a translation of let's say Five ten a hundred values per block But this would last for months, but then every node on the network would theoretically be able to follow So these methods are have names the one where Like you follow the pace of the network. It's called the overlay tree The other one was called offline conversion. There's a third one That is known as the roll-up appreciation week Where you just do nothing for a week or a month and you wait for everybody to be done a translating That's it's just here because it's a cool name. No one's really considering that Yeah, one last thing I wanted to say about this slide is pre-images. So Most of most clients including geth do not Encode the addresses directly. They just write the the hash of those Those addresses so to do the translation and because we use a different hash system We need the pre-images. It turns out that most clients do not store that Arrigan does but the rest of them don't so pre-image availability is another problem that needs to be needs to be addressed and It's not a it's not an easy one Another thing is the slower Cryptographic primitives. It's not as fast as Ketchak. So this is one of the latest runs and You can see that roughly 30% 33% 35% is spent just doing elliptic curve operations. So Cryptographic primitives is really where Well the effort needs to be The optimization effort needs to be made so either by writing faster crypto or by By not calling those functions as much. So Caching for example is is a technique that has worked well Yeah, there's a slide on database design. So basically the idea is that That's like current most clients have written their optimized their database layout and their database access layer For the current MPT a lot of those assumptions are no longer valid Let alone help helpful with vocal trees So there will be some need to adapt to something that is a bit close to to what Aragon is doing but that will take time unfortunately and I wanted to finish on people on what you can do if you want to help The first thing would be there. There are test nets So the first thing you can do is just try to deploy your contracts on test on the test net and see if that works if You can also try to run your own client like hashtag testing the verge you can also modify a CL client to figure out how to Propagate the proofs because currently it's not it hasn't been defined. So it would be interesting to to run a fact-finding mission Yeah, finding out where and how the proofs need to be need to be propagated in a proof-of-stake world Like I said crypto is the is the bottleneck So if you can find a better crypto cryptographic primitive than what we have that would be also quite helpful Yeah, it's also going to affect layer 2 solutions like presumably layer 2 layer 2 groups don't really want to to diverge too much from from the main net so They will need to they will need to To adapt as well. There's no really there's not a clear path for that yet Like I said pre-images are also a problem So if you have a way to to make pre-images available to everyone That's a very good. That's a very good test very useful and then you can go crazy You can try to prototype The interaction of verical tree with the portal network with a try to implement state expiry using verical trees all of that None of none of that is greenfield But it's also quite interesting to to get some some information some ideas of of what is to come and With this that's pretty much it I have put the addresses of the two test nets Knowing that the second one is still in a bring-up phase So it will probably not work today But the other one is the landing page for the proof-of-work test net and this one works or should work And you can look you can look at the explorer you can send you can send transaction You can you can try everything and that's it. Thank you Thank you so much Guillaume Guillaume. Do you mind taking a minute to answer our questions? If you do have any questions for Guillaume go ahead and raise your hand and one of the volunteers will actually come towards you There's a question right there In the fourth row or fight fifth row with the black sweatshirt you mentioned accessing data is going to be a little bit different Does this imply that like? Tooling teams and wallets and such are you're gonna have to like enforce access lists now moving forward? No It doesn't mean that but it means that the gas model is going to change to to follow this this new model Which is why I was like if you've got a contract, please deploy it on the test net But you do not need access lists are going to disappear They're replaced by something else that is not really exposed to the To the to the user so to a 40 end user in theory apart from the gas cost everything will be transparent There's one more question. Do you mind answering one more? Can I repeat the question real quick? Oh, sure I'm just gonna paraphrase it real quick and they said that they wanted to know if there's any drawbacks to the Fargo trees. Yes, there's plenty of drawbacks. Like I said, there's the the transition the the slow crypto Otherwise, yes, like the biggest drawback. I only alluded to in the previous answer It's that the gas model changes and that means that a lot of code You know like Contracts tend to some contracts tend to be very optimized for gas Those optimization can turn out to be completely obsolete and counterproductive So that I would say that's that's the biggest drawback. I can think of awesome if you have any other questions for Guillaume I'm sure you'll be over to the side. Feel free to ask him after the talk to thank you. Thank you