Stateless Implementers Call #28

Transcript

hello welcome to stateless implementor call 28 issue 1203 in the PM repo uh cool we can start off with any team updates anyone want to kick things off yeah um I can mention that I've been work starting to work on uh e draft for binary trees but it's still in the works uh to be polished before being shared so stay tuned and also I've been working on some tests on some new execution spec tests

for veral regarding some uh bugs that we found in depent 7 in our clients but um yeah I will mention that later uh one thing I don't remember did we have an A Vic since the test net launched sorry sick now uh if we did not then we relaunched ctin and devet 7 and uh yeah please please go play with it and break it yeah did GS is sort of playing with Conant 7 and we are resolving some of

the issues uh that we are encountering um which which basically are the updates uh for the constra S itself uh and we are making good progress on it on business side uh so not a lot of update we we still can't follow the dev Nets um Lis is still trying to implement the block Ash gas cost modification Toma is still trying to implement the proof verification it will unblock some stuff like the stink for their K snaping equivalent and also validate the the proof coming

from the other client and uh we are also trying to optimize stem gen eration by um modifying who we are calling the Ros ver Library so we are trying to use multiple times the same address commitment so we have a test it's working it just to clean the code in order to integrate it into bizu we should see more more better performance thanks to this modification and uh yeah I forgot to say okay so the flat based on stem can follow theet and also the Legacy flat DB so we have two version of the flat DB

and we will choose depending on the performance what we will use at the end and yeah it's mainly that I think yeah everything for cool any other updates if not we can keep going uh next up we have a update to the execution spec test version 0.0.0 Osio yes uh this will be a quick mention um okay so we launched levet 7 and uh

after some blocks um we um never mind had a consensus P so we Deb that with Danish and yeah um found a kind of really weird case in which um yeah there was a v in in in our mind so I created an execution spec test to simulate that um so yeah we don't have regressions in the future and the same thing happened with um for another case uh so yeah we dive into details with Lis and found the situation and I created

another test for that so this is under the um the usual idea of like now every bag that we find in every devet uh should be a new execution spec test so we kind of start accumulating all these situations somewhere because yeah whenever we launch a new DEET the previous one is lost so um yeah and also we are making sure that everyone like if a new client joins the next devet is kind of also being covered by all these own situations so yeah I see that you already shared the link in the chat so if you're running execution spec Test please run this new version

and make sure that it runs correctly cool thank you next up on the topic of pre-image distribution and portal I think we have Piper here who is available there can you guys hear me is my audio okay yep perfect cool uh had a meeting with gam and the team at Devcon talked about pre-image distribution uh got a decent understanding of the problem um portal can solve this but it isn't probably the optimal solution um portal is currently best when you're looking at clients who want to grab a subset of the

data sort of on demand and my understanding of the pre-image problem is that just generally all of the clients in the network need to grab the full F uh the full set of pre-images um and so while portal could solve this I don't think it is the optimal solution um we talked about a file based approach does it make any sense for me to lay that out here on the call sure I mean I think uh everybody knows about the file approach but maybe uh to the the read y the reader digest version of it was something around you know S3 buckets being able to generate

the file potentially having pre-coded S3 buckets in clients that are already distributed being able to distribute probably a signature over the file so that so that they can have pre-distributed um uh private keys or something like that there's you know the the the model doesn't have to be exactly that it's just that there is a model that we can use that kind of has a pre-distributed trust model and frankly Distributing big files from S3 buckets is a pretty straightforward approach and even if it's not S3 buckets uh Torrance anything like that are are going to be a a a simpler solution and then then using port for it

so that's all I think I have is there anything I missed nope that was it um I don't know if W is here presumably I don't see him no um yeah so I think wuk in fact I don't think there's anybody from nether well there's way but uh I don't know if if you're uh yeah involved in day-to-day veral design decision um but I know cash from nether mind was really really uh pushing for making a peer-to-peer change to the protocol um or at least having a peer-to-peer distribution system um I think it's pretty clear that the CDN approach is uh is the simplest

and we should go with that um okay yeah I guess there's no more to to discuss right now because well unless someone is still adamant there's the we should go the P2P route I think we can we can settle this maybe what we can do like it do it's not Argent but we can make some kind of spec on a potential format for the file that we already have uh it's super simple but I know maybe it helps um to move forward a bit more with the idea cool if nothing else on this topic we

