Stateless Implementers Call #33

Transcript

Hey everyone, uh welcome for to the stateless implementers call number 33. Um I will share the agenda in the chat. As a brief summary, we have the usual team updates. Then we have a presentation um from Julian about the protocol design view on stlessness if research post and then we have some sorry some uh EIP discussions um about the overlay tree IP and this three conversion EIP.

So let's start with the team updates. Um I can start first. So I've been working on adding some extra pre- conversion execution spec tests and I've been sharing them with um some people and yeah they have been running them and I think they will give their updates but things look pretty well. Um I also wrote some other document that I shared with Spencer regarding some internal things that we have to do in the testing framework. Um this is like mostly technical depth uh created while

creating all these tests. Uh so we have to work on this and will be mostly transparent from everyone else hopefully. And I also wrote some document regarding EIP 4762 worst case scenario for block sizes. So this is in the context of um helping a bit Tony from the ARC team that is working on a refresh take on worst case block sizes.

uh and worst case for burl is a bit different from the usual way you think about it uh currently mainet. So yeah, uh I will share it in the chat just in case somebody else wants to dig more on it on that. But I think in in the future we will probably discuss this further uh because it might require some tuning in the constants of 4762 or or not. I mean it depends on on what we decide. But uh I think it's interesting that maybe more people uh read this document. And yeah, we also been working

on some new um pages in the stateless book uh that hopefully we will finish reviewing internally soon and they will get published. But I would mention that in probably future s goals. Um that's all for me. Um yeah, I've been working on like two weeks ago I think I was working on uh implementing binary trees so that when we want to make some measurements we can. Um I realized I haven't tested it. So yeah the implementation is there but it hasn't been tested and last week I was working on implementing the transition into guest master. Um, yeah, there's been a lot of back and forth, a

lot of uh redesign that needs to happen only at the code, right? And not uh not at the EIP level, but it would be pretty cool to have a guest master being able to go through the transition. Um, so this is going to continue this week. Um, yeah, hopefully we we can get somewhere. Um so from my side I've been mainly working on the integration of statelessness with fossile uh kind of trying to identify possible problems or incompatibilities and also things that have a good symbiosis between them. Uh so far it's looking nice identified one particular thing that I I think we all

agree that requires further discussion which is how do we actually solve uh IL flooding uh attacks within any regime uh that uses statelessness so weak or strong and aside from that planning to start uh executing some networking benchmarks as networking is also highlighted uh as one of the most critical things on statelessness since basically we're trading disk or hardware by by network. Uh so I will likely be using a shadow to do this unless someone has a better suggestion which I would definitely encourage uh mentioning it wherever it is. Um uh on the postquantum

bal site not much news this week. uh we're doing some meeting uh I think it's on Wednesday uh with Madan and uh some other cryptographers and also Rancher from the cryptography team. Uh we're trying to look for a very particular vector commitment based on latises with certain properties that suit vertical trains and so whether we will find it or not it's an unknown but at least we want to know if it's possible for this thing to exist or not. So that's what we'll be also working toward.

Okay, on be side so we mainly worked on the transition. Uh we had to try to fix some issues um detected by the test from Ignashio. uh I have al I have also to modify the code in order to pass some test because we are not completely agree with get regarding how we are migrating the code when we are modifying an account so normally it should be fixed uh soon I don't know when but yeah should be fixed soon and also Louis uh detected maybe an issue when we are doing some roll back of the vertical state so we will have also to investigate that and um yeah it

was mainly uh the work we did uh during the last weeks uh on another side it's same as BU we also worked on integrating transitions with the vocal code base and we are also passing most of the test there are some things that uh everyone does not agree on and we'll probably be discussing those today apart from those specific tests all the other tests uh we are passing Apart from that I also started working on rebasing the work code base on petra and after and I'll be done in like a week or two and after that I'll start integrating the transition uh on over the rebase as well on Ethereum JS side uh we haven't

made as much progress as we expected on the transition because we've been focused on are a new release. Uh but the work is going to resume this week for uh the converting to MPT to verbal. Anybody else want to give an update?

