Verkle Implementers Call #7

Transcript

okay uh welcome everybody to veral implementers call number seven we have a solid but not huge agenda today I have shared it in the chat um if anyone has anything that I neglected to add please feel free to drop it in the chat and we are starting off with an update from Gom on the test net on Cal g yep thanks uh absolutely so finally uh we were able to relaunch the test net um I'm going to share my uh window to my screen to uh show the landing page so

yeah it's at keltin testet not it used to be kelin but now it's kelin D test net and uh you you well there's been a few changes so the first one is uh that uh we now have a block Explorer so it's not um it's not veral specific it does say Electra though but it's uh it doesn't show anything really uh really veral specific so that's still work in progress but at least we're very happy to have it because we can follow the what's going on a bit better um there's uh still the RPC of course uh we have a faet we have the fork mons So currently

the only um the only consensus client is uh is loar but uh Mac from Lighthouse wrote us this morning that he was ready to go so it's only a matter of taking the time to to roll roll out some Lighthouse notes and we should be uh we should be good to go but the thing has been really stable um it was was uh so initially we were planning to do uh to have a couple Epoch of MPT and then perform the transition but that was not uh that would mean that only the client that implemented the transition which is gu

could join it so the the goal is to also have nether mind test the sync uh so we decided to to go back and change change that to uh to a client that does the The Verge at uh well technically there's no conversion it starts with with a Genesis with a veral block like veral tree at Genesis and uh yeah uh a few other changes uh so we now have the the post state in the in the blog uh We've there was a misunderstanding of what uh the postage should contain so with Le at least I thought that uh that the proof should contain both the pre-state values

and the postate values but uh it's actually not the case it's only the witness that contains the postate values so I mean there will be there's an an agenda itemp to to get a bit deeper into this but yeah so currently the proof that are being provided on on Cen are not exactly the the right format so that means we will restart it uh but currently it's good enough that we can we can try getting all the all the the Els and the CLS we know are working to to see if they can this discuss and then when we have everything um working out we we will relaunch it so that should be uh I don't know maybe next week maybe in a couple weeks uh yeah one thing that I should mention also is that for whatever

reason takes first doesn't work so I have my own uh fuzzer that SS very simple transaction it's not as comprehensive as uh as T fuzz but yeah we tested that deploying contracts work uh that we we've been sending a lot of transactions we tested withdrawals that's another uh new feature of that test net I don't know if we can see the withdrawals here if we look at the latest U I don't know some block um yeah it's got to be in the slot of course uh withdrawals yeah there were three withdrawals right here so the withdrawals because the traffic is not so uh intense the the amount that is

being displayed is is pretty uh like is almost zero it's it's not zero it just looks like it's zero because the values are extremely small but uh yeah overall quite happy with that so still a lot of work to do but um but yeah if U at least at least we go somewhere so I right and uh when it comes to what's what's happening next uh I think we're going to launch another test net to perform the transition so a dedicated test net as a first step towards the Shadow fork and uh otherwise uh yeah we if if uh people need we we might also create a test net without proofs um it could be

useful because at least G is going to slowly merge the content of of that Branch into into main net but what uh like the first step they want is to only have enough uh features to join just join the test a test net that doesn't produce proof something simple that they can review and when they they're done with that uh they will start merging all the proof stuff but uh yeah so it would make sense to have a simpler test net but currently ctin works great for for most applications so hopefully um other clients can join but we'll see that during the client updates I'm sure and yeah that's pretty much it for the for

the presentation great uh so yes client updates actually GM do you want to continue and and give a quick update for GU uh yeah actually basically that was my update uh cal cal working all those new features otherwise just working on like I said trying to merge some PRS into um into gu uh like Mainline gu and then um yeah like we we've got some discussions with in asio so we keep the optimization SL compatibility

