Vitalik Buterin | What makes an ideal state tree?

40 okay yeah okay great um so today what i wanted to uh talk about is uh to go through some of the motivations for like what kind of uh data structure and what or what kind of cryptographic structure makes sense for the ethereum state tree um and like talk about um some of the thinking that we've done going from hex trees to binary trees to virgo trees um to cryptographic accumulators other kinds of fancy algebraic constructions snarks and basically just explain kind of what are the very specific properties that we're looking for from a yesterday tree and how the different options that we've considered compare with each other and like basically why the verbal tree looks like the most attractive out of what we've seen so far um how some of the other options look and like what kinds of structures might state trees be used for um in the future um so start off the current uh merkel bridge wishes tree so this is the structure that is used for um in the storing the ethereum state uh today and so every ethereum block contains a bunch of roots one of those roots is a state root and the state root is the root hash of this tree and the tree has a hexary structure and so every node has 16 children every node is the hash of 16 children i'm actually up to 16 children so if they're like for example there's no addresses at all whose hash starts with a seven then or or whose hash starts with a five but then there might be 14 children instead of 16. um but most no instead are not right at the end in practice tends to have 16 children um so notes have 16 children and then every note is a hash of some child notes and then child nodes or hashes of other child nodes until eventually at the bottom you get to the leaves um so the reason why we have the state tree is so that every block can contain this hash commitment and from that hash commitments you can then make a branch and that branch can prove um any individual values so like for example here um if he wants to prove this about this value 27 inside of account 175 that you can make a branch that consists of the portion of the tree that goes down from the state where to the the 27 and those values can actually be combined together um and they or the the notes along the way they can be verified together and as long as every step is the hash of the the values um at the level below it then you can verify just with that one branch that that 27 actually is the object in this particular position in the state tree and so the um once um term i guess medium term at this point the goal that we want to achieve is this idea of stateless clients right so we want it to be possible to verify an ethereum block without having the entire state yourself um so if you don't have the entire state yourself then if you have a transaction that accesses some state well how do you verify it so this is where we use these proofs right so if you have a transaction that um touches a few accounts then in order for stateless clients to verify it someone has to package a block that comes together or together with the merkle branches for every single object so a bunch of accounts a bunch of storage keys that that particular transaction touched um so these stateless blocks they're going to be much bigger than regular blocks because they have to have these extra proofs attached but the benefit is that you do not have to have any state right so you as a node can just join and you can start verifying a block immediately um you do not need to do any syncing um you would only even even needs to do syncing if you actually care about like getting historical data or actually having some large uh piece of the state locally because you just want to like run some uh some script on it or something like that all right so just to verify the chain uh you would not be required to have state uh you would be able to start verifying immediately you would not even have to verify blocks in order um you could only verify a block if some node raises an alarm about that block um stateless clients technology is also used in fraud proofs um so a lot of important just use cases and benefits for stateless clients um another thing of course is that if we ever want to as your knowledge prove blocks then um the zero knowledge proof approver is not going to have access to the entire state um or whether the verifiers don't have access to the entire state and so you would want the thing that would be proven basically the approver would have to prove over uh verifying a block the way that a stateless client would regardless right so there's a lot of benefits toward moving towards stateless clients i'm just reducing dependence on disks making it easier for more people to run nodes uh making it more flexible so validation instead of being over nothing you can verify some blocks and other blocks but i've talked about all of this um a lot the important point is that for sales clients to be possible the sizes of these proofs so we call witness sizes they have to be reasonably short so how short well we can look at the properties of a heck of branches in hex patricia trees as they exist today right so if we want to look at the branch the length of a single branch then the length of a single branch on average is roughly 128 times one again now you might ask well why this number um so it's actually 520 512 times the log base 16 of n um because uh at every level of the tree every node has 16 children and so if there is some like say n nodes in the tree then the depth of the tree is going to be a log base 16 of n so say if there's 16 to the power of five nodes in the tree then level one will have 16 and a little two will have 16 squared or three off 16 cubed little four all 16 to the 4 and then level 5 will have 16 to the 5. um so and then log base 16 of n just equals log of n divided by 4. i'm and then because every node has 16 children and a merkle proof actually has to include all of the children that make up each note along the path so that you can hash these notes together and verify that the hatch actually matches and so like basically the you ha at each one of these levels the proof has to contain all children so all children of this guy all children of this guy all children this guy and then all children each child is 32 bytes 32 multiplied by 16 512 um but then because log 16 of n is a log of n divided by four so we divide by four go back to 128 times log of n um so for example if the state tree has a size of two to the 30 so about one billion then the length of a branch is going to be about like 3.8 kilobytes the cost of generating a branch um it's going to be log of basically log of n over four database reads so the data for our branch is already in the database um and so you just have to read a bunch of times if you want to do many branches then the formula becomes roughly basically this multiplied by k except instead of log of n it becomes log of n over k basically you get to save a little bit because if you make lots of branches and then they start sharing hashes at the top and so you get a little bit of savings right and then the cost of editing one branch right so this is if there is one block and then now one block actually changes a branch in the state then how much work does the node have to do and in this case um you have to basically um redo a bunch of hashes so like you say if this 27 becomes a 28 then you have to rehash this though do you rehash this do you rehash this though you rehash this node and each of those hashes is 512 bytes and then also on top of this you have to do a login over four database race so that's where we are right now um the main problem is that branches are too large right so for example if we look at a block that has a 15 million gas then 50 million gas divided by 21 000 which is the cost of a basic transaction um that gets us to about 715 transactions in a block i think um so um 715 transactions and then each transaction has a two and a from so we're talking about 1400 addresses 1400 addresses multiplied by this gets us stuck around like something like six megabytes and then that doesn't even and that's not even the worst case right that's that and then i'll go down a bit because of this login over k thing but still like around four megabytes it turns out that that's already a little bit too big um and that case is not even the worst case right like there is much worse cases where you have transaction certain types of transactions that are much heavier on state reads and state rights and so the witness sizes get even bigger so the challenge is can we make these uh branch sizes smaller so one very simple thing we can do is we can go from hexay to binary um so the reason why going from hexa to binary is better right is that if we zoom in on just a particular set of uh 16 like in this case it's just a set of eight right well let's look at it if let's say this was a node where he just had eight nodes in parallel then if he wants to prove that the this hash is the hash of a node that contains this value you have to get you'd have to provide one two three four five six seven right you'd have to provide all the sister nodes so that all the data can get hashed together and generate a hatch but if the tree is binary then you have to provide fewer hashes right you just provide this value and then this value and then this value and then this value right so instead of providing these seven sisters you only have to provide one two three and then if we go up from eight to sixteen then instead of providing 15 sisters um you have to you have to provide one two three four right so with binary tree is basically the number of layers goes up by a factor of four but the number of sisters um goes down by a factor of 16.