I can quickly mention where I'm at on the um testing execution spec test side. So with the framework updates, I've basically finished um a long overdue rebase and yeah, I'm going to start working on these uh technical debt um issues that Ignasio outlined at the start of the call. So yeah, thanks Ignasio for for listing these up. Okay. So the next item in the agenda is a presentation from Julian uh from the Rick team in DF about an ETH research

post that I will share the link in the chat. Um yeah Julian whenever you want. Thanks. Let me share my screen. Sorry. Give me a second. Um, sorry I have to rejoin quickly.

Sorry. Yeah. So, um this is research post is highly recommended for people to read it. Uh I find it pretty uh useful. So, yeah. And now Julian will do a

presentation to give like a bit. You are muted. Yeah, let let's wait for a minute if Julian can solve these technical issues and maybe if not we can go to the next item and give him a bit more time. Sorry, it didn't allow me to click

any buttons, which is kind of annoying. Okay, I think there we are finally. Yep. Okay. So, thanks for hosting me. Uh yeah, I'd like to present um the protocol design view on statelessness which is also a new research post as Ignash mentioned is work that analyzes the statelessness design space uh in its interaction with other parts of the protocol and we treat the individual roles that validators have like the testing and block producing as separate.

So to me statelessness is really about jointly choosing the proof server node architecture and state growth and the proof server node architecture will be the node that the pro expects to provide state to users. And what this means is that if the community wants extremely large state growth then the proof server node architecture may not be so robust. Perhaps only a few agents are able to provide the state and thus proofs. On the other hand, if you want extremely robust proof server node architecture, then state growth can't be so big. And that's pretty much where we are today. Attesters provide the proof that is they provide the witness, the piece of data that convinces the tester that the state used in a bot is part of the canonical state tree. In turn, we have fairly small state growth. A core idea behind statelessness is that a tester should

not be approved serving nodes, but who should be then instead in my opinion that's an unexplored area and the central question of the recent post I wrote. And so I try to contribute to that question by answering three sub questions. First assuming a weak stateless protocol is it necessary to implement partial statelessness in protocol? Secondly, what's the fundamental difference between weak and strong statelessness? And thirdly, how does state growth constrain the DA limits in a weak stateless pro? So we'll start with the first question and the first finding is that in partial statelessness is not necessary if there is weak statelessness. The idea is that partial statelessness uses a state expiry rule to partition a state into an active and an inactive set. Uh the most known one

is that state expiry rule where the uh state is moved from the active set to the inactive set if it hasn't been touched in six months. And a tester should all adhere to the same state expiry rule. If they were to hold different pieces of state, it may call sports. However, in in the stateless world, the testers wouldn't be holding states. So they don't need to act upon any state expiry rule. But we still may want a state expiry rule for block producers because they now have to store a local state. Uh but the finding here is that block producers do not actually have to adhere to the same state expiry rule. If a block producer wants they can store a piece of state and if they don't want to they don't actually have to store it and nothing forces them to store it. The only thing is then it

can't interact with a piece of state. So the simple example here is if a block producer is interested in account one the the green node uh it must store account one and it must have uh two it must have access to 2 and B um to create a witness but it doesn't have to store three and four for example um and therefore builders could use their own state rule and it's not necessary to have one in protocol if the testers are already status so that might be useful for if we're drawing a state beyond the a state that we expect builders to be able to uh And that being said, obviously it would still be nice to have a universal state expiry rule because it's better for user experience. But that universal state expiry rule could be stored offchain. So you may be asking why would

block producers do so? Why would they prune some of their state tree? I would see two main reasons. Um the first one is some states is not economically meaningful yet storing it does impose costs. So some state is not interactive with much or it interactions are not very valuable. In today's meboost markets, we see builders leaving out transactions because their value is very small compared to the value of the large me sources. So this happens in blocks where there's a huge arbitrage opportunity then some small transactions may be left out just because the builder can't yeah can't be bothered to to think about it. Basically this happens even when the builder is not explicitly trying to censor these transactions.