work awesome anybody else want to give an update next I think I can go next just a second uh yeah so NE mind also join the question Des initially there were some issues uh we were like failing to process some blocks during some like basically after 3 4 hours but now uh it's been stable for last 5 six days so I think everything seems to be working now uh I didn't get around to test the sync part yet I think the server should be working but yeah I didn't get around to testing the syncing yet but yeah I'll

try to uh get to it as soon as possible I'm just busy with some other things right now uh and yeah I think that's it so Tanish can we integrate uh nether Minds working in uh lotar quick start uh yeah I think we can because the client is now stable I tried restarting and everything and it seems to be working yeah I think we can we can add another mind to the quick start right so uh only uh the image would change or are there some arguments that are extra needed uh no I I'll send you the details because

there are some arguments for if you want to enable proofs verify proofs while processing and like multiple things that I need for testing but just for simple uh things I don't think so we'll need anything else I'll just send you the image uh tan do we also have the option to have a light note without State uh not with the configuration right now I have to change a few things like uh like I have another Branch where it works but it's hardcoded I'll just add a few configuration and uh we can work with that okay that also would be like a bit interesting potentially for people to

test yeah I I'll I'll create a configuration for that and then probably send both of the instructions to yeah um yeah I just wanted to mention something about ctin and um and Shing documents um I sh this in the chat so I'm taking Tak advantage of now cust and running for getting some metrics

about how things are working uh so I won't go into details about this document uh you can read this data if you're interested but um I I have like a modified G that is collecting some information and I will be updating this do once in a while because uh I was interested in seeing things like uh the average depth of the state tree considering how many key values we have on it and just to have some s checks about some expectations considering the design of the tree um also we have been talking about for a while about proof sizes so another

report there is uh the witness size uh for each block um and I do some deaggregation of how much of the size comes from the state def so the pre values and the post values and how much comes from the cryptographic proof um just to get some better understanding on um like real proof sizes from like some reality in quotes ch um and then I also collect some metrics regarding uh proof generation and verification times um this is a bit experimental in the sense that we don't have much

loading cment yet so like this witness sizes and proof generation times and proof verification times that a bit um you know not that meaningful but um whenever we have more more load or the state is bigger or things like that uh at least we can have some more real numbers um so yeah I will be updating this do I know maybe once per week or something like that and maybe we can start concluding some some stuff regarding all this um yeah just that anyone else would like to share an

update toas do you want to share something or I can yeah I can on b side uh we are working on some libraries so we are trying to implement the Java implementation of verel tre we are also moving forward on the cryptographic stuff in order to generate the r a valid State rout uh when these libraries will be available uh we want to integrate this Library into Bonsai in bzu so I hope that maybe next week we will start this work and at the same time we will also start to do the modification to be

able to join the test net so I don't know when we will be ready to join the test net but uh yes we will start some integration into bizu maybe next week or something that yes uh just just to to to complement um what Kum said uh there there's a yeah there's a little bit of uh there's one or two bugs left uh to to get uh the the specs right for the um for the rolling up the commitments so it's a it's it's just a a matter of of of that concerning the that but uh as Ken said there's a there's there's the

also the extra um feature of integrating with with Bonsai which is something that's uh that's some something to my to my knowledge is new so that's an interesting part also uh with this uh with this client so um but yeah hopefully we can start joining the testnet like Kim said next week and and hopefully also getting the uh by then the the bugs fixed in terms of the the crypto the root hash uh just wanted to add that uh to

join the test net do we need proofs now or or not I didn't understand from the previous because we you do not need to if it's just about following the test net which would be a first good step you do not need to verify proofs you can just ignore it you need to be able to deserialize the proof or at least receive an execution engine payload that contains them and you can just ignore it so you do not need the proof to to do that okay because we have uh crypto Primitives ready and only crypto Primitives needed for for uh Computing the root hash and inserting key value is the pon hash for the try key and the pon