and so on net it's uh going to be four times uh the proofs are going to be four times smaller the hashing is going to be a bit less um so binary is already a significant improvement over x-ray right so the branch length goes down from 128 log into 32 again um so once again right the uh the depth goes up by a factor of four but the number of sisters at each level goes down from about from 16 to one or from 15 to one i guess technically um but um so it's uh it's a altogether a factor of four efficiency um the cost of generating a branch um now you can actually get a little bit clever here um so the way that if you're like the kind of ex most existing somewhat fairly naively designed ethereum clients work is they just uh store the data like they make each node in the database corresponds to one node in the hash structure right so like because you have a single 512 byte node that gets hashed together you store that as one as one unit um and but you don't actually have to do that right on the disks um you have a page size of four kilobytes and so it's basically about as expensive to fetch four kilobytes from a database as it is to fetch a much smaller amount of data and even going up to fetching eight kilobytes um it's only a little bit more expensive than fetching four kilobytes right so hard drives are really actually optimized for making big reads and you so when you store on disk you can even if the tree is binary from the point of view of hashing on disk you can make it a like a base 256 tree for example right like you can just store lumps of 256 notes all in one single node and then you just pretend it's a 250 it's a it's a tree of width 256 except instead of hashing unknown to just directly hash it by making a mini merkle tree and instead of and then like when you make branches you get to optimize some more right so with binary trees like you have you get somewhat more flexibility with hexa retrieves you sort of can accept with the i think yeah with hector tweezy do you have somewhat less freedom because like you still have to grab pieces of information that like the database nodes have to have to contain like individual notes that are being hashed but with binary trees the nodes that are being hashed are smaller and so you just have much more freedom in terms of like how what the size of your database chunking is so you get some benefits here um k branch length um so once going up from a single branch to k length once again going down from 128 to 32 factor of four difference and then editing um once instead of these uh big size 512 hashes um you're hashing four times more nodes but the hashes become eight times smaller right so binary trees are an improvement but the problem is that binary trees are not enough of an improvement right like these numbers are are already much better but the numbers are still not good enough right like we're still talking about these multi-megabyte witnesses in the worst um in the worst case and we really really want witnesses to be significantly smaller than that so what can we do right so we can use polynomial commandments right so uh polynomial commitments are an algebraic alternative to cash-based structures for committing to large amounts of data right so and i'm sure people in ziki study clubs have seen the the the equation for a um commitment witnessed before right the q i equals uh p of uh p of x minus the y coordinate divided by x minus uh by x minus the x coordinate and stick that into the uh analytic curve point and this just is this one single witness that you can use to prove that p of x i actually does equal to some particular value right so polynomial commitments they're algebraic they're nice um they have this really nice property that it seems like no matter how big the polynomial you're committing to witnesses have a side like a fixed size you just uh awareness is just a single qi it's just a single point so can we use witness uh polynomial commitments and specifically academic commitments to do a uh better to do better than binary trees so let's go through the properties right so the the length of a proof um instead you don't it's not a tree anymore it's just a polynomial commitment the length of a single branch goes down to for just a 48 bytes right if they're bls walk 381 points they're 48 bytes long and so proof is just going to be 48. um it turns out that if you have like uh if you're gonna approve for k items then your proof size actually is also just 48. um well it's 48 plus the data that you're proving right so the data you're proving so i probably should just say plus 32 times n here um but then add uh but you only need this one extra witness right you basically get like instead of dividing by x minus x die you divide by the product of x minus x1 x minus x2 x minus x3 and instead of just the p of x1 here you just you you provide like the interpolant of a bunch of values right so like i'm sure the the math voices i've seen this before right but the point is that you can make a witness for as many values as you want for just um the data itself plus 48 bytes the cost of editing one brand of the proofs right well you just you just update the data um so so far so good but there's a uh this one problem right which is the cost of generating a proof in order to actually compute one of these quotients you have to actually do polynomial division this is a degree n polynomial divided by degree one polynomial and this is an o of n operation right and here we're talking about n being a billion so this is just completely uh ridiculous and practical so here's the so so it seems like we have a problem right but the math wizards among you may have uh also remembered that there exists this magic algorithm where you can pre-compute all the quotients in n-wall again time right um i think it was like the paper is like fc 20 or something there's some acronym for it but uh dimitri umadrich did some work on it dank rad did an implementation it's a really amazing and lovely piece of math right so we can you might wonder well yeah you can pre-compute all the witnesses and then you know evan will again time and if you generate all the witnesses and analog end times then you don't actually have to generate the witnesses anymore because the witnesses are already there problem is that this does not work now you might as well why does this not work right the reason why it does not work is because when you edit the data right you basically have to do the pre-computation all over again and the thing with stage three is is that state trees get read very frequently and they also get written too very quickly right every blog reads thousands of values from the state tree and every block makes thousands of rights to a state tree so it's uh definitely definitely the um like sort of a case where you don't want reads to be super expensive and you also don't want rights to require recomputing the entire data um so unfortunately this is also prohibitive right so you can do it you can do it without um precomputing witnesses in that case computing witnesses is prohibitive or you can pre-compute the witnesses in that case editing the data is prohibitive because you have to recompute all the witnesses every block um so polynomial commitment schemes are just not designed to deal with large polynomials that are constantly changing right now it turns out that there is one last trick up our sleeves we can have we can try to do some even more clever math to try to rescue polynomial commitments um so this is this uh e3 eth research post that i made i think um i guess um about a year and a bit ago um basically um we have we can actually do a square root of and compromise between the two so we can split up the state polynomial um and you don't have to do this in consensus in consensus clients can actually do it locally um clients locally store the old state polynomial so this is a polynomial that gets reconstructed and witnesses get reconstructed and this is done every square root of n steps and then you have a recent deltas polynomial and the recent deltas polynomial just um contains changes to the state that were made very recently like within the last square root of n steps and witnesses from the recent illness polynomial get generated in real time there's this really nice algebraic property of kate witnesses that a witness if you generate a witness against a and you generate a witness against b and you just add the witnesses together you get a valid witness against a plus b right so we're going to use this property right basically yeah the clients are going to store this old state and they're going to regenerate it and they're going to run this process in the background so it's amortized and they're going to regenerate the full state and all the witnesses every square root of n steps um and then if whenever they needs to generate a proof they're going to use one of the pre-generated proofs against the old state and then they're also going to use um just generate a proof against the recent deltas which is uh this much smaller polynomial um while smaller in the sense that the evaluator evaluations are sparse right and that's a kind of smallness that's actually good enough for us um so and then you generate these two witnesses separately and then add them together so what are the properties here right the cost of generating a branch so generating the old state branch is trivial but then generating the new state branch requires size square root of n arithmetic and no optic curve work basically because um the from the recent delta polynomial you have to just regenerate the witnesses every time um and then the cost of editing one branch amortized is going to be square root of n1 again um because you you have to keep running this background process that regenerates the entire o event uh with the set every square root of n steps right so we have square root of n over here square root of n over here but so this is better but unfortunately it's not quite good enough right it's like maybe like two orders of magnitude away from being a super awesome and uh an amazing solution that we can live with but unfortunately it's uh um it's not quite there um now of course like maybe this is the time when like someone likes darkware or some asic manufacturer is gonna come in and say like hey wait you know we're gonna come in here guns blazing with our super awesome hardware we're gonna we're gonna make a square root stuff work and maybe like maybe they will come in and do that or someone will come in and do that but like without any some kind of breakthrough that just makes all of this like an easier by big constant factor it's still not good enough so this is where we come to vertical trees right so a vertical tree is not a single polynomial commitment it's a tree of polynomial commitments where every polynomial commitment has a large size right so for example every polynomial commitment would have a size of in our design uh 256 elements and then proofs within each commitment are of one size right so each commitment works the same way polynomial commitments normally do except instead of the data being in a single commitment the data is in a tree of commitments right so like you might you have a root and then that root is the root of 256 um different values and these values are all themselves roots and this is a root of this set of values and this is a root of this set of values um so instead of one commitment you have a tree of commitments and you might ask well what's the benefit right well the benefit basically is that if he wants to prove a single value then you would have to make a proof over here then a proof over here then a proof over here but the nice thing about commitments right is that proofs are all of one size so because each commitment has size width 256 um so instead of needing like say depth 32 for a billion item tree you you would only need depth four for a billion item tree and then the proofs are constant size and so you just you would just need to have four proofs um and the proofs are nice and small um and and so all together the proof size is smaller but the process of and then to do updates it's fairly simple um you would just update the data to generate proofs you do have to do computation over the sister nodes but the computation is like relatively simple and fast just kind of like arithmetic and a fuel optic curve operations so here here's the chart with the properties right so the brand the length of a single branch is going to be 12 times log n bytes right so instead of 32 again goes down to 12 log n um basically because um we so because these nodes are each have a width 256 and so instead of log n we go down to log n over eight um and then at each level um you have to provide the intermediate polynomial commitment which is 48 bytes and then an e12 we have to provide the proof which is 48 bytes right so at each level we provide 96 bytes and there is eight times fewer levels and so 96 i divided by eight gets you to 12. so 12l again is better than 32 again um the cost of generating a branch is going to require um so log n over eight steps right so because um every one of these levels has size 256 so instead of so instead of needing um like eight steps to go up by a factor of 256 you want to need one step to go up by a factor of 256 um and so same database reads as before and you also need to do size 256 linear combinations right so you have to do a size 256 a linear combination just to sum up a bunch of uh like elliptic curve points multiplied by the values over here um to generate the proof do the same over here generate a proof do the same over here generate a proof to edit one branch um basically oh i think this is actually a mistake again you don't actually need linear combinations like you basically just um to edit these values you like edit one value in place and then you can recompute the recompute the commitment and then you added this value in place and you recompute the commitment data this value in place and recompute the commitment so you only actually need um log n over eight um just single up to curve multiplications to edit you don't even need the linear combinations um so this is already better right and then for k branches it's basically the same kind of like k times like an overcame formula so fairly similar to binary trees except we replace the 32 with a 12. and also the cost of generating a branch does go up a bit because we have to do some extra elliptic curve work the cost of editing values goes up a bit because we have to do a bit of elliptic curve work this is all instead of uh doing hashing elliptic curve work tends to be more more uh computationally complex than hashing but we it's not that bad and we have managed to decrease proof sizes but we can go further right it turns out that there is a very clever fancy protocol where instead of needing to explicitly provide one proof at each one of these levels we can provide one proof that simultaneously proves an arbitrary number of parent-child relationships right so the vertical proof now only has to provide the inner notes and then there is a single proof that simultaneously proves this parent-child relationship between root and the inner node prefix b this parent-child relationship between internal prefix b and the by sheep node this parent child relationship go from roots to prefix four this um parent child relationship going for prefix for the prefix for c and then this uh from uh prefix pair child always shipped from prefix 4c to the force horse node right so one single proof proves all the parent child relationships and uh so you can this gets a lot of benefits right first of all you can get rid of the instead of 96 this goes down to 48.

