DAPPCON 2018: Updates from the Solidity Team - Alex Beregszaszi (Ethereum Foundation)

Transcript

thank you for the intro so this is gonna be a fairly technical talk about everything what we have done in the last two years and I gotta have a lot of links to external documentation or external videos don't try to mark those down because at the end of the slides they're gonna be a bitly link to the slides themselves so you can just download the slides okay we started out with this one idea let's create a language which is like JavaScript I think that was a great idea because in this new space where everything was brand new and nobody can understand anything really at least one thing was familiar the language and as a result it was really accessible to a lot of people and we got the the ecosystem release pinned up so many people joined

and it's really hard to take track of what kind of libraries and what kind of frameworks and what kind of projects are out there at the moment but probably it's time to improve that and change solidity from not being like JavaScript but something better javascript has some of as a result of having JavaScript as an influence we had some of the limitations listed here so for example we have veer scoping rules we were trying to guess a lot of intentions of the users and the last part is probably the wire so I'm going to give you some examples here to show what I mean

so instead does it work great is that valid valid solidity code any guesses it looks horrible it actually isn't valid but not for the reasons you would think the reason it's invalid because this I variable is redefined so if we remove that is this valid code it's horrible and unfortunately it's valid any idea is what it does it's really hard to decipher but it returns one so that's one of the really bad examples this other one is a textbook example of what

could go wrong what do you think what is this for loop doing is this for loop finite or is it infinite dance where is its infinite and the reason for that is whenever we try to loops whenever we try to deduce the type of the variable I we look at the shortest representation in where the zero letter fits in your zero fits in into eight bits the I gonna be a un Tate and since 256 is larger than eight bits this comparison will always be true so it is an infinite loop so this were like a couple of examples of why some of these legacy things we receive from

solidity are a bad idea and of course we have worked the last two years to get rid of most of these you can try many of these new features by inserting the exponential pragma and I would urge you to try it because if you make your code to work and compile with that pragma then you're going to be set for the next major release which is 0 5 0 release which is gonna be a breaking one you won't be able to do all this mess anymore you have to write proper code there will be a much longer explanation in the afternoon by Chris with all the features step by step what have been changing for 0 5 0 is there anything else of course a lot of other things one

really big topic which unfortunately won't really make it into 0 5 0 is redefining inheritance rules in addressing solidity is really important because we are composing contracts of multiple abstract contracts or interfaces and a couple of questions we have there is what about shadowing what about when we redefine or override a function which is defined in the parent how does that work our interfaces interface contracts which probably not many people have heard about our dough is useful at all at the moment can we change visibility or mutability levels during inheritance these are a couple of questions which have to be

solved and if you have a strong opinion or just would like see the discussion just a link this is the link to check out okay what else did we do so I got a list you probably four or five things here which all have happened the last two years mostly last year so the first one the contract metadata has anyone heard about the the metadata and nobody has heard about it that's really unfortunate so the thing here is for every single contract we are generating this metadata which is a JSON file and that JSON file contains all the necessary information needed to recombine the very same contract and achieve the very same byte code output

so of course this can be used to verify the contract it can be used to verify that all the source is provided will result in the very same contract so what are people doing right now instead of this usually they are using either scan and the verification tool on either scale if the metadata will be adapted you could have multiple implementations on liters and other blockchain explorers other tools to do the verification for you the last important part there is we not only generate this JSON file which explains all the details needed but we also have the JSON file and include the hash of that in a byte code that's the way you can verify that it actually corresponds to the to the right input so

if you want to get more into this there's a link to the documentation but I'm going to show you an example of what this JSON file looks like so on the top you obviously get the correct compiler version used to compile this and these are all the settings which were used in the compilation and these are all the sources which can be utilized so notice there there is a hash in this case we haven't included the actual source code used we just include the hash so it's up to the user to upload the sources to a relevant URL this is possible because the busy CR I'm not sure if you're familiar with that but that's a URLs will swarm so if you publish your