commitment for the commitment in the in the tree and we have that ready now it's only about constructing the tree and Computing the root HH and also what Thomas mentioned how to integrate this into Basu yeah but that's good enough we are making progress yeah nice uh I had a question regarding that so do you are are you still pursuing the rust route or are you just reimplementing everything locally like are you planning to uh when you do that integration work next week is it using r verle or not um

it's using rust uh not sure about rust veral but the the rust uh like the the libraries that r verle are using yes for the for the crypto and we'll continue using rust yes yeah it's basically we are just exposing the call to Pon both hash and the commitment it's a bit different but it's I mean it's the same thing but we are just taking the code from rust veral and exposing this to Java Java sends bytes rust receives bytes and process it turns it into field elements and computes the pedon commitment or hash and then serialize it

based on whether it's TR key or it's commitment in in the tree and then returns it and we just save bytes in in Java and the same thing we want to do with the proofs so we just need some time to understand how exactly it will be done because we don't want to create Bender wagon and uh bers snatch elliptic Curves in Java and actually idea that I had is uh because I don't know about other clients do they also want to do this way like ffi uh cryptographic Primitives because if they want it would be useful to create maybe a separate repo with these uh quote

unquote calls cryptographic calls to to to these Primitives so they can also do the same thing like just call the pson hash or just call the pson commitment or and in the end just call uh like the tree data which is needed to construct the proof like just following the kev's uh uh article about uh five calls that cry crypto API needs to exposed to the tree so yeah maybe I'll do that or next week at least for Pon has and Pon commitment because it's useful I don't think sorry I don't think there's anybody else that

wants to do that uh maybe maybe the JS but my understanding is that everybody else is not doing that okay then okay I mean uh you know I'm not telling you what to do I'm just saying if it's uh yeah if it's an effort that you're trying that you're doing just because you think other people are going to need this I don't see it at the moment maybe there is Maybe completely wrong uh but yeah just uh just for your information yeah just in my opinion it it takes a lot of time uh creating the curve testing the curve then bandwagon understanding what's the bandwagon it takes a lot of time I mean so but

okay right and regarding the wasm uh rapper is it up to date I don't remember Kev okay looks like we lost K can you can you hear me now yes um yeah I said it got modified about two weeks ago to um include the same API as go

IPA denish uh I just wanted to confirm like uh for Basu when you say that you implemented pison hash and pison commitment so while so when calculating the root of the tree and like when you insert something new so one thing that we can do is like we can just add the differences in the commitment and recalculate the state rot are you using that or are you recomputing the uh entire commitments again because I just want to ask did you basically did you implement the addition subtraction of the commitments also or just the uh hash and commitment functions I can answer that for now the um there's there's a it's on the it's on the in the issue board uh to do that optimization

of updating updating the the commitment hash um right now we are recomputing everything but a single time anyways we're just updating like every every we're not updating commitments um at every insertion uh we have to to trigger the uh updating the commitments anyways so but but it's in the issue board to actually do the uh uh that optimization I just just wanted to ask like what yeah so I just want to see that what kind of of performance hit that those kind of operations have on the ffi because I was using the rust work for nether implementation earlier and I faced some performance issues

that's why we decided to implement uh in our client so yeah that's why I just wanted to understand like how much of a performance it do we have on yeah yeah yeah that's a it's a good question it's a it's a good question but uh we're not there yet we are at the um at integration and then we'll do that kind of um optimizations afterwards sorry quick question did I understand that correctly tennish that when you have an ffi interface from from C you also have a huge like overhead I'll not say huge overhead but yeah like for basically the the so I did

that I think a year ago and and to basically pass the arguments to the functions over ffi we need to do some conversions and because of all those things uh the performance gain I was getting from using rust was not that much uh than implementing everything in C so that was the problem then but I didn't try it out recently and it might be possible that yeah I missed out on some optimizations so yeah that's also case right there's K K's question uh yeah if he was to doing a normalization in the sterilization that that would definitely have an impact yeah I don't remember that so

