Verkle Implementers Call #23

Transcript

all right let's get started welcome to veral implementers call 23 I have shared the agenda in the chat this is issue 1121 and TM repo cool we don't have a huge agenda today uh yeah anyways so uh sorry starting off with uh updates from client team says anyone have any updates they would like to start off with okay I guess we'll start uh we've been working on do testing ignasio has

uh some update about this uh afterwards and also making some progress on the next test net so we finally managed to get the the branch with the all the the Kenyan gas cost uh cover so we've been testing it it's uh mostly works we still have an issue updating the the like kosis to to be able to build a test net uh but once this is ready uh we should be able to to start uh of course there's this new approach but I let nasio talk about it uh where we would rather make sure everybody is able to

replay the test test before we even try to start a test net um but yeah at least guess is getting ready oh and also I've Been Working On The Fill cost uh for not the next test net but the one after um yeah so this is uh starting to get uh some stuff merged into into gu um so hopefully Barnabas just asked how is the rebase going well it's painful as expected but yeah uh the field costs are exactly that uh we are trying to implement them directly on master so that we don't have to rebase uh well to go through very very painful rebay so yeah that's what we'll be doing in the

next few weeks uh I think I can go next uh so from NE mind side uh for the test that we have everything implemented and I'm just waiting for test trors from GM so we can test like if uh the things that get generates can NE mind also process them as expected and apart from that we've been working on a few cryptography improvements and uh a major refactor to implement the transtion so might be able to implement a test transition in like next few weeks yeah I can go next uh so in the bizu

team we are working with Toma we are trying to modify how we are saving data in the database because we want to try to implement a flat DB uh based on the stem of the tree uh so we are investigating this part uh we have also a new guy and this new guy will work on the gas cost implementation of bzu uh so if you want to contact him it's Lis Pinto and um we have also Gary that will continue to work on the transition so uh for the moment I don't think bzu is ready um to is ready to join the new

devet because we didn't implemented everything on the gas cost but uh I hope soon we will be ready uh I just wanted to ask a question G do you think it will be able to have at the beginning of the devet uh one transaction per block and each transaction testing a specific part of the gas cost or something else I think it will be more simple to to deel have only one transaction with a specific use case at the beginning after uh after we can have more complex block but just at the beginning I think it will be nice well so this is exactly where we want to have the the test uh one block

with very few specific transactions testing one specific uh specific aspect of it so normally when you join the test net you already went through all this testing so you wouldn't have a lot of uh very difficult debugging anymore uh I mean okay you will probably still have a lot of difficult debugging but at least the the basic stuff will be covered um yeah I guess we would have to ask Barnabas or pay if he's here but I don't see a problem creating sending like regular targeted transaction but like I said we've got a test framework for that now yeah yeah okay okay if you have the framework it will not be a problem but just if the framework is not completely ready it

will be nice to have a this uh this fallback yeah I can give the update so we should be ready with all the gas costs that were discussed in Kenya would be great to have these test vectors that we can test before the actual test FL and yeah as Karen was saying I think individual like gas changes are bestest as standal factors rather than itself yeah that's it our side uh so from Aragon I was working on

getting up to speed With The Changes uh up to the last devet which is devet 6 I wanted to ask if uh the devet 6 is still up and running before devet 7 comes up because uh the all the changes I've done I have no way to test it because I'm not getting any peers uh we should check but it should be running um yeah I think uh if I go for something like a folon or Dora it's there but I think when I try to Ping any of those uh list of boot notes I don't

get any replies to pings I have tried various uh tws and vpns perhaps those are closed off for some reason I don't know anyways give me 2 minutes sure you can update it element or something um yeah so when the tests are available uh I can start implementing the next incremental set of gas CH gas cost changes for devet uh 7 as well thank you sweet any other updates client teams or

testing set I can uh quickly on the testing side just um I pinged in the Discord we have our latest uh fixture release in the verle tree migration e&d Channel um yeah I think uh ignasi was going to go over some some of the testing stuff but I can jump in after ignasio if there's anything else to cover awesome thanks sper cool if no other updates then we can move on to agenda item two okay cool uh ignasio and an update

on the test framework stuff um yeah let me share my screen um can you see it yes okay um yeah so I want you to give an overall update of the state of foral trees tests um this has been this has been work in the last weeks um I want to thank Spencer for taking some time or being making making a lot of fixes in the testing um Library I know that the testing team has a lot of work to do