sources on swarm and you publish this metadata and swarm then the system just going to work on its own get the next big thing which is quite a big topic is the SMT checker framework we have so it's the seamless way to verify safety properties and by seamless I mean that it's part of the compiler it's not an external tool you don't need anything else you just need the compiler and you can utilize all these verification steps some of the properties are SMT checker framework can verify and includes overflow underflow division by zero and lastly the most important one it can check for user specified assertions I'm going to give

you an example here so this is a sample code and we have enabled the SMT checker with this line and it's gonna give us a couple of warnings what could go wrong and this piece of software so first of all it tells us that this is always true and that means it's an infinite loop and what is the reason it can think about that well it's very simple I is an unsigned int and therefore it's always equal or bigger than zero but a more interesting example is this one which looks rather confusing so let's decompose what the compiler means by

this so say it shows us that I the documentation of I if we start off so these numbers here are the state of the variables and it tells us is this apostate no that's said that's the pre state so if we start with I and we decrement it we're gonna end up with minus one but that means the end result are also going to be zero because it's an unsigned number we cannot really go anywhere so it will just tell you all these tiny details probably one last note on this one why is there space and

in equal so that refers to the written variable written variables are named I guess this can be improved in the future but you just have to understand what all those lines mean another example is the values safe math add operation so let's see if our SMT checker can give us any indication that is safe math works or not so it gives us an example case of the input where input values where this statement going to overflow so it is telling us that if a is 1 and B is all bits set then on an unlimited bit length this is the value

we're gonna get and if you count all the zeroes you're gonna see that this is bigger than 256 bits and the value we got here is 257 bits long and a top bit is set but since evm only works in 2056 bits it's going to truncate all these values so we're only gonna have all these zeros and as results see you gonna be 0 however the SMT checker is only a compile-time feature it won't include any kind of front end check into the code so you definitely still need to insert assert statement which will be part of the generated code yeah give you another example you can specify assumptions for the SMC checker probably

everyone here has heard about the require and assert statement and solidity the difference between from a user standpoint a required statement will do a revert so it won't consume all the casts while the assert will consume all the gas but we can use these slight differences with static analyzers verification tools as well as the SMT checker feature we have so here we verify the set the assumption that a and B gonna be less than 256 and during runtime we can revert if they exceed that since we have set these assumptions the SMT checker can know that C can never go above 512 and therefore it

won't complain okay the SMT check unfortunately assignment it's seamless you don't need anything else but unfortunately it's not yet part of the JavaScript release of solidity so it cannot be used in remix you need to compile it yourself and you need the z3 or the CBC for libraries first in order to compile it but it should work seamlessly the completion should work seamlessly and once you insert this experimental pragma to turn it on it should just give you the proper warnings there is a much better intro on this URL which goes through step-by-step and explains all the reasons one thing I wanted to mention here that

inferentially it's a well it's not widely used yet but augur has decided to use it and they can actually pass they can compile the entire code base with SMT checker turned on video - any warnings ok we did a couple of more things so that that's done with SMT checker here say quick intro into the ABI encoder probably everybody has heard about ABI here but ABI actually made a contract API which is a specification on how to encode data by communicating with a contract and it is an example for the ABI we take this function the balance function which takes an input and

returns an output what happens during the compilation process is that we generate an ABI decoder code piece which takes the Col data and parses it and puts this address puts an address type variable on to the stack and then it does whatever it wants to do and returns the number which is the UN so that a cool piece we're generating here is an encoder of that stack variable into a return data currently all of this is written handwritten with generating EVM byte code in C++ as you can guess that probably is quite quite a heavy process

