 All right, we are live. Cool. I think what we did last time, Alex, was we actually had each of the E-WASM team members briefly share like a quick update about what they're working on. I don't know if you had a different format in mind for this call or if you want to do that. Is it that like me or? Oh, sorry. Is it that like, wait, I'm just gonna, I'm gonna refer to you as Axic on this call. Yeah, I think that that might be a good idea to give some kind of updates where we are. Especially regarding the design process we started to do. So who is willing to start? Okay, I can start in that case. So I have been mostly working on a couple of different things. One of them is HERA, which is the C++ implementation of an E-WASM VM. A couple of different things. One of them is HERA, which is the C++ implementation of an E-WASM VM. A couple of different things. Greg, could you switch off your mic? I just muted him. Sorry about that, Greg. We were getting some echo from your side. A couple of different things. Okay. So worked a lot on the HERA together with Jake to get mostly a VM or more like engine abstraction into it. And the main goal with that is that we're gonna support multiple underlying engines to execute WASM code. And that will enable us to do benchmarks across them and have a better idea of performance. I currently only works with Binerian, which is an interpreter. But we have Vebit, again another interpreter, and Vavum, which is a JIT in progress. And that should be hopefully finished pretty soon. The second thing I mostly worked on has been the Rust implementation of the pre-compiles. So we have a repository called Rust, no, rather E-WASM-pre-compiles on the E-WASM project, which has pretty much all the current pre-compiles implemented in Rust. With two exceptions, it doesn't have the mod EXP and doesn't have ECRecover, but it does have everything else. And on top of that, it has two new proposed kind of pre-compiles in progress. One of them is for EC pairing on a curve called BLS12-381, which's supposed to be much faster to do pairing on as opposed to the current BN128 curve supported by Ethereum. So this could be utilized by projects such as Socrates. In the last thing I spent some time on is E-WASM, which is our E-WASM translation tool. And I'm kind of excited about that one. So that's the update from me. Awesome, thanks for the update, Alex. Yeah, let's continue with updates and then maybe we'll move into questions after that. Cool, Jake, you wanna get a quick update what you're working on and maybe just feel free to introduce yourself as well. Hey guys, yeah, well, I'm Jake. I work on primarily HERA right now. And at the moment I'm working on kind of, well, the abstraction layer for the execution engine has been done for a while, but at the moment we're working on merging it into master in a more PR friendly way. And we're also laying out the foundation for implementing support for WAVM, as Alex said. Additionally, we're considering looking at JIT engines used in browsers, for example, SpiderMonkey or V8, to as alternative JIT engines for WebAssembly. Another thing I'm working on is a tool written in Rust to validate the properties of E-WASM contracts. More generally I've been referring to it as the ECI tool, but looking at it now it actually might be kind of like a prototype of the Sentinel contract for all the parts that don't involve metering. Yeah, that's pretty much it for me. Cool, thanks Jake. Jared, do you wanna do the same? Hey guys, I'm Jared. Lately I've been spending most of my time on infrastructure automation for the upcoming testnet, public testnet that we're working on. And I've also spent quite a bit of time lately just getting a full tool set for that ready. And so what that looks like is a block explorer, an E-WASM plug-in block explorer, and then a small smart contracts, E-WASM smart contract editing environment that I've called E-WASM Studio. Yeah, I've made various contributions to other E-WASM projects, but yeah, mostly everything I've been focused on is around testnet lately, so yep. Awesome, thanks Jared. Pablo? Hi, I'm mostly working on EMC, which is an API for VMs. That includes EVM, so-called one and E-WASM engines, and helping with some build system issues. And I'm maintaining C++ client of Ethereum. Awesome, thanks Pablo. Cool, I'm Lane and I'm primarily focused right now on a new tool chain that I'm very excited about using TypeScript. So actually it's called AssemblyScript, which is sort of a subset of TypeScript, which is strictly typed JavaScript. And so basically giving you the ability to write smart contracts in TypeScript, in AssemblyScript, and compile them, and run them, and test them, and everything integrated into the truffle suite, which is coming along really well, and I hope to be able to share that sort of publicly quite soon. Cool, okay, actually I think you wanted to talk about the design stuff a bit. Yeah, so basically some of you may have heard about it, but we had a decision hangout probably a month ago, and the main purpose of the decision hangout is kind of like the format of the all core devs meeting to discuss design issues which have been proposed. And the goal would be to actually agree on some of those and make decisions. It was a good learning curve, and we have adapted that and set up a process on the design repo right now. And the process is kind of, okay, maybe to start from the part that first of all, I'm not sure if everyone is aware of that, but we had kind of a revision system for the evasive specification, but that was scattered around between the different parts of the specification. So different parts have different revisions. For example, the one for the functions, the host functions contracts can import had a version number versus everything else. And we have changed that into a single revision. So the specification has a single revision at the moment. And right now it's a revision number three. And in the past couple of months, we were kind of in a limb over, it was really hard to make decisions or changes to this. And that has been solved now with a process where we have, we're using GitHub's project system to mark revisions. And right now we are discussing changes for revision four. And we plan to have a fixed amount of time for discussing changes for each revision. And once all the changes were given revision around the deadline are accepted, we bumped the version and that's the version of the spec. And at that point, the test suite and all the VMs we maintain will be bumped to that specific version. And from that point on, also contracts and other tooling can use those versions. Now to the point of how to actually discuss issues and changes is that probably is the more important one. So anybody is free to propose changes either as issues or even for requests. And when you do something like that, you should indicate better you plan to discuss it in this round of changes. So for example, in changes for revision four. And we would like to get as much feedback as possible on the issues and the poor requests. But one exception for this specific revision four I have mentioned is this is kind of an internal one in the sense that we would like to close it off really soon and just get going because it changes like basic things we weren't happy with. But the next one, revision five, plans to be a three month long discussion period. Planned to finish end of August. And then during this period, we plan to review every single exported host method deeply and provide suggestions how to improve every single one of those. So in that, I would invite everyone to take a part of. And then the next stage is called revision six, which is planned to be another month of discussion. I hope this kind of sets like a baseline on how we do changes in the specification. So if there are any questions regarding this process, please ask it now. Yeah, I don't think I have explained it clearly because I was just jumping around. So if anyone from the Wasm team wants to do a recap. I mean, just to set the stage a little bit here and just to provide a tiny bit of context that might be helpful. E-Wasm is sort of like a standard, right? So where we have this thing called, the name has changed a few times, but I still call that the EEI, right, the Ethereum environment interface. Actually, cause that's sort of the right term to use for the kind of standard we're designing or I always forget if we landed on a different name for that. I think that's also maybe one of the issues to be debated, but EEI originally only stood for the host functions contracts can import. So it's only a subset of the entire specification. So yeah, so we have this specification that originally was intended to be completely EVM compatible, which is to say that you could compile contracts using the E-Wasm tool chain, deploy them and they could sort of interact with existing EVM legacy by code contracts bi-directionally. But so the spec is now beginning to deviate a bit from full EVM compatibility, which I guess is part of the motivation for introducing the revision system here, right? Is it actually, is it the case that like revision one is the EVM compatible version and revision two is where we kind of begin to deviate or is it three, I can't remember? No, I would say we're gonna probably deviate deeply at revision five. So the old revision, we started revision zero and it's been kind of stable for two years at revision two, when we resumed the actual work on the project. And in from revision two to revision three, we only made small changes, still keeping full EVM compatibility and mostly the changes were to support Byzantium features. And now in revision four, which is the one we're working on currently, still maintains full EVM compatibility. We are just trying to clarify a couple of things to make it more easy to use. And by EVM compatibility here, we mostly mean because it can have two different meanings and we have to also explain this in the future much better, but it means two things. One of them is whether E-wasm contracts can interact with EVM contracts and EVM contracts can interact with E-wasm contracts. And the second one is whether we can implement EVM to wasm as a tool on top of this E-wasm API. And we may deviate in both of these different parts in the future. It might be helpful as an example. Could we bring up one or two concrete examples of elements that are up for discussion in the design repository and things that are sort of going to go into like revision four, things we talked about yesterday, for example, just to give a people a sense of the type of things we're struggling with here deciding about. So a good example for these tiny changes, which just make life easier, is one where there's an upcode in EVM called return, which stops execution and returns data. And the EI and E-wasm host functions, we have decided to use the very same name. So contracts written in whatever language would import a function called return, which explains what it tries to do, but isn't really convenient in many languages because return is usually a keyword. So in most of the languages, if you're importing a function called return, you have to work around a bit. So we decided to change it to call it finish. So probably is one of the examples. And another one, which is a bit more changed, is the one regarding block hash. The block hash function is doing the same thing as the block hash upcode in EVM is doing. And we have adapted that as opposed to the EVM, where in EVM, the only way to know whether it failed or not is it returns all zeros on the stack. In E-wasm with functions, we do have the ability to write to memory as well as to return a status code. So we decided to also return a status code indicating whether the block hash function was successful or it was a failure. So these are the kind of changes we are making right now. They're not really substantial. They don't break any kind of compatibility, but it just makes life easier. One other question that might be helpful to talk about is sort of the standards we're using or the process by which we're deciding how these things should work. So like POSIX is definitely a factor we're considering. Would you mind speaking briefly to that? Like how much is this informed by the EIP process? How much is it informed by existing standards? Like POSIX, how much is it something else? I mean, the EIP would be the process of how to make decisions, I guess kind of. And that regard, we do plan to move into that direction, especially with this so-called revision five. I guess that's as much as we can really see but the EIP process in regards to E-wasn't-designed. Yeah, sorry, I wasn't referring to the EIP process. I was referring to like the E-wasn't-designed process. When we're deciding, you know, whether things should have return values that indicate success or not. Like how do we make that decision? So the initial design was also kind of influenced by POSIX. And therefore, so there are like two aspects to this. One, the way E-wasn't, the one the way WebAssembly itself is designed and it's designed in a way that functions at least currently can only return a single value which is up to 64 bits in size. And that means if we are trying to return larger data which we do need to do a lot in Ethereum, we need to find other ways to do that. And the natural way is kind of to use a memory space and have these functions just referred to a memory location where they expect the output data to be written. So this is also basically this is what WebAssembly offers and this is the way POSIX is usually designed. So by POSIX, we mean how like Lipsy or any C APIs would work. So basically all of the functions were designed initially with this in mind. And now we are trying to at least in this stage we are trying to make sure that every single function in the specification follows this logic more closely. And there's no like two or three different ways of handling things. Any questions about any of this stuff? Or I don't know, maybe we could also open the floor to more general questions. Sorry guys, I'm out of questions. Someone else has to ask a question. So as far as the block hash status code works, like how is that implemented where you have like a return value and a status code and how are you checking both of those? Or like what is the syntax for that look like? That's actually a good question because there's a second outstanding design decision pending on that one. So basically how get block hash works is it's a function with two inputs. The first input is just 64 bit number for the block number. And the second parameter is a memory offset where it expects the actual block hash which is 256 bit wide to be written into. And lastly it can also return a value. And the value it returns is a zero on success or one on failure. And so far we have decided that in case of a failure, the input memory requested by the block hash function remains unchanged. So whatever was there in the memory prior to execution will be left as is. And there was a reason for this but there's also a reason to just zero out or decide on what kind of value that memory area should take in case of a failure. So there's a new design discussion where we review every single function which can have a failure and also has an output memory area and we should make a decision consistently how those should operate. Should all of them just keep the memory unchanged or should all of them set the memory to a specific value? Does that kind of answer the question? Yeah, definitely. I think that this is sort of the same way that I would view like the high level delegate call operation in Solidity where you have a status code directly returned but it's very unclear at least to developers that you can still access the data that was returned by that another high level calls by just like accessing return data. So is this like something that, I don't know, yeah, I guess is the decision now that we're going to put a pointer into all of these functions that and just everything will be copied to that location? Yeah, most of these actually work like that. And regarding delegate call or any kind of call, that is one of the changes which have been made in revision tree that any of the calls don't take memory pointer. So they don't write you any memory, rather the contract has to explicitly call return data copy to acquire the data. So basically there's only one way to receive the data from calls as opposed to the two different ways in EVM. So with the get block hash function, I guess you're expecting only a 32 byte return size. So I guess I'm wondering like, are you implementing some sort of a pointer type? How do we make it easy for developers to supply a destination to copy memory to and like they know that they're not overriding anything? So mostly this would be answered by the fact that, okay, this is like personal opinion, but I do feel that domain specific languages make a lot of sense for things like writing contracts. So for example, if you take the solidity plans to have E-wasm support and in that case, the compiler would hide all of that complexity from the user and there wouldn't really be any change to the user had to interact with the blockchain. But if you're speaking about more low level languages, for example, C, then the user has to be fully aware of what's going on and the middle layer between these would be probably assembly script or Rust. But yeah, I would say probably assembly script is kind of like a middle layer between these two where we're still not like a fully domain specific language, but probably it gives you better guarantees than what C is doing. Maybe Lynn can talk a bit more about this. Yeah, I mean, I think that's accurate in terms of where it falls, you know, relative to C and solidity. It's definitely not strictly a domain specific language. So far in the work I've done so far, I've made very, very small number of modifications to assembly script itself, right? So I'm just using decorators right now, primarily. But I think it's just too soon, just not enough of it has been built yet to sort of answer that in more depth. When changes get made to EVM, actually, Alex, I'm curious, I'm curious how this works, right? What is the process by which like solidity itself gets updated to add support for new like opcodes or changes and things like that? Like for example, return data copy. So it's solidity mostly, this may change because now we have an EVM version setting in a compiler. But before that we were really conservative when and had to introduce new opcodes. But since we have that setting, things may be a bit easier. But how it has been in the past is whenever a hard fork decision on the EIPs for a hard fork were really concrete, really close to acceptance at a confidence level was high. That was the point when we started to implement support for it. There's one caveat is that in many cases, this testing infrastructure of Ethereum relies on either code written in LLL or we're even code written in solidity. And in order to do that, they would need language support. And now with the, for the last like two years, solidity has that feature for inline assembly. But the funny thing is that both LLL and solidity is inline assembly, they rely on the same underlying assembler. So basically the first step usually we did is we just added the basic opcodes to the assembler which then made it accessible to LLL and inline assembly in solidity because this was needed for tests to be written. And then confidence was really high that all of these opcodes gonna make it into the main chain. Or if it was a backwards compatible change such as using revert because we wanted a failure anyway so we could just start using the revert opcode which caused the failure and after the change still caused the failure with less gas. So we could merge those upfront. But now I think it's just gonna work based on the EVM version requested during compilation. So one of the things that was mentioned was like can we create a method to, I guess provide a way to do EWASM to EVM and vice versa. How like divergent can these get before that becomes completely infeasible or is it even feasible with the current direction? Does anybody else from the team want to have a go at this? I feel lonely speaking here but I can get an answer if nobody else wants to. So I can try. So I believe tool called EVM to EWASM it's going to be feasible for a long time. It's with the incoming changes probably there will be like more work for the tool to be done at runtime to simulate EVM within the EWASM context. So, yeah so far we have quite long queue of changes that were proposed but just on a paper it looks like it would be possible to simulate EVM it will require just a bit more code to generate to support that. So you would get some additional so the mapping wouldn't be so like one to one you will do additional checks to support particular EVM opcode maybe to some conditional evaluation depending on some preconditions of that or maybe like execute three or four different EWASM host functions to support that. But it looks like at this moment there is nothing so big on the horizon to break the compatibility. I think the only aspect of that is to support EVM we are adding functions to the set of host functions that probably wouldn't end up there if we designed that from scratch. So that means maybe at some point we'll just forbid using them in pure EWASM contracts. So like we'll have the specification of them but depending on that if you're deploying the new EWASM contract they may be forbidden there and to support EVM to EWASM they might be available because EVM to EWASM will work with some privilege in the client. So we might end up to specifying the subset of functions and then subdivide them into subset and they might be useful in some context and not useful in others. So is EWASM to EVM planned? I guess that's where I was having a hard time figuring out how that would be possible if they're particularly divergent or is it just EVM to EWASM? It's just EVM to EWASM. The other way it's not something that would be useful I guess. And then I guess one of the things that I think other Alex mentioned was that you may have for example so if you have a call or a delegate call then you remove the parts of those opcodes that currently require specification for where you want the memory to be copied to so out and outsize. I actually really like that idea is that a change that would be mirrored in the EVM or is that just something that is planned entirely for EWASM? If I understand the question that's already in the EVM. It's only the matter that you actually have like two different ways of getting the output from a call and the newer one is also more flexible and more generic one. So in EWASM we just like we skipped the old one and we use the pattern with this return buffer that is accessible after the call and also solidity switch to that as well. So there's certainly a return buffer but what I had thought from what he had said is that specifically so a call opcode takes gas address value in size out outsize and you would remove the out and outsize so it would only take four or five arguments instead of seven on the stack. Is that what was being said or? Yeah I think so. I mean actually I'm not like super familiar with the calls in EVM spec yet but yeah that might be the case. Yeah in the EWASM version of the call those two have been removed so you understood that correctly but I think your question the second question you had was more like whether this change could also be proposed to EVM if I got that correctly. Right as I understand it there is some talk of EVM 1.5 and I'm not sure if that's still a possibility or if that's yeah. I think personally to remove those fields from the call seem kind of unlikely at the moment because that would break backwards compatibility so the mostly features if there was changes they were introduced with the new opcode as opposed to changing an old opcode so I think this specific change probably is unlikely to happen on the EVM but as regards to your second question regarding EVM 1.5 I think that's a separate discussion but we certainly have the right person on the call with Greg who is the main person pushing EVM 1.5 so he may be able to give you some ideas if Greg wants to speak. I'm here. I'm not sure I got a clear question to answer there. Yeah I think the question is just I don't want to hijack the EWASM call here but I guess the question was whether the out and outsize would be removed from the call-based opcodes and the EVM. No, no, Axix right. It's for backwards compatibility it's almost impossible to change anything that's already in the EVM. The best you can do is put in something new that works better and encourage people to not use the old stuff anymore and if once EVM 1.5 is supporting validation at least you can refuse to put stuff on the blockchain that does things the old way but you still have to keep supporting the old way forever. Makes sense. Blockchains never die. Yeah, one more. Sorry, what is the current line of thought on EWASM and EVM contracts interacting with each other? How does that work from a client perspective? Does it become really inefficient if you suddenly switch from one EVM to the other? I don't know how that works. So as of at least today and I think that probably is one of the motivations at least right now for the upcoming test net is to have compatibility and have the ability to run both kind of EVMs on the same network but this in the future this might change but I think for the test net this is one of the goals we have and then in terms of has seamless that is to the user it should be entirely seamless. If they keep using EVM code then obviously there's no change but one tutorial we are planning to work and publish is one where there is an EVM or more specifically a solidity contract which can be deployed and interacted with the usual tools such as remix and this solidity contract interacts with an other contract which is an EWASM contract. And for example, that other contract could be something similar to a pre-compile in terms of implementing a more heavy feature which is worth writing in a low-level language. So one example here could be that we deploy say Blake to be hashing as an EWASM contract and make it to speak to a solidity contract and the tutorial would explain how a solidity contract can speak to such an EWASM contract. Sure, I think it makes a lot of sense from someone that's maybe using the contracts but from I guess the node's perspective is really what I was wondering if you have to simulate running an EVM contract that calls into an EWASM contract are you then using two different programs to like mid-execution to run that and is that inefficient? So maybe I'm just gonna say one word before maybe handing over to Pavel if he wants to explain a bit more on that. But in practice, every single contract has its own enclave, its own instance of execution. So even with EWASM for every single new call we need to instantiate a new instance. And it doesn't really matter whether that's a WASM VM or that's an EVM interpreter. So it instantiates a new instance of the VM, whatever VM it's supposed to run? Yeah, but that's a case for EVM already. I'm not sure if Pavel, if you wanna expand a bit on that with EVMC or is it worth expanding on that? I think you pretty much answered my question anyway. Right, I guess I have a question now. What will everyone on this call what will be the first contract slash project? That you will deploy on the EWASM testnet? I tend to just shoot for the token contracts because it's something that's so easy to understand. And do you plan to write that in any language compilable to EWASM? At the time that the testnet is released what will be compilable to EWASM? Will Solidity exist yet or will I need to be using something like TypeScript or Rust or what? So CC++ and Rust are definitely working even today. I think AssemblyScript is close to completion at least in terms of usability of like basic things. I do hope and expect that AssemblyScript at the time of the testnet launch will be in a state where it can be used for basic tasks easily. Unfortunately, Solidity probably will take a bit longer. To be supported, but yeah, that's the end goal to also have Solidity to compile to it. When is the testnet launch? So we're aiming to launch it at before or around DevCon. Okay, that's like early November, right? Yeah, like end of October would be DevCon. So yeah, around that time. Hi, I'm Joe. So I work on a project called Arithmetica and it's a computational mathematics platform and we'll probably be interested in porting some of that to EWASM. I'm interested to know for EWASM project, what's kind of like the simplest way to get involved as far as like, do you just read the repo and then just start kind of like a branching or what? Hi, Joe, yeah, that sounds awesome. Probably the best thing that you could do is have a look at the design repo, some parts of it and join the Gitter channel if you're in Gitter because in Gitter we can give mostly instant feedback to questions. Yeah, I think we need to probably do some kind of tutorials because the design repo isn't the most digestible one. So if you do a deep dive into looking into the design repo, I'm sure you're gonna have a lot of questions and you could tell us where you got lost or how to improve it. Great, thank you. Yeah, we're very well aware that we can do better on documentation and that's high in our list of priorities, certainly as we're gearing up to launch the testnet. We'll be putting a lot of effort into tutorials, documentation, hopefully like sort of explainer videos, that kind of stuff as well. And we really need your help with those things. Understanding, like Alex asked, what are your priorities? What formats are the most helpful, that sort of stuff? Yeah, so it definitely wasn't a critique on it. I have just kind of had a cursory look at the at the GitHub repo and it seems to be, you know, put together, I'll definitely get in the getter channel and let you all know if I have any questions. Yeah, please definitely get onto the channel because the design repo probably doesn't explain a lot of things and it isn't really organized in a way that it can be digested. So you probably, yeah, it doesn't really explain how to run a node, which should be possible already and how to interact with it. And, you know, what kind of languages and how to use any of those languages together with EWASM because most of this information is scattered around in the different projects. So for example, some information can be found in the EWASM pre-compiles, which in a basic way explains, if someone is familiar with trust, explains how to compile Rust code to EWASM and what features can be used. And then Hera, which is the VM in the readme kind explains how to compile it and how to use it with CPP to run a node. But none of this is collected into a single place yet. I think a fun project could be to implement the EVM inside EWASM. Is that something that anyone's tried just as a side project or something? There was an EVM in Solidity project, I think, right? I don't remember how complete that was. I've seen a couple of those, yeah. But hey, that could have interesting implications for like Plasma and stuff, if we could actually get it working. Yeah, I think the most appealing aspect of it to me is just that that really, I guess, helps you understand what the conversion is between the two or, you know, at a low level, how they both work. Thanks Alex, are you volunteering to work on that? It's interesting to me, so maybe, I don't know. Sounds sort of interesting to me. A better EVM to WASM would be a more useful project. I think you'd learn the same things. EVM to WASM implemented on the EVM or on WASM? No, just turning it into a really good compiler rather than just what it is. But, well, maybe it's improved since I last looked. It's in C++ now, that's an improvement. Last I looked, it was a fairly, well, maybe it can't be much better without 1.5, but it just sort of chops it up and spits it out. And then it's left to the WASM compiler to try and re-optimize it. Yeah, yeah, that's still the case. So I think Alex was kind of pointing, well, I guess we have like this two different options. So with EVM to WASM currently is doing, it's translating EVM into WASM bytecode, which then can be executed. But another interesting project that's mentioned here would be compiling an EVM interpreter into WASM and running it as a contract. So instead of doing the compilation up front, just run it at the time. Sort of the difference between ahead of time and just in time compilation, I guess, right? Or I guess it's interpreting versus ahead of time compilation. So that would be a tool to take EVM contracts you had on the blockchain, basically convert them to WASM and stop using the old ones. I don't think that it would be a real tool. That kind of thing sounds really inefficient. It's just a for fun project. No, it would be very efficient. You wouldn't be translating it over and over again. You'd translate it once and stop using the old one. Yeah, I think I meant that the overhead of simulating the EVM within a WASM contract sounds like it would be far less efficient than just writing it in WASM or something like that. True, true. I think that the idea actually is good in terms of, so with EVM to WASM, one of the reasons for, so basically EVM to WASM was part of initially of a compatibility proposal where the, especially in like clients, would need to implement the EVM at all. They could just implement the WASM and then they could use EVM to WASM to still run EVM contracts. But lately, the main reason we have invested time in EVM to WASM was that with the help of it, we can tap into the testing speed of Ethereum. But as Greg has mentioned, the code could have some improvements and it isn't compatible with all the opcodes, at least in Byzantium. So compared to that, and that kind of seems like it's gonna take a while to make it fully compatible. But compared to that, your idea of compiling an already existing, maybe an already existing EVM interpreter, and here any C or Rust implementation comes to my mind, could be like a good way in the middle to tap into the testing suite. Now, when you're running like clients, all of these issues of attack surface go away. Like clients can run code of their own choosing. They're not part of the attack surface of the entire net in the same way. I don't understand the various kinds of nodes and how they interact as well as I should, but there's a level below which these attacks don't affect anything but the node that's being attacked. So these nodes can actually go ahead and use existing WASM implementations, get the performance out of them. Running EVM to WASM doesn't look so expensive. They can go ahead and cache the results of having done that. It's a whole different world there. And a lot of efficiencies can be gained in various ways that are not available in full nodes that have to be DOS hardened. Was that not understood or not interesting? No, sorry, Greg, I was just looking at something else, but thank you, I think that was good insight. And I was just actually looking at the clock because we are taking to the end of the one hour. So I was wondering if you have any other questions, topics to discuss? Cool, thank you guys for joining for asking questions, for listening. Alex, do we know what tempo we intended to do these calls on going forward? Is it two weeks, three weeks? I think we really wanted to do them every, yeah, two or three weeks, but last time we kind of leaned towards to do it every two weeks to be consistent and do it at the very same time. So just like the old core devs, people have an expectation when it is and there's not much deviation to that. So I think that would make sense for this call as well because then we could be better prepared and yeah, it probably is a good idea. But maybe two weeks is too short. Maybe we should do it every three weeks, I'm not sure. My gut tells me three weeks, every three weeks is enough for now, but maybe after the test has launched and we have more questions coming in and more to talk about, then maybe we could do it more often. One housekeeping thing, I was looking at the meeting kind of like times, right? And the ones for the US were off by an hour because we're in daylight time right now. Just FYI. Thanks, Joseph. Yeah, I appreciate that. I did double check the times, I'm pretty sure they're right, but I'll triple check and we'll be super careful of that going forward. I know that the one hour thing with the daylight time can be confusing. UTC is our friend. Yeah, that's what I did. I put it in my calendar as UTC and then I got the right time. Yeah, when in doubt, UTC prevails. I'm gonna run. Thank you guys so much. This has really been helpful. Great, excellent. Thank you for the great questions. Likewise, thanks guys. We should talk soon, Alex. Yeah, definitely. You're good.