[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]