second um because you only need one proof um we we can actually switch from using cassie commitments and bls to using bulletproof commitments and just using some regular 32 byte curve um so that makes the math a lot simpler it makes the proof size one and a half times smaller again right so we made the proof size two times smaller because we got rid of the proofs and replaced them with one we made it 1.5 times smaller again because we go down from 48 to 32 bytes and so we've gone down to um like basically three times smaller proofs um and so all together right going from hexa to vertical uh here we go down from 128 to basically four once when it will again to formal again there's a constant factor of about 200. cost of generating a branch um it turns out that to generate a branch you actually don't need um you only need a fixed number of elliptic curve operations um you only need one one single um size uft six linear combination and you need 128 times the log n um arithmetic operations um log n over eight database reads then um like um then the for key branches the proof it's very simple um the size of a bulletproof commitment is a little bit bigger but it's still logarithmic size so this is pretty negligible and then the cost of editing one branch is basically the same it's just like some into um a few electric curve multiplications and a few database rights right so basically all the costs just go down a huge amount the most important thing of branches goes down by a factor of 32 compared to the status quo which is hexary trees right so this is just really an incredibly amazing um and verkal trees are already this very a nice and powerful compromise right now there is another credible alternative to virgo trees which is snarked miracle groups right basically we'll start miracle proofs um the idea is that the proof length is just going to be the data plus one single snark you just snark whatever the merkle proof is it's narco is going to be about 500 bytes if you use planck the cost of editing is just going to be hashing and then the cost of generating a proof is going to be the database rights plus about 400 times we'll again prover constraints if we assume that we're using some of these uh really fancy um arithmetic friendly hashes the problem is to actually do this we need to have like properly verify um de-risk and uh do all of the kind of all of our homework on the arithmetically optimized hashes so long-term this is a totally viable approach um once uh quantum computers come and break everything um then you can do stark merkle proofs which are only a little bit worse than stark's merkle proofs so this is another one um another a nice option but virgo trees are the current uh kind of assumed path forward um but the i guess the the the point of all this right is that coming up with a uh an algebraic structure that does everything that we want is kind of hard right verbal proofs are in verbal trees they're nice they're not perfectly algebraic in the sense that like ultimately they are like a hash of a commitment to the hashes of like of a of a commitment to my commitment and so there isn't like a clear algebraic relationship between some node multiple levels down in the root um and so that doesn't mean that like for example if he wants to make zero knowledge proofs over it um then like you are just gonna have to make zero knowledge proofs over uh elliptic curve commitments and or and over elliptic curve multiplications which is uh not the worst thing but it's definite but it's also not the best thing um but at the same time like it's uh it is something really powerful it is something that has a lot of these very nice properties um there are also recently there have been a couple of designs that that have attempted to provide for the data for this data structure that we're looking for more explicitly in a much more algebraic way um there was a design based on n-dimensional uh polynomial polynomials that was uh uh done recently but one of the problems with that design is that it ends up the proof ends up having to contain some uh some gt elements and then the constant factor overhead ends up being pretty high so it does end up having some issues and that it ends up um like so far out of everything we've seen virgo trees like still are the least bad of what we know despite i'm still having this um a little bit of uh proof overhead that we would um that we would rather see disappear um but this is still an ongoing problem there's still an opportunity to do more work and come up with better designs here so but that's the yeah that that's where we are that's basically where we are now with verbal trees that's uh you know the reasoning behind them some of the other approaches that we tried and ended up rejecting in order to get to them and like some ideas for where we might go in the future yeah uh thanks very much for sharing um let's see are there comments or questions uh comments in the snark proof that's not my country yes um when there are k branch whites in historic market tree um well what's the question sorry oh wait uh no sorry um yeah sorry i guess i'll be a problem uh i can't say it again sorry um the question is like why why there are like k branch calls in the stacked microproof like what do you mean by when like uh if a star like if a stark's miracle proof gets used for the ethereum state tree and then there's like a block that makes a thousand accesses then you're going to have to make a stark of a thousand vertical branches right which is still a single snark yeah right but they are like witnessed uh off general right well basically um well you don't have to provide the witness like the snark itself is just a proof of that the witness exists um like you provide the snark instead of the merkle branches yeah okay yeah now i mean i think technically if there might be a ratio like you might want to still provide the merkle branches for the for the data that was updated um if you want to like help nodes get an updated tree but like i think like theoretically you don't have to okay that makes sense thanks uh any other questions is it possible to create um sparse vocal trees with proof compression as you can with murkle trees by proof compression you mean snarking or something else uh if i recall correctly there was a post on a proof compression on the youth research blogger i think by you actually um oh do you mean do you mean this is like the stuff to do with these uh efficient proofs for like you've mentioned multi-proofs um yes it was on the esmt's post right it's very so that you can efficiently do um a proof of exclusion or range proofs or uh various proofs can be compressed that way can you do the same thing for vocal trees oh i see it um range proofs for virgo trees interesting um well no well proofs of exclusion you can definitely do right because uh like you would just uh like kind of walk down the tree and then at some point you would walk down to a node and you would see that one of the nodes has an empty child and so a range proof like yeah you would just like i think if you just provide the proofs to two adjacent nodes then that already also satisfies as a range proof or as a uh an empty proof for um every key that's uh in between those two just because like add every single like whatever the first node is where the two uh the two keys diverge like you're going to have the two children and the two children are going to have a different uh like every like you're gonna basically end up also proving oh no right you have to like actually make a little bit of an extra proof to actually prove that the children are in between our zeros you do have to add a little bit of extra on top um so you don't get it automatically but it's it's not hard to do right and then the key is obviously they just to get proven because uh the like once you get down to a single key value note that by itself just proves that there's nothing else there so answer answer is yes um with the one caveat that you you do lose the property that a proof of two adjacent nodes is simultaneously an emptiness proof um of everything in between them but i think in in practice in the ethereum context that's never been a big deal basically because uh like things get hashed before they get put it or keys get hashed anyway and no one really cares about like uh what the order is of um or of hashes of addresses um but yeah it's very easy to make a proof of exclusion for a value thanks uh vitalik i'm gonna have to take uh quite a few notes on some of these things to understand a bit more but you had mentioned about uh quantum technology breaking everything would you mind elaborating a little bit more on how to possibly prevent that or your thoughts sure so quantum computers break a lot of cryptography but not all cryptography right so quantum computers break anything that depends on factoring or discrete logs so they break anything rsa based they break anything class group based and they break anything um elliptic curve based including pairings and including simple elliptic curves um these quantum computers do not break a lot of cells and they do not break hashes um so quantum computers will break vertical trees but they will not break uh snark margol trees um i mean potentially it might someone might be really clever and come up with some kind of fry based burgle tree that doesn't um or fry based vertical tree that does that that doesn't uh break but like i think the most realistic post quantum path is to just uh make a merkle tree using an arithmetically friendly hash function and then just go into a stark on top of that um if anyone by the way wants like materials to read up more on these things um i mean on my blog i have articles on vocal trees and ziki snarks um dink rad on his uh blog has a a lovely piece on cat day commitments there was that ether research post that i linked um let's see if i can find the number on the uh um on the fancy scheme that doesn't quite work 7520 um those are probably um and then well dan grant's piece on uh katy commitment says yeah yeah but cece already liked it that's uh the one that covers a lot of the math um and then the other one that i was going to mention is um that one is uh the one that talks about snarks and it also talks about polynomial commitments um oh amazing someone has one in a traditional chinese um oh and of course another somewhat fun thing is um hold on a bulletproof um i'm i made this uh a kind of picture explainer for how about um for how bulletproof commitments work i'm just trying to find it um oh there it is no there's a bulletproof commitment to what we actually use in the workload they're worth exploding they're worth understanding as well