Verkle Implementers Call #9

Transcript

okay welcome everybody to veral implementers call number nine uh we will jump right into the agenda uh starting off with client team updates would anyone like to kick things off I guess yeah I'll go ahead uh yeah so for me at least uh we've been working on the shadow fork and uh yeah so there's been some some progress we now can simulate a shadow fork in in kosis

um and uh yes so we start with with with MPT States we uh let TX first run for a while until we have a big enough State and then um we we trigger the transition so that's that's working um and then we started using uh uh okay sorry I see a message from Pari not fly curtosis uh I'm not sure what we oh it's uh using anible um but wait I I run it on my own machine so it's got to be it's got to be in kosis somehow that was just a simulated

version where the for the first bug we found where you just had a multiblock transition okay understood uh but yes so so okay right so it's not fully curtosis okay gotcha uh but yeah anyway we we have a demonstrator um and so um so we could build a test net like this but of course the more interesting approach is to uh is to start a shadow Fork so we attempted holisky and because it's a real payload we started finding bugs that were not visible before so um yeah it was just about uh basically saving pointers and restoring them it's it's a bit finicky but um

we're uh I mean I think we're making progress although we're we're it's not done yet and otherwise I also looked into the testing I don't know if Dan's here maybe we'll talk about it at the end so I created uh an equivalent uh of well a subcommand for evm transaction so that they can uh stimulate transactions and see what the output the output tree is but uh yeah there were some misunderstandings so uh yeah I'll fix that after my holiday because I'm currently on holiday but yeah I I'm hoping to to have some better like nicer announcements to make uh in in a couple

weeks time uh yeah Ino did you have anything else uh yeah there was a test Vector is there anything else you we we SL you worked on um no no I will share again in the chat something that I Shar in Discord if somebody wants to take a look at it um there I just completed some the vectors for cryptography liaries I covering some Corner cases in crypto implementations um I already run this things in the go implementation uh I know that people from the n team is um including them in the new implementation and probably we will work

on the rust implementation in the near future so yeah and probably in January I will complete the other part of the test spectors regarding the veral tree data structure to cover some interesting Corner cases there and um withness generation which also has some interesting uh Corner cases that's just that I can give some update regarding uh eum GS stateless syc effort that is going on and for that basically I was integrating the new gas schedule uh

basically adding the charges for uh for veral Access uh veral weakness accesses and uh so I have had some limited success on that front that you know we are able to uh sync few we are able to run few of the transactions and I aim to basically complete uh this uh in this week and maybe then we can again try syncing constant into with e theum JS stateless and I have few queries regarding this GM and I have sort of dropped them in the test net I think you haven't seen them

yet uh that's right I haven't I'll have a look sorry about that I can give an update regarding bizu so we are working we are still working in order to have the same root Ash for the Genesis block so we fix several issues uh the last issues it seems that it's a difference between between specification and the current implementation in guess so I'm waiting for your feedback G it's not urgent but it's seems that for the specification uh in order to have the main storage offset we want to use the PO operation and it in guess it was a

shift left so in order to have the same route we are doing as guess we are doing a shift left but uh we need to know in the future if we want to it's the next item on the agenda yeah okay okay so I will let you talk about that but after this modification uh we we have the same root node so we still have a last operation in order to have the same state root Ash but clearly we are close uh we are close to have the same um generally State Route and when uh we'll have that we'll try to join the test net in order to import more block I still have to do some refactor on my side but uh it's not

uh something that will prevent us to to try to join the the test net so yeah uh it's it's all on my side uh I can go and share update for Aron so I have been able to join the network per se uh but I'm facing uh issues on block number 12 so I think it has something to do with uh gas schedule mismatch so I'm working and looking into uh what sort of mismatch that might be although I uh sort of implemented the gas schedule changes but I hope to