regarding Petra so yeah just wanted to to mention that um the situation today is that uh if you want to look at any kind of what is happening on the vectors for verl um you should see the Burl SL main branch in the execution spec test repo uh so all the action uh around veral test is happening here um if you want to look at the existing tests um regarding bural you can see them in the test SL Bal folder so um yeah I like all these test

that I wrote um are like separating by eips so you can maybe explore them a bit later um if you want to look at some examples for e6800 uh you can just like take a look at for example this called chuning tests that I wrote um so the idea here is that I think I did a pretty decent coverage of these eips [Music] um um of course like anyone is invited to really see this in more detail and add more test cases or uh things like that but I wouldn't say that's very much

um useful now apart from running whatever exists maybe like in some months people can review this in more detail or more test cases um yeah there are like some 4762 tests I separated them in usually by instructions uh so if you are if you know about the IP you will I think that this organization will make sense um again you can take a look at um any particular test and hopefully also will make sense and um some minutes ago

Spencer uh created a new release so um yeah you can see a bit more detail about what happened here um but in the assets you can see this um two talls one is called um veral conversion fixtures let's say and the other veral Genesis fixtures I will explain a bit more what uh these fixtures are about uh but there are already fixtures that you can run today so that's mainly from the execution spec test repo side from the get bural Fork side uh we had

to do many changes um both for um filling the tests and for consuming the consum consumption of tests so for test consumption I mean the changes are't really that complicated apart from what you might machine um like uh having like a new fork in your configuration that is called bural and just filling the pre-state in a bural tree instead of a Mer partia tree and things like that which is pretty obvious for the filling of tests that's a bit more convoluted mainly because the execution spec repo doesn't have a pure python

implementation of perries and some of the cryptography so we had to create some new um let's say CLI help such that the testing Library have to call this new CLI commands uh to do some kind of uh like Tre generation and things like that it isn't like the end of the world if you want to allow your e client to fill tests but it can be a bit confusing and maybe in some months it can be much simpler so I won't go into much uh detail about

that'ss we also have a new oci pipeline in um in G where now for each PR that we do we fill and consume the tests um I I left the link here if you want to look at this later because some of you might want to do the same for all real clients uh here we have like the job for filling tests um for consuming the tests um this has been pretty useful um also on each PR this workflow also uploads the um generated

fixtures so you can you can use like the fixtures from the release in the execution spec test repo which let's call them like stable fixtures but for some weeks it might be probable that we will be fixing many things in G so maybe you will be more interested in these uploaded fixtures on each PR that we do or if you were more like bleeding edge fixtures um so yeah so the the way that the C this CI works now is basically tests uh and consuming them uh and just

checking that on each PR or Branch this isn't broken I'm doing some kind of let's call it Branch Self coherency because it's pretty obvious that on hbr you should be able to feel and consume those tests what is a bit more interesting and we will try doing soon is also running test from stable fixtures because it doesn't make much sense to only run test that you feel on the same Branch um but that can be tricky for some weeks because we might be doing fixes and those stable fixtures might be wrong so yeah uh this is something that pretty common maybe when you are

starting um but yeah this I just wanted to make this distinction about one thing is catching regressions by running test from stable fixtures we usually you will pull from and other thing is kind of testing self- coherency so regarding fixtures that exist today here's like a quick summary uh I will separate them in two big groups what we call bural Genesis which is basically saying these are test where the pre-state and the block execution happens only in a burgle tree so it's

kind of a post conversion world uh so for this setup we have all these um veral related EIP T vectors that I showed earlier which are around 161 um fixures and we also uh were able to kind of backfill or re existing tests let's say a test from Shanghai uh but run on veral Fork so there are a lot of already existing tests that are also run in only like in a workot tree so that's pretty

interesting I mean despite these tests aren specifically targeting like the new mechanics of some parts of bural um we might still catch bugs um by running them on a Barco tree uh so these are like many more tests um and the other big group is the overlay tree test vectors uh which I don't know if many y clients have this already uh and this basically means running tests under the setup of having the pre-state in a frozen MPT and doing the block execution in a

veral tree right this is the stage of the fork in which we we freeze the MPT we run blocks in the veral trep but we haven't started the at the conversion so that's a whole like complete different setup which is basically testing this overlay tree where you might you have to read new data from the burco tree but if it isn't there you have to go to the mer Patricia tree so there are a lot of things that got can go wrong there so for this seta we have like a really simple um multiblock test uh that's pretty kind of dummy but we also could backfill all existing test so this is like the same

