I
yeah and the slides are they're great so
yeah this talk will basically yeah I
just want to tell what we did during the
last year and what the plans for the
future are with regard to solidity I
want to start with explaining what what
the the initial goals were for solidity
so the the idea was to have a statically
typed language that is easily readable
for web developers or for not
necessarily rapid wellas but for I don't
know casual programmers so yeah we we
chose something that looks like a
symbiosis between JavaScript c java and
it should be high level but at the same
time it should be also very very
efficient because there's not a lot we
can do inside a single block at least
currently and yeah keep that it keep
that in mind because sometimes yes a
little she looks really really high
level but actually it's not that far
away from assembly okay what happened
since DEFCON 1 we extended solidity to
be more flexible more usable so we added
some some usability features and not to
forget we made it safer at least I hope
so so what exactly did we do next slide
please it's now possible to build custom
types and solidity and that leverages
the new features of inline assembly and
libraries that were present for DEFCON
one already but we added so called
intern
library functions and not to forget the
using X for y so let's look at an
example this is I think Nick Johnson
string library at least a small fragment
of it and it inside this library you
have this struct slice which defines a
new type and it's basically a a view on
memory it has a pointer which is so it's
a kind of rather low level object it has
a pointer and a length so it references
a chunk of memory and the function to
slice can be called on any string and it
creates such a slice object that
references the data of that string that
is important because usually when you
when you create so we want to be able to
reference parts of strings and if we use
just the string type itself we would
have to copy it all the time and using
this slice we can talk about parts of
strings and let's so at the bottom we
have a contract that actually uses this
slice it takes a string it calls to
slice which converts it to such a slice
and then checks whether it starts with
foo so it checks whether the prefix is
foo and no not yet so and the great
thing is that you can so using this
using strings for star statement you can
basically attached functions from a
library to an existing type and that's
why we can call s dot to slice although
s is a built-in type that usually that
that of course does not have the
function to slice and I think this is a
really powerful tool especially when
coupled with inline assembly because you
can create tools using inline assembly
without having to change the compilers
you can basically add types that look
like built-in types but you do not have
to take do
have to look into the compiler okay what
we also did is we so we extended the AST
output capabilities and one of the goals
there is to provide more make the
compiler more accessible to external
tools which want to do static analysis
or debugging and so this is still a bit
fluid so we might change the we might
still change the design of the AST
output but as an example we have the the
statement return x + y and this gets
converted into the to the following json
a representation of the ast ast we have
an ID which is used to reference other
nodes in the ASCO perhaps I took a STS
then is short for abstract syntax tree
and that is basically a representation
of a structured representation of the
source code of a program and so this
return X plus y is decomposed in the
return statement and then inside this
return statement we have a binary
operation which is the addition and the
two operands again are inside the binary
operation and these are the two
identifies x and y and you can see this
this attribute SRC that is a reference
to the actual position in the source
code where this this piece of the AST
came from and that is very important for
further bugger because at any point in
the code it can show you so if your
debugger transaction then you can at any
point inside the execution of the
transaction you know where that was
where you currently are in the source
code and you can also do more analysis
on the ast and perhaps so perhaps
analyze the AST for insecure stuff
and notify the user and point to an
exact location in the source where this
problem is yeah concerning safety we
already had several talks about formal
verification so I won't say anything
about that with the 040 release of
solidity we added some changes that
intentionally broke backwards
compatibility in order to add some
safety features and some of them were
that we created exceptions for in more
situations than before and the effect of
an exception is that a transactions
rolled back or at least a call inside
the transaction so whenever you
encounter a yeah troublesome situation
or some situation where it's not really
clear what to do how to deal with it at
least not for the compiler then this
basically undo the effect of the
transaction this is this can be
dangerous in some situations it's so
especially when you for example have a
loop and one of the eight arrests inside
the loop always triggers an exception
then it's impossible for the loop to go
through so this is something to be aware
of but we chose to rather revert the
transaction than so yeah we chose to
reverting a transaction is less of a
problem than getting stuck and so yeah
failed creations now throw an exception
division by zero throws an exception and
yeah function calls to a non-contract
this function calls to a non-contract is
especially important because if if you
call a non-contract it will basically if
you send other together with it it will
just accept it and it might be forever
stuck there and then we have the the
payable modifier so you now have to
explicitly specify
for every function whether it is allowed
to receive other and the default is to
reject other so it's harder to
accidentally send send fun somewhere and
to make the the version transition safer
we also added the version pragma which
means you can now specify the compiler
version your source code is designed to
work with and if we if we change the
compiler if we change the language in
the future then this version pragma will
tell the developer yeah there might be
some changes so you probably have to
take a look at the source code and
modified accordingly and then some we
also fix the problem with modifiers so
modifiers are kind of properties you can
attach two functions which insert a
prefix and suffix into the function and
this underscore part there is where the
actual function is inserted and
previously if we hadn't previously it
was more syntax based which means if the
function had a return it actually
returned and in the sense that it also
skipped the trailing partea so this
locked equals false would have been
skipped before with a return but it
would not have been skipped if you just
completed the function and this now
hopefully makes it possible to create
mutexes which allow a function to be
active only once in that there is a
variable and storage called locked in
this example and if the function is
active its set it true and it's
automatically set to falls again if the
function exits and if if the function is
locked then you cannot call it so this
yeah right
okay how does the future look again
formal verification then one important a
large feature we will add is something i
call authenticated sources and binaries
this means that we that the compiler
will automatically insert a hash of the
metadata into the bytecode and using
this hash you can retrieve the metadata
from swarm that means that so the
metadata will contain a lot of
information about the contract this
includes the ABI interface and the
effect of that is if you load up a smart
contract inside mist and want to
interact with it you do not have to copy
and paste the ABI anymore it will
automatically retrieve it from swarm and
it's also authenticated in the way that
that is the ABI the programmer intended
to prove the smart contract you have so
you can't make any copy paste arrows and
it will also have a link to the source
code and link in the sense of link to
swarm of course which means that it's
it's the source code is hash
authenticated and this hash is part of
the bytecode so it's the exact source
code of the the programmer used when
compiling a smart contract and it will
also have the the compiler version which
means mist can automatically achieve
both the ABI interface and the source
code and the compiler with the correct
version compile the source code and
verify that this is actually the source
code and then show the source code
documentation to the user yeah and since
the the form of verification conditions
are part of the source code it can even
automatically do just in time former
verification of the small contract ok
then templates is something we would
like to add so this is sometimes called
generic data structures or generics and
I hope that it will also increase
flexibility because you can implement
one tree one routine
one algorithm once and then reuse it for
multiple data types we will also add
functions as first-class citizens this
means you can have things like anonymous
functions lambda functions and use them
as for example as callbacks in Oracle
queries so currently oracle eyes uses
some kind of yeah manual solution to
that problem because if you if you make
a request to oracle eyes then the oracle
i smart contract invokes the arclight
system and retrieves the data and then
calls calls back the original contract
in a later transaction and currently
this call that goes to a fixed function
with a fixed name but in the future will
be possible to just supply a callback
function as is usual in asynchronous
programming and yeah speaking of
asynchronous programming not sure if
you've seen this proof-of-concept hack
two weeks ago about the air with about
the await way to program so yeah we in
the future we will explore no new
notations for how to you how to do
asynchronous programming because often
smart contracts are a sequence consists
of a sequence of things to be done in
exactly this sequence and it kind of
doesn't really make sense to put these
different steps in different functions
and it's much easier to actually program
that sequentially that's probably hard
to explain without example that's okay
he will see so what else do we have yeah
so we plan to add algebraic data types
and as I said templates but it's
probably too hard to explain the source
code in this talk and there's another
slide with even more complicated future
solidity code
and I would just encourage you to take a
look at the slides later and read the
comments yeah this is just a rough idea
of how it could look like so i hope that
the urls of the slides are published
sooner for the conference and yeah i
think there we also have relevant reddit
post them okay thank you thanks
Christian
you