yeah might be the guess we didn't test the performance yet but at least doing something in understanding I think it will be then easier to reimplement everything in Java but for the first step I think we we should be fine with the rust jni from what I I know in general in bzo for cryptographic stuff we are using CA Library uh sometimes R libraries in general it's better but yeah as Dragon said we we didn't have time to test performance

with this library for the moment but so we really see anyone else like to give an update I think we might be missing let me see load star and nimbus uh yeah so I can uh uh talk about imas so on our side there is a good progress

uh we've done substantial work on the on the match Primitives uh so credits to to ad andish that have been really focusing on that uh and so in the new world we have a library called the uh which has been around for a while and B man uh developed most of it so we extended that library with the PRI we needed for B wagon um so we uh the rough development is done uh now we're in the process of taking that library and integrating it into the N

PL um so I guess that hopefully with something like a two or three few weeks away from seeing the first root commitment being computed correctly uh we are still a bit like farther off from joining the test net I guess that will take uh like a good two or three months from now uh but like seeing commitments work I think we're about like two or three weeks away so that's it from our side okay uh yeah last call for anyone

else if not we can move on okay uh the next agenda topic was uh guom I believe you wanted to have a conversation on this topic of per block versus per slot during the conversion yeah so that that came up I think last time or maybe the time before um and I was trying to look for the conversation because I I remember after after NCC where I discussed the topic with denr um we yeah I I announced what the the solution was but I haven't been able to find the exact moment uh so yeah I uh

I need to to C but uh regardless of that uh yeah I think the the decision should be made whether we want to go for uh doing the conversion like end values per slot or if we want to convert values per block my current favorite model is that we convert per block because in the case of a reorg we would have to uh to reexecute every block uh like the the conversion copy n not n values per block that we have to reexecute during the reorg and

less difficult than uh um at least that's less comp comput computationally intensive than doing it per slot um the problem with this approach is that it um it makes the uh what's it called the like if a lot of reorgs happen it will delay the conversion by this much so let's say half the slots get missed the conversion lasts twice as long twice as long uh of course if half the half the slots were missed that would mean the network has a has a huge problem but um yeah let's say if onethird of the slots get

missed we we would take one one week longer or sorry not not a week longer a um uh Yes actually and um so um so yeah that's uh that's the problem of of doing it per block uh the advantage of doing it per slot is that all the problems I mentioned just now would not happen but if you have a uh big um a big reorg you the notes that reorg will have a significant amount of work to do before they can join the new the branch they they reor to and that could still be uh that could still be

okay I think it would actually be possible to save the amount of conversion that was done at least in gu where we have this layer system we could save it at every layer and is so if we need to unstack the conversion we could uh we could save it so that when we redo it uh it's possible I mean this optimization can be used either in the case of slot or blocks uh but yeah my my preference right now still would be with blocks uh so doing n values per block I wonder what you guys are are thinking like if if there are any opinions um but yeah that's uh that's one decision we we

should try to make it if possible before the end of the year I think on b side I think uh didn't had time to to look at this part uh a lot but from what I understood I think per block it's better uh regarding how Bonsai it's working so for the moment my preference will go to p blockish w do you have any opinion on

that uh I think last time also we discussed that if we do per slot I think we'll need some information from the uh that's actually not quite true because you could just look at the Tim stamp oh okay yeah from sometimes time we can calculate the slot number okay yeah second thing is like yeah you I was just saying that I'll also pray for per block it'll be easier to work but like uh yeah if if uh slot doing it first slot gives us a guarantee that we can finish a conversion in a particular amount of time then I think

it might be better because I'm not sure how many deep reog we see on the main net so like the case where we have to do a lot of computation again due to theog uh like how frequently with for me per block is no brainer and we should just move on okay any I mean good because that converts me in my opinion but is there any dissenting opinions all right it looks like we are moving on okay I think the next one is also you

