 Hello everyone, can you hear me? I can hear you. Just so you know, this call is recorded and likely will be published in the future. Just like the previous ones were also published. I don't think we have any kind of agenda today, but feel free to ask any kind of questions and we'll try to answer them as we can. Just mention your name and ask as many questions as you want. Hey there, my name is Dan Ellison and I'd just like to know the fastest way to get up to speed or get a development environment going for E-Wazen. Anybody else wants to jump in? I guess the first question is what kind of language you're interested in? Well, I'm actually interested in the WebAssembly text format, most of all, not surprisingly I guess. I'd like to build a thin language on top of that that can compile to E-Wazen. So actually, let me just try to find it. There are a couple of languages like that already which try to be a tiny layer or the WebAssembly text format. That would be great. I think it's better to extend those. I think we'll just post it into the E-Wazen lobby. Oh, I see it now. Thank you. Yeah, there are a couple of them. Some of them are maintained, some are less maintained. I think there are at least two which try to achieve the same thing. Okay, I'll definitely take a look. Now on top of that, we have on the E-Wazen slash testnet repo, we have most of the user-facing documentation which includes how to compile Solidity and how to deploy it, how to compile other languages like C or Rust. It also has detail regarding connecting to the testnet and running a node. It has one section which is missing but we have an issue for that section which explains how to deploy a contract, a Wazen contract, because it needs to be wrapped into this deploy stage and we have a tool called Uazen Studio which is a website to do that or there's also a another tool written in Rust which is a common line tool to wrap the binary into a deployable binary. And we're going to add that description to the testnet repo hopefully before Monday. Okay, great. So the thing that wraps the deploying binary is it similar to the way the old smart contracts were constructed sort of like you've got this wrapper that sends, that returns the binary that needs to be deployed? Yes, that's correct. It's the same process. Okay, great. Thanks. Thank you for that information. I'm also giving you the link for the issue which tracks addition of this to the documentation. And I believe we don't have Paul on the call but Paul has written the WRC-20 challenge in handwritten in WebAssembly text. Yes, I've seen that. It's quite something. Yeah, probably that's the, I don't have the link, Andy, but probably that's the best way to start. I think so too. It seems like the ERC-20 standard is becoming a standard for examples of, I guess, contract system compatibility, not compatibility, but saying this is how the contract, this is what the contract should produce. I didn't say that right, of course, but it's sort of like an example contract these days. Yeah, that was the goal of it too, to have something fairly simple, yet useful. Yeah. And to see how it can be done with various languages targeting it wasn't. Yeah. Yeah, Hugo has posted the link to Paul's handwritten WebAssembly text on the channel. Thank you. I see that. Who joined just right now, feel free to ask any questions. We don't have any agenda. And I think Daniel's question was just answered right now. We open for any new questions. Hi, this is Achala from KIPF Foundation. Yeah, I just wanted to know how the Wasm Chisel will work. Like, I tried to deploy some REST contact that is WRC contact. I got from the WRC link. But I'm getting the create error. I tried to add the Wasm Chisel in my terminal. So how can I fix those issues? Sorry, I didn't fully get it, but I think I've seen the work you guys were doing. What is the problem you're facing with the Wasm Chisel? Like, I tried to add the dependent Wasm Chisel package in my terminal. Can I do like that? Yes, you could. But right now, probably easier way to use it by installing it as a command line tool. And just using the command line version of it. So you can just use the command line. So you just run cargo install chisel on the command line. Yeah, I tried. And then if you did that, then you should be able to run chisel on the command line and it should work. No, it's not working for me. So I tried to add the package in my terminal, but it is giving the create error. Yeah, I think it will be easier to resolve this if you write it down to the channel. And probably it's easier, more interactive to write it in text. Maybe just write down the comments you have used and what system you're using. Yeah, sure. Thank you. Can you explain, Alex, what exactly is chisel doing? Yes, one second. Achala, if I pronounce your name correctly, I posted the command I used. And at least on the Mac it seems to be working. But just please write down how you tried to use it. Yeah, sure. Okay, regarding what chisel or wasm chisel is, it is, first of all, library, implementing a couple of smaller transformation and validation steps on WebAssembly in general, not related to e-wasm only. But it does have some steps, transformation steps and validation steps specific to e-wasm. And secondly, it also has a command line tool which uses this library. And the command line tool will have two ways to use it. One way is just run it on a given file and specify the step to be done. And the other option, which isn't implemented yet, to have a configuration file. And in a configuration file, one can specify a path pointing to a wasm bytecode. And different steps can be then defined for that given bytecode. To explain what these steps could be or what these steps are, as an example, one transformation step we already have implemented now is fixing the import statements in WebAssembly too much what e-wasm requires. Now, imports in WebAssembly are two level. The first level is the actual name of the import. And e-wasm itself requires that the namespace is called Ethereum. And the imports are such as use gas, get call data, external code copy, etc. Most of the languages, most of the general-purpose languages, which can be compiled to WebAssembly, don't have an option to specify a namespace. And instead, they just use a single namespace called env. And that means compiling most of these, using most of these languages will result in a bytecode which cannot be used on e-wasm without any changes. Chisors should make this fairly simple because it has a step to translate these, so to say wrong imports to the right ones. Apart from transformations, it also has validation. And one of the validation, sorry, my internal cutoff, so one of the validation steps it is doing, it validates that a bytecode has all the correct imports, and use floating point, etc. So eventually, this wasm-chisel library is also used in the central contract, which is a key part of e-wasm. I don't know if you have any more specific questions about what wasm-chisel is doing, or if this was good enough as an explanation. Yeah, it was perfect. So, Alex, once you run this wasm-chisel tool on a wasm binary, what will be the next step to deploying this contract to the e-wasm testnet? So one transformation we actually have implemented is doing the deployment in Chisel. So this transformation just takes a wasm bytecode as an input and then wraps it into this deployment stage. Unfortunately, this is not enabled in the command line yet, so it cannot be used yet, but soon it should be there. And when that is released, that means one can take any wasm bytecode compiled by any general-purpose language, and it can translate this bytecode into fully working e-wasm bytecode. Another important step it will support is removing unwanted data from the bytecode, such as unused functions or unused standard library functions. And in the future, it should also be possible to replace some fairly commonly used implementations of memcopy, memset, etc., with a more optimized version and or use system libraries in e-wasm to provide that functionality. So eventually in the future, it should not only help in generating working bytecode, but also generate a more optimized bytecode. Okay, thank you. I was wondering about the gas limit, like what's planned to be the gas limit for, like, if we get a version of that herald that uses e-wasm, seems like the e-wasm instructions, they are, like, more simple than evm, so probably the gas limit will be larger. Well, I think it's too early to say anything about this. So I think it's much more complex than just changing the overall block gas limit. As you may know, there's, like, lots of discussions and work into, for example, separating costs for storage from computation and, like, how to limit the Ethereum state inflation from the computational cost, which is not stored anywhere. So if that can be solved, even for current Ethereum blockchain, we can increase the block limit for computer, the gas limit for computations. And for web assembly, that would be proportionally, I think, so depending how performant it is, in most cases, we can just bring it up or, like, make the computation cheaper accordingly. I have to get going, but thanks for this, everyone. If I have any more questions, I'll put them in the Gitter channel. Thank you, Daniel. Yep. See you next time. See you next time. Bye-bye. Okay, the only plan for 20 minutes, but if there's also a new person who joined meanwhile, Clive, if I pronounce it properly. If you guys have any other questions, I think we can see another, like, seven minutes to make it 30 minutes in total. All right, then I think we will hang up in that case. So thank you, everyone, for joining today. Great questions. And hope to talk to you soon at the next call. Thank you. Bye-bye. Thank you. Oh, hold on a second. There's a chat message. Oh, thank you. Yeah. All right. See you then. Bye-bye. Bye, everyone.