can keep going next up on the topic of State expiry we have adrean here yes and told me to come but I'm not exactly sure what what what you expect of me yeah yeah g maybe you can prime the topic here yeah yeah so we had this conversation in uh in Bangkok about um you know resurrecting like do we want to resurrect based on reads or based on writs and you had a lot of uh Reflections about it like a lot of

thoughts so I wanted to know if you could just summarize what your position is uh see if we want to do the yeah like maybe summarize all the problems you Corner cases you you found and uh yeah yeah so I tried to think of of expiry and Resurrection from my knowledge as as a smart contract developer of like Corner casing how storage is being used and most of the storage accesses are kind of like as someone would expect like reading and writing uh and in that regard like the question is whether I read uh would uh extend the the lifetime of of an extension or not uh I mean I

think the discussion was bit back and forth with that regard so I'm not sure if there is any good conclusion uh there are a few slots that are being read and never or basically never written to like written during the construction of the contract and then you read them most of the time this happened like of chain like reading anc20 uh name or symbol something like that uh but I think there are very interesting uh slots to consider in the case of ERC 721 uh for those that are not familiar with the details of the implementation of RC 721 each token that is being transferred has kind of an an approval like in R 721 you can approve a specific

token being sent to a specific person and most of the time this uh this slot contains a zero because basically nobody is allowed to take the token and anytime there is a transfer of that token what the current implementation doeses is it writes a zero to like reset even if the old value is is is already zero like currently it's cheaper to just write zeros and to read and decide what to do depending on what you read and so there is this interesting case where uh there are slots on the blockchain state that are likely to always be zeros but depending on how State expir works there will be different cases and different

cost model depending on whether the zero is like an implicit zero in the sense that value was never written to the state and possibly there is no extension in the state I'm not sure how it's implemented but that's what I would expect compared to basically the same case except a zero was written there and so it's like no longer implicit in the sense that at some point somebody actually RS at zero the state of the chain is is basically the same but as far as the clients are concerned there may be a difference here one of my concern as a solidity developer is how these explicit zero will be uh will be dealt with how they will expire like

will it be more expensive to me to read a zero if it was never written to compared to a zero that has been written a few years ago and when I'm saying a zero I'm not just about the slot in that case like the entire extension would be zero like the 256 uh objects in the extension will all be zero just one of them may at some point be the target of a n store that puts a zero where the there was an implicit zero before um I have a question in this model when you do write a one so you you or something you give the

authorization uh what happens to that slot afterwards like is is is it uh ever accessed again so whenever the so let's say you have toen ID number one and you allow and you approve it to me so you write my address here if I use the approval to the allowance to move the token either to me or to a third party this uh this value which is my address will be reset to zero if you decide to transfer the token and like move it to anybody in this the will also be reset to zero so that way I'm can I I lose my allowance when the token is moved so yeah whenever basically the token moves

this is this is written this is set to zero okay so yeah try to answer trying to answer your your question um when nothing has been written you read but like you go with um you know the the node does not exist in the tree so if you read from it you you will find a zero so you will know it's a zero I me you will know it's missing yeah and so you will read a zero and it will be uh well it would be just the cost of a read as soon as you've write something else um it will expire well it yeah it can expire if you if we keep uh like there okay so just to give some context

there's this rule we want to change that every read like the first read uh that you perform in a group per Epoch or era or whatever you call it um will be effectively will cause the same as of right and it will update the counter for the whole for the whole group that's what we're considering so if you have this rule then you have you no longer have a problem um I mean assuming you you do read it frequently because it will always be uh refreshed of course if you don't read or if we don't have this uh first rule in an era is a is a right then you will find yourself having to

pass the proof like to resurrect the contract uh sorry the not the contract but that part of the the contract storage to for your transaction to properly execute so I don't know if that answers your question well not entirely because one very subtle thing you say is as long as someone writes something else I'm understanding that as writing something that is non zero my question is more like if there is no if the note is not present in the three when you read you basically read as an implicit zero but let's say that this node doesn't exist in the tree and I decide to write but what I write is a zero will that create