It's not about the transactions. it's it's about the size that they take up in the blockch and the second reason would be state growth is too large and um so that so that builders would not store it and they have to remove some of it that point may seem surprising and builders are sophisticated and surely have enough hardware to keep up with state growth and while that's true currently I approached the problem from the other side there could be a state growth at which builders can't keep up with the increasing storage requirements that is the pro store could set state growth such that it grows so fast we builders won't keep up with it and we may want to be able to live in that world and it turns out that if we would want to be in that world we do not need in protool

state expiry uh to facilitate this and then the second question is about the difference between weak and strong statelessness. In weak statelessness the protocol expects stability to store the states and in strong statelessness the protocol does not expect ability to store states. However, from uh the previous slide, we know that builders could in principle uh use a state expiry rule at their own will. And so that means that if the proto expects the builder to store states, it doesn't actually mean that it also has to happen that way. To me, the difference is really in the definition of owners spot producer behavior. So, and we in uh in in weak state expects an own spot producer to store the state

while in strong state it doesn't expect this from spot producer. However, we can't rely on all those block producers um in in principle uh because there are only two major ones and they are they are rational profit seeeking actors. So we have to find some other parties to store the states in either weak or strong statements. The block producer definition is still important because it helps to design other parts of the protocol. For example, fossil fossil pushes builders to behave more like builders. If we say block producers do not have to store the states, then fossil transactions should come with a witness. If we do say that block producers should store the states, then perhaps this isn't necessary. Finally, we need to consider

who holds the state after a test or stateless. Um, users clearly still need access to the state to create their transactions and potentially to create a witness. In principle, only one known sensoring party is needed, but it should be be clear who this person is. And once we know who these people will be, who the state providers will be, we can reason about how much state to grow state growth to allow and state growth should be set such that users can reliably gets up-to-date witnesses from these state providers. To me, it seems intuitive that perhaps DAPs and users or wallets on behalf of users seem like natural candidates to store estates. They're more censorship resistant than builders because there are only two major

builders. uh they're naturally incentivized to store state and they are less likely to have state that's not economically meaningful to them which remember that the builders would have um and they care a lot more about robust state storage than a builder would. So perhaps an application would want um state to be stored in in a few redundant ways whereas a builder might not care so much about that. However, there are also clearly problems as this puts a heavy burden on applications and users. Uh so that's something we need to think more about. So I guess the main points here is that I'd be very interested in in who should hold it and I think that we should think more about that. Yeah. So that's it. In summary, builders could use their own state expiry rule. So no improvisable state expiry rules necessary if a test is very

stateless. And we should clearly define almost builder behavior in a stateless world which to me is the main difference between we can join statelessness. Um and we have to think about who holds the state after our testers are stateless. uh because we can't just rely on some honest blog producers to to keep this. So yeah, thanks for your attention. I'd be happy to take questions here or offline on Telegram. But here you can see my handle. Great. Uh uh thanks for for your research. It has been super useful uh even for us to get like a fresh take on like definitions and um all these discussions about in protocol and out of protocol rules and

how this connects with the state like expiry and fossil. Um I know if anyone has uh questions for Julian actually I do. Um have you explored like the the last slide uh the one you know who who should hold hold the state. Have you um contacted anybody um you know from DAPs or wallets to see like I I think we we talked about it before we said wallets are probably unlikely to to hold the state for you. Um, is are you do you have any contacts with apps or with DAPs, sorry, that would be interested in

uh in hosting the state or at least signal that they would be interested in uh in hosting some of the state? Yeah, that's a good question. You guys probably have way more experience with that. Uh, so in principle, no, I haven't contacted uh applications about that and I probably should. Um, yeah, I I would say I'm not convinced that applications are uh the right the right person. It would be like my first guess. Uh I guess um I would say my conviction is more that builders aren't the right people for for the network to rely on to store state. Uh but yeah, I should probably transact some applications. Yeah, I think that would be I mean maybe not just you, but it would be a nice followup to to figure that out because yeah, I agree. Maybe dev should not be

the person like the people doing this. uh at the same time like you said builders should not be relied on and if wallets are you know they have no uh incentives to keep uh to keep the data I guess it's going to fall on dabs to do it. Yes, Milos. um any particular reason why portal wouldn't be considered a solution for this since portal we already planning on keep having this data anyway or am I missing something from the design as I didn't look into details right um so for we would need to have the the state at the head of the chain and um as as I heard Porto wouldn't be