g uh postate in the cryptographic proof uh no actually I think it's in you ah sorry apologies um yeah um so uh last week when I was working fixing some the bux in the proof generation verification G I got into thinking um that since we included the post State values in the witness we also in get implementation included the um openings for these postate values uh in the cryptograph proof so uh the

way this worked or works now I would say is that uh the cryptographic proof of the witness it is proving the openings for both the pre values and the post values and um if you think about this for a moment the reason that we want to include this post values is is because we want to allow potential clients to know about the state difference um that happen in a block without actually executing the block because if you're executing the block clearly you will compute yourself the

new valus so but what this means is that if the parties that are using these post values are executed the block they are actually trusting the new root of the tree um so if you are trusting the new root of the tree it doesn't make any sense really to have a cryptographic proof that the both values are part of this tree simply because you're trusting the root of the tree so um I can give you like some post values um I can generate a correct cryptographic proof of that these po values are part of the

new tree but I can be simply cheating on what is really the new tree uh and since you are trusting that root you're not gaining anything really from having cryptographic proof so the bottom line is that um yeah I talk about this with Y care and also an um yeah this was mostly I think a confusion between these the specs in quotes and the implementation mostly because I think we never kind of formally Define what specs for f values is um but uh this is kind of good for

performance because this means that the cryptographic proof will have less openings because we don't have to openings for po values and that's good for proof generation and verification uh not like a huge amount because because there won't be a lot of post values usually because that's quite expensive um for transactions but I know this is a bit less work but the dldr is anyone that is using post values should be kind of careful in the sense that it is fine to use these values but you have to be getting these blocks from trusted or semi-trusted sources

because uh we still don't have any kind of proof of block execution so um you will have a new state rout claimed by the block but you still don't have a proof of um correct execution from the pre-state to the Post State um so yeah if you if you are aware of that fact uh it is fine to use the post values but if you're are getting this blocks from an untrusted s well you have to be more careful about using these values because they can be um failed or invented or something like

um yeah so that's kind of the the the update um I already changed I have a working version of G with this fixed uh but it isn't really yet deploying Cent uh we will do that in the next days or week um so this basically means that the proof for this version of cin are like the same of the previous version of cin um which basically me the cryptographic proof only has a proof for the preate uh which is also good for I guess T since that means he doesn't have to do

any changes there uh so we yeah that's it uh so I have two questions based on that uh one of them is for tenes is do you need you know because your sync uses those proofs and especially the postate which is very which is untrustworthy and uh my understanding is that you are not re-executing the block every time uh how attackable is this and should we come up with a sign mechanism to require that people that provide proofs somehow sign them so that we can slash them

somehow uh yeah so that's the first question like like if we think about the worst case then I think it's quite a big problem because uh I think not actually because eventually if the values are wrong and we already have the correct State Route then eventually when the S finishes we'll have a problem we'll not be able to uh like get the correct route right but and any anyways like again sorry I missed this so if you are not providing the postate proofs then

anyways uh like or for healing like every time like we need to calculate the all the internal nodes and recalculate the state route so anyways like like we'll be able to verify if the postate values are correct or not yeah that's true yeah yeah and like yeah if and another way is to just directly reexecute the block I'll have to check like how much time extra time would that take but like if the post values are like actually a very big problem then we can just reexecute the blog I don't think so it will be that big of a problem and since like we are doing it in a stateless way so what we can do is like while the sink is running we can re-execute every block in the background

and collect postate on our own and whenever we need the postate for healing then we can use that collected postate to heal so yeah that is another optimization that can help yeah that's very nice yeah I didn't realize that that's that's pretty cool yeah uh the other question was for Kev um yeah it's because we're no longer including the proof sorry the post state in the proof uh we don't need to like do we need to change the proof verification code in uh either r veral or go IPA sorry in IPA multi prooof my my understanding is that we don't but yeah you know the code base better than I