and requires a lot of effort to you to make it proper and it's not the best way to do it so we have decided to rewrite it and there's this feature called a bi encoder v2 it's written in you which are going to talk a bit about soon it can on top of what the current Davi encoder can do it can ensure some safety properties for example it can detect if the input is too short and can reject the transaction it can also validate and more conditions regarding input values so for example it can validate if a boolean only contains 0 or 1 would reject otherwise but what's more important I guess to you guys is it supports more complex data structures

for example structs and multiple dimensional arrays so the way to enable it is by this experimental pragma however it's not stable yet so we wouldn't recommend using it in production but we would definitely recommend in trying it in your test suite next to the current version and report any issues found because if nobody going to test it we never going to be confident enough to release it and we definitely want to release this feature into the main branch because it's so much better ok and lastly yo is our new assembly language some of you may have heard about this when it was

called Yulia last year but we have renamed it and a current name is you so it is an assembly language and one of the main driving forces was that we want to have a process where we can audit the compiler code base which might better confidence and much faster and with you'll we can achieve that because I guess this was ok so the way we can achieve that is we want to compile you a salinity your contract into a representation in you which so compared to that currently solidity goes directly from solidity source code TVM and that's like a really bad process so we want to

introduce this extra step in the middle be compared solidity to this fuel assembly and then we compile it to EVM but it's an addition to that if you have you'll in place we can also compile you'll into other VMs for example we can compile it to wasn't so by doing the step we're gonna have support for the future you know however you was designed by the solid ad team we don't really want to own it we don't really want to limit it and restrict it to solidity only so we'd be really glad if other projects other language teams would try to adopt it so for example a Viper would decide to compile to you'll instead of what they

are doing currently and currently compiling - LLL see if they would compile to you they would get even output webassembly output and they would get all the optimization features they have implemented in you they don't have really any optimizations in LLL say there's there's more documentation on the URL and I would also invite you to watch the talk from Def Con which confusingly is titled Julia but talks about the same thing and explains all the features in a new ok two more things we had in the last year there was an audit and of last year sponsored by augur and done by Co inspect it has found 10 low-risk issues

nine of which we have fixed a while back probably in December and there's one single low-risk issue outstanding which is a proposal a bit over about the override keyword in inheritance and that is of course part of the inheritance discussion so it's not forgotten just report there if you want to read it but we have a second audit ongoing at the moment which is done by the Zeppelin teams and actually we are working closely together with them so whatever issues they identify we can fix them up front they haven't identified any anything major just low-risk things in with tooling so whatever changes we have done as a result of that improves the

way people can get into contributing to solidity because the way they wanted to understand it is hard key they can start work on solidity and identify issues afterwards okay two more slides the team it's a solidity for long wine for the two years mostly have been only Chris and me which worked out really really well but we were kind of slow in and trying to get new features we did had a lot of external contributors but they were coming and going some of them stayed longer than others we will really like it this year to grow the team and we managed to grow the team into seven people the names are in order of joining we had Eric Daniel

Leo Christian and Chris and now we have three Chris's and we have no idea how to distinguish them somebody has Chris want Chris to you and Chris tree but that's not the best one we were lucky to we were lucky to grow the team but that doesn't mean we don't want any more contributors and contributing to solidity doesn't mean that you have to write compiler code we're happy to receive feature requests or more than happy to receive discussions on existing design issues and feature requests but if you're not a coder or if you don't want to get your hands dirty with language design you can still improve the documentation because the documentation can always be improved well if lastly if you do want to get your hands dirty with the compiler code

I would suggest to have a look at this tutorial which has been made by one of our external contributors Federica and it ifs you a step-by-step guide how you can get started with writing with changing the compiler itself it's one hour long but I think it's worth watching if you do consider to help out I would suggest you look for issues labeled Help Wanted or good first issue and you can also find a lot of them labeled bounty worthy and they would have usually a gate coin bounty attached it's really great that we have so many been teased by get coin because we actually had I think at this point close to 10 external contributors joining true

the mentees and some of them stayed so that's the link I mentioned please download the talk there and click on all the links thank you [Applause]