providing states at the head of the chain reliably um so that's basically why I didn't include Porz here um Yeah, I'd be happy to hear otherwise. Yeah, it's it's not meant as it is to to Portal. It's just that we we contacted Piper and he said uh wait and see. So that's why that's why we haven't considered portal yet Sophia. Uh yeah, thank you Julian. Um, I'm also happy to see someone thinking about um who's going to hold the state in a a stateless world because I I've been wondering that for a while and and um I don't think anyone is thinking about it uh so far. Also um I do expect the state to be um much larger uh than it is now

as we're um thinking about significantly raising the gas limit um in the near future. And um like most people I think that strong statelessness is unrealistic like from a UX perspective. Um that said like we kind of don't know yet where um when state size becomes an issue. I think that's something that we're just starting to uh figure out how to test this year but um won't know very soon. Um what I'm most curious about is uh with state xbury, right? And we talked about this a little bit on the last uh one of these calls two weeks ago. Um if you know current state xree designs like

are sort of um uh not really feasible, right, in that they're they're they either um don't reduce the state growth enough, I think, in in the context of having, you know, a 10x or like 100x even gas limit. um or um they're they require address space extension or contraction. Um does having out of protocol state X free solve any of that? Yeah. Um so I'd say to be honest probably not. Um I'd say having it out of pro rule doesn't fundamentally differ any of those things. Um yeah I I find rest is kind of an interesting example

in in principle it's also partial statelessness with a state expiry rule uh but their state expiry rule is not based on date or or time stamp or whatever uh but based on like some optimization problem of of minimizing uh both the state that people need to store and uh the network bandwidth and other related problems. So perhaps there's an avenue to go down there. Um yeah. Okay. Thank you. I want to say something else that Toma shares um minutes ago in a telegram group. And maybe also interesting to think about how private mess versus

public mess relate to asking the users to provide a witness if like witness creations might be fulfilled by private me um owners. Of course, I mean this is not like a a freelance solution, right? But it just might be a um a way for like improving UX in a way like most of the transactions will go through private main pools and we could maybe um not really ask users to to solve this. But of course if you want to have strong censorship resistance and you are using the public man poolool the the problem still stands of course

right that makes sense thanks okay so if there's no more questions uh we can continue with the agenda uh the next item is uh a discussion on EIP6 66 um 7612 which is the overlay tree IP. Um to give a bit of context about this topic uh when uh Karim was running the execution spec test for the tree conversion he raised a question on why whenever um why the code isn't migrated whenever a transaction touches the state

of an unconverted accounts. So to explain a bit better before the tree conversion logic activates, we have this period of time in which uh we have the overlay tree. And the idea there was that whenever you whenever a transaction touches an account, the right will happen in the burl tree. But in the current rules um converting the code at that point in time uh wasn't there and I think Karim said that that will simplify a bit the um the implementation on the client. So the idea is to discuss this a bit

further. I don't know if Karine wants to add something else. Yeah. Why I was uh saying that is because in order to migrate the account we need to have the code size and push this code size in the header. So as we are to read the code in order to to update the header, why not directly um also migrate the code and also on my part uh it will simplify to to when I detect if an account is present to be sure that the code is already present in the vertical tree instead of doing to checking if the account is present and if the account is present also checking if the code is

present. So it will reduce for me the amount of check and I think it will also reduce the number of disk accesses if when we have an account in the veret tree we know that we also have the code in the veret tree. So it's why I was asking gu if we can also uh modify guess in order to have uh this kind of behavior. Um yeah, so there are two things here. Why we shouldn't do this or at least why I'm against doing this. Uh okay, three things because yes, we have to do it in GU and um it's a bit complicated. Uh like I have an issue explaining how I would do this and um I'm not sure it's