do uh not as far as I can tell um so no but I can double check for cool uh yep that's all for me one question uh is there an implementation or or the specs of stateless client is this what nethermind does is that's the the most close to stateless client or we are not there yet so nether mind has a implemented

version of stateless client but I don't think so there's a spe but it's very uh like uh straightforward like so the idea is that you get pre-state in the block so you generate a status three from that pre-state and you verify that the pre-state proof is correct now you have all the values you need for Block execution so instead of using the actual state from the database just use this state for Block EX execution yeah yeah I don't think you need to spec for that it's just a regular execution uh like whether it's stateful or Stat less I would say it's an implementation detail um so it it's up for clients to decide what kind of store they want to

have and uh yeah if they if they want to implement stateful or Stat less it's whatever they want to do it's uh it's really left so yeah there's no such spec because at least I don't think we we need one okay thank you yeah evm Remains the Same the only change is that you get the state from the proofs and from the uh and not from the actual database okay makes sense we we'll read

more about Post State values how that comes into play okay uh last up we had the verification pre-compile Gom uh yes so that's actually been asked by uh zahari from uh from Nimbus um he wanted to uh like he was asking whether there's a pre-compile or not and it's true that uh sorry a pre-compile that could help uh everybody you know all the all the D developers on board get onboarded with

with veral because right now everybody understands the concept of Merle proof but if you have to wait for the tooling of veral to like the tooling of all the all the those libraries that currently are relying on Miracle proof to start using veral instead because of the math because of all the problems we're currently talking about with every client trying to to implement veral dap developers and people who provide like evm level libraries are going to have the exact same problem so um yeah I came up with a uh proposal for a pre compile yet another pre compile proposal uh to verify uh vertical proofs

so that for example a bridge or whatever could call the call this precompile in their in their contract and um and just uh get uh the proof verified and so that they don't have to really understand the workings of veral right off the bat if people want to start doing optimization later on that's always possible but um but yeah maybe speed up the adoption uh of veral via this pre-compile so I created an EIP the I'm sharing my screen again if uh if it shows uh is that um is that the

one uh let me see sorry always having an issue sharing yes that's the one um and uh so there's the text of uh of the EIP the AIP number is 79 sorry not the EIP number it has been changed to 7545 which is easy to remember um and uh yeah it's currently half anip because uh it explains how the pre-compile itself would work so basically it receives a version number if it's uh if the version is zero then uh it will distalize uh a veral proof like they are currently uh not specified

I I guess not specified fully but are currently used on cinin or what will be the proof format that will be part of the of the Verge uh and then uh further down the road if we switch to ZK proof If we invent a new system for verifying those proofs newer versions could uh could come um if we decide to move from veral back to some uh Quantum resistant tree or whatever we could we could do that uh as well via this pre-compile so this pre-compile would be uh future proof um maybe one thing that's missing currently is from that precompile is the gas model I have not uh really given it

much thought so I'm I'm happy to get input on that if uh people have ideas but yeah that's pretty much it just wanted to mention this exists uh there's an his magician red as well um so yeah if you have any idea if you have any input on this please uh please share it there and uh yep that's uh that's all I wanted to talk about on this topic just a little bit of context here I think the main use case is indeed Bridges between evm different evm chains usually what is security transmitted by

a bridge say a zero knowledge sying Cent for the chain is just the root hash of a particular block and usually in the block you will find the root has the root commitment of the entire arum State and then when you actually need to kind of materialize some data from the other blockchain it could be a receipt or it could be um evm variable and so on and so forth you will need to provide veral proofs when this data is transmitted over the bridge

okay any other things that people would like to bring up otherwise uh there was uh last time we didn't get around to do that but uh Jason from uh we we wanted to have a quick discussion I'm just checking if Jason is here no he's not okay uh yeah so okay nothing more from my side yeah I ping Jason I will follow up and and see if we can get him on a future call uh it is not the best time zone for for Jason right now on these calls okay uh if there's nothing else just one very quick uh update we will be changing the Cadence of these calls to

