 Welcome everyone to the first ever EWASM decision hangout, which should be a prototype to the prototyping the decision process on changing anything in EWASM. And for every one of these calls, we record them. We will try to live stream them, but at least publish the recording. Anybody is free to join. Each of them is usually announced two weeks prior. And we have a GitHub issue to track all of these details, as well as all the proposed agenda items, which everyone should propose agenda items prior to the meeting, preferably a few days before the meeting, so everybody is ready to read on them. For this meeting, we already have, it seems like, seven agenda points to discuss. And I think we haven't done the groundwork to make a decision on what kind of order we want to go through these agenda items. Anybody has anything to add to this or any questions so far? It's Alexis here. I'm glad to be in this call. And I've looked at the agenda, and I probably won't be able to contribute much to any point apart from the pre-compiles. And I won't be able to stay for the whole call. I will probably need to drop off in about half an hour. So if you could get that point, the pre-compiles point earlier, that would be great. All right, so the agenda points we have is one of them is the pre-compiles discussion. And we have one other tiny issue, which is just proposing to change one of the exposed function names, which should be a very simple decision to be made. There's one bigger one to discuss how certain exported functions can stop execution. Three of these would be self-destruct, a revert or returning data and finishing execution. That probably is a bigger discussion. And the last one of these extra changes is a versioning discussion, which probably we should just give for this call. I have three giant topics, I would say, proposed by Pavel. One of them is how, agree to kind or maybe discuss the process of how we define the interfaces and how can we change interfaces. And I guess as part of this is a proposal to maybe offload some of the discussions to each research as opposed to GitHub. And the last proposal is, again, probably a really big topic discussing different metering options. So I guess based on that and based on Alex's request, does everybody agree to start with a discussion on the pre-compiles? All right, I can give a bit of intro to the pre-compile discussion. So basically, this idea came based on a couple of face-to-face discussions at the Ethereum Client Developers Conference, of which I think all the recorded talks and videos should go up soon. I'm actually looking forward to it. And there was quite a big block about introducing E-Wasn. And basically, what this pre-compile proposal means is so far, there was an understanding. So initially, the understanding was that E-Wasn would be introduced in the main chain parallel to EVM. And at some point later, this idea shifted to having E-Wasn introduced through sharding. But it seems like the sharding still will take quite a bit more time to be more finalized and be in the stage of discussing E-Wasn or execution engines. However, there's quite a big need and push from the community to have more features in the main chain. And most of these features come in the form of a pre-compile because the EVM wouldn't be flexible or speedy enough to introduce certain features. Some of these features, for example, would be new hashing algorithms or new algorithms regarding crypto mostly. So the idea here is to maybe introduce a subset of E-Wasn, which this subset would be enough to implement pre-compiles. And during this process, we would gain a couple of things with a reduced exposure to some of the risks already identified to E-Wasn. So basically, if we decide that these pre-compiles follow the way pre-compiles were designed so far, that means they have some kind of a gas calculation logic in them to E-Wasn at all. So basically, this reduces the entire process onto introducing E-Wasn VM into the clients, writing these pre-compiles once in a language which can be compiled to E-Wasn, testing them fully, and that that should be it. This removes one of the other concerns which comes up quite frequently is the problem of jet bombs. This should be eliminated because, well, fairly eliminated because we don't need to prefer for any kind of contracts. We have this limited set of contracts. Yeah, I guess this is a very long intro to it. So if anybody wants to speak up and raise any concerns or please comment on this proposal. If we're talking about user-deployed pre-compilants on the main chain, another concern that we might have is a implementation specific vulnerability with the jet engine. For example, if we have every single person on the chain executing a user-deployed pre-compile, that exploits a vulnerability in the jet that allows it to execute arbitrary code on every single host. Basically, every node on the main chain should be compromised because of that if they're using, well, every node that's using the same jet implementation with that vulnerability. That's one of the concerns I have. I think probably this explanation wasn't clear enough. I can clearly see that. This is kind of like a limited proposal. So it wouldn't enable and open up the door for anyone to deploy contracts. It is really to introduce pre-compiles as they are today in a much more quicker fashion. Because right now, if we need to introduce a pre-compile, we need to first agree what's the API, how the pre-compile works. Then all the clients have to implement their own version of this pre-compile with native libraries. So the go client would do it in Go, the C client would it in C, et cetera. And tests have to be created for all of these. And then somehow it needs to be ensured that no consensus bugs are there. So this is quite a lengthy process. We could save here quite a bit of time if there's only, and probably introduce other kind of risks. If we have a single kind of implementation, and we wouldn't need all of the clients to implement it natively. Yeah, so I completely agree with this. If we introduce it as the first step, and we're not going to open it up completely, at least in the beginning. I think it's very useful to just introduce it as the first step, where still the core developers will be adding the pre-compiles. But it's simply going to happen much faster. And they will be less reluctant into adding the new pre-compiles. Yeah, for me, this sounds good, even better than good. So I think that would, I think that the, so are we going to actually use metering contract to estimate the gas cost for pre-compiles or that would be something for later. And for now, we just provide arbitrary formula for calculating the gas cost. Right, just to reiterate, that's one of the challenges with this approach, is that if people are running an E-wasm reference implementation of a pre-compile, then there's no problem doing the gas math. But on the other hand, if the one particular client decides to implement the same pre-compile natively, then we're going to have trouble getting the gas metering to line up. I think the gas metering probably opens a lot of different questions. Because, so for example, we have to come to, I guess, an agreement on the gas metering. And that may delay the process. But on the other hand, coming up with random gas calculation rules as we have today is a challenge on its own. So I don't really, at least for myself, I don't really have a preference for either of them. But probably we need to explore both of these options a bit more depth than we have done so far. Well, I think if we're using the E-wasm kind of pre-compile system as a way to simplify deployment of pre-compiles on a main chain, then we shouldn't be thinking about each client implementing its own native version of pre-compile, because that wouldn't really be much of a difference from the way things are now. What I'm saying is that the pre-compile implementation should be well. I guess what you're saying with the E-wasm reference implementation makes sense. But at the same time, it could also be beneficial to steer away from native implementation of pre-compiles that are initially implemented in wasm because we could figure out the gas calculation and it would generally be kind of agnostic to each client in the sense that the only thing the client would have to implement if they want to is their JIT. Well, yeah, I think if we do the pre-compile in first step just for the introduction of the new kind of primitives, then it makes some sense to somehow inject it in the code because then you have to have run exactly the same code as everywhere. But then the question is, how do you do that? Do you do it via function calls? Or you just have a counter inside the your code, which is incrementing through and does something when it reaches a certain point, which is kind of more efficient. I would just want to comment on the table. If we, so following up from Jake's thoughts, if we allow clients to still choose their own native implementation of the pre-compile, as well as we allow clients to use the wasm version, then we lose one thing. We cannot choose metering. We have to come up with these random gas calculation rules. But second, we gain something, which is we don't require all the clients to support the wasm. We can have, at least initially, we can have a subset of clients which do e-wasm and the rest may decide to do it natively. And then it's a much more slower process to expend that support base. But on the other hand, we may be able to push this through much quicker. I'm not sure which makes more sense. I mean, as far as understanding the, sorry, go ahead. OK, in the case of, sorry, just go ahead then. Yeah, I just, I mean, I don't know much about the e-wasm, but I read a little bit about it. And apparently you can construct basically the static graph of the program flow in the e-wasm. So it allows you to essentially post-process any candidate implementation and just inject something in there. I thought it would be quite simple. And then it doesn't really matter whether the client implements the e-wasm natively or not. The actual code will be there. But yeah, I mean, and if they want to be compatible with the, like in a consensus compatible, if the client wants to do the natively without e-wasm and they want to be consensus compatible, then they will have to do it in other way. Otherwise they will just fork from the e-wasm supported client. So I don't think it's a big problem. That's similar to what I was going to say. Basically, in the case of just trying out the e-wasm pre-compile system, it does make sense to not require all clients to support the e-wasm pre-compile system, but at the same time that introduces much more surface for consensus failure. Because you have some clients running their native version and some running the e-wasm implementation, and that requires a much more kind of like wide surface for reviewing each pre-compile. Basically, that's the drawback of not requiring all clients to use the e-wasm pre-compiles, because then you'll have to vet both the e-wasm implementation of the pre-compile and the native implementation. This is Paul here. There's no way really to force people to not have a native implementation. They're going to do whatever they want. If they have a speed up, I think. We should, are we, first, AXIC, are we talking about issue number 104 for e-wasm design? Correct. Yeah. I think we have to also, I think it would be wise if we can just compute, automate computing an upper bound on gas use. To do this, we would also have to restrict what we can do in e-wasm. For example, we wouldn't allow while loops. We would have to be able to know how long each loop is going to run statically before it runs. So we would have the finite predetermined loop, number of loops. We'd also restrict these call indirects. And then we would prevent recursive calls. If we can do these three things, I think we can compute statically, as Alexei was speaking, based on the abstract syntax. Maybe we're going to be able to compute, I don't know for sure, but we can maybe compute an upper bound on gas use. Once we have this upper bound, that would be our automated computation of gas metering. Perhaps we would sometimes have some error cases, but we would use that upper bound no matter what happens. And I think we should precisely do this, automate this gas computation by doing some static analysis. I wouldn't go as far as restricting the loop count. I agree with restricting the recursive function in indirect, I think. But restricting the loops, it's probably a bit too harsh. And I wasn't thinking about actually pre-calculating the upper bound, but simply post-processing the wasm binary just to basically inject a counter in every loop. And essentially, that will just increment it in a loop. Yeah, that'll work. There will be a little bit of a slowdown because you have to compute the metering. But yeah, that works, I guess. Yeah, but you basically can do it in a way that doesn't require you to have some sort of trust checks because as you just post-process it in such a way that you introduce the new variable and then just increment it instead of calling some sort of consuming gas function. And in the end of the execution, you just basically pass this variable back. Yeah, there are many options to compute gas and to meter things. One is to have an internal variable, maybe a global variable in some WebAssembly and others to call out to use gas. I don't know if there are security concerns for one or the other. But yeah, there is overhead, certainly. Personally, I would like to see fully static analysis. We only allow four loops. We follow the ViperModel where we only allow four loops of a certain number of iterations that are known beforehand, this type of thing. But if we wanna be very generic with our pre-compile, sure, we can allow while loops in arbitrary. So let them have the gas run as long as, you know, as much as, use as much gas as it wants to use. So actually, we'll ask a question here. What would be, what would be the process? What would the best way to propose this? And I guess on what forums? I would think probably all core depths would be one of those forums to propose this idea. I also think it would need a bit more description, substance around it than the current issue has. But I'm also wondering if we should kind of spend a tiny bit more effort on looking at what kind of pre-compile people want. Maybe even implement one of them and just have some kind of more information around this idea than we have right now. And we could probably prototype that with CPVterium because that should be working. And, you know, what kind of like times or like milestones we're shooting for. Yeah, just in general, probably discussing the process of proposing this to the wider audience. Well, I think we can, as an example pre-compiles, we could take something which is going to be like things like a BLS signature verification, which will be useful anyway for the future process or something that Nick Johnson has asked about, which is some of the curves for the DNS verification or something like this. So, yeah, you could get a couple of examples like this which have some practical use and just implement them. Yeah, I would choose something that is waiting for a long time already. So one I remember is Blake Hush. And the second one is what Alexi mentioned, this elliptic curve for some other kind of... Yeah, that's also useful DNS. I mean, there was some team that wanted that really much and they implemented, I think, that in every client. So that would be like my two candidates for that. But maybe there's more in EAPs that I'm not aware of. Yeah, I guess we need to have like a really good understanding of how far clients are regarding wasn't support and we get some kind of update about that last week. Probably like one of the blocking parts or like one of the core parts we have to probably wait for is supporting Go Ethereum. But I think that's like really in a good state. And then probably writing one of these pre-compice as we mentioned and potentially testing them and looking into different kind of metering options at or around the time we proposed this probably would be like a good way to take it. But probably this metering, whether we would want to have like random gas rules or we would like to use a more deterministic process, probably that is one of the bigger questions to be answered. You know, I will, this deterministic process of pre-computing gas, an upper bound on gas before it runs, we need an algorithm. I don't, my sort of hope that we would use this would need to be supported by some evidence and algorithm, a runtime of this algorithm. And I have done nothing like this. I haven't provided anything. So I think it's one of my jobs to sort of write down an algorithm implemented in PiWebAssembly, show that I'm computing an upper bound of gas, maybe proof something that I'm doing what it's supposed to be doing. So I guess that's one thing that I owe you guys if we're gonna do it with pre-computing an upper bound way. So is the upper bound which would be charged the user? Yes, no matter the run even if it sort of errors out early for like an invalid input, it would always be charged the upper bound, yes. Do you think that would be like a good incentive or kind of pre-composed or a certain types would be good to be done this way? Certain types, yeah, certainly. If you need a while loop, for example, this would be bad because if you don't know how long it's gonna run before you run it, certainly you would have to give a gas limit. So certainly you have some idea of how long it's gonna run, but maybe there might be some algorithms where you're doing some search and sometimes it might find something right away, whereas other time, you know, and you would like exit early with just use a little bit of gas. Other times it might run much, much longer. Yeah, so you lose some flexibility with this deterministic way because you'd have to have an upper bound. I argue that you will have an upper bound one way or another because you have to have a gas limit anyway. And if you need a higher gas limit or some algorithm that has more iterations then you can make a new pre-compile for you can do whatever. But yeah, certainly this limits the algorithms you can use to be not touring complete but almost touring complete. There's a Brandon Ike Twitter thread about maybe almost touring completeness is enough. Obviously this is bad for marketing because EOS or someone might say, yeah, well, we do have touring complete, but I think it's worth at least leaving this as an option among the other options. Yeah, so if we look at some of the hash functions, I think pretty much all of them have a fixed number of rounds and in each round you have a fixed number of operations. I think that might work well in that case. So maybe there are like the whole class of pre-compiles that would for which there will be enough. But I'm thinking if we decide to do that, we will be able to extend it later on if we realize that actually that wasn't enough for other cases. I think we should explore whether we can put this limit now and then remove it later on if it's really needed. I think it's not enough for even for hash functions because it works like it has a constant cost for a single block, but most of the implement pre-compiles we have can hash arbitrary length of data. So it's linear, it's proportional to the input length. So I think that breaks this model already. I just wanna mention is to be conscious about time because this was scheduled to last 20 minutes more from now and probably we're not gonna answer all of these questions we have. But probably it would be good to some kind of layout plan how we can work on this, communicate about this and have maybe more calls. I think everyone at this call is part of the Decatur channel. So probably that would be a good way to quickly discuss matters. But probably we need to figure out who is interested in writing some of these actual proposed pre-compiles and in the language compiling to Wasm and who would be interested in figuring out appropriate gas costs for it, better through some kind of deterministic process or whether through other means. Okay, let's make the discussion to the Gitter because yeah, I think we spend a lot of time on this. I guess anybody who is, I mean, anybody from us on the call or even anybody on listening to this from recording, please also check out the, there should be a link I guess on YouTube, but please check out this Gitter issue and maybe leave a comment and also join the Gitter channel. I suppose this also ties into another decision we should make is whether to move some of the discussion over to ETH research. I don't have any particular opinion on it, but I suppose that idea there also ties into another decision we were supposed to make on this call. Yeah, I wonder how much of this would qualify under the research category whether each research is the best going to have discussion about this or is this a more practical discussion which is usually part of the all core devs process but or the third option as of today to have it on this EWASM repository. What are the proposals to what kind of parts should be moved to ETH research? I think that certain topics such as what more like high level design discussion could be moved to ETH research. For example, the EI design in things that are non-trivial for example, an example of something trivial would be the name of a method and the an example of something non-trivial that could be moved to ETH research is probably more like how the EI should be designed and what it should support in a way. Pavel, you were the one adding these three proposals to the agenda. Do you wanna create appropriate issues for them on GitHub for the moment? Okay. And yeah, I mean personally I would be happy to move certain things to the ETH research forum if that brings us a lot more response and discussion because probably that is the thing we're lacking at the moment. Yes, that was one of the reasons it's to like expose the issues we are heading. But I only meant the EI for that because it somehow also affects account abstraction and maybe something like that. And I don't have for picture of this ideas. And yeah, I don't think there's anything at the moment that is worth moving there. Yeah, with account abstraction considered, seems like a good idea to me. Yeah, the topic of the EI to ETH research just because it's also kind of bottled up in the design repo at the moment. I think we should maybe enumerate lists of options and spend some time writing things down in a way that's easy for people to understand if we start posting things on ETH research that is sort of not sort of organized then. The discussions might not be what we should discuss. So I think we should spend some time curating and writing things nicely, enumerating all of our options and letting people sort of the high level of everything. Paul, would it make sense too for each of these discussions to have an entry on our GitHub design repo and then maybe iterate there before it goes to the ETH research or at least for any ETH research topic, there would be some kind of cross link from there. So it still could be tracked through our design repo. Yes, and even more so we can maybe try to build some prototypes whenever possible, accumulate statistics, whatever the case, anything to sort of, so we can give people that are gonna make the rest of the community some sort of information and some sort of clues and hints on what's better and that kind of. Yeah, so let's iterate first. Okay, Pavel, do you wanna, since you posted those, do you wanna create an issue for each? And you just listed the EEI design process, redesign process as one of the points. Do you have, can you give an overview about that with any kind of proposals already or it's just like a high level topic? I can say two sentences about that. So my idea is to actually review current EEI methods one by one. And some of them are kind of obvious and probably there's not a lot of discuss about and some are not like that. But like what I wanted to do is to actually create separated threads about each one of them. Maybe list some alternatives and some, yeah, to mostly have some on in-text discussion about each and when we finish that, I would propose the whole document as another version of the draft and that could go to, yeah, bigger peer review. So depending if there's actually something that's, it's not very clear. We can reach for if research in some cases, but mostly I will keep it as a github issues. Actually I created, I think, two per requests, each of them tries to address some basic EEI methods, improve documentation a bit and that I would see it to proceed with that. Yeah, that's all. I can describe this as well as a meta issue, describing the process idea. Yeah, please do, I think it would be really important to have an issue about this and have more clarity and probably that would also give us a framework how to make decisions. Yeah, I cannot promise the same framework, yeah, but I will do my best to have good description of that. Do you also wanna give an overview of the alternative gas counting implementation? Is it a proposal or it's just them? Yeah, it's probably better to skip it for this time. All right, so I wonder if we should, so one of these easier EEI change proposals, we're falling into the category of a simple name change, which I get as kind of like the sentiment that may be okay if we're the discussion on a free search, but like one of the other points here is this anything we're gonna extract, that probably something we cannot make a decision on this single call. Is anybody interested to try to make a decision on something in spite of the first call? The easiest one is the return to finish and it doesn't matter to me, do whatever. I used return underscore whenever I needed to not conflict with Python return. And I think a lot of people would do like return underscore or whatever. In Wabasemi, hello, hello, can you hear me? I think you were breaking up if you could just repeat please. Yes, for the return to finish, if it doesn't matter to me, I use return underscore, I think in Wabasembley. The return, there's no keyword, you're just using UTF-8 strings for the imports. So I think it's fine to use return for what in terms of Wabasembley, but there might be some conflicts in. Paul, are you still there? I think we lost Paul. Yeah, for me, this change is improvement. So I would go with that if there's the ideas for different names than finish, that can be proposed separately. Yeah, but it's improvement of what we have at the moment. So I agree to merge this one. Yes, I agree with that. I think we need to change this name because we have some conflicting in many languages that uses this as a keyword. The only thing I see is that, for example, right now for each one of the EI methods, we have, we see that each one of these methods is related to an opcode. And if you already know the opcode, you can guess what the method is doing. So maybe for the, when we change it from return to finish, that idea is not that we are talking about something like the return opcode. So maybe we could change it to something like return data or something like that so we can still know that it is related to something like the return opcode. Yeah, I see that that's a potential issue. Return data probably is a relevant name, but unfortunately I think it would be, I'm not sure if it would be confused with return data copies slash return data size, but probably this is something we should actually discuss. So Hugo, if you wanna leave a comment on the issue that could help in sparking the discussion. And I also think, again, looking at it, that I think it depends on issue number 72, which is the self-distract calorification, self-distract slash reverse slash return, which was another agenda point. Because if we call it finish and actually the execution isn't finishing because it's still up to the contract to finish the execution, then probably finish is misleading. Right. So yeah, I would say we cannot really make a final decision on this, but please leave comments on whatever was said because I think it was useful input. And I hope we can make a decision on it on probably on the next call. But before the next call, we should think a bit more about the process of how we make decisions and whether we move any of those into each research. So what do you think? What would be the best way to discuss this? And what time should we have a second similar like core devs? It wasn't core devs call or it wasn't decision hangout. Should we have one sooner or should we have one in two weeks or even three weeks and have more of this other discussion but the process done or should we have this call to discuss the actual process brainstorm the process rather? I like the model that the Ethereum Foundation uses for EIPs where you submit a proposal, you do some background on it, some of you sort of have some like good pros, cons and things like this and then people will respond and then you'll have a text discussion where people have time to think about things. And then I don't know. I like the model of EIPs. Yeah, I like it too. I mean, I would say like it can be some like introduction given on some of these meetings but then it should go to some offline form in text or something like that to actually accumulate pros and cons on paper. And if that's, it's kind of like reach some unstable point then we can come to the meeting again and discuss like maybe some, yeah, and then make like some final decisions on that. But this middle term process, which is quite long, I think it doesn't suit online meetings for a while. Well, the idea of an EIP process is that the discussion happens asynchronously offline and then once a proposal is deemed to be technically sound and has been merged and stuff, then someone can bring it up on a meeting and champion it and at least in theory the vote to sort of approve it should be quite straightforward at that point. I think that model is pretty efficient. So can we create these proposals as an issue on the design repo for the moment? Yes, but it's important to say this, that sometimes you have some sort of proposal when I had students, I would tell them, write it down. Like clearly write it down exactly every word is important. And sometimes when you do that, the issue sort of disappears because in the act of writing it down or in the act of writing it down, you have new ideas. So I think that we should have it in the design repo. But I think if you're proposing an idea or you have some sort of something to write, just write it down clearly. If there's something unclear, say, I'm not sure about this part, but it should be written down, not some vague thing that is sort of interpreted differently by everybody, then we don't know what we're talking about. That's it. Yeah, I think we're coming to an end to the allocated time slot. And I personally, we need to leave roughly at the end of it. But if there are any last minute comments or proposals, please say it right now. Alex, when do you think you'd like to schedule the next of these calls or maybe how often should they be scheduled? I was shooting for every two weeks, strictly every two weeks. I think we can try to do that, but in a few days in a week, we should know that it makes sense to make it or not. I wrote up some of these comments we have made, what is called as a comment on to the decision hangout issue. But basically, most of the comments I made were if we need to create issues for all of these and we need to discuss them there. And if they are kind of ready, we have to bring them on to the call. So I hope we can make a call in two weeks if everybody is laying out these ideas more clearly in a written form. Actually, Lane, have you, did you keep minutes? No, I haven't, but we have a recording on YouTube. So we can still do that. Do we want to publish minutes or just published recording and have this summary there? I think we're fine not having the minutes for right now. Yeah, I think at the point where we're actually making decisions on these calls, having the minutes is pretty important, so I'm happy to do that. Well, thank you everyone for being here today and sorry that I want this really strict schedule for the moment. I think we made some good progress and probably realized some of the limitations we had so far. I'm really optimistic that this is gonna be super cool and we're gonna make all of these changes really fast. Thanks, Alex. Thanks for organizing. Yeah, thanks. Thanks, Alex. Thank you. Thank you. Bye-bye everyone. Bye-bye.