very reliable. Like I would I would have to work around it. Like I would have to hack my way in. I'm not super super okay. I I have a bad feeling about this. That's I guess at the core this is the real problem. Now there are two real problem two problems that are a bit more um I'm looking for the word uh yeah um okay forget the words uh I have two more problems. uh one of them is the the witness size because for example someone could bloat the witness by I made some calculation if it's a 30 million block um they could just write or or access

some some um account um and and that ties of course into uh the next conversation which is about converting accounts when they get touched and not at the end. Um but if you start doing this, if you start updating uh like the code or converting the code when you touch the account, you could find yourself in a situation where people pretty much what Ignasio did with not touch only when we are updating when you are updating the account not only touch I'm not saying when we are just reading an account when we are updating an account yeah no when we are updating an account yeah but updating an account could

just sending one ETH uh well sorry one way to the account. Um so you could send one way to every account um you know that has 20 24 kilobyte code uh which is pretty much the same attack as what Ignasio did when he took down some of the provers on eroof.org um except I think even cheaper and uh what you would do is just get 24 kilobyte codes and this way you would bloat the so I computed how much extra nodes that would represent in the witness and that's uh about 3.7 kil

kilo kilo uh sorry 37 sorry 3,700 leaves extra Um so for example if you're if if the stride is 10k uh this is like one one/ird but we not said that we will not have uh witnesses during the transition. Um we no uh did we say that because okay I'm trying to think because I keep hearing contradictory opinions on this. Um we no we want them uh on um for the purpose of syncing like doing things. Yes, we want them for that.

But I think we decided that uh we don't need it for sync because it was too much of a hassle. The witness size will be will bloat. So I think we decided that we'll sync snap sync until the transition point and then we'll do a full sync while we are in transition. All right. We do a full sync. Um yeah. Okay. I'm not sure who we is because yes, I can imagine us uh vertical uh vertical uh oriented people to or stateless oriented people to agree with this. But then there's what the guest team has been saying. That's why I'm a bit confused and I'm not sure what the final decision is.

Um I'm happy to go this route, but I think [Music] uh yeah, I I think um it's not very it's not a good idea in in any case to to blow the the witness. What we can do, however, to to uh lower the this risk is um see how many leaves got touched um during the Yeah. But okay, actually we can't really do this because we only we can only do this if the the sweep the tree sweep happens after the block execution. But if it happens before the block execution, which is item five on this road map, oh, sorry, on this um on this call

agenda, um we would have 10,000 leaves and then potentially 3,000 more or uh maybe even more depending on how many transactions there are that that do this. Uh no sorry the 3.7K is uh limited by the 36 million. So no that would be that that would be about 4,000 4,000 leaves extra. Yeah. Okay. Ju just regarding uh the transition how you will represent a key that was in the patrica market tree and not in ver in the access witnesses you will said that the prior value was new or was present. It's a proof of absence. Yeah. Okay. And then you have the new value which is non

which is non zero. But the stateless client will uh not work as as the node we have the value tree. So it will be the execution of JM will not be the same. So the the execution client uh sorry the stateless clients would not be able to work. That's for sure. Yeah. Um, however, however, like I said, we we might want to use those proofs for the sync because the sync would still need them if if we decide to do a to do a stateless sync this way.

So, yeah. Yeah. You're saying Karum? No, because Yeah. I'm just thinking if we really need access witnesses if we say that we will do full sync uh during the transition and it will simplify I think it will simplify the the logic like that. Mhm. No, I agree. Um I totally agree with this. It's just that I need to make sure the rest of the guest team is on board. Yeah. Uh just to summarize a bit your point and let let me know if this is makes sense. So you're raising a concern regarding the witness size bloat if we do the call conversion here. Okay. So

that's one thing and I think another thing is um just execution load because I know if like there's like no bound in the amount of rights in the Oracle tree that we might do if like a block migrates a lot of like even if we don't include witnesses during this phase and we rely on full sync we have to still answer the situation. If a blog converts, I know thousands of 24 um accounts, you still have to do the rights to the new tree, right? And that

might be a lot of work. Yeah. So, that was not my point, but that's absolutely a fair point. Um Yeah, that's that's an extra concern. You're right. Yeah. Um, and on top of that, it's not just the rights, it's also the well state root computation, assuming we don't really benefit from the the pooling of of all those values together. Yeah. Um, but yeah, as as it is, I don't think it's a true stopper.