back feeling from here but the difference is that all the pre-state of existing tests are in the Frozen MPT and whatever happens in the block execution happens in the burkot tree so um yeah that might catch other kind of bugs uh and we get this like for free in the sense of back filling already existing tests and another thing that um we do in the CI is fing and consuming test from previous Forks which is basically just to check that the client can still feel let's say a a test from shahai and consume it on that

fork so um yeah all these veral changes haven't really broken executing blocks pre C code so regarding next steps um from the execution spec test Library side uh we want to finish supporting what we call witness assertions this is a new construction whenever you write tests in where you can do something similar to post State assertions just uh so the idea is like as a test writer you can assert that the erated witness in the fing as whatever you

expect uh for your test intentions so similar to The Post States um and we have to fix some needs about the generated fixtures having the post State output which is usually useful for debugging the test um apart from sh like checking the state route right so what I would just suggest as a way to go to devet 7 is kind of having people running these fixtures and gaining confidence that we are agreeing on like stuff before we launch it and I

would say would be useful to go in some steps the first one that I would suggest is only running the fixtures related to 6800 which are around 23 fixtures this already cover a lot of things on the like ver tree workings like all these changes that we did for basic data encoding in a single leaf and things like that um then we can jump into running all these Back Field tests um which are that many more uh after we have this witness assertions working I would invite people

to run all the 4762 tests uh I I want to wait for this mainly because until I have this we have this ready I'm not like 100% sure that the test that I wrote are actually like satisfying what I intended to test and also these witness assertions will actually catch any gu back um so yeah um and these are like more like 100 fixtures but to be honest like if you are greedy you can like run everything like c00 fixtures but this might be a bit noisy uh but in any case it will be

testing that whatever other clients are doing matches whatever G is doing so there's like no harm actually in running everything and yeah just see what happens right but um I kind of suggest going these steps just to be a bit more have a a better like signal to nose ratio of um yeah and yeah another next step is basically implementing um new test vectors for State conversion so a while ago okay so some weeks ago um I created the CIP where I kind of

describe all this state conversion with the overlay tree that we have chat about for many a long time um I had this hgmd dock where I did a high level description of all the testing cases that will be useful for the CIP which is like not entirely trivial so the idea is that yeah I will be implementing all these tests um so we can also have state conversion test vectors for for later if other clients are planning to implement that which like State conversion is something we have to do uh whatever

happens with like whatever Target uh tree structure we use being veral or binary or whatever so uh this is like 90% uh work that will be useful in the future for sure um and yeah that's it I know if Spencer want to add something else um that's all from my side I think that that was perfect for my site um I just add that if anyone needs help consuming the tests just uh send me message so I know gu is

consuming the test using their evm block test commands I'm not entirely sure how other clients consume tests specifically but if you guys run into issues with that just let me know um on the execution spec test size we we do have a alternative way to run the tests um within Hive um using block rlp so if you wanted just a standalone way to run the test immediately and we can help you with that as well thank you ignasio and Spencer it's

good stuff cool if nothing else on that topic up next on the agenda uh it was suggested that we do a quick sort of up update or sorry more of like a sort of uh status check to see where teams are in terms of gas cost updates uh some of the stuff that we discussed in Iota and just sort of seeing a doing a test net Readiness check kind of I don't know if um folks want to just post in the chat where we are or anyone wants to chime in Gom or anyone else has any thoughts on this um yeah we're um we're getting ready

we're like I said there was this uh cryosis issue that we couldn't test um test Nets that start at veral Genesis um but we're going to fix this uh with uh with devops like this week I suppose so as far as we know we're ready but of course the only way we know for sure is if other clients agree with us uh NE mind is also ready for the test we have implemented I think I think we have implemented yeah said we still have some

modification the so I hope we will be able to to do that more quickly thanks to the framework yeah I was talking there with my mic muted uh yeah what Kim said we're working through the implementation at the moment uh of the gas costs so cool uh so I guess on the air side still a work in progress as well and ejs same uh I think Gabriel should be able

to update our progress can you repeat the question sorry did you say something Gabriel can you repeat the question oh yeah sorry just seeing where uh each team is on updating latest gas cost schedule yeah so we are we should be up to date but we haven't uh implemented the Des vectors so once we do that be confident cool okay great all