resolve uh this issue and uh make further progress with uh work gen devet to that's all for Aron sorry quick question didn't someone else not have a problem with block 12 yeah we did uh with ethereum JS but I think block 12 is the first block that contains other things and just like simple value e value transfers so it makes sense that you know people would block on that right okay uh yeah well if you if you have any questions on that just uh yeah just message us we'll do

sure uh I think I'll go next uh another mind side I don't have any significant updates is there are some uh issues with blog production and I'm just trying to get that fixed after that we'll get back on syncing uh using wal sync okay so I can speak for name team um not much progress lately lots of end of vacations uh we're finalizing our M library uh and we will integrate it into our V implementation in the next couple of weeks apparently and then we can

finally start seeing root hushes but then we still a bit further away I have to join the talk okay uh anyone else cool uh we can move on then uh the next agenda topic is guom with the main storage offset value fix right um so like I mean km already described the issue uh pretty well uh

let me look for my uh window here we go so there was a mistake in the in the I don't know if you guys can see my screen uh yeah so there was a mistake in in the computation of the main storage offset value uh it was supposed to be a power and uh we were instead using some shift some uh some uh incorrect shift so um Caren pointed out that this was incorrect this is my fix I would need before I merge it uh to to confirm

because what um was maybe a bit uh surprising to me at first was that uh tennish didn't find it or etherum JS didn't find it but then if you if your reference was uh this my repo clearly you also have the mistake so before I merge it and confirm that uh that this is incorrect I wanted uh yeah people from etherum JS and nethermind to to have a look and confirm that this is a bug uh I mean I expect them to confirm that U but just want to make sure and uh yeah when this is done I mean we're not going to relaunch the test net just for that it's just uh it's just a um it's just a value it's just an offset but

when we do relaunch it would make sense to to have it fixed to have the fix in uh yeah I don't know if you guys have a uh some comments uh yeah that's also what I was thinking maybe the block 12 is um is related but then uh because uh 11 uh sorry uh G11 or gender went um uh and and and Gabrielle passed this issue U I guess uh they must have somehow either taken the taken the the same made the same mistake or um or it's not related

to this I think we have made the same mistake okay uh so yeah if you could just confirm you know read look at the spec look at your code again confirm that this is incorrect on your code in your code as well and then uh get back to me I'll merge that fix and we can uh we can well we'll be ready for relaunch basically oh and I'm also going to copy the link into the chat so that you you have the [Music] reference but yeah that's pretty that's

pretty much it on this topic if everybody agrees cool thank you uh next up we have on the agenda the curve discussion I believe Carlos if I heard correctly from Gom you we'll give a quick update or summary on some discussion that recently happened around curve choice in veral uh yeah no changes so far so nothing to be worried about but uh I kind of did a bit of exploration uh based on Antonio's uh latest paper which is exactly about deriving BLS curves and

curves embedded into those um and basically the only thing that I was trying to see if what was easy to sort out is the fact that we currently need to split the ebm stored value into 128 limbs uh to then commit to both limbs instead of a single one of 256 bits that's because of uh bers snatch uh field size well BLS 12381 field size indeed which is uh 253 bits instead of 256 so we cannot fit everything into it uh the proposal was basically trying to find if it was worth it to to find a new pair of Curves such that we can get rid of uh this extra uh commitment or MSM

term plus uh not lose I think it's one or two bits of information for every single value that we store so far uh the feedback was given from Antonio danr and godri uh I recall at least also igno if I remember correctly uh the most important things mentioned were uh the extremism term shouldn't be a performance uh or space uh issue this is from Anton danr same with the basically the design of a new BLS curve isn't worth the deal considering all of the work that it would take to to actually put this into a compile and design everything and all

that stuff third BLS 12381 is also probably going to make it into main net anyways via 4844 so it's probably worth it to like reuse this uh anyways and and like like hack a little bit the way in which we commit to the storage values by having these two Limbs and finally this is the one I don't really understand uh it was mentioned that the scaler field bigger than 256 bits uh might not be a good thing performance- wise uh but this is only one extra bit and we only use the scalar field if I remember correctly for the msms So This only affects in having one more iteration of double an