Uh, we can always just say, okay, the network could handle 20 20,000 leaves. Um, but because we expect potentially an extra 4,000 leaves to be created, uh, instead of 20,000 leaves, we will do only 10,000 or 15,000 so that we have this buffer. So, I don't think it's a it's a showstopper. I'm just saying, yeah, this is what I don't like the idea. Uh, the the So, there's a second point I was trying to make. Um it's that uh for me in the code it's really hard to tell when uh code has to be rewritten because uh in G at least the first time the code gets created. You have a flag

it's called dirty dirty code and uh it's set because the co the contract was just created and we need to we know that we need to update the the code to disk. Um, the second time I have to say it I'm not really really clear on how I could detect this thing and this is why uh I I already asked but I I'll ask you again because I'm really interested in this. How does uh you Tanish can you Karim detect that this is the time to um to convert the code again basically to to write the code and how do you ensure that you don't write it multiple times like you

only write it when the code is created in MPT mode and then when it's accessed so that by the during the conversion during the transition so that you know that you have to write it again to the tree and more importantly that if the contract uh you know if the contract is storage is written to multiple times how do you how do you ensure that you only write the code once and not like yeah every time the contract gets accessed I think it will be difficult to explain laz but in u in bizu we have a notion of accumulator so when we are reading something it's similar to the access witness we have the prior value and the new value and uh during the transition I

have an accumulator for the vertical tree and I have an accumulator for the patrica mer tree and when I'm reading something from the patrica mer tree so it will it will be marked as it was present in the patrica mer tree and not in the ver tree because it will be null in the accumulator of ver so when I will compute the state root I will detect that the prior version was new so I will have to write it in the database But in the next time if I want to read it from the database, the prior value will not be new. So I will be able to um to detect that I don't have to write it again.

Mhm. Yeah. And that's true. You you have several account types and I could have the same thing. H Okay. And Tanisha, do you know do you know how you're going to do this? So right now what I do is I calculate the state through twice that's not like a good solution. I just wanted to make transition working. So what I do is like before we start executing the block I move the data and I calculate the state. Do not like the data to the database or anything like that. just calculate the state root and then when you execute the block you can very easily uh check if if something was like while calculating the first state root you can check if something was written already in the

database the workable tree and you should not move it and if was it was empty then you move the account or rewrite the account and then when you execute the block you use a different mode where you just like to do the normal operation that you do during block execution but I think I'll do something similar to what Kim is doing uh when I skip the two creative calculation thing, but yeah, I haven't thought about that yet. Okay. Um, okay. Thank you. Then I guess I'm relent relent, excuse me, reluctantly agreeing that this is what we should do. Um, provided we keep some buffer precisely for the the block size overload and the computation overload.

Uh, over yeah, like overboard going overboard. Um, I just have to keep thinking. Uh, but I guess uh, yeah, I agree we should convert the code. I just don't exactly know how to do it. So, I might raise the point next time. Um, but yeah. Okay. I I get the point and I think it should be doable. It's just not going to be easy for me. Yep. Okay. I think I got a bit confused, but I I don't think so. I get why do we like for storage slots I understand that we might need to rewrite again and again but for account and code if you're moving account and

code at the same time then I do not understand like why do we need to even check to avoid rewrite like what I do right now is uh if the data is not present in the new workle tree then I read it from the old data and if it's already there I like yeah I don't go to the PM partition tree um yeah I'm trying to avoid the database access every time that is so I I can't really check the tree um that's why I I would like to not have to check the tree because that's an extra an extra read and it's a fairly

critical uh part of the code where you recomp compute the route. So you want to be going as fast as possible. Um because that used to be a bottleneck and it could still be a bottleneck in the future. Um so that's why um it's it's some information I would have to go fetch from the database and I was hoping to not have to do that. But anyways, when we compute the state, you have to read what's already there if I'm not mistaken.