every two weeks uh that is unless there are any objections concerns or recommendations from anyone here otherwise we will move forward with that um and yeah and thank you everyone for being on these calls oh di go ahead yeah sorry just a question uh I'm not against increasing the Cadence I'm just wondering because in two weeks supposedly that's Dev connect if I'm not mistaken so do we start increasing the Cadence after def connect or yeah that's my question good question um that would make sense to me um any any quick thoughts from anyone else here otherwise

that's that's probably a good idea yeah I know I know a lot of people are getting ready for their own presentations and traveling me uh question is there going to be some kind of a special event or somewhere on the dev connect where we can I chat or meet in person or or is workland not going to participate in any of the events uh there was going to be an event that just got cancelled so I guess the answer is no for for the moment we could uh still try to do something it's a you know it's getting to be a little bit last minute uh maybe it's something that we can talk about

more offline but yeah it's a good it's a good question as well Dron yeah I just wanted to share a few things regarding uh veral in circuits that I'm still researching that based on uh Z which is a ZK evm project from risk zero uh katak takes more than 50% of the resources for proving the block so because in veral there is no catch I guess the improvements when the veral goes mayet and these rollup or or whatever ZK technology projects move to uh veral

tree structure I guess we should I mean my expectation is that we should see uh much of an improvement uh for the proving time and yeah it's just exciting that that we have that yeah and I'll I'm moving forward with that project doing more research and contacting people and see if there's any interest interest around teams to implement veral in circuit and mostly I'm getting positive feedback so we'll try to report on other calls uh like by the end of the call if there's time because it's a bit far away because

if I understand correctly there are people thinking that the veral won't even happen happen on mayet because of complexity so yeah I'm careful with this it's only uh uninformed people who think that yeah I get it and if anyone wants to share thoughts regarding this this approach yeah feel free to share thoughts uh I do have a quick question you say Kack uh did they try shatu 56 instead uh for this specific project they are just replicating MPT as is now

in ethereum so they're doing cck but I think with shatow ph6 it should be similar because it's a bitwise operation and it's hard to prove that uh in ZK circuit it just takes a lot of time so the tree structure is a big bottleneck for all the ZK evm projects which try to prove the Block in in ethereum as is right now without any changes without introducing different hash like posidon um yeah I guess my thoughts are that uh it'd be good to figure out 50% of how much time and uh also the Scala

multiplication might not be cheap for them if they're sort of not using bls2 like if they're using b254 they sort of a mismatch there to my knowledge they have the most performant and they are not even using BLS uh they're using a fry small field I think it's goldilux so I know uh veral is designed to be compatible with the proof system which uses BLS curve but more and more projects are using fry small field so fry Goldilocks it's called I think it's 46

bits so I think as the times goes by things will just get more and more improved so we will have multiple proof systems but I don't know which one will be used in in production but I think there will multiple proof systems but it's still good to to think to know this when designing uh uh veral p and like which curve is using and and stuff like that right yeah yeah it'd be good to figure out sort of what is the cost of doing um a basically a Bender Bender wagon Scala multiplication using their

the field that they're using um since it's not going to be cheap if it's not BS 1231 yeah I plan to do that yeah that's the first step which I plan plan to Benchmark thanks okay okay uh well so with that just the final thought I wanted to quickly mention if anyone has any other thoughts or ideas on ways we might be able to uh further improve collaboration around

veral uh please ping me anytime uh this is just a small change that we're making to increase the Cadence every two weeks post uh Dev connect um but open of course to any other ideas and and would welcome any feedback uh but I I do think we are doing quite well considering where we are so uh yeah thank you everybody for being here and we'll see you in a month if we don't see you at death connect thanks see see you by bye bye thank you bye