right sounds like we're getting there if nothing else then yeah we can move on to the last agenda item uh which is Gom giving um sort of an overview there's been lots of discussions or some discussion at least recently that I'm sure everyone has seen around just sort of the various paths that we can take and some folks feeling like maybe there should be more of a push towards binary trees versus veral uh and so just wanted to share some thoughts as we several people have been sort of um having those conversations and just evaluating and rehashing old

conversations and Gom of course was an author on the original binary tree EIP so yeah I guess I'll just hand it over to you you thanks um yeah so I do have a presentation that some of you have already seen or at least uh you've seen the older version of this presentation can I uh share my screen uh apparently not let me try again it's always like this um yeah okay um right can you see my screen yes okay cool yeah so the the Bas team has

already seen that but yeah there's been a couple updates that they might still be interested in uh so like like Josh said we've uh like there was an ACD two weeks ago where people were asking um if it made sense to to keep working on veral if we shouldn't go to the next uh the next technology um this is really uh I mean clearly uh I am convinced that the answer is yes it makes sense to to work on veral but um yeah I would like to share some of the elements that we base our ining on um so can I change slides from no I have to change Windows okay uh so as a starting point I want to remind everyone

that uh there was a like The Verge includes a lot of steps veral trees are really the first step it has always been planned to to do something else afterwards um starking snarking and then starking ethereum so that could be a lot of uh a lot of um there are lots of ways to do this um clearly there has been a lot of progress on Stark front recently um this being said uh there's still a lot of advantages that uh that veral uh veral still have over binary hashes um the first one and I I would say in my view the the main one is that

it stops uh or it slows down the the state of the s the growth of the state um because not only uh don't you not only do you not need to store every single hash in the tree thanks to the homomorphic properties of of polinomial commitments but on top of that uh you do not um yeah you you can reduce the arity of the tree so you have a a smaller tree a tree that is wider but shallower and since you don't need to store every sibling um like sibling hash you're saving quite a lot of data so that's that's I would say the

advantage that uh that other proposals don't really uh don't really uh compete with um and then there's of course the the compatibility with h with snars which might or might not be an advantage depending on how fast each side of the of the ZK World develops the fastest and uh there's uh this proposal by hand that was made two like two acds ago uh based on state expiry and the advantage of of his proposal is that it really fits it fits really well into into the veral model so if we want to implement State expiry which is also a way to uh to slow

down state growth or at least to to deal with State growth uh there's a pretty much readymade proposal for this uh which others don't really have um but yeah the other the other big advantage of uh of verical trees are uh hashing sorry are proof the the proofs proof size if you have uh so I'm taking those numbers from some presentation that D made uh so this is my source but you have about half a megabyte of uh fixed Pro size and then you need to pass the witness and with veral we have actual numbers of Replay uh that you might have seen in the

previous Vic and witness plus proof are depending on the encoding method we choose just uh above above 400 and 400 kilobytes on average to uh just under 400 kilobytes on average so this is uh this is really uh where vertical shines and this is really where the the strength of rle is because these are proofs that you can not sorry that you can reuse unlike uh for example if you just knock the whole block execution yes you know the block execution is correct but uh there's nothing else you can do with that um now on the other the other side of the coin is that um in in veral the

hashing and the commitment computation are pretty are pretty slow compared to regular arithmetic ashes um the the quantum resistance aspect has gotten a lot of uh a lot of uh attention recently um so clearly uh everything that is based on elliptic cryptography is going to be broken um and uh apparently because I'm not a stark expert but uh apparently it plays better with with Starks um so yeah that's uh that's basically the the choice we have um up to some uh

extra piece of information that we that we'll talk about at the end but um yeah the question is what if you if you look at uh the amount of work you have to do to switch to Binary tries um what would you have to do well the design and there's been some conversation with the research team the EF research team about what we want is to keep those two things both vertical and binary trees as compatible as possible so what we would change is of course the proof system we would be using mle proofs or some kind of ZK proof that that does that and we would be using we would be getting rid of uh polinomial commitments replacing them by hashes and uh key computation

also getting rid of person hashes and using some type of arithmetic hash but um most of it won't change uh because most of those changes are actually uh targeting or at least designed to to uh to bring about statelessness they're not veral related so the gas cost um that disincentivize growing the block size or the the the blocks witness size these will remain because we don't want to to grow the size of the block The Single Tree structure is the same thing it's meant to to simplify the proof to to make it to to make it a bit smaller so there's

