New and future Features of Solidity - Dr. Christian Reitwiessner

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