# Julia – IR for Ethereum Contracts

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2018-10-07
- Duration: 18:24
- Watch: https://streameth.org/watch/yt-zXriQW1ATFI
- YouTube: https://www.youtube.com/watch?v=zXriQW1ATFI

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/3/julia-ir-for-ethereum-contracts

Brief introduction to Julia, a new intermediate language to be used in the Solidity compiler. It reduces the complexity of the compiler, helps in auditing contracts and makes supporting multiple VMs, such as EVM 1.5 and eWASM, possible.

Speaker(s): Alex Beregszaszi
Skill level: Advanced
Track: Developer Infrastructure


Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 3 was held in Cancún, Mexico on Nov 1 - 4, 2017
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] yeah hello everyone so I'm going to talk about Julia which is an intermediate representation or an intermediate language for ATM 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 the first problem is you know auditing contracts written in solidity is not that simple I will explain that in a bit then the solidity compiler is written in C++ and a lot of things a lot of helpers lot of code generators are of course between 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 feech future we might move on to new virtual machines so one such virtual machine is called a vm 1.5 and that one is called it wasn't in the current state of solidity there would be a quiet big change to rewrite the compiler supporting any of those and lastly creating the cells or domain-specific languages it doesn't really exist at the moment and the most practical way to do that is to compile a domain-specific language - solidity or - 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 do auditing before one needs to make sure that the contract written 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 did the second problem with auditing which might not be done in every single case is verifying that the compiler creates byte code 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 byte code counterpart and it doesn't really look readable the tone of swaps and dupes the reason for that is in solidity every variable is as 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 ability to make duplications of them I guess you can agree that it's quite hard to verify that even byte code 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 we resize it then we get to reference in this example we get to reference of a storage slot and a 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 etherium 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 let's 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 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 debt solidity only has two stages were more like 1.5 stages there's one stage which does everything and there's another one which optimizes evm bytecode at this stage has no idea what the source code was now introducing an intermediate language we'll change it to or till all the other 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 this makes sense for solidity is verification of what happens within the compiler well actually I just said these there and yeah like the last point in your 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 ABI encode into memory and death memories return the part in the bottom is you know 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 in code string and sure nowhere you transfer extract code signature so these are in this slide of course not all of them are implemented and but you can see they are fairly simple these are all helpers which will be I put it into each of the contracts and that happens already but all of this is written in C++ and is hidden from the eye there is one thing which one can notice here extra code signature is a one-liner that's why optimizations make sense this one should be inlined it shouldn't be a function call it should be just 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 auditing 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 is 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 and you know if we have all these helpers written in Julia and they are verified they could be used by other 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 align assembly so you know somebody was introduced last year it's supported jumps instructions and functional instructions but over time we have restricted that we remove the you know more risky part 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 serpent the Viper would ask why not do it with LLL use lll axis and serpent actually use LLL as an intermediate language so the two main reasons is ll L is really based on a VM it's based on the VM opcodes it has a couple of extensions on top but it really is just a VM assembly in a lisp like language and of course we have 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 a function switch statement I guess soon we will have an if statement as well video today else condition and via for loops then important part we don't have instructions evm op codes behave just like functions they are not a separate kind of expression so variables and functions this support multiple assignment the earliest relies to the default value of 0 and functions can have multiple inputs and multiplied so here here are a couple of examples on a table you just have a same simple excitement if there's no where you specify it as assigned a zero oh actually the third line is invalid I just miss to market because 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 the switch statement is the core of the entire language it can have multiple cases it can have a default value at least one case either specified case or the default case has to be present one major difference here for anyone used to normal languages is a switch statement with support for true and you would have a keyboard break to stop at any given point of time naturally it doesn't have that every part of a switch statement will be executed entirely there's no break and there's no fall 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 tails if not else and the last feature we have is for loops which has an initializer has a condition has a post block on the block now one interesting part here is in an initializer so actually all the blocks initializer block and post block there are the same scope so any variable created in the 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 in solidity for Julia right now evm the normally VM we have is is of course working and we have even 1.5 implemented the interesting part of a TV of 1.5 is that it supports basically functions and stack frames and so it's you know that's the main improvement what it means we can really easily translate julia functions into idiom 1.5 functions and that makes it really easy to verify it was a 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 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 more parts of the application they tap in solidity right now you have to only write account D on chains part in solidity but you could in the future right off chain parts in solidity and compile those parts into JavaScript if anyone volunteers I'm happy to help to get that back and down and we already have a tiny bit of third-party support for Julia there is a Julia interpreter named lamp and that's the URL for it I think it was written in less than a week so they're probably shows that the language is quite simple to deal with 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 it even less if you have a parser ready 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 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 any optimization at that level and the next step one can apply simple optimizations step by step so in this case here I would want the LLL - Julia compiler to output this code but it's not really optimized so the next step I would want an optimizer to inline a node so below get owner wouldn't call node it would just have called data as code eight a 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 point 12 we have released support for functions for loops and point 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're not we're not really confident yet that it should be used in production but if someone wants to try out it it's certainly possible hopefully 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 to releases from now we will have a first version of a solidity to julia compiler as part of solidity and then in the future he was so it can be already tried out if you dare those are the command-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 at the last line is changing the output machine if you're interested in Julia or solidity development and you can join the solidity - dev channel on Gator or you can just talk to me directly ataxic on Gator thank you [Music]