 When you design a programming language you have to make compromises constantly there are People who request features and of course features are nice but with each new feature the language gets more complicated and thus Either harder to understand and it's easier to make a mistake the more complicated the languages So you have the constant balance between Functionality and safety of course there are features that are safe, but yeah, that's the the compromise you have to find and This has not been the case for general-purpose programming languages for several years now, but in blockchain there's always the factor of cost so Smart contracts have to be very cheap to execute and that also limits the features you can add in a language Back in the days when solidity was started the initial goal was to create a usable high language High-level language as fast as possible, and I think we succeeded in that But of course we made some decisions. We know yeah, which turned out to be not that Turned out not to be the best decisions and Now is the time to change them and solidity is still a language that changes and that allows us to make the necessary changes to the design and Yeah, the the path you want to go is we want to keep Features that are relatively safe and we they Look like high-level features, but most of them are actually quite low level So we want to have features that that yeah look like look look like high-level features, but are still cheap and We want to remove everything that can surprise users or has some some magic involved and then a third factor is We are adding formal verification tools that are easy to use and this I would like to stress this easy to use part because that is essential and we will see that later in the talk and Then if that is not enough for you we provide direct way to access very very low-level features of the Ethereum virtual machine and The important point is here that we remove everything that is kind of intermediate level so for example address dot call will be removed in the future because It has some Magic some some unexpected things involved that we would like to avoid so if you want to do such low level things You have to go all the way down to the Ethereum virtual machine Okay this is kind of the Yeah, the path we want to take now. Let's talk about some new features. We added in the last year This contract here is a yeah simple database that stores people By an identifier a name and some flag that says whether they are owner of something and you have a function there Which allows you to add one person to the database It already looks quite repetitive and but it gets even more complicated if you want to add a function that Can append a list of people into that database the problem Many people run run into is that you kind of have to create an array out of these three things here And what you usually do is that you add three parameters, which are each an array And this of course creates the problem that you have to check that all of them have the same length because you have an ID that corresponds to a name and this flag This looks really really ugly But fortunately now what you can do now is oops, sorry What you can do now is this and we added structs as a Central feature to the ABI which allows you to actually just directly pass this truck from JavaScript into the contract and remove all this the these weird repetitions and Of course, you can also return an array of structs. So this is not This is not yet available, but yeah, thanks So we hope to get that fully functional by the end of the year So and the way we the way what this this was possible while was Through a change in the compiler itself So we we could have done that the old way but we decided to do a full rewrite of the ABI encoder and decoder and This is a snippet of the Solidity code generator and how it looked before this change Yeah, this also this is also really really ugly the EVM is a stack machine and because of that you have these these pop and dup operations and In the code generator you constantly have to keep track Which variable is where on the stack and because of that we have these Commons and it's really really complicated to understand what this code does and also complicated to write new code and This is how it looks now and it Leverages a new intermediate language we introduced called Yulia Alex talked about that. I think yesterday or the day before yesterday. So I will not go to into depth about that but You see this is really really readable It has variables, you know What happens you can? Use names we have for loops and so on and what you also see is you have these angle brackets here, and this is because this is an intermediate language Mixed with a very very simple string templating engine to make it more flexible What you see here is the full function to do any encoding of an of an array into the the ABI encoding so it does handle memory arrays call it a race storage arrays Arrays of arrays arrays of constant length arrays of dynamic length and so on and The way it works is that for example here at the top we have length equals length fun and At the time of compilation this length fun is Replaced by the name of the actual function to retrieve the length of the rate Which is of course different for a statically sized and dynamically sized arrays okay, and a Language becomes more and more useful the better tools are available for that We already see that by in the questions that were asked in the previous talk Remix got gigantic updates. I think Jan will talk about that later today We now can track variables have break points See references of variables, and I think soon can also rename variables and so on We have a way to export the AST which is the result of the of the parsing step and these this allows many new features and one of them is a Tool to do code coverage not based on Syntax not just based on lines But on semantics so for example is a less than operator actually tested to do what it does and Then a standard JSON IO this is a way to get more fine control fine graph fine grain control about the settings of the compiler Yeah, then I have a very special announcement to make and this is that the Solidity documentation that we only have in English for now is now also available in Spanish So please give a big round of applause to these five people who? To these five people who did that in their free time Just as voluntary contributors I think this is really important to make if you're inaccessible to the world and Languages like so like like Chinese or Russian should also have a their own translation of the documentation and I want to spend the rest of the talk on formal verification of Solidity and Whoops, I Think I showed this slide to you last year in Shanghai This is a smart contract and It has comments Which allow a formal proof that the the sum of the balances in this token construct a contract never changes The way it works is that the smart contract gets gets translated by the compiler into a language called y3 and it mixes this translation with the with the comments you have here and Then you run an external tool on that to create the proof that the balances are constant the sum of the balances are constant but what you see is that The there are almost as many lines of comments in this code as there is code and you also see that the These comments use a language that is slightly different from Solidity, so it requires you to learn a new language it requires you to learn how to use these tools and this is this makes it very hard to use this formal verification tool and the harder it is to use the easier it is to make mistakes and Also, it is easier for so Formal verification is only useful if people understand what is actually proven there so the statements that are proven there have to be understood by humans and If that is not possible then nobody will use formal verification and it's useless and because of that so yeah, perhaps that approach was not so great, so we took a step back and reconsidered and How it looks now is like this We've replaced Y3 by a tool called an SMT solver SMT solvers are less powerful than general Theorem Provers and because of that this smart contract in this smart contract We cannot prove that the sum of all balances is constant, but we can prove that The sum of the two balances that are modified is constant So what happens here is we have a require statement, which is Yeah, doesn't have much to do with the formal verification This is just the regular Solidity requirements require statement and then we store the sum of the two balances in the before variable we perform the modification and After that we check that before equals after And this is a regular Solidity assert so if the sum of the balances is Not the same then this will throw an exception at runtime But using the SMT solver you also get a proof at compile time that this assertion will never be triggered Okay, more specifically what happens is that so you can use this tool with require statements to have expressions that you assume to be correct and then The tool proves that there is no assertion that fails There is no overflow or underflow in your arithmetic operations No division by zero. No constant conditions. No unreachable code and whatever we will come up in the future and so let's take a look at a simpler example This is still an experimental feature and because of that you need this first line that activates the SMT checker and Yeah, the function here it just takes two numbers and adds them of Course there's a problem because we can create and we can have an arithmetic overflow here in this edition and This is exactly what the so if you run the compiler on that then this is the message you will get and The great thing about this SMT solver is that it has so it's More limited than why three but it has a feature that why three did not have and this is the following so you If an assertion fails it tells you why it fails and I think this is really important because otherwise people say I don't know It doesn't work, but okay. Let's just let's just comment it out or whatever through something at it so that it doesn't complain anymore, but this tells you why it fails and Kind of forces you to think about this edition and think about why it might create an overflow and then Take the necessary steps to prevent the overflow before it happens there are so Currently what people often do is create runtime checks about overflow add runtime checks about overflow in in arithmetic But this can be really dangerous because if you end up in a situation where you you have an overflow because of some yeah internal Mechanism of the smart contract then it will be that the smart contract will be stuck because it will always throw this exception because of the overflow And you perhaps can't get the money out or whatever But if you already get the warning at compile time before you deploy your contract You can think about why it happens and prevent this from happening in the first place and how you prevent it is like this So you had a require statement Which of course in the end has the same effect as if you would just check if there is an overflow But the benefit is that you see that there's an there's an additional condition that is present about these numbers a and b and The SMT solver will now see the require statement take these conditions into account and then check again Whether the overflow will happen and of course it sees that a number Less than 2 to the 100 plus a number less than 2 to the 100 will be less than 2 to the 256 Okay Yeah, let's take a look at another example This is taken. This is an actual example from the underhanded Solidity coding contest where there was a Loop that used an unsigned variable and decreased it but checked against greater or equal than zero and of course This loop condition is always true That's of course something that can be detected from the type of of the variable alone and you don't really need an SMT checker, but yeah, I This was a simple example to present here and it can do much more complicated conditions and Yes, this is what we'll see next and Yeah, this talk was quite dry about Programming language theories, so I would like to end it with an exciting math puzzle So here we have a Circle plus circle equals 10 Circle times square plus square equals 12 circle times square minus triangle times circle equals circle. What is triangle? and he guesses So yeah easiest pie we just write a small Solidity program that is equivalent to this puzzle and We add the conditions as require conditions and then at the end assert false so assert false sounds weird Why would we do that and the reason is? if the SMT checker Can prove so a failing assertion so assert false is not bad. It's only bad if it's actually reachable code so False assertion will not be triggered if it's not reachable So the SMT checker has to prove to us that this assert false is actually reachable and it's reachable if all the three require conditions above are true and Of course, it doesn't just tell us that it's reachable. It tells us how it's reachable So what are the exact inputs to get to this failing assert and we see that triangle is one Okay This kind of shows the power of the SMT so we don't really Know yet, so it's not it's still experimental and not fully finished yet We don't know how it will behave on very complicated Contracts, but yeah, we're we're optimistic and let's see how it goes. Thanks. Thank you for your attention