Um, yeah. Yeah, that's true. But it's in a different layer, so I would have Yeah. Okay. So, basically, you're right. It's not just a database read that is more or less necessary. It's mostly that I have to hack my way through interfaces. So, yeah. Okay. Okay. No, but I I get the point. I'm not I'm not saying it's not possible. I'm just saying I don't like it. But if I find a good way to do it and and prove that it works then uh I am I'm happy to to indulge.

But I think uh the reason of uh what in pointed out that it it will increase the execution load. I think that is a reason enough to not do it this way because like yeah if if like if someone wants to actually create an attack where it just like sends one to the accounts that have a lot of code and that would slow down specific blocks. So I think that's a reason enough to not move code when the account is modified. Yeah. Yeah. But like like I said, uh we can ex we can get some buffer so that we make sure it's not going to be a problem. I mean it's inefficient because then we our stride is 15k when it could be 20k, right? So we we make uh um what what 25% less progress. But uh

okay, we make the same progress eventually, but we we don't go as fast. Um but I mean if it's what it takes uh yeah I guess it's but but this point is unrelated with the stride, right? This is something that happens before the conversion starts. Um no, I'm I'm not sure I get what you mean. uh what I mean is like before the conversion starts if we migrate the code when uh an account is has a right then there's nothing stopping someone to create a block that only writes to 24 accounts and forces e clients to do a

lot of writes in the Oracle tree and all this is happening before the tree conversion right yeah that's that's also true yeah um but I would say because we're converting nothing then we definitely have the buffer right because the the limit I mean the computation is like 3,000 oh sorry three 3.7 thousand leaves um that should not be a problem I I don't think it would be it's uh it's going to be extra extra work for the for the machines but this is work they would have to do eventually so might as well do it at the time it's actually beneficial I would Okay?

Because it's h doing it at at a time that is not uh where no other leaf is being converted. And once once they're in the tree, they won't be converted again, which I would say um is good because we don't have to uh um yeah, like we're we're saving time in a way. we're we're starting the conversion early. Um even though well we might have to we're in a situation where we might have to to reorg um but ultimately I would say that's uh that's not going to take the the whole thing down. uh but but the problem I mean it's it's beneficial from the sense that you are front running a lot of work that will

have happened in the tree conversion but the point is there's no clear bound of this work compared to the tree conversion where we have the strike protecting us no no I think uh I think there is I mean from what I I computed which is uh like the maximum bloat you can give is uh doing this at least is 3.7 uh Sorry, 37,000 sorry 3,700 leads. So it's well within the balance that we currently have. So it's basically 30 36 million over 2,100 something like that amount of 24 by it's actually sending sending a transaction. Um yeah okay that's that's

the idea. Yes. Uh it's just sending a way to one way to the to contrast with 24 kilobytes. Yeah. So that's way way way way higher than the bound that we designed for the tree conversion, right? Um is it 30? Well, 20. Okay. Either my math is wrong or it's it's not. No. Okay. I'll I guess I have We're going to double check it. Yeah. Yeah. Let's double check the math. But uh from my understand it's fine. Okay. So I mean uh yeah let's

double check things um offline and we can uh come back to the topic in in future sik to see if we can reach some conclusion. Um, one small point about that. It couldn't wouldn't it be possible to have a design where the amount of conversion that happens depends on the size of the execution witness. So let's say we're aiming for like 10 10k leaves per per stride or per block. But couldn't we have it so that it's uh it's just the delta between the target and what's already provided by the E block in execution witness. You see what I mean?

Where I mean if we have like 3.5K that's already like converted in the by execution we could just do like fill that up to 6.K then we have a reliable number that we know clients will convert every block. Yeah. So this is actually an idea that long ago got suggested for the stride being dynamic instead of static. Um I think the conclusion there was just that static is much simpler and to implement and it was mostly a complexity argument. But just to be clear the discussion here is actually about a situation that happens before

the tree conversion. So it's not really strike related. Um so the the the point here was that before the tri commercial happens if we are migrating code what is the worst case scenario there and if might be too much low for your clients. I mean but actually if Yeah. Yeah. So it's not just before right it's also during because if you uh have a normal conversion and on top of that especially if the conversion happens before like what we want to do on point five we probably don't have the time to discuss that today but if if we do the conversion before executing the block then you will have a fixed number which is 10,000 leaves and then on top of that

