 the slides are there. 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 regards to solidity. I want to start with explaining what the initial goals were for solidity. So, the idea was to have a statically typed language that is easily readable for web developers or for not necessarily web developers, but for, I don't know, casual programmers. So, yeah, we we chose something that looks like 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 in mind because sometimes, yeah, solidity 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 in solidity and that leverages the new features of inline assembly and libraries that were present for Defcon 1 already, but we added so-called internal library functions and not to forget the using X for Y. So, let's look at an example. This is, I think, Nick Johnson's string library, at least a small fragment of it and inside this library you have this struct slice, which defines a new type and it's basically 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 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, yeah, 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 attach functions from a library to an existing type and that's why we can call s.to slice, although s is a built-in type that usually, 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, you do not 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 statement return x plus y and this gets converted into the to the following JSON, a representation of the AST. We have an ID which is used to reference other nodes in the AST, perhaps I should, so AST 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 identifiers 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 the debugger because at any point in the code it can show you, so if you debug a 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 transaction is rolled back or at least a call inside the transaction so whenever you encounter a trouble some 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 undoes the effect of the transaction this is this can be dangerous in some situations so especially when you for example have a loop and one of the iterates 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'd 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 funds 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 modify it accordingly and then some we also fixed the problem with the modifiers so modifiers are kind of properties you can attach to functions which insert a prefix and a suffix into the function and this underscore part there is where the actual function is inserted and previously if you 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 part here 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 in storage called locked in this example and if the function is active it's set to true and it's automatically set to false again if the function exits and if if the function is locked then you cannot call it so this yeah okay how does the future look again formal verification then one important and large feature we will add is something I call authenticated sources and binaries this means that we 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 the smart contract to have so you can't make any copy paste errors 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 compiler version which means mist can automatically retrieve 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 former verification conditions are part of the source code it can even automatically do just in time former verification of the smart contract okay 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 Oracleize uses some kind of yeah manual solution to that problem because if you if you make a request to Oracleize then the Oracleize smart contract invokes the Oracleize system and retrieves the data and then calls calls back the original contract in a later transaction and currently this callback goes to a fixed function with a fixed name but in the future will be possible to just supply a callback function as is usually an asynchronous programming and yeah speaking of asynchronous programming not sure if you've seen this proof-of-concept hack two weeks ago about the about the weight 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 you 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 and this is just a rough idea of how it could look like so I hope that the URLs of the slides are published soon after the conference and yeah I think there we also have relevant Reddit posts and okay thank you thanks Christian