 So I'm very excited to talk to you today about Axelang, which is a new programming language for Ethereum smart contracts that we are building. And in particular, we'll talk about the compiler for it. First of all, Axoni is the company I work for and it's a technology company that builds blockchain platforms and smart contracts for the capital markets. In fact, our smart contracts will soon process live derivative trades worth trillions of dollars in national value, which you can understand that a secure and reliable language is very important to what we are doing. This is why we are building Axelang, which in a sense is not a new language because it's really Scala. So when you're writing an Axelang smart contract, you're really writing Scala code. That you can compile with a regular Scala compiler. Formal verification is very important for us as well, but I will press forward to the main topic of this talk, which is the compiler. The first thing about the compiler is that it's actually two compilers, a front-end and a back-end. The front-end compiler is a Scala compiler plugin written in Scala, of course, and relies on the Scala compiler infrastructure, and the back-end is written in C++ and it's written from scratch. These two compilers interact through a common intermediate language that has the four properties I'm listing on the side. First, it's unambiguous, human-readable, language-agnostic and retargetable, and I want to highlight the last two by saying that the intermediate language is not tied to Axelang in any way or EVM, so at least it's not supposed to. So in theory, you can convert other languages into it like Solidity or Viper and you can target other machines like it was. Looking closer into the front-end, this is an example of what it does. So it converts the program on the left to the code on the right, and two things I want to point out here is that types are being reduced into bytes and storage accesses become explicit. The line you see at the top is how this happens. Which is through a Scala function that pattern matches the Scala syntax tree, which is the tree input parameter and converts that into the intermediate language tree. I think this is a very robust and elegant way to implement a language specification. Another feature of the intermediate language is that you can use list expressions that you can compose very nicely. I wish I had more time to talk about this, but I will now proceed to the back-end of the compiler. Compiler engineers will find the back-end very familiar because it uses an intermediate representation that is pretty much a norm in compiler development. That is a three-address code and static single assignment. This intermediate representation is naturally compatible with optimization and static analysis. That's why it's the norm. Compilers that don't have that are not great compilers. The cuts here is that these intermediate representations are not compatible with a stack-based machine like the EVM. For that reason, we add another phase, which we call stackify, that makes the transition into EVM bytecode. Putting all the pieces together, this is how the compiler looks like. I want to note that the back-end also can decompile raw bytecode into these intermediate representations, so we can optimize and analyze raw bytecode that was produced by other compilers as well. To summarize, Axelang, we believe Axelang has a highly modular and scalable implementation. It utilizes an industry-grade compiler framework, which is the Scala compiler. We are getting very close to open-sourcing it, so please follow us on Twitter and YouTube for more updates on that. We are also hiring. Also, feel free to reach out to me if you have any questions. Thank you.