which shouldn't be at least to my perspective an issue uh performance- wise but in any case um this was all of the feedback that Antonio danr gave and as Antonio and gotri agreed on points uh two and three and I do agree too uh so so far it seems that uh as was already presented bls2 381 plus ler wagon and the splitting value looks like the the most the most precise technique or the best one that we can that we can aim for so far so that's that should be it awesome thank you Carlos does anyone have anything to add to that or any

questions yeah yeah uh I mean just a a quick comment I mean yeah the the extra bits would not be a problem in my view because we could always Shuffle it somewhere I mean this is this is what we do but it would have the same it could have the same complexity because we have an extra bit uh hanging around uh yeah I I think it's still it's still interesting to to dig but if it makes no sense to I mean if it's not worth the effort then uh yeah we'll continue with the with the current model um it's just that there was an opportunity to maybe make things a bit simpler for for kids but yeah I mean I I was trying to answer

the question you put on the on the chat Josh got it thank you okay uh next up on the agenda item is agenda item for gas schedule and perhaps uh reviewing it as initially EIP 4762 was created with the idea that the gas schedule would be adopted in the fork before veral trees and that does not seem likely anymore I think y maybe you had some thoughts that you would like to start with here possibly yeah uh so it's it's really an open discussion uh D was going

to say something already go ahead okay sorry me yeah so um I thought uh we talked about this before and decided that it didn't really make sense because uh we had the ideas of lowering gas for S operations because of verle but we can't really do that before we implemented verle right that's my my memories of this discussion last time uh yeah exactly so but the the problem now is that um uh we we have this when all the tool Ling breaks basically we have TS first we we have

other like for example Adrian from open Zeppelin uh started deploying some of his test contracts on on the test debt and all the tooling breaks because uh we pay for each transaction you have the intr intrinsic gas which is 21,000 gas that you pay from and my understanding at least of this uh the the reason for this for this uh in intrinsic guess is to cover all the costs that you would do uh that you would uh incur to Kickstart a transaction and one of them is of course to go get the account from the database the sending account from the database and um and yeah this is something that we pay on the site we pay

for on the site now because we pay uh the cost of adding it to the witness so that means that even sending a simple transaction is no longer 21,000 gas it becomes uh something around 36,000 I forgot the exact number 34,000 but uh uh a lot of tooling um is uh gets broken because that value is simply hardcoded including TX fuz but also uh like I said some open zein tooling uh and I assume this is just the surface there there's got to be uh thousand other tools that uh that have this value hardcoded so my my question is uh maybe we should revisit at least the the in intrinsic gas and

potentially other costs that we should update during the the vertical transition because uh it feels like you're paying double really it doesn't feel fair that if the in intrinsic gas cost covers the reading of the sender account uh user should pay on top of that for the witness cost so yeah that's uh that's basically the case for it so maybe reduce reduce the the inin gas from 21 ,000 to 21,000 minus uh the cost of accessing One account at least one account if not the center account and and the re recipient account um but yeah I don't know if

there are some counter proposal to this or if um if it is expected that the cost will be will be higher I mean I think that makes sense what does it so it's like really accessing two accounts what would that cost in isolation it's just like it's much less than 21,000 right yes it's uh I mean I would have to do the calculation but it is much less than 21,000 for sure although when you could simply you could simply say the 21,000 already includes the cost of accessing the sender and the target account right so my question would then

be do we keep the 21,000 and so make the sender and Target account free seemingly free uh so we don't charge the the vericle cost for this or do we uh do we make uh do we change the iny gas to make it uh to make it 21,000 minus the cost so that when you actually charge the cost it becomes uh it becomes uh like you you find 21,000 again I mean I think it's very clearly better to do the first one because otherwise let's say later we decide oh we want to change the gas cost or roll up want a different gas schedule they would have to do this like like rebalancing to make sure this is 21,000