no reason to change that so that would be a single uh a unique binary tree instead of a unique veral tree and in fact that was already the case in 3102 which is the binary the initial binary tree proposal uh so this is uh most of that stuff is actually older than veral the conversion itself uh would remain because you would have to rehash first you're merging a lot of trees in to a single one and on top of that you are changing potentially the the hashing method so you would have to rehash the whole tree so preimage distribution tree conversion all of that remains and in fact uh all of that has been is also preceding veral trees the conversion

like the overlay method was proposed uh EIP 2584 if I'm not mistaken was proposed to um to perform the the the conversion from from MPT to a binary tree and then the sync so uh in my view it's pretty much the same because it's only dependent on the structure of the tree uh Tanish might disagree on that and he's the one that has worked on the topic the most so uh I'm happy to to hear a dissenting voice but from what I can tell it's going to be pretty much the same thing um right so uh I'm adding some information What would the what would the you know the the structure of the

tree look like well basically uh instead of being nodes of WID 256 you you have a binary tree uh you would still get the value so because the binary tree tends to expand hence the the incre the increase in in size um I have to put a lot of dots to to yeah to to make the everything fit into one picture but uh every time you see three dots means there's an an entire sub tree there and um and what happens is that you would get the 256 values that you hash that you hash over and over um you get the top of the suffix tree you hash it in with the stem and the and the leaf Mark

sorry and the and the sub tree marker exactly what we do in uh in vertical trees right now um and that would be your structure so the the hashing method is a bit uh is a bit different uh it's not just a bu binary hash but it's pretty much the same idea and uh and yeah so the structure is the same you still get the 256 56 groups you still get the opening uh like the cost for opening a group the cost for accessing an individual Leaf uh the non- deltion of leaves etc etc everything is same um now uh yeah the question is uh how do we make it future proof well

clear Starks uh recently have uh have been good at uh have been good at hashing uh Quantum resistance has been a question recently uh but there's still um a lot of issues so uh for example Star Security is conjectured I got some push back from from nethermind on this but uh from what I understand this is the case or more exactly this is the case as long as you want to keep the the proofs small enough um the performance has improved but it's still not there we can't imagine every single validator building their own uh Stark proof within the 4 seconds uh they they

have to build a block so um we might need to change like this would entail a lot of changes in the in the whole ethereum model not just the storage tree model if we if we decided to to get rid of this requirement um and we we could also can't rule out that snarks uh snarks could uh potentially get much faster as well in which case there's no clearcut path anymore uh and when it comes to Quantum resistance so the NSA has Rec I'm saying recently but uh not too long ago they created a u a recommendation a new version of uh their I forgot what they call it the

cnsa what it stands for but it's basically their recommendations for the cryptographic toolbox that every everybody should have um and you can see that for example um they themselves don't expect much to or at least they want uh forw signing like everything that is going to be Hardware um that has to be ready before everything else uh to be ready by 2030 and um everything that is more like software to be ready by 20 33 uh so there's really no rush uh in my view to to try to fix Quantum resistance

in the state right away because even when Quantum resistance is um Quantum resistance becomes a real problem uh people are going to attack Communications they're going to attack a lot of things before they attack the they attack the state itself so it's not like every everybody's going to have a quantum computer by 2033 it's more like very big companies that have better things or better interest than then hacking the etherum state uh will uh will start will start creating those uh will start using them but um yeah like I said there's no of course there can always be a surprise Discovery tomorrow

but from where we can see uh there's plenty of time to to work on uh on Quantum resistance and getting it right um and then uh yeah then alternatively just rushing and and get potentially getting it wrong so there was something that was uh missing from the initial presentation that has been once again thanks to Nether M for pointing this out um it would be to create some kind of veral uh veral equivalent using something called Ash hash which is uh Quantum resistant um so I had a talk with goti so I hope I'm not saying anything stupid

otherwise please correct me goody but um it's called it not Ash okay that's a start thank you um so IAI hash um so yeah it's uh it looks a lot like the cryptography we currently have in veral except it's not using elliptic curves um so it's using ltis based cryptography which which is quantum resistance um it still has the property of homomorphism which I was talking about at the beginning of the of the presentation which are really desirable for State growth or to stem State growth uh supposedly faster computation although yeah goatee told me to check