you might have another 4,000 or 3.7 hund thousand leaves But during the conversion, this is a point already addressed in the IP. Uh because you can only migrate up to there's like a clear bound here's like a link on the AP touching that. Um okay. Um, for some reason the link doesn't work for me. Okay, I guess uh we can maybe take that offline for now and uh

right account okay tracking done a single step uh conversion stride. Um yeah but that's not exactly what I mean. uh right if you are touching the account but it's not uh in the leaf we want to migrate by block or something like that or uh come again now you are saying if we are touching an account during the transition and not because we are because we need to move only an account by block. Mhm. You are not talking about this part. You are talking about when we

are touching an account during a transaction. Yeah, I think it's the same before and during the transition. Same issue. Yeah. Okay. Um I guess because we're almost at time and we have other things on the agenda, we can take it offline and uh we can uh yeah, let's let's sort it out. But I I think it's manageable. Okay. Um I think we have a bit of time for the next one. Um next item in agenda which is a discussion regarding uh this rule that we have for the tree conversion of

not migrating empty accounts which have storage. Um yes tanish I think we skipped the part where there's the third also as a like sub part on storage route triggering the conversion like changing storage yeah so there was I'm sorry yes so there was another sub discussion on the previous topic which is something that we discussed in the previous call the previous call I raised a point in which uh Yes, Karim was also mentioning whenever we uh write to a storage slot a priority the only data that might be

written in the BL tree is that storage slot. But by the way that GU works that also uh the way that GU get works is that it would also migrate the account data because technically storage root changed. So GU interpretation is that the account data changed. So that means that the account data should also be converted to the to the BLE tree. Um so I think people wanted to touch again on this topic. Yeah, I think um now that people ran the test uh passed the test, they understand a bit more what was meant here.

Um I'm still against this idea because okay because that's the way guest does it. Um but maybe people want to make the case to do this. I think it's also connected to the previous uh issue of writing the the storage because then if you write a slot you have to convert the you have to convert the account and then the question comes whether or not you convert the code as well. Um but yeah, I mean I guess it can be done in G and once again I'm I'm not happy about it because it makes the code ugly.

Um yeah, the question is how do you guys do it and what's your preference? Uh I think I prefer like not moving the account when we are moving when we are just writing to a storage slot. But I think right now the test assume that we move the account as well when we are writing to the storage. Yeah. So right now indeed when you write to the storage slot the account without the code will be translated. Yes. Yeah.

I prefer that you only translate the storage and not the account. So you right. So you okay that's what you want. And how do you uh how do you ensure how do you detect that the account um that the code has not been translated? Sorry, that it's time to translate the code. How do you detect this? Uh I still need to work on that because right now I'm moving like code with the account. That's why I'm not passing the like test where we don't move the code with the account. I need to rework that.

I'm not sure how to do that, but yeah. Okay. Yeah, on my side, um I'm not against this proposition to move the slot uh without the code, but it's not a problem if you are moving the slot with the count. Um it's not a big issue for me. uh migrating the code with the conf for me it's a it's a bigger issue but regarding the slot yeah it's not really a big issue so as you want okay um yeah I'm looking at my code on

how to do this uh I thought I had the fix for this but I don't really uh I don't know if it's going to I don't know if it's going to work um okay well I guess Tanish would implement this and let me let me know how how you do it and I guess Karen too and then we can uh if if I everybody manages to do it I guess that's the that's the simpler way to do it. Yeah. So for me it's working as it on my side for the SL. Uh for you it's not what for me I'm Bezu is working as get for the Yeah. So never mind like the thing

that I am proposing is already implemented. So maybe I can try to like implement something similar to get it's not a huge problem but yeah I will give it a try. Okay then I I will ask you for uh links so that I can go and check what you're doing that would be informative. Okay. Uh so we have another two items in the agenda but since we are running out of time I think we can roll over them into the next call.

Um so yeah thanks everyone for joining. Thanks everyone. Thanks Nasio for leading. Yeah take care.