or less so if the goal is the base transaction should cost 21,000 then I think the answer is very clear yeah okay yeah then it's fair enough I mean if any of anybody else has an opinion but I I think uh I think that's also the best the best approach okay I think I think what we can do is basically uh in 21,000 we can basically give few excesses I the first the origin and the destination excesses free so basically then we charge 21,000

we basically add those accesses anyway to our accounting and then maybe you know we don't really need to yeah I I think this is exactly what we agreed on I'm not sure maybe I misunderstand your point uh G there I think okay okay I'm fine I mean I maybe I didn't understand a bit on the discussion here right so let let me summarize uh maybe I'm the one who did not understand uh instead of we keep the 21,000 value so we don't change that but in the code like when you know at least I I visualize it in gu when you start up your transaction you say uh okay this is

uh you're going to read the sender account you're going to read the recipient account those values don't get charged basically you know this in this specific context those values are free well seemingly free they're included in the 21 000 and then um and then we just uh we just charge the regular but oh oh yeah and then we still add those values to the witness so that they don't get charged later on and that's uh yeah that's basically it yeah then we are on the same page

okay if nothing else on this topic um yes just one point I will therefore make uh update the update the like create a PR to update the EIP and I will share it on the channel on the Discord R&D channel for for more feedback sounds good cool uh last up we have a topic that we've discussed on a recent call the uh vergal verification pre-compile I think Gom again you had a few things that you wanted to touch on here uh yeah we didn't really have time to um to update to mention it last time

but so there's been a proposal let me share my screen again uh here so the idea would be to to add a pre-compile that does State verification so it should no longer be called the veral pro verification PR compile because it's actually the state uh State proof verification precompile uh because protol Lambda uh sweeped in and gave some feedback and said it would be great to have uh to have also the ability to verify meracle trees um so the yeah the principle of this pre-compile is uh the way it works is very simple you just pass uh series of bytes and the first bite is a version

which is currently one bite we can make it larger if you think we'll have so many proof systems in the future that it's it Warren more than one bite um then you have the state rout which is taken from the Block and then the proof data which is really just uh uh I mean it's it's an arbitrary payload that depends on the proof on the proof type and then what the precompile does it it gets the version from yeah from the first bite and if version is zero it will uh get an MPT it will deserialize the MPT multi prooof and verify it called the verification the MPT verification function if version is one um it will deserialize a veral proof and

uh maybe those function should actually be called something else or at least have a different name and then uh called the yeah the polinomial commitment scheme multi prooof verification thing and um it's in its current description the the prile returns one if it was uh if it successfully verified the proof and zero if it did not verify the proof successfully uh another feedback that was given by Proto was that the precompile should revert period um I'm not sure there's I mean okay according to him it saves a bit of gas so uh we could uh we could do that I'm honestly

not having any opinion on this I think uh it's a bit simpler to describe describe that so this is to describe just returning a value but uh I don't I don't mind reverting if that's what people prefer uh and then in asio had some extra comments about it which uh if you want to give them uh in you yeah um I had uh two comments regarding this topic the first one is that um some weeks ago I was reading this and realized that I think this API is missing something else so the API today is that you give

the the proof the serialized proof and the state root and you will get a yes or no if that verifies but I believe that this precompile also needs to uh have a way to check which keys are being proven in this proof because from like if you're a contract and you are calling and you are receiving a proof and you will use this precompile to verify the proof you will be interested in knowing which keys are being verified because if you don't know that you are not actually sure what is being proven um so yeah that's um one point and and the the other point is um the support

from the Marco Patricia tree proof verification um my concern about this is if this is like worth it because um I know if in a year or a year and a half or something like that bural trees will be used in mainnet I know if many people would still be using Mar Patricia tree proofs for things and also the CG VM will have to include implementation of the proof verification so that's kind of some extra complexity that we are pushing there um but maybe Carlos has a better idea if that's a huge pain or not