the node no okay and if I write a one that obviously creates the node then later on if I write a zero then the node the node exists and will expire yes okay so that's why I didn't I didn't make a difference because yes there's no difference whatever you write there will create the node and the node will expire yeah so so basically the all expiring thing starts whenever someone writes something different than zero even it FS then reseted back to zero the fact that at some point there are something that was non zero means that the state of this slot changes basically forever exactly so if you find

yourself like reading this slot very often every six month you will pay a lot more just to refresh the okay assuming we have this uh thing we talked about where the first right sorry the first read is also right um yeah you have an extra cost every six month so that that may change I mean there are a lot of optimization that may change depending on like the state of the of the of the storage structure going to work or things like that uh I mean my personal feeling is that in my opinion if I was to write zeros everywhere I would love the notes to disappear so that there is no expir issues anymore in that sense

that would encourage people to clean the state and and hopefully like clients would be able to to remove the node directly and not having any kind of garbage colure but again I'm not an implementor I don't know how it works in other Hood so maybe that's not possible I mean this is uh Han is probably better suited to answer this question um but yeah the problem is there used to be a lot of uh proposals like this one where you would just simply delete stuff from the tree and the complexity explodes so this is where this is where the approach of 7736 is really nice um you you circumvent a lot of complexity so I I

agree would make your your use case a lot simpler but there's a lot of core uh yeah there's a lot of issues that will pop up if you do this yeah and yeah just one last thing is I'm always very happy to to discuss with any person that is interested in in basically discussing how changes to state will impact like standard contract that I happen to be writing yeah uh I just want to give an update as well since we are talking about the

implementation I think right now what I'm trying to do is to implement the E 7736 um the current progress is that um um the changes that the St aspir need on veral is is done now I'm just working on the Gap part so once we get all these components ready integrated and hopefully we have some sort of a death net uh ready then we can start testing out all these scenarios and see how we can make the changes to suit um the needs of like certain age cases or things like that but yeah um that's that's still in progress but yeah um we can talk about all these uh special scenarios later on yeah awesome anything else on the topic of

State expiry before we move on cool last up then uh we have uh a potential EIP for stateless transactions that uh gender wanted to share hey guys so uh basically this was something uh that came up in discussion when we were in Devcon and trying to figure out uh what are the challenges for stat less clients and one of the challenges would be that uh they would not be able to do block uh so stat

clients which don't maintain any execution State they won't be able to do any kind of local block building and uh this proposal is sort of to El uh to uh remedy that in a limited way because a transaction is uh a transaction execution is during complete so if basically it really deviates uh from uh from the execution when there is some previous transaction that has been included and that it has changed something uh which basically dynamically affects the execution of this transaction then uh uh then this transaction might uh would be at a point where uh the Builder won't be able the

stateless Builder won't be able to include it uh because it might access a state uh which was actually not bundled with it but uh uh removing uh but ignoring that scenario uh so there there is this uh so what we can do is we can with every transaction uh uh so the transaction submitter will also have to uh have to submit an execution witness sort of a thing with the Trans setion and that execution witness will have state diff as well as the proof of the state diff or if that's a stateless uh transaction or U maybe even a ZK proof of the

current execution uh uh to to produce the state def if it's a z transaction so basically these are two points uh that are out there uh so but uh this execution Witness would also bundle uh parents State root uh which which is basically what a builder would look at to see whether it can include this transaction in this particular uh block bundle that it's building and even though uh it might have included some other uh some other transactions before this it can still include uh it can still try to include this transaction because it know it knows that okay uh if these are the states that pre- states

that this particular transaction accessed and uh if I have made changes to that particular state by including some other transaction so I know what the pre-state of the transaction is and uh the uh and basically it will be able to again uh include try to include the transaction by again doing uh the transaction execution uh uh so uh and we'll basically see that what what are the new diffs that it produces and this diffs might not be same as uh uh same as the state diff that was included in the execution witness of the transaction because uh that that part is only used to validate whether the transaction was

valid or not and similarly if that is a ZK transaction and uh that has a ZK proof and uh that proof will basically be used to only validate uh if uh if the transaction was valid because if there is an so so so there are two scenarios if there is any pre-state change then basically that transaction will need to be executed and the diffs will need to be produced but for example if there is no pre-state diff chain then probably uh since there are no time based elements that are currently uh currently there uh currently there uh in evm unless we have time delay functions uh so one could