some stuff so I I don't know for sure um but the yeah the big problem is their the size of their commitment so uh quoting my conversation with good that's between the commitments each commitment would be maybe 2 kilobytes maybe 8 kilobytes um so that's way too much and that would completely destroy the benefit of having having um improve computation like faster computation because you have to store this in the database and that would kill performance um yeah but nonetheless I think that's an interesting uh point to to to uh study and maybe maybe in the

end we we get it hash instead of elliptic curves um but yeah so as a summary um there's a lot of very desirable properties that we can have now and uh I like to say done is better than perfect um even if we switch to Binary chice today uh we will get the exact same issues that people don't like the change cost the conversion everything um we are also in a period where a lot of discoveries are made so it might make make sense to wait before changing before finding the perfect technology but until we do uh we have something that works it's veral trees

and uh in case we do find the perfect technology by next year because uh those uh those two structures have been designed to to be um fairly similar we it's not unrealistic to do a last minute swap of The cryptographic Primitives because that's the only thing changes and uh yeah so that's from what I understand Quantum yes Quantum could uh could happen tomorrow but most likely not and I think there's no reason to panic and it's not a good reason to to change uh the Primitive right now especially when it's so easy to change it well so easy relatively easy to change it in the future uh yep that's pretty much it for the presentation but

the point was also to figure out if people have questions people have worries so yeah we hope to answer those uh yes Gotti yeah just a quick comment I wanted to sort of add to this kind of tldr I mean I'm not sure about this um MSA or this government sign that you have sort of um shown regarding sort of the timeline for the Post Quantum transition I mean I mean first of all this is a bit of outdated data I mean G given probably I mean I don't know from when this is um

probably it's from before 2022 I mean just from the just from this and you have all have to be aware that these kind of transition timelines are sort of not just taking into account what needs to be done but also um sort of what can be done it's more directed to towards a bit slower changing users um I'm of course not an expert in quantum computers and I don't have I'm not a clairvoyant knowing when quantum computers will actually arrive but just to inform you we've had an interesting talk with um Scott arenson um last week um sort of basically the Godfather of quantum Computing in some sense about sort of his estimates and so on and it seems that a lot of people in the area

are estimating that F consumers are arriving potentially are arriving much earlier than was previously anticipated so at 20 mean this 2030 I mean this is the timeline for actually changing not the timeline for actually emergence of I don't know quantum computers in the hands of a few and given this kind of information I think this is I would feel uncomfortable with with the with 2030 as a Tim I mean as you said on your last slide already I mean we can always change and so on but just saying that this is way ahead and we still have at least 10 years time is not a stance I would comfortably defend

anymore uh I didn't get quite get your last sentence oh well I mean the question is really how much time do we have for sort of to get sort of um to transition to postquantum secure schemes and sort of the CNS any timeline is sort of suggesting that yeah we comfortably have like at least 10 years time to make every change in order and do it in orderly and and fashion and so on of course this is a bit of a prediction that is hard to sort of know know that hard to really know but um given what sort of happened the speed by which things have picked up by which is mostly improvements in the Fidelity of actual Quantum systems not much size but rather the Fidelity of the cubits um from sort of the benefits of the the gains that

have been made in a last couple of years and also some kind of what sort of result the experts seem to think then I mean we could actually have a quantum computer by that time frame that by the tooth by 2033 let's put it like this if everything proceeds and the the if the key um indicators are proceeding at the same speed as they have before and they have actually progressed kind of linearly is and then we would actually have a quantum computer by 203 just to point by 203 2033 we would actually have a final computer problem if everything

progresses continuously linearly in the measured as measured by some key performance indicators for this we would actually get them by this time not not sure this is an accurate prediction but just to make a bit of a warning that I think the NSA timeline is a bit optimistic um yeah so I was in that presentation too by the way um that's not I mean I I I I heard what he said um there was a lot of caveats in that uh in that presentation um he was also insisting on the fidelity thing uh the aspect because uh people keep for example talking about having thousands of cubits but uh they

are so extremely unreliable and he he insisted on the fact that uh you needed to ensure uh yeah basically that they could remain uh in the in the state you want them to to remain for a long time which is what they're struggling with um and so currently they batch cubits together um I read a bit more on things so once again it's just me reading U so far the shore algorithm uh the biggest number has been factorized by the shore algorithm is 21 yeah but that's that's misleading that's kind of misleading because um the point with this kind of looking at