or um because yeah maybe in the future we can remove the support for version zero which is this Marco Patricia tree but that's kind of a breaking change and um I don't know if that's kind of nice so yeah those were my two points yes I I think there's better ways to go with this I think we we started briefly discussing it with Y and I think you also after talking with JY uh that for instance you can do proof proof proof of equivalence uh for threes and stuff like

that and you can like have external Services you can even have yourself uh this kind of thing so that you need to load the entire main net to be able to support this kind of protocol when it the usage might might already be low but even lower when we switch to B because I agree there's not many reasons why you would like to use MPT is I'm with you uh yeah so one question I didn't understand like uh one point I didn't understand from what you said Carlos yes uh it's true we we have this possibility of having proof of equivalence but um

you know like okay what I mean is um we have even if it stops in a year if people don't use this precompile after sorry the MPT part of the precompile after a year um we there will still be deployed contracts that could potentially use it to verify appr proof at any moment so uh that would that would break those use cases and uh it would still be useful now now the question the point I didn't really get from uh from the point you you made Carlos is uh is it is it uh really much more complicated to implement this prile because this is not the impression I got but I'm not uh I'm not really versed into the the zkm I wouldn't say

complicated as to like just support it mainly uh the complex thing will basically be all of the logistics if then this gets replicated or the space that it might take of the maintainance SL Gordon on reviewing auditing Etc if then almost no one is actually using it which is kind of the same thing that happens with return D or Blake 2 F or stuff like that that almost sees no usage yet everyone need to pay the the cost of supporting it yeah yeah and and indeed I mean that's basically uh the other like the other side of the the argument I was making which is indeed you would need uh we

would still need to support it like we support ripemd or or other other pre- compiles that we really no one uses but in the off chain that they could be used um we have to be able to support them uh the other point about this uh is it really going to be a year because all those uh veral sorry all those rollups some of them are presumably not going to switch to veral at the exact same time that uh that mainnet switches to veral so if it takes them another three you know a further six months I would say my AR my argument doesn't hold but if uh

for example uh I think we had a talk with scroll they were not super super eager to to jump on the veral bandwagon so if those uh if if those uh people decide or people like them I mean uh decide not to not to switch for more years a a non a non insignificant number of years uh it would make complete sense to to keep it so I guess one of one thing we need to do is talk to every rollup and figure out what their plans and and I mean mostly the optimistic rollups um to figure out what their plans are regarding veral um but yep sorry go

ahead oh I mean it's not obvious um that a rollup having a different state scheme should impact what we imp should Implement on an L1 like for example rollups might just use completely in compatible schemes that we're never going to implement natively in our precompile um so so I think like it's worth thinking through what is the exact advantage of say L1 being able to verify a rollup State um there may be applications but I don't know if it's still properly investigated if that's necessary be Universal like there are applications

but I agree with you that if they want to support those applications they should be the ones that try to be compatible with L1 rather than the opposite so I agree but you can you can swap the the roots of the trees to like make goals that interact with data from L1 being in L2 or vice versa so there there's there's definitely applications for that but but yeah I'm with you also on this right okay yeah that that it's a good point um just also jumping back to to what you said about the equivalence so for example a ZK rollup would have no problem and inde like if a ZK rollup maintains the equivalence between two trees then all they need is uh because they have the proof of the equivalence

all they need is to have the vertical proof uh yeah part of the part of the precompile but what about uh non ZK rollups yeah like for example optimistic rollups would they need to also maintain an equivalence uh on their on their own um to to be able to use it this way I don't think what the say sense because the whole reason someone uses a different scheme for example z r up is that they don't want to like it's too complex for them to use mer or ver or whatever so they want to use their own and so completely gets rid of that Advantage like then they might just as well just