basically probably just not even uh need to uh execute the transaction to produce the diffs and could just take the diffs from there uh Post State tro uh uh in the execution witness is uh not really uh valuable because even if uh uh because if because the postate root can't be used like how we use it in in the block execution witness that you know you get a block you get a get a post def postate route and then you can basically in a stateless client use that postate route uh as as the next starting point for the next block so that is not

possible over here uh so uh in this case the execution uh the client will have to uh recalculate uh uh if it's doing its own block execution uh proof but uh I think uh that is something that can be figured out by the client uh so uh so uh I I'm basically trying to uh spec it out and trying to figure this out uh and also trying to see how it will look for ZK either I will just make a single IP so I'm basically currently writing the EIP and trying to figure this out I'll I'll either make a single EIP for both uh stateless and ZK transaction or

I'll convert into two different eips if it looks quite different yeah that is currently where I'm at yes it's actually more a question for goody and and maybe from Milos as well because I remember we had some similar question about portal could we rebuild proofs from um you know from like could we somehow aggregate proofs from blocks to to provide proofs uh for single elements um and for the proof you need all the FIS which will not be available

in um in uh stateless client so I guess we could have a semi stateless client where you only store the internal fil of the of the tree which um sorry the internal noes of the tree which would you know save a lot of space already so it would still be beneficial um but I'm just wondering is it really possible to take just the transactions and you know like recreate the block proof my understanding is that it's not possible and yeah that's the question for goti and maybe Milos mean depends on the proof system you're using but I mean with um IPA not

really mostly because because you have just basically kill you mhm what do you mean thees kill you uh I mean um basically I mean ipas just are not linear or have any nice structure that's kind of the problem uh right so maybe I was just talking about the witness more more exactly uh like setting aside the setting aside the IPA Al together you know you you rebuild like from all the transactions you've got to rebuild a view of the tree which is stateless and then you have to create a block proof mhm um and to do the block proof as far as I know you need the FIS like all the

what FIS um it's the it's the evaluation of the function at every single point in polinomial which you don't have because it's a stateless tree yeah right because you're making one gigantic polinomial Division and you need the yeah the value everywhere so we could still have like a semi stateless Builder which would be a because the tree is smaller but yeah I think there's a bit of a difficulty here yeah or or if we basically sort of change uh uh block basically so we this

is we'll change the tree to store diffs for example for an error and then apply at the end of the era maybe in that scenario we can just accumulate the diffs uh all along the way and uh maybe then somebody who has full state will be able to apply it right but then you would duplicate the IP approv for every single transaction you've got I just want to add that uh from the portal Network like if you have access to the portal Network and the way that I kind of Envision it it would work with a beret tree you would be able to fetch the the data only the data that you need

to approve the transaction execution or just just the data that you need for that purpose it's it's you you basically have to fetch the entire inner noes so it's not so small but it should be doable you don't need the entire State you still need a slices of the state but you need the full internal nodes I would say if you want to create the proof or if you want to create a different proof like specific proof that that will be used within the portal Network you don't necessarily maybe need to catch the entire it it depends how how it's actually implemented the portal Network at the end but it might be possible that with a different proving schema you

might be able to have like a smaller proof or something like that but it should definitely be possible using portal Network I'm not sure about performance wise if that's actually going to be good enough yeah so G while while building the block proof uh I mean do we require to pull extra nodes internal nodes uh to to build that proof because yeah in my in my understanding I mean since it's just homomorphic X for example what IPA and that would basically that if we can apply and sort of update the tree just based on

that yeah but you still need to evaluate like you need to do an fft if I remember correctly I'm a bit uh Mery on the details now but you need to do some uh some transform and you need all the values for this to to compute um um yeah I don't quite remember but yes I'm pretty sure you need them I have to reread the code to to remember exactly I can get back to you cool anything else on this if not we can

wrap all right cool and uh this will be I believe the last stateless implementor call for 2024 as we're getting close to the holiday season uh we can of course keep discussion async in the meantime in in the Discord all right thank you everybody for joining thanks bye y right see you