 good to go. Alright, everyone. This is the real, this is the first thing you're waiting for here today. Just really going to be a very nice discussion session here. Hey, have a seat. In the right room. This is the place to be. You can tell the friends about it afterwards. Okay, so, I think, so before we start, I guess we have a couple of things to clarify here. Maybe first of all, I'm a Skype. My name's Eric. Eric. And we're from Steps. We work on Embark. Excuse me. And you probably noticed already that the title of this talk here, Building EWars and Depths with Embark V5, is a little bit different from what you see in your little DevCon application. This is due to some reasons. So basically, the description of the talk doesn't entirely match what we do here today because we have to change a little bit based on some time constraints. So basically, we were a two-hour talk workshop and then we got cut down to 40 minutes. We had to shuffle some things around. So out of the 10 points that we listed in the description, you might get maybe one or two. And also that at the same time also changed the format a little bit. So it's not really going to be a workshop where you, you know, coach yourself. It's more going to be like a little bit of a theory session. And then afterwards, we can demo some stuff and maybe walk you through some code and maybe have some questions and then hopefully we get some answers. But just, yeah, just also clarify. Our goal for this wasn't to be an expert on EWars. If you have any EWars questions, Sean will probably answer them hopefully. He tries best. Our goal for this was to integrate the EWars contract into EWars. So just to help developers build contracts using EWars essentially. And before they're using EWars. So that's what we expected. Okay. Any questions at this point? Okay. So then maybe like, yeah. First up, was anybody at the EWars talk yesterday? Was it yesterday? Yeah. So we've been to that talk and it actually turned out that, you know, there's a lot of things still in the making. And so what we're going to show you today is, you know, stuff that works for the demo purposes, but it's probably not like in a production ready state. So just keep that in mind. It's more like exploration of what we can do with a mark. And then, you know, flexibility of the guys and so on and so forth. The main point there is that we want to show you how you can extend a mark to do just about anything you want, including some very, very experimental stuff like EWars stuff. All right. So just to give a little bit of an agenda of what we talked about today. So we talked about EWars, just a little bit. Then we're going to talk about the NIM programming language. Anybody have about NIM before? Okay. That's what we're talking about. That's awesome. Everybody here is going to learn something new today. And then there is a very mysterious project called NIM Play, which actually enables us to write smart contracts in NIM. And then we will show you a demo of how that works. And then this is actually what's going to use EWars momentarily. All right. So let's start off with, if you're WebAssembly more, you wasn't enjoyed. I mean, you probably have heard about EWars before in some way, at least like the acronym, right? So EWars was a restricted subset of WebAssembly to be used for smart contracts in Ethereum. And now if you're like new to this stuff, or more experts or whatever, like we are, then you might be wondering, what is WebAssembly actually in the first place? So WebAssembly, for those of you who don't know, is a binary structure format for the stick-based VM. So it's actually an open standard for the web that aims to provide developers an API in a way to run very fast programs and nearly native speakers. It's very portable as well. So basically you need to imagine, you can write programs in any language that transpile to WebAssembly, so you will never write WebAssembly yourself. It's an assembly language after all. And then computers are really good at translating that WebAssembly code to CPU instructions, which is why it turns out to be very fast. Yeah, so that, in general, about WebAssembly, there's actually a couple of browsers that already ship that. I believe that Firefox already has WebAssembly VM integrated so we can run stuff in WebAssembly in the browser today. So this is basically the web thing. So what that means in practice, you have your Swiss code turned into a wasm code in some way. There must be some sort of transmitter or compiler for it. And then ideally, since you have this wasm code, you can run on different CPU architectures because they can translate that code easily, which also means that that code is very portable. That's a good thing, obviously. There's generally a textual format and a binary format, so the textual format is like the assembly code that you can actually read as a human being. Again, this is not the code that you would actually write. It's the code that you can, the code that you can actually inspect and that you'll put in which you read. And then this is the binary version of that. So you can execute it. You could write it if you wanted to. Yeah. And yeah, so coming back to, it wasn't so doubtful that we know, like, a rough idea of what WebAssembly is. So E-wasm is a restricted subset of WebAssembly. So I'm not actually sure if the wording is quite correct. Maybe, maybe, Jarkis, so I might see if that's fine. Yeah. So essentially what that would mean is that if you write E-wasm code, it's automatically also valid. I want some code because it's a subset. But, you know, what does it mean, a restricted subset? So there's obviously, there's some very specific semantics to E-wasm that make E-wasm what it is compared to WebAssembly. And there are a couple of things. So we have, actually, maybe, can I open this here? It looks good. So there, the E-wasm VM kind of like, comes with like certain, yeah, semantics specific for Ethereum. I mean, we don't have to read this here, but there's this E-wasm website with all sorts of resources about E-wasm. So basically what makes E-wasm code, E-wasm code, is the environment that runs it eventually because it comes with certain semantics. That also includes things like a E-wasm contract interface. Basically an interface that allows you to have an E-wasm code that knows how to talk to contracts, smart contract APIs. And a couple of other things. Oh, sorry, there you go. There's also built-in system contracts. If you look at that, it's quite interesting. I'm not sure how hot today that still is, but there's like a central contract, EVM-transcom pilot contract. So like different addresses that are already available in that environment that your code runs in and that could also mean that, for example, you know, you have like certain functions like hash fonts and functions and stuff, as contracts, that's how I understand that you can call them from your own contracts within that environment again, right? So this is obviously stuff that would not be in plain WebAssembly available. You have that in your E-wasm environment. Coming back to the semantics. Non-deterministic behavior, basically, you know, removing floating points from that environment. And then there's this metering system which is kind of like the new gas. So in a way, like E-wasm is wasm minus the non-deterministic behavior and then plus the metering plus some system contracts. Does that make sense? Yeah. Nice. You can ask John. Also please feel free, I guess, to ask questions. Yeah, yeah. We're very open, you know, format. There's the question. Oh, there. If the performance of WebAssembly is close to native, what's the point of using system contracts that are part coded by the pre-composed? So the reason for it this time is basically the E-wasm team wasn't able to make it as fast and also because of gas costs, they're mispriced at the moment. So if you go and look at how much a SHA-256 or a SHA-3 costs you and you had to implement it in WebAssembly raw, it would be mispriced. So you'd suddenly be spending, like, 10 times more gas. So that was kind of what, just to add to that, what the talk was about, as well as referring to is basically using pre-compiled and using the optimized interpreter. Basically, Ethereum 1 is just as fast as E-wasm. That's a non-optimized E-wasm. That's how I understood it. So at this point in time, they're using pre-compiled and optimized interpreters to get really fast speeds, but E-wasm will be faster. So what I understood right now that when we write a smart contract, we compile it. Byte code, let's say, byline code, not byline code. It's in between. The EDM is going to interpret that code. However, the E-wasm is an embedded code that's going to be compiled to be native code. It means to me that there is a hacking to the virtual machine itself that should run that code, which means that when it reaches the area of the native code, it's going to start executing it. Is this correct? So at this time it's not a compiled. It's still interpreted. Is that also what they're talking about? So that's what they were talking about from the talk yesterday. There are certain problems with using a compiled VM, especially security concerns with a jet bomb if it's a jet based one. Actually, could we bring this up so that the next slide is visualizing this a little bit? So from a classical standpoint of view, the way we build dApps today with solidity and stuff, for example, we run it through a solidity compiler, and then you get an ABI and a Byte code, and then eventually the Byte code is what ends up in the VM. That's how I look at the chain that lets you talk to your contract instance. Actually, very similar, is what happens with E-wasn't as well. Instead of writing your code, all of them you can write in solidity too. It doesn't really matter as long as it transpiles E-wasn't eventually. So you have your code, at this point you can use C, C++, Rust, or NIM, which we touch on in a second. You get your E-wasn't code out of that, and then that's going to get run inside of that E-wasn't environment. You still get an ABI code as well, so it's not in the graphic right now, but you get the idea. From a flow point of view, it's still the same process. You're just dealing with a different language and a different format. It wasn't itself directly in the EBM. So it will be dual stack, so at the point that they visualized this, it would be that you have a mark over when you deploy, and it will know it's E-wasn't, and you'll stack the E-switch between them. I'm not talking about deployment, I'm talking about compilation. So E-wasn't should be compiled to be understood by the EBM. Yes. Well, but... Yeah, so that it's... Yeah, like so... It's just actually an otherwise run time, if that makes sense. Okay, so from C to E-wasn't, some sorts of compilation. Yes. That's going to generate a code that could be understood by the EBM. Well, it's still a wasm run time that has EBM hooks as functions. I can show you later as well. We'll do it all down for you. Thank you. Good answers as well. So in continuation to that, in a different perspective, can we call that in a web-asm-plea-native run time, we have a metering library or something that... talks to completely in a different perspective? Yes. Because that is the missing piece, right? Yeah, if you look earlier at the slide, there was about... the metering currently gets injected, but you could still do the metering inside the servers as well, which is what I would prefer, but I decided to inject the metering. So it could be still treated as a package of a library that can transform the... Yes. Sure. All right, so eventually what that means, given what we've just seen, the benefits of using E-wasn't would be, first of all, you can actually write your smart contracts in any language. Anything that transpiles or compiles E-wasn't, which is kind of cool, but then you don't necessarily just tie to Solidity or Viper or whatever. So, originally, it's going to be a fast execution. There's also better library support, because, you know, since you can use any language, you probably can take advantage of a very big ecosystem of libraries and plugins that your language supports. And then, after all, there's also a community that E-wasn't is an open standard, so we have a lot of people who talk to about this stuff, but I can help you as well. All right, so, given that, we will touch a little bit on one language called NIM. That's the thing that nobody has heard about in the industry. And also, there's another expert here in that language. And so NIM is just yet another language that can compile or compile to E-wasn't. So, it's one potential candidate for you to write your smart contracts in the future. So, what is it? NIM is a Steadily Type Compile Systems Programming Language. If you look at the language and we'll see some code in a minute, it looks a little bit like a mix of, I would say, like JavaScript, Python. You, like, smash it together, and then maybe a little bit of touch within there as well. So, the idea is that NIM, it aims to be very expressive and elegant and, you know, have a very intuitive syntax. And it aims for native performance as well. So, if you look at the website, the official website here, there's this features section, and you also see already some code there. But basically, it, you know, it claims that it has native performance with the state of the optimization. So, the point here is that NIM actually also compiles to, like, C code, which means, you know, you can put the C code through a C compiler, and, you know, those are really optimized these days because there's, like, four weeks of experience going in there. And so, yeah, that's a pretty good thing, I guess. So, yeah, that's why we have here, you know, translation targets, like possible ones, or Cs2++, JavaScript, if it wasn't. Even JavaScript, so that's also pretty cool. Like, if you like to build web applications but you don't like JavaScript or TypeScript, whatever, you could use NIM, you know, that's your jam. And what's also really cool about the language itself, which is kind of like a key point here of this whole thing is that it supports data programming using generics and macros. Now, why is that interesting? So, first of all, some NIM code just to get a general idea what the language looks like, right, Python, JavaScript, smash it together. It looks kind of like that but it's just some weird indentation syntax as well, I think. If you're not used to that, it looks good first, but I think, you know, it's just a matter of getting used to it. So, you see there's like different things like iterators and you can create your own types and object structures. There's important statements as well, you know, if you've used any other language, you should probably get an idea of what this stuff is. So now, but macros, you know, being one feature of that language, has anybody used macros before in any other language, you know, from all the time? Okay, so for those who don't know, special functions that execute at compile time, so you can basically define functions that expand to the language that you're using and that expansion happens at compile time. And that essentially enables you to create custom domain-specific languages, which is a very, very powerful thing. And, yeah, so here's, I'm probably not the best example. You don't have to read and understand this code. I really just took it from the website just to give an example of what a macro could look like. And then, this is a debug macro. You see, like, you define it with a macro keyword and then, you know, you give it some, some logic and tell it what to do. And eventually, once you've defined a macro, you can, you can, like, call it like that. So you can find an array here, a string, and then we pass it to that function. So it looks like a normal function at this point. So you might wonder, like, what's the point really? You can just use all functions over there. But then, it turns out, you can actually go, go way beyond that. Again, like, if we, if we come back to the, the idea of creating a DSL, you can have some language that would, you know, with its own semantics that gets very powerful. And there's, there's this project that this guy is working on. It's called NIMPlay. NIMPlay is exactly that, right? It takes the power of macros and creates a DSL for smart contracts. Again, keep in mind, like, NIM transpiles to EOSP as well. So you basically get smart contracts in NIM that you can transpile to EOSP and then, essentially. So, right, NIMPlay is a domain-specific language for running smart contracts using NIM macros. Again, given what we've learned before. Essentially, that means NIMPlay is just a set of macros and, yeah, it takes care of, like, expanding it to NIM code. All right, so, another cool visualization. So, you write your NIMPlay contracts. They get expended to NIM code. So you, actually, you write NIM but you use the macros syntax. You expend it to the actual NIM code. Again, the compile time macros are executed at compile time. That code, that's sort of maybe in your contract code, right? It's going to look more familiar to you and easier to write your contracts in NIMPlay. It would be to write them in NIM by itself. So, it's kind of like a convenience feature. Yeah, right. So, once we expended that to NIMP, again, the whole process starts to oversee transpalting. It wasn't from there. It ends up purchasing. And, again, just to stress it once more, essentially, this could work with any language that transpalting wasn't. Ideally, it supports something like macros, like Rust, for example, is the same thing. And here's the sample code. This is our go-to example for a very simple smart contract that simply stores, you know, simple storage, like sets and gets a value. This is a simple storage contract written in NIMPlay, essentially. So, just that you get an idea. There are probably some things here that, you know, don't really... I think the main functions of construct is not really supported at this point. So, you get, like, an hour demo that little children are not going to be there, but just to get an idea. Take some pictures. It's good. But really, the important thing to look at are the first two methods, the two procs, set and get. I mean, when you're doing a set, you're just setting a global variable, store data to whatever your value is, and when you do a get, you just get that value. So, imagine this is a contract employee and, you know, in Ethereum, you'd be just calling the set method to set the value of the contract and going to get... So, you'd be sending a set transaction and calling the get to get your value up. It's very simple. I'm going to show you this. Is the main here representing the constructor? Well, we don't have... I haven't done the constructor project. It requires a different transaction to be bolted. So, the main is usually in... The actual entry point is usually just like salinity, or, I know, you would just have a... It'll probably change the syntax that you say is just a constructor. It still works that way. Because, like, main is a bad word to use for that structure. So, top-end of the transaction. Yeah, and in salinity, we don't have entry point. Uh, except... Yes, we don't. In salinity, we don't have the entry point because of the way the language works that it just starts executing from the beginning. But in wasm, we have an entry point which is usually the main function. Yeah, like a main exported function. Any other questions? Okay, cool. So, there's this thing. Uh... Small problem. Small problem. Spoiler alert. So, if you take a little bit of the installation instructions and if you happen to run other machines than Macbooks, for example, uh... Installation of NIP play can be... can be a little bit hard. So, there's, like, this whole process that you have to go through. And, um, now, to kind of, like, draw the line back to NABARC, you know, the tool that we work at, who's used NABARC before? Who's heard about NABARC before? Wow, okay, that's really cool. Check out NABARC. Yeah, I mean, I think this is really good for you to be here. By the way, you have 10 minutes left. You have 10 minutes left? Okay, then you really do get going. All right, so, um... So, basically, what we want to do is 15 minutes. Okay, I want to slow down a little bit. So, since this setup is this kind of hard to do, um, we want to help with NABARC, which, we're going to dive into it in a second, um, it's basically a tool that helps you build decentralized applications. So, when you write your smart contracts, you want to compile and deploy them and test them, you know, you want to have your front end, you know, that talks to them, and so on and so forth. So, if you want, that gives you, like, all of the different features that you need to make the process very easy. And one thing that comes with it is basically a plug-in ecosystem and a plug-in API that enables you and us, but also you, um, to extend NABARC and its features. And so, you can basically also create a plug-in in that, you know, a key system, right? So, to give you a little bit of an idea of what NABARC looks like, it's a command line tool. You can run it on your command line. In the NABARC project, you get, like, this dashboard that tells you who are the contracts that we're compiling and deploying. You get, like, logging outputs, you know, transaction hashes, gas costs and everything. So, it's like your, you know, it's like a whole, like, you know, conflict you into your depth development. Yeah, what? Yes. What are the contracts through that interface? You can top-level it as well, which is pretty nice. Oh. Oh, by the way, this is Michael over there. Sorry, I took the wrong train. Or the train going in the opposite direction. We have the father of NABARC here as well. You, Ray, and Richard, and other team members. So, you can talk to all of us. Speaking of cockpit, there's also web interface that comes with NABARC. With NABARC, you can basically it spins up for you a web server with cockpit, which is all one flight. Basically, that's your intent in the same way, but in a bit more rich way, I would say. You still have the rebel there. Yes. It's kind of like what you get at the CLI just on steroids. All right, so, and then, again, there's plugins. Like NABARC has tons of plugins. People can build plugins. There's an API. So, you have plugins for remakes, ethos, scans, sellers, snarks. With X. Yeah, with X. There's like tons of stuff. Again, you can build your own. We have docs here. So, in case you haven't heard about NABARC before, so go to NABARC.status.im and then there's like, you know, we put a lot of time making our documentation as good as possible. So, there's lots of docs about how to do things like creating plugins and stuff. And so, yeah. How cool would it be if we could use NABARC and new play and create a plugin that makes this whole process easy so that you can actually go ahead and write your smart contracts in a language like NABARC. Ideally, it would look something like this, right? So, like step one, you would install packages. You wouldn't install NABARC. You create a new project with it. There's a new command, right? You would CD it to it. You would install a plugin, something like NABARC new compiler for example. Configure it and then you're done in an ideal world. And I'm very happy to tell you that Eric is going to present you that. By the way, this is like what the plugin configuration could look like. There's an NABARC JSON file coming with every NABARC project. If you have other plugins, usually they come with their own custom properties that you can configure them. In this case, we don't even need to configure any configuration here. And, yeah, we go over to Eric, to the right corner. So, I am going to show you a demo first. I'm going to show you the demo first. And then, with the remaining title, kind of digging into some of the turtles, but and then there are any questions as we go. One thing I forgot to do before this, some of this is going to take a little while, so I've got my elevator music on cue. All right, so okay, so what we're going to do is we're going to do some before there was an embark CLI command. So we're going to run, we're going to do a embark run. That's actually going to spin up our dev, so I'm just going to do a embark run. Oh, yeah. Is that maybe too much? So, what this is going to do is it basically spins up all the services that we need to run our dev. So, so you can see like Pascal showed in the slides. Here's our dashboard. And this is basically starting up it's starting up a node for us, a local node. It's starting up any storage services that we might need, which we don't need. We don't need communication services like Pittsburgh, which we don't need. E&S services as well. Again, we don't need that for this demo, but it'll do that on all fours based on our configuration with that. So, as you can see, what it's also done after starting up the node is it's deployed our contract models. Well, it's if you look at the top here, it's deployed the simple storage one. This is our solidity contract to the top one. Now, the one underneath it is the exact same thing written in. Okay, so the code that we saw before, the simple storage written in, that's this guy. And it's taking a little while to deploy because it's on Testnet. We are connected to our own node project thing. No, I'm pretty sure it's the Wi-Fi. It's gone into the Wi-Fi. I mean, it has to be the Wi-Fi, right? You can try it once again, otherwise it's pretty short. You can try it once again, then otherwise it gets pretty short. So that you also test that currently it's very small. There's not a lot of nodes. Things can go wrong. It's one of the downsides of this right now. And a lot of it has to do with the fact that EWASM is undergoing a lot of changes. Anybody go to the EWASM workshop yesterday? No. Did you guys already talk about that? That's what happens when you take a late train, man. I took the wrong train. That was a problem. Thank you. It's important to know if our contracts are on the track. And we can wait for this. Can you open this to show the contract? Yes. All right. Show the code. Up, up, deploying, come on. Show the code. It starts with the receipt. Okay, so just to quickly show you the file system of our DAP. This is actually not a DAP. Just give me a second. I want to let this deploy so I don't mess this up. All right, fine, fine, fine. It does, like, work. Fantastic. I'm running that most of it. Hey, what? Hey, you're right. All right, so let's check it out. So basically, you can see here we've got a web server that's spun up. This is for our front end. This is for the DAP. And also we have a web server server for company. That was the screenshot I was going to show you before. I think these are working like all the services are working. You can do that using this link, but we're not going to do that today. We're just going to look at the front end of our demo, which is a really, really small React demo. I've got a few from open already. So, green lights. Hey. All right, all right, all right. Okay, so it's slow on just that. Can you see? Oh, yes. So we have two tabs here. One is for the solidity contract, which is this one that's showing right now. And then we have the NIM contract. So we're just interacting with two different contracts. This is all using what embark does in the background as it co-generates an object for us, like a contract object that we can then call methods inside of the contract. So for example, we get a value that's stored. If you guys remember what the contract looks like, just getting a value that's stored in the contract. The value is 100. So if we then change that to 53, set, that will eventually get set. It's just a bit slow because it's untested. So, at some point it's going to change. So I have a question. Yes. Is it because you're using the block here, I need to go back and sign transactions? Yeah, this is a good question. So the question is like, and the way embark works right now is you can configure wallet accounts inside of your configuration for your debt. So when you want to go create a transaction on the front end, instead of signing a transaction using metamask, embark will actually send a transaction through embark's proxy. And embark will pick it up and say, hey, you're trying to send this transaction. Is this from an account that embark controls the wallet? If it is, of course we have access to the private key, we can sign the transaction. In development. Very important. I mean, embark becomes your wallet at that point. So this was working. I promise. This isn't so difficult. You can imagine that the value usually is set and you can call and you can send it in one way. Let's try this in one way. This is not just mining. Nope. Nope. I'm trying to help you. I'll show the code while he's setting this up. So, basically this is, I'm sorry, you know what I need to do. So this is the contract that we're looking at, but I'm going to show you the file system a little bit first. So if you look at the top level of our file system, there's a few components here. The front end stuff is under app. We've got our configuration files under config, contracts under contracts, a disk, obviously. There's no front end. The only thing you need to really see here is the marketing system. So, what's cool about this is that you can see where our plugin just set up. Okay, so we've got this plugin here. This option is, we don't actually need it, but again, as Pascal was mentioning, you need custom options for your custom plugins here. So, don't worry about that one for now, but you can just see that we have the compiler plugins set up. That's how you install it. So once you have them installed into your app, you just enable it using as an object of plugins. So, in our contracts, we've got our simple storage solidity contract. So, we can set up the value, and set stored data to that value, and then we can also do the same thing that's set, so we can actually set the stored data value to where we pass in, and then to get, just pull it up. I think crazy. And looking at NIM, it's exactly the same thing. So, we can set a value using this set function, get the value using the get function. Quickly looking at config, there's configuration for blockchain. So, how you want to configure your node, and any of those accounts, like those walled accounts we were talking about earlier. So, you can basically add a mnemonic, and sign transactions that way. Communications for things like whisper, if you want to add a whisper to your three, it's left. I'm good, I'm good. How are you doing? It's good to be pleased, man. I'm pleased. All right. So, to look at in these, I don't want to get into these, but once you start looking at it, it's a lot to see. Any burning questions? Yeah. Well, I was just wondering, is it possible currently for this simple storage NIM contract to read? They don't like this sort of simplicity, that storage out of the solidity ring one? Like, how do these two be? So, currently it doesn't do a stack? No, no, okay, currently. But I think the idea, well, at the point when they made it was that you can switch and then, yes, you'll be able to read the same story. Especially with you, when you think about, like, you're going to have to hard fork at some points and then you'd have to run for a few years. So, you'd have to. That sounds hard. Great. Sorry, and I was going to show you just quickly in the last few minutes we have, and this is just full of NIM works. What did you say? Because there's, like, one thing that you might be interested in. You're going to stay here. All right, you can see this. Wonderful. So, you see there's this message of value set to 100. I did not just code it in there right now. I actually set the value. So this is the NIM contract right now. I set the value to 100. I'm going to call getValue. Can we change it? Can we change it? Yeah, let's do that. Well, should we get a number from the audience? Yeah, yeah. Let's pick a number. Any number. There was no clue. There we go. Any other numbers? No, no, no. Get the number. Let's get another number. Yeah. Thanks for warming them up. Okay. Yeah, well, you see this works. So what is the version of NIM? Good point. This is a custom development version that you don't have right now. Now, if you install, like, at this point, it's a version that's, like, latest master running on. Yeah, you can see a little bit of the program. So these are the two value changes, and then, so if you go on recent transactions, you can see where the contract was deployed. And you guys have tested it? You see it. And then the two set functions that you called one earlier when you were looking, and then you called the 100 actually. So yeah, it was 100 and 101 probably. Yeah, and then going to go into the transaction and then forwarding on the contract. It's quite cool. You can pay, you can even browse the data. You will hold on the contract to the two. The two. And then 0x49. 0x49. And then your storage tab. Cool. Yeah, so this is actually cool because we can, some of the things that we've discussed before. So here you can see setting the value. And then it does 0 because it's the first variable in the contract. So you just ping them into that. And then if you check the last code where I can share someone asked about the gas injection, and we'll see this is the calls in the current field of how the injection was. So they do a single pause and they make JP's. And basically if your contract fails together, they just, like, touch a little bit of gas. Any other questions? Okay, well then I have a question. Yes, because you don't want to write your own interpreter? So it was, I don't know why they did it specifically, but I think it's because they wanted to test all the interfaces and compile time available. And not all of them exposed the interpreter to do for the county. So doing it this way allowed them to test all of them. You found the star.