Fidelity is just quantum computer that once you reach a certain threshold about certain Fidelity threshold what you can sort of do is you can actually um start using Quantum error correction and this Quantum error correction really has a threshold once you hit a certain threshold you can pretty much do anything right right um yeah but okay my that you can only Factor the number at the not 21 or whatever that that's kind of not really telling you sort of what's the biggest number that can be factor is kind of not really informative for this kind of decision you need to take well I mean the what it tells you is that it's very hard to uh to factor bigger numbers and um yeah like apparently okay so I

write some numbers I can find a source for you if you want they were saying you would need to be able to have uh 20 20 million cubits to be able to use error Corrections and everything in such a way that this breaks to 248 bits I say that's that's okay I'll find the source I'll share it with you yeah um just just two things first of all we we're not trying to break RSA we want to break elliptic curves which is easier right um secondly the number of cubits you need um sort of depending on the quantum on the on the error from the quantum error correction so actually depend on the Fidelity so that that number sort of that blowup number actually depends on the Fidelity that you start MH yeah I agreed um I mean maybe I I just interpret it completely

differently but in my view that's the big question I don't think it's that optimistic but just to answer the question about the the cnsa timeline this is the recommendation so that's true I don't know where it comes from uh but it hasn't been updated that's for sure um and this is the recommendation that the NSA does to American administrations and companies to make sure that by 20 2023 they will be Quantum secure so clearly they don't expect uh something sooner than this uh of course them sorry or the NFA is the only ones having them right or even worse they they know it will never it can never work the quantum computer but they know

they can break ltis based cryptography and therefore they want to everybody to start using it because yeah we don't know for sure that's um but yeah okay fair enough uh fair enough point I I guess just to summarize and because we only have a few minutes left obviously this is an important conversation it's a very big and complex conversation around Quantum timelines um and I guess maybe to summarize or sort of try to frame the question correctly in my mind I think it's mostly around like by what date should we have the protocol generally not just State not just sort of veral but what date should we have the protocol generally Quantum resistant

I don't know got if you disagree with that sort of framing but I I think to me it's first like okay what is that of course we cannot predict the future but what is that date um and then working backwards from there we can use that date to inform the question of veral and whether or not veral is still viable how many years do we need to what what is the minimum life span of veral for it to make sense to ship I mean the question is I mean that's that's one way of phrasing it I'm not sure whe it's the right one because I mean you can also ask sort of for the question about um what would be the minimum timeline for us to actually transition away from ver I mean if we

went to verle how long would it take us to sort of to shift from veral to I don't know to change it and what how much work is it also to change from veral say we Shi verle right right but but we can work backwards we can figure out all those things once we have sort of if we can come to some kind of agreement internally I mean this is maybe a conversation for ACD um I guess maybe I would say this's a separate conversation around Quantum timelines that we should that maybe we should bring back to ACD now that we can't discuss it here of course but um and just like a broader conversation around Quantum that we should have I think as a community and core developers researchers every everybody someone else wanted to have

say something yeah yeah sorry I think Mikel Mel did you have your hand rais sorry about that uh yes uh yeah thanks for the the presentation you you mentioned I that iai's commitments are are just too large uh could you give some number such that you know the the size of the commitment would need to fall below that number to be acceptable in size um that's a good question but it's roughly 64 bytes um anything bigger than this we're going to have to do database performance to figure out where the cutting point is we know that 32 bytes 64 bytes is fine uh we know that 8 kilobytes is not fine at all because

this this used to be the size of a node of a veral node um so somewhere in between there's a cut off but uh yeah I could I could try to Benchmark this and give you a proper answer but yeah the target would be 64 bytes at most thanks a lot just question how how much does this depend on the a or any kind of other um computation or nothing because I mean what the question is of course also what kind of nodes how many internal nodes you would have to store right you or can you say something about that yeah so the the two things that kill performance are on the one hand how much data you write

per uh node and uh how much you jump around the dis so if you increase the aity and you don't store uh all the associated commitments uh you just stored the sorry you just stor the the commitment to a node but not the commitment to every single child which is what homomorphism lets you do which is great uh but yeah so the the more data you've write the more the database will churn basically uh it needs to unpack like it's it's built as a tree itself so it needs to unpack a tree make room Shuffle stuff around it's it's very uh poor performance um and uh yeah so if you increase the rity and you don't store the data you can afford

to make the commitments a bit bigger but not like 8 kilobytes bigger because 8 kilobytes this is what we used to write and that was destroying performance okay well we are at time any last thoughts before we break okay cool thanks everybody see you next time yep thanks bye yeah thank you