use B only uh well okay I think uh the problem is I mean from what I understand at least optimism does use the same scheme like the same MPT scheme so if they don't want to switch to veral immediately the we are exactly in that use case I described where we have a major player that still uses the old system that is compatible with the with the current version of main net but will no longer be in the future I would ask a question like um how is optimism working now without this precompile it's like is this something critical for them is they are having

some other work around today um uh that's a good question I mean they they are really eager to push for it so I assume that it's basically that yes they have a work around but it's costing them a lot of gas um okay well I guess uh when uh Ju Just for to progress at least on this on this point is figure out if in indeed it is a problem because if uh it is a problem what I describe is really a problem that people won't switch because if optimism switches and other optimistic rollups like um like arbitrum like the major ones decide to to move on

at the same time or close enough uh they yeah it would not make sense to support it I agree um the other point I wanted to discuss uh or at least get a clarification on in n is when you said you need to pass the keys but uh I do not remember that was the point you initially made because if you like if you pass the witness you do pass the keys right like if you pass something that is exactly like what we pass in a block we we have the we also decare the keys that we that we want to to prove so uh maybe I mean I I don't think I understood your point like how why is that uh why is passing the key important uh like via the API

I can clarify um yes I mean the keys are part of the proof but my point is that the contract wants to know which keys and values are being proven by this proof uh so for example if you are a contract that what you want to know if I know is like which is my balance at a particular uh blog number what you would expect to receive is a proof of that so you will receive this proof blob and this state root and you will use it precompile and you will get yes it this proof is correct but if you don't do anything

else if you don't check that this witness includes the keys of my wallet address with the value that you want to verify is true then the only thing that you know is that the proof is correct but you don't you don't really know which is being proven if you don't have a way to also tell the the pre compile hey is this witness including these keys and values in the proof or not uh because I can send a proof of your balance and not my balance and you don't have a way to know that if you don't have a way to tell the precompile to also check if some particular keys and values are part of the

witness you know if that's clear yeah yeah because indeed you receive an opaque uh payload and you don't know if your key is really in the witness unless you implement some logic yourself and therefore it kind it kind of Beats the point of of using this pre compile I mean it's um yeah I think there are use cases where you don't need this but it's true there are potential use cases in which you do need this yeah okay now that's that's fair enough I mean I would like you want even more ideally you want even logically to say what you want to access so that's not even because even if you prove the values then the pro is

still dependent on the mapping like wa say where you store the balance ideally for like a really independent proof scheme you would just say like account balance is this yeah I agree with that okay so that's a huge change to the interface but um yeah okay no that that makes sense I would uh yeah I need I need to think about it how to implement the the API um but okay yeah that can be done I

guess okay cool we have made it through the agenda anyone else have anything they would like to bring up if not think there's an extra point in the agenda number six uh yes the testing dock that was created by Dan uh so we could touch on this I was thinking that uh I was dming with Dan before the call and just now actually I don't know I don't think he's

on the call he couldn't make it uh that maybe it's best to wait for Dan or anyone else from the testing team to be on the call to discuss um it's linked in the notes if anyone would like to review the doc I'll link it again here uh one second but yes I think that will wait for a future call that sounds good to you and cool okay um MOS yes oh yeah sorry Milos I I forgot that you had had uh brought up a few things please go ahead um yeah basically I had uh I

posted a question on the on the agenda as well it's about um the state and how the nodes are encoded and if there is some standard way and whether we should standardize some way uh like for example I'm not sure exactly how we currently store what are the nodes and the values uh or we actually just store the commitments of them in the in the block itself or just in general like should we standardize this in some way I agree that clients can do however they want implementation but maybe there should be more or should we think about standardizing and also did we calculate the impact on the archive nodes uh

