 Hello. I'm Yuri. I'm the lead developer of the embark framework by status. We're trying to do a framework that makes it as easy as possible to develop decentralized applications. And I do mean decentralized applications in the true sense of the word. So, dApps that really use the entire decentralized stack that is currently available. And we're really excited to talk today about embark four. And we also have a few other surprises. First, though, we'll just do a quick detour for embark three and what happened this year. For those of you that might not be familiar with embark. So, this year, back in May, status announced that it was supporting embark. And the team has grown a lot. We're now seven members full-time working on this. And so, first of all, embark goes far beyond just the smart contracts. It does support Solidity and other languages like Viper and Bamboo out of the box. And you can even use them together if you want to. But it also supports Swarm, IPFS, Whisper, and recently ENS as more components in the stack. And we can also add other technologies through the plugin API. And we're working with some other projects to add their projects to embark. So, the first big difference in embark with other tools is that the contracts, you describe the relationship between the contracts. So, instead of very complex and often spaghetti-like migrations, all you have to do is really describe all contracts are related to each other and what actions you might want to do once a contract is deployed and other events. And embark will automatically figure out what is the best way to deploy those contracts to reflect the state that you just described. And this also affects if you change a particular contract, it will not deploy everything, it will deploy only what's actually needed to, again, reflect that particular configuration. So, a status uses embark extensively internally for DApps and smart contracts. This is a more or less real example. I modified a lot for the purposes of this presentation. But the first thing is that there are environments. So, there's the special default environment, which is a sort of environment that applies to every other environment. And then you can override in a specific environment any particular configurations that you might need. So, in this case, there is this MiniMe token factory, which it's already deployed on Robson. So, we define it there. So, when we deploy to Robson, it will take the configuration of defaults, merge it with Robson. And in that case, we will not try to redeploy MiniMe token factory, we'll just reuse that address. Then, here you can see there's a MiniMe token factory is being passed as a string with a dollar sign. And this is a special directive that it tells embark that this contract for this argument needs the address of this contract. So, embark with this knows that it first needs to deploy MiniMe token factory or get that address. And only then it should deploy this STT token. There's also other directives like deploy F, which will only deploy if a particular condition is true. That can be something in JavaScript code or can be something in a contract. And you can also do multiple actions when a contract deploys. And there's other directives here which I'm not really going to because there's a lot of them. There's things like after deploy and other directives. So, you can do a lot of different configurations with this type of thing. And here's another example that you can also specify URI for a particular contract. And this is very useful if you want to quickly prototype something that needs a contract form, open zappling. In this case, give us. You can specify a URL or even a swarm URL or IPFS. That counts configuration by the ratio. Okay. Questions we're asking? Is that okay? So, the accounts by default, we will take the accounts of a connected node. However, you can specify, yeah, there's a light wallet functionality which you can use to specify accounts and even set their balance. So, in this case, we define here two accounts. We use a private key, not want to use a mnemonic. And there's two examples that are possible. Preferably, don't put your private key in source control. It's a good idea. And you can see there's a balance five ether which, so if you're in a development chain or on a test variant, we'll set that to five ether. Of course, this won't work on mainnet, but it's just for development. And ENS is, so ENS in embargo is considered one, another layer in the stack. So, which is the naming layer. And yeah, ENS right now seems to be the only working decentralized naming system. So, it's the only one that's actually supported. When you are in a development chain or in a private chain, ENBARC will automatically deploy and set up the ENS contracts so you can use them in your application. And this configuration might look like. So, in this case, when this is enabled and we are in the development chain, if I go to my DAP and resolve status that add, that will resolve to the address that is defined. And you can put a contract that you just deploy as one of those addresses. If you're DAP, then it's, if you have ENBARC connected to a known chain like Robstein or mainnet, then it will just use the ENS contracts that are already there. It will not try to redeploy them. All right. The tests, so there's a lot of functionality in the tests. They are quite flexible in the sense that you can use the same contract configuration that we've seen before. If you don't want that, you want to do very, very pure unit tasks, you can also do that. Just import the contract object and deploy them before each or before all. They're quite fast. They try, there's like little tricks that the framework tries to do. If you have any ENBARC instance, it will actually connect to that instance and reuse a lot of the code that's already running, like the might reuse the compiler or might even reuse the node that you already have, which is much faster than booting a VM on the spot. It will display gas codes and it also supports code coverage out of the box. There's a lot of functionality in previous ENBARC. We cannot really cover it here, but for instance, there's full support for Webpack, so it makes it very easy to do production builds of your DAP. You can have very small file sizes, which is really handy when uploading to Swarm, for instance. It supports already IP1102. There's many templates ready to use, such as if you want to use like a React template or when you want to do like a status DAP, there's also a plugin for that. And it can very easily create private chains. So if you're with other developers, you want to develop on the same chain, that's also pretty simple to do. And there's a plugin API that allows you also to extend and completely change the functionality if you want to. In fact, ENBARC itself is entirely a plugin base, so everything in it is implemented as a plugin. So if you want to add some other technology or completely change, you can actually quite easily. So now ENBARC 4. So the team has been working hard in this the last few months. And there's this feature in ENBARC 3, which is the transaction logger. And what this did and still does is when you do a transaction in your DAP, so you're developing, it will show in the logs what contract you're calling, what method, what parameters, and all that information. In ENBARC 4 now, it will also show why, if a transaction fails, it will show you why and exactly what line caused that to fail. It will also show you the variables, values, and so you can easily see why. We also include ENBARC 4 debugger. So if you type, you can either type debug in the transaction, or if you just type debug, then it will debug the last filling transaction, so you can easily, you can quickly see, okay, what are the values of the variables, you can do next, previous, and other commands. We also include an experimental DAP generator. And the idea of this is that you can give ENBARC a contract and it will attempt to generate a React app that works for that contract, which can be quite handy for prototyping. And we went a level deeper and for particular cases, you can also just specify like a model and it will create the contract and the DAP based on the configuration that you did. So in the case of this command, for instance, because it has picture IPFS, it knows that it has to put the functionality to upload and display pictures, they should go to IPFS, and the hash that gets returned needs to be in the smart contract. Now ENBARC has since version two, I believe, this dashboard and just be very clear, this is not going away, because we got typically very good feedback on this. However, we're introducing now Cockpit and this is essentially a complementary, but it launches a UI that you can access to interact with ENBARC. So it kind of takes that dashboard and puts it as a web UI. So you have the same things that you had in the console from the services, you can see the deployed contract, but it's obviously much more interactive. So, for example, in the console, oh yeah, we also have like light team, dark team, depending on your preference, I prefer the dark. So the console, for instance, you have Autosuggest and it tries to recognize what you're doing and give the appropriate suggestions. So if you're using Web3, it kind of gives you a documentation on the spots of what each of the suggestions are. If you're typing a contract address, it will give you information like where that contract is deployed, what is the type of object. It also has a blockchain explorer and it has pretty much typically everything you would expect to have from accounts, block transactions and the contracts as well, the contract that you have just deployed. It has an editor and again, this is complementary. You can still use Veeam or VS codes or God forbid Emacs. So when you open a contract file, you can immediately, you can interact with it in the IDE. You can see that you're in the sidebar. There's also, I thought the screenshot might be missing, there's also a gas price estimator, which is useful for connecting to a more public network so you can see how fast the transactions can actually go and for what price. We also have the details in case you need the ABI or the bytecode to copy and paste that. We also have the same transaction logger that I showed in the console. Here you can actually see what the transaction is done to that contract and you can actually filter them if you want to. You can filter by events and you can also debug them. In the case of the debugger, it will show you the contract global variables. You'll show you the Solidity variables as well as the local variables to that function. And you can step through it, step in, break points, the whole thing. And there's also a browser preview that you can use for more quick prototyping. So a good workflow in this would be, for example, that app, I press the set value. I see in the transaction, the set went in, maybe it broke. I press debug, go to debug, and I can then debug the contract and see what went wrong. And we also are introducing this deployment tool. So the idea here is that from speaking to many of our users, we realize that a lot of people actually prefer to deploy directly with MetaMask, typically with the browser IDE and then deploy to MetaMask, because sometimes they don't feel very comfortable deploying from the command line. And because in the case of more advanced tools like Embark, it can do a lot of deployments. And when deploying, the main app people need to have the confidence of what's actually happening. So here, with this option, Embark will tell you what is the intended deploy order, and then you can actually deploy semi-manually, one by one. And each time you deploy a contract manually, you can interact with it, see if everything is okay, and then you can move to the next contract. So you can get more info in the Embark website at status.im. It's now available as an alpha. It's still on an alpha stage, so be careful. And we also intended to make it available as a pure web application. If you're interested in that, you can go to the Embark website and sign up in the mailing list, and you will get an invite. And I just want to thank the Embark team and all our contributors that made all of this possible. And thank you. Debugger, like the Visual Debugger, are you leveraging Remix for that? Yeah, we're using Remix. So you're just reusing most of that library from Remix? Yes. So Remix, it's being basically refactoring into an API that you can use, and Embark is leveraging that. So it has pretty much the same functionality as Remix. All right, thanks. Hi. So I understood that you provide a testing framework for off-chain code. Does it work for Solidity Contracts too? And as an alternative, do you integrate Truffle or, I mean, the whole suite, Truffle, Drizzle, and what is it called? Ganache. Thank you. Can you repeat the first question? Yeah, in your presentation, apparently you can write tests with Embark. What do you test exactly? Do you test the smart contract code or you test the off-chain code? So that's my first question. And if it works for both, and if not, for testing smart contract code, do you integrate Truffle? Right. So it tests the smart contracts. That's the main focus. It actually supports Solidity tests. Truffle is like a different framework, and it does one more, it does like specifically just for the smart contracts. Well, this does the smart contract, so what you were describing like Truffle does, but it also focuses on the other components. And Drizzle, I assume that's independent of Truffle, so in that case, it should work. We have one right here. Hey, so when you are showing the configuration, you are showing some kind of hooks in this JavaScript object, like onDeploy and the string representing the code that it's going to be evaluated. My question is why don't you just use anonymous function with some arguments, and like you're doing it like Angular 1 style, like with this funny syntax. So I took like a real configuration, and then I thought, okay, what's missing here that could be educational, and I added. I didn't really think about that type of stuff. The goal, if anything, it probably confused people more, and it was already a big config file. So to answer your question for educational purposes, that's the answer. Hi. As a long time Truffle and Embark user, I've been waiting anxiously to see which framework, actually which JavaScript kind of version of the blockchain, so Ganesh or whatever Embark powers up, is going to support default event reading, like when they happen in contracts without having to subscribe to them. So are there any plans to have events tracked by default from your smart contracts and shown in the Block Explorer? So you mean actual, solidity events? You don't mean like just the transactions? No, no, just actual events from the code without having to subscribe individually. I'll think about it, because I feel there are some downsides to it. I know this is coming in the next version of Ganesh, and I really hope you guys beat them to it. Yeah, yeah, that's exactly what I was thinking. Yeah, because we do have the logger that you can see the state. So doing that, it looks fairly trivial, not some misunderstanding some, but yeah, so I didn't show really the explorer for the contracts, and you can choose your contract, and yeah, you can interact with it, but I think we could also add the state to it. So I think it's a good suggestion. So you support ENS, you support IPFS, are you going to support IPNS? We actually do support the IPNS, I thought I didn't mention it, but we do support it too.