 Is that it? No? Maybe? Yeah, let's go. Okay, thanks. Yeah, my name is Mr. Lakin, and in this talk I will tell you what the certificate team did about you in the last year. If you can't properly see the screen, then you're out here in the bottom. These are the signs. So this is more or less of the situation of the talk I gave at DEF.4. Let's guess more about optimising what contrasts to you. It's not a problem if you haven't seen that talk, just from context. In that talk, I explained how we want to or we wanted to leverage an intermediate language for you so that vicinity compiler has a better readable code generator. And I will put optimiser and in general, more flexibility towards which backend we compile this. For example, you can be compliant to EVM, to EWASM, EVM 1.5, or maybe LVM. And on the bottom here, you can see some example U-code. It's an allocation or it's the standard Solidity allocator, memory allocator. And I think it's rather obvious what it does and in the general. At least you can know some of the EWASM code. Okay, what did we do? So this was basically recap of the talk of last year. What happened after that? We started the rewrite of the Solidity code generator to you and your kind of pathway there. This will be the first third of the talk. Then I will tell you how you can generate the EWASM code from Solidity and the last part will be about the UR2. Okay, the code generator. We are actually quite far with that. We had to stop at some point because we want to release Solidity 060 soon with new features and breaking changes. We are it's possible to compile the ERC-20 contract. General ERC-20 contract with Solidity including mapping events required and whatever is necessary. The new code generator has a breaking change and that is that it will automatically revert on aerobatic overcome. The code generator only reverts on division by zero and similar things and the new code generator reverts on multiplication and addition of code flow. The main reason why we didn't do that for the old code generator is because these checks will have branches and the old optimizer can really follow the code generator but the new optimizer, we will see in the current. It was also much easier to write the code generator using because it might actually look like that but you will have to not have the concept of stack. It only has local variables and these are there is a rather direct translation from the local variables to a stack machine but in general you do not need to worry about the stack layout so there is one of the most complex parts in the Solidity code generator is internal function calls because the callout code has so many parameters and it also depends whether you call a library or a regular function or whether you specify the gas or whether you specify the value and so on so there is different ways to use the callout code and all the time you have to keep track of where everything is on the stack in the old code generator and the new code generator just referenced stuff by their name so it's just gas as a variable and another thing is that so when in the old code generator we forgot to or did not yet implement a certain feature but by accident the stack layout is correct then this will lead to code that is actually generated and will of course do something about it so in the old code generator sub expressions are always referenced by their identifier and if the code generation of that sub expression is not implemented then the identifier will just not exist in the old code so we have an additional level of checks on the intermediate language and this will be detected and everything how can you actually use it I will only show you how to use it on the command line, the standard JSON also works it's more complicated on the screen here so c-minus-ir will generate a new code from the Solidity code and for safety reason we do not support a direct translation from Solidity through UL to EVM because it's still in an experimental stage so you have to copy the output of the first stage and then re-run the Solidity compiler in assembly mode and then transform the unit code to EVM bytecode yeah let's take a look at how that then looks in practice so this is an example ERC-20 contract or a part of ERC-20 contract we have an event we have the mapping of the balances total supply and a mint function that generates tokens which is called a mint constructor so the sender gets 20 coins and the mint function starts with this require call so the address to mint 2 cannot be the zero address and then total supply balances is modified and the transfer event is needed now we compile that to UL and so this is not the code directly generated by the code generated but this is the code after optimization and I think it's really nice that this is still nicely reviewed I would say let's get into detail and then you will see but you see that it still has expressions and so you would even see the mint function call here and you would recognize the name mint the issue here is just that the mint function in it context is only called once and because of that it was inline and so the function is more but it starts with initializing the memory allocator then we have the call value check so because the constructor is not available and then the second thing here is the require that the address we mint to is not zero and you actually see the error string here here's the 20 and mint to the zero address so this block here is the require call and then we update the total supply but this is the command I added manually and you take the data that is currently at storage location 2 you add 20 and you store it again now it calls it calls a user defined function called check add this is the overflow check I was talking about earlier and that is one of the two functions that is not visible on the screen here and the rest of the code all there is to the constructor so this is the full constructor code missing two more functions and now we update the balances so this is still a kind of problem there is a function called mapping index axis team mapping and so on it's a little bit longer so the reason is that so this is the index axis helper function for storage mappings and the name is generated from the type and I think we still have to come up with a way to shorten it but yeah and another issue here is you see the mapping index axis the function I was just talking about it's called here and it's also called here again with the same parameters usually the optimizer is able to combine that and call it only once the problem here is that it calls the catch up function which works on memory because of that it has to access the memory and the optimizer cannot yet recognize that writing this stuff the stuff that is written in the first call and the stuff that is written in the second call they do not conflict because it's exactly the same so they write to the same memory location because of that it can't really swap them but it should detect that it's actually the same stuff that is written okay let me speak a little yeah, talking about bytecode size I'm not sure if you can compare these numbers with the earlier talk because this is 256 bit EVM code and I think it's also a lot more of ERC 20 than it was in the WebAssembly church but we can compare the compiler that goes via U and the compiler that does not go via U so the the current compiler takes 1,747 bytes that's a bit unfair because it does not include overflow checks if we add the overflow checks it's 1,805 and if you do that via U it's 2,162 so it shows that there's still some work to do actually I did not find the time to see where it has these additional bytes so it might be just in the fix okay WebAssembly similar to solc-minus-r you can use solc-minus-e wasn't it will so and this will actually generate ewasm text representation in one run the thing is it's not tested at all and it can be a deploy contract because we couldn't yet find a good execution environment we can deploy contracts and the reason for that is that we have not implemented the transform from WebAssembly text representation to WebAssembly binary representation and you need that for deploying actually deploying the contract because it needs to return the binary optimally the binary representation how does the compiler to ewasm work it takes the regular ebm UL code so it starts exactly at the point where the so we need to UL to ebm compiler wait and so you have to transform 256-bit code to 64-bit code and this is done by splitting all the UL variables into UL variables and at that point we have some kind of a mix of WebAssembly UL dialect and ebm UL dialect because we still use the ebm opcodes but we already use 64-bit variables and then we add a library code that implements all ebm opcodes as defined functions using the ebm built-in for any ewasm built-in functions and at that point we have ewasm flavored UL and we run the regular optimizer but also run on ebm UL with site modifications because we have different built-in functions and it turns out that we are able to reuse almost all of the components of the ebm UL optimizer and yeah, it generates a kind of a pretty straightforward transformation I would say yeah, a signal that is specific for example we just store the current block gas limit at position 0 in memory this yeah, I have to worry because of the 256-bit 64-bit thing it's a little bit complicated okay, what we do is gas limit returns a 256-bit value, so we have to split that into four variables and that's what is done here in the beginning, so we call gas limit and assign it to four variables and then we call end store that is the kind of sudo hybrid ebm ewasm function that takes eight parameters so four for the address and then we add the implementations of the ebm opcodes in the assembly built-in so gas limit for example just calls ease.get block gas limit and then end store a way to perform indian swapping because what assembly is any machine but anything else okay, this looks really complicated but if you apply the optimizer then you will of course inline the list that we call here and also remove all the other variables we don't need anymore and also the end store it has constant here so it probably makes sense to also inline that and then it will look like this only the indian swap is okay, now third part of the talk, what we did on the new optimizer all all components of the optimizer take your code transform it and output your code so it's no reduction of the expressivity or something like that so all the modules are simple and can be combined in an arbitrary way if all the modules are correct and the whole optimizer is correct it turned out that we need more modules than we initially thought we currently have roughly 25 but most of the modules are really, really tiny and there are only 2 to 3 components that really store opaque data structures so 3 minutes, okay let's speed up a little bit so for example the conditional simplifiers that I did for that module it takes a look at branches so for example if C stop the body of this almost terminates so after the body you know that C is false so the only thing that this does is it injects assignments of this form after terminating branches and other modules in the optimizer can pick that up and use that information but the information is visible in the code it's not stored in some data structure and you would have to look into it but there's some error let's skip that and talk about the plans for the future memory types, we already saw that we have some problems with memory this would hopefully be solved by adding memory chunks as a built-in type into you that way different memory stores to different data structures are fully independent because it uses a different hand to access memory also we're thinking about adding a super optimizer so an optimizer that takes a real long time and tries to really crunch the numbers and find a good way to optimize the code and that can maybe have shortcuts if you want to recompile stuff but it's faster and we're thinking about adding a genetic algorithm to find a good order for applying steps so as I already said each step individually should be correct the order doesn't matter for correctness but it matters for efficiency and yeah it's kind of hard to come up with a good order to apply them so we want to work in a direct way to come up with a good sequence of these I'm not sure if it's the type of questions but thanks for your attention