whether the workl would actually be more helpful or not um compared to the meray and the reason for that is if we have a node that has like I don't know a bunch of a bunch of values but only one change per block then every new version of that node would basically just duplicate the entire node itself and with just one version one one value change one child change would that like increase the value that is used or how like did we do any analysis on that uh did you see my answer in the channel because I I did respond to to you I mean I can give you the the summary um gist um the so no there's no

standardization and uh that wasn't part of my answer on the channel but I don't think there should be simply because uh even in the MPT space there's a lot of uh design iteration going on right now so it would be it would be uh I don't think it's just it's a good idea to to standardize right now when everything is still uh evolving quite fast um when it comes to the when it comes to the to the archive node or at least size estimates I also I responded to you I gave an estimate we do not have uh like I said I was saying at the beginning we we are currently working on on the

shadow Fork of holis key so we can give more accurate data then but the estimate without all the optimization that you mention and and those we have in mind uh we have we save basically 10% of the space like this is this is the back of the envelope calculation so could completely go wrong uh once again we need a real payload to give you some actual number actually an actual explainable number but uh but from uh from what I can tell yeah I me it should be much smaller because we don't store as many as many data um but we also have the problem that currently we don't have any uh any

specific I'm talking for GU here at least we don't have any specific optimization when you have uh when you recognize a pattern for example for an account you could store that in a much smaller way uh but we we don't have this optimization so uh I would say currently the amount of gain uh is limited because because storing an account is basically five times as large as the way you could store it but that's connecting back to my first uh point that we we still have a very large design space that we're we're currently U discovering or going around um so so it's uh it's not a good

time to standardize in my opinion okay uh thanks uh but let me return the question then if if I may uh what were what would be your needs for for that uh like why why do you ask for standardization like is there a reason behind it or is it just because uh like uh because yeah for example you have a uh is it out of herocity or is there is there an intent behind that um yes uh I was basically just looking in the portal Network case of how how much let's say data would a node need to store and how much data

when the noes transmits the like the portal Network nodes transmit the workland nodes between themselves how much payload would that be and stuff like that and realize that for a big nodes that 8 kilobytes which is um like for the branches they that are full uh that's not that's significantly bigger than what what is the case with the merket tree but it shouldn't be the problem and I was looking like if there is a way to standardize of course we can create a standard within the portal network but I was considering if there's maybe already some standard that is used that I just wasn't aware of but yeah we can make a standard for us when we transmit like a smaller noes and also

like the way would store them as well Etc but I was just curious if there is a standard and um yeah and I was looking for the archive State because I was basically the portal network if we support historical State and everything it would also maybe affect us in a way and I wanted to know if there was some estimate down that space so basically I was just looking how it connects with the needs and usage in the portal Network case yeah uh when it comes to Archive note uh I'd say let's wait for what uh some that uh you know like for some that work to to complete because I'm sure we can get some very accurate data um but uh yeah I just wanted

to go back to one point you made no node stored in the datab base is 8 kilobytes right we we only store we store by path I mean I'm talking about guess here we only store by path so when we pass when we give an internal node we only give the its commitment because its children are known by the path so you should never find yourself in a position of um of sending a 8 kilobyte note around the network I mean I'm saying you should never you shouldn't have to basically uh yeah so I don't know if that helps but this is clearly not a standard I'm just saying you don't have to worry or at least you should not have to worry about sending 8 kilobyte node across the network I

mean okay I will have to think if that's something that we can use in the portal Network case as well because you don't have like you as a one client in the network you don't see the entire tree you don't know the entire tree so you need to find that through the network itself but it's it's hard to know because we cannot store the like where would you get the information how do you get to the leaf no that actually contains the data but yeah um I mean if I understand your question correctly which I might not uh you how do you know that well you find

uh oh yeah but you need to connect to the to the parent yeah okay uh yeah maybe maybe what I said doesn't apply to you I would have to thank it over okay thanks okay uh well thank you everyone for joining and we will resume the call next year in January talk to you soon thanks have a nice holiday thank you happy Holidays happy holidays