 Yeah, hello everyone So I'm going to talk about Julia Which is an intermediate representation or an intermediate language for Ethereum contracts You know, let's just first see what are the problems? Why would we need a new language or am I just crazy that we need a new language? In fact, we do have a couple of problems and most of these problems actually related to the Solidity compiler itself And the first problem is, you know auditing contracts written in Solidity is not that simple I'll explain that in a bit Then the Solidity compiler is written in C++ and a lot of things a lot of helpers a lot of Code generators are of course within C++ and they are quite complex And you know with time they can become even more complex as more features are added The next problem is optimizations, you know different optimization steps on the compilation that can become very complex as well This one so far hasn't been an issue because Solidity can only output EVM bytecode But you know in the future we might move on to new virtual machines So one such virtual machine is called EVM 1.5 and that one is called E-wasn In the current state of Solidity That would be a quiet big change to rewrite the compiler supporting any of those And lastly creating the ASLs or domain-specific languages it doesn't really exist at the moment and The most practical way to do that is to compile your domain-specific language to Solidity or to Serpent And by doing that you will be exposed to the very same problems Solidity is exposed to So this is one of the example for auditing Right the multiple parts to auditing first of all one needs to make sure that the contract written in Solidity Does what a functional specification says in this case? The intention was to being able to redeem the money once, but I don't think the contract does that The second problem with auditing which might not be done in every single case is Verifying that the compiler creates bytecode accordingly to the source code So there are two examples there. The top one is a assembly call in functional Representation so functional inline assembly And there you see four variables in the call That is quite readable in the bottom. There is the EVM bytecode counterpart and It doesn't really look readable the tone of swaps and dubs the reason for that is in Solidity every variable is Has a life cycle of existence until the end of the block So in that case there they still exist after the call So they have to be kept on the stack and therefore we need to swap them around and we need to make duplications of them I Guess you can agree that it's quite hard to verify that even bytecode Actually corresponds to that assembly and these are this is one example for helpers This actually is the code for pushing a value to an array First we retrieve the length we increase the length of the array and we resize it Then we get the reference in this example We get the reference of a storage slot and the storage offset and then finally we can interact with that array So there must be a way to improve this Let's just take a step back and look at other compilers, you know outside of the Ethereum So basically for many years Compilers traditional compilers have been working in different stages The first stage is the front end which parses the source code does Analysis check several things and finally creates an intermediate representation of the program The next stage is the middle end which can apply different optimizations on the front end on the intermediate representation And the last one is the back end of course, which generates bytecode for the target machine and again It can do optimizations there Compared to that solidity only has two stages or more like 1.5 stages There's one stage which does everything and there's another one which optimizes Evian bytecode At this stage has no idea What the source code was now introducing an intermediate language would change it to Ha or they'll have all that are compilers work However, there is a big difference Because the reason most compilers work that way is they target multiple machines So if you look at GCC or LLVM They support a like C and you can compile the same C code to multiple computers And with compiler toolkits, they also support multiple languages on the input side and they can utilize the same back-end written Of course this applies to solidity But the main reason and this makes sense for solidity is verification of what happens within the compiler Well, actually, I just set these there and Yeah, like the last point Evian bytecode and Since this intermediate representation this language By definition has to be a much simpler language than solidity is and that of course means the bytecode generation of it should be much more simple So what does the language look like? Here's a simple contract. It just returns a string and This is an incomplete example of that contract in Julia The important part is the one highlighted on the top. So you create the if you look at the string That string is encoded there in hexadecimal It is assigned to a variable. It is a bi encoded into memory and that memory is returned The part on the bottom is you know a helper a compiler real output into the contracts What it helper does is it receives Control when the contract is called and it decides which function within the contract should be executed Or in the case none of the match. It just ensures that the contract hasn't received any money And you can extend this with the missing parts because you see there's an ABI encode string Ensure nowhere you transfer Extract call signature. So these are in this slide Of course, not all of them are implemented But you can see they're fairly simple. These are all helpers Which will be outputted into each of the contracts and that happens already But all of this is written in C++ and it's hidden from the eye There's one thing which one can notice here Extra call signature is a one-liner That's why optimizations make sense This one should be in line. It shouldn't be a function call. It should be just the those few instructions Now here's the the helper you have seen and Here's a possible way to write it in Julia. I think it's much more readable So, you know by moving most of the compiler into Julia from C++ gives us a couple of benefits It should help all the think efforts Because one can't just review this much more simple language Julia and all the helpers written in them As opposed to finding someone who's happy to review C++. I mean I wouldn't want to review C++ And it also allows a simple framework for optimizations because basically here you will just Optimize Julia code right now if you want to optimize contracts You should also do optimization steps in solidity in the solid part before it gets converted to EVM and In fact, we only have one single Tiny simple optimization step in solidity everything else is in EVM And you know if you have all these helpers written in Julia and they are verified They could be used by another languages as well in the ecosystem So where do we stand right now? Julia I guess looked familiar to those who use solidity because it looked kind of like the inline assembly solidity has and That's of course because it is an evolutionary step from inline assembly So inline assembly was introduced last year It supported jumps instructions and functional instructions but over time we have restricted that we remove the You know more risky parts and we added a couple of new features like functions for loops which statements and Yeah Okay, so one question there. I guess those people doing a Serpent the wiper would ask why not do it with LLL because LLL exists and Serpent actually use LLL as an intermediate language So the two main reasons is LLL is really based on EVM. It's based on the EVM op codes It has a couple of extensions on top, but it's really is just EVM assembly in a list-like language and Of course, we had this organic evolution of inline assembly, which was already used So the language features we have We have variables which can be typed Well, in fact There's Julia, which is the intermediate language that must be typed and then we have inline assembly Which you can already use that is not typed The functions with statements And I guess soon we will have an if statement as well without any else condition And we have four loops that important part. We don't have instructions EVM op codes behave just like functions. They're not a separate kind of expression So variables and functions these support multiple assignment they are initialized to the default value of zero and Functions can have multiple inputs and multiple outputs. So here here are a couple of examples On a top, you just have a same simple excitement If there's no value specified, it is assigned a zero Oh, actually the third line is invalid. I just missed to mark it Because the right-hand side has to be a single expression. It cannot be a tuple expression And that is a simple function and that's how you call it now this which statement is the core of The entire language It can have multiple cases. It can have a default value at least one case either a Specified case or the default case has to be present one major difference here for anyone Used to normal languages is a switch statement would support full true and you would have a keyboard break To stop at any given point of time Now Julia doesn't have that every part of a switch statement Will be executed entirely. There's no break and there's no fault true That's a very important thing, but it might not look Obvious from these examples so basically how this gets compiled into bytecode is In EVM it will do a couple of comparisons. Does it equal zero if not do that? Does it equal zero? Does it equal one? Does it equal those if not else? and The last feature we have is for loops which has an initializer has a Condition has a post block and the block Now one interesting part here is in an initializer So actually all the blocks initializer block and post block. They are the same scope So any variable created in initializer is valid in the for loop, but it's not valid outside It does support break a Couple of examples Okay So we do actually have different backends and Solidity for Julia Right now EVM the normal EVM we have is of course working and we have even 1.5 implemented The interesting part of it even 1.5 is that it supports Basically functions and stack frames and so it's you know, that's the main improvement And what it means we can really easily translate Julia functions into EVM 1.5 functions And that makes it really easy to verify E-wasm is a different back-end which is in progress it already works, but it's not finished So it's not really part of the tree yet And the last back-end I think possible is even doing a JavaScript back-end the use case There would be someone is writing You know more parts of the application did up in solidity right now You have to only write the on-chains part in solidity, but you could in the future write off-chain parts in solidity and compile those parts into JavaScript If anyone volunteers, I'm happy to help to get that back and done And we already have a tiny bit of third-party support for Julia There is a Julia interpreter in LEM And that's the URL for it. I think it was written in less than a week So that probably shows that the language is quite simple to deal with And I did a toy LLL to Julia compiler just to see you know How much effort would it take it takes a couple of hours to write that even less if you have a parser ready and And lastly You know with Julia it should be easy enough to create domain specific languages Because Julia is quite low-level, but at the same time it does have a lot of convenient features like functions and switch statements That is actually example of compiling LLL to Julia and as you can see most of those parts Entirely resemble the LLL counterparts. It is also highlights the need for optimizations Because the first step in using Julia converting from any language to Julia is to be able to ensure The code is correct. So it will be verbose There won't be an optimization at that level and the next step one can apply Simple optimization step by step. So in this case here, I Would want the LLL to Julia compiler to output this code, but it it's not really optimized So it's the next step. I would want an optimizer to inline a node So below get owner wouldn't call node. It would just have cold data As cold data load as an instruction So that's just an overview What happened in the last couple of months regarding solidity and Julia and as you can see in 0.12 we have released support for functions for loops and And 0.17 which was recently the added support for a new ABI encoder So many people who were complaining the lack of support for structs That new ABI encoder enables support for passing structs between functions Now that's already in the compiler, but it has to be enabled by a special experimental switch Because you know, we are not we are not really confident yet that it should be used in production But if someone wants to try out it, it's certainly possible Hopefully in the next release we will have a new ABI decoder merged at the same time and that will enable Functions to receive structs because right now you can send structs, but you cannot receive structs and then hopefully two releases from now we will have a First version of a solidity to Julia compiler as part of solidity and then in the future you wasn't So it can be already tried out if you dare those are the common line options To use the solidity compiler to compile assembly and you can also switch to Julia mode The only difference there is using types And the last line is Changing the output machine if you're interested in Julia or solidity development You can join the solidity dash dev channel on Gitter or you can just talk to me directly at AXIC on Gitter Thank you