# 'The Future of Solidity' - Alex Beregszaszi

- Speakers: [Alex Beregszaszi](https://streameth.org/speakers/alex-beregszaszi)
- Channel: [ETHGlobal](https://streameth.org/ethglobal)
- Date: 2021-10-09
- Duration: 30:01
- Topics: Alex Beregszaszi, Solidity, ETHOnline, Ethereum
- Watch: https://streameth.org/watch/yt--aSMCa4O7mg
- YouTube: https://www.youtube.com/watch?v=-aSMCa4O7mg

## Description

Alex Beregszaszi of the Solidity team discusses the future of the programming language and improvements the team hopes to make.

## Transcript

um next up will be alex so my teammate from solidity alex is actually co-leading the solidity team and he's also leading the e-wasm team but this talk is going to focus on solidity alex is going to present the future of solidity which will entail a feature preview for the upcoming 0.8 release but i guess also a bit more than that hi alex welcome heather i'm just still trying to share is it shared yes we can see it i'm just a bit confused with zoom can you also hear me yes okay now i can hear you as well um thank you francie um okay let's get through this so what i'm talking about today is um a couple of different parts um regarding solidity um initially the goal was just to talk about zero eight um but if time allows we'll see am i gonna go a bit further than 0.8 um but before that i can actually um so before that i just wanted to highlight a couple of things we have launched this week a language portal which can be found on soliditylength.org and it has all the relevant links to to everything including the blog um all the different forums um the the releases um and also some some background detail and i think all of the links i have in in in the slides can be found to the portal now that the portal is still in development and it's just the first version and we hope to make it um much more um you know packed with features and and and content um but that that's just gonna take time um the second thing i wanted to mention is this underhanded uh solidity coding contest um which is a fun little challenge uh to see if you can hide functionality in the source code now regarding the agenda of today um here's another link which also can be found on the portal um it goes through the past five years of solidity handling which has changed with a couple of uh interesting tidbits um but we're not going to talk about that today um i'm going to have three parts but depends on how we get on with time um first the short term um part is i just wanted to to make clear you know how the the the release process works in the team i know we have mentioned this many many times already um but it never hurts to mention it once more um so we try to make really frequent releases two three weeks um i know sometimes we we haven't really gotten to do that and maybe it took like six weeks um and in in case of of bugs we do make quicker releases but i think we're fairly consistent at two three releases um to release this every two three weeks um and we also try to make breaking releases uh twice a year um we haven't really done this so far but maybe this year going to be the first time we actually achieved that uh so the last breaking release was zero seven in july and we hope to have one um 0.8 by end of this year and for 0.8 i've collected four interesting features which um seem to be becoming part of 0.8 um i think some parts may change slightly um but i think mostly what i have in these slides gonna be uh what's included in zero eight uh regarding those um there might be some other smaller or different changes i haven't listed um but it just isn't time to go to everything so the first interesting one uh i'm sure everybody is is waiting for this forever by now let's start with a simple example here so what happens in this function if he passed in minus one and one um the function would return one because it wraps around and why doesn't it just revert we you really shouldn't wrap around one could say and there's a very simple reason to that um because solidity is just exposing what the evm is doing we are not trying to add extra code because that costs gas and people don't really like to spend extra gas if they don't need to um but in this particular case it seems that actually people are willing to spend gas because they don't really want this to happen um and that is signaled by uh the safe math libraries and um or the safe net library well actually probably more of them um which prac in practice everybody uses so the good news is that you may not need to use it anymore in zero eight um so in 0.8 we're introducing what's called checked arithmetic by default so this piece of code here uh would cause a revert uh in the previous example and this is exactly what safe math is doing but what if you actually want the overflow the wrapping around behavior we actually got you covered um because we have this extra feature here called unchecked and and any piece of code which is uh wrapped in the unchecked block won't have the the um the overflow underflow checking generated so those will behave as they were in 0.7 um i haven't really gone through everything here there are various different edge cases so please check the documentation because it's it's much more than these two slides could cover but there's another interesting piece here regarding type conversions actually a few weeks ago i uh tweeted about what what do you think is address minus one valid and initially the the response it was a poll so the initial response to that um was what i hoped i gonna get is that it's not valid uh but people actually checked the documentation or remix and turned out yes it is actually code which compiles so the the call ended up saying it's valid code the reason we found this because i mean it's not about finding but the reason it came up as a discussion and is because we were heavily working on the smt checker functionality and we wanted to properly implement different type conversions and actually all these little details on this slide and the next slide is the outcome of that review process and we found that this is rather confusing so i collected a couple of different strange conversion scenarios here unfortunately we are not really interactive but i gave you two seconds to think what each of these going to result in okay so these this is what actually happens i mean some of them you could you could understand it's could be said to be intuitive but i find it rather confusing that we have so many different rules and um in many cases we restrict everything and and then we have this type conversion mess um luckily we won't have this type conversion mess anymore um the really interesting part down here is the the bottom three cases so depending on just basically this this very last line here the outcome would depend on the implementation and by implementation i mean whether first design conversion is taking place on this line or whether the size conversion is taking place first the outcomes would be different this is of course not a problem in solidity because the the order precedence hasn't changed um neither it did in the new code generator uh compared to the old one so nobody has really uh seen this as an issue but as we are uh having more compilers for solidity and more people looking into solidity if this is not well specified then this could become a problem um but there just doesn't seem to be any reason to support this functionality so we actually just removed it um so all of these weird cases here with the exception of this valid address all of these are becoming invalid um so basically the literal has to be the literal is this here so it has to be less or equal to the bit width of the type and the signs must match the type and by this i mean that if it's an unsigned type it's not possible to assign a signed number to it um it's only possible to assign it to signed numbers we do have one exception is address zero because that's that's really useful and it's used very frequently um now another i think extremely important piece is panic codes and you will see that this is actually connected quite a bit to the stuff previously discussed so currently there are two different ways where code can abort and the one case is where the code is gonna have an invalid up code and that means that all gas is going to be consumed [Music] and the second case is where we have a river drop code and of course this only applies after constantinople or byzantium anyway this has been introduced a couple of years ago but it hasn't been there initially so basically there are two ways to abort execution with failure one case is with the invalid opcode when all gas is consumed and the second case is the reverter code where the remaining gas is kept and there's another main difference between these two is that it's reworked it is possible to send a message um to the caller and that message could explain why it did via board now this is what we have today before zero eight and in many cases invalid up code would be used uh internally and this is changing now just a bit more explanation what what rewards are um so this case like with the require statement which i'm sure everybody is aware of that of course uses the reward of code and actually what happens here is that we have an encoding for this message we're not just putting this message into the the revert message but rather we encapsulate it and we encapsulate it with the ebi encoding um and and practically it just looks like a function call so with the the error function which has a string and then we just encode the message and so one could say that this expression here this statement to require statement would equal to this one so it's just a weird way to to encode the same thing um so we have um these error messages and now we're introducing a second case um the panic messages and a panic message is basically any kind of internal error is emitted as a panic message so the main benefit we get here is that we are not going to consume all the gas and second we are able to deduce from the outside why did the execution stop i didn't list here all the different panic codes and i think it's still possible to argue whether the code should be different because the release hasn't really come out yet um but we do have um i think i'm missing three or four more because there just wasn't enough space on the slide um it's however documented um in the the breaking branch um so it's possible to to still discuss these error codes but this is roughly what they mean um there is a specific error code for manually calling a search there is a specific error code for under or overflow and obviously that's outside of the unchecked blocks and there is a specific one for division or modulo by zero um the specific one for out of bounds access and type conversion there's also form for um trying to allocate too much memory etc there are a bunch of different error codes i actually invite all of you guys to to check the documentation and maybe give some feedback because it would be bad to you know hard code these and then next release people wanted to change them um and the fourth big change um i think is the api encoder b2 uh what changes related to it now maybe i i should just give a first um explanation what the hell ebay encoder b2 is i'm sure many of you do know what it is but maybe some others don't um so it has been introduced uh in 2017 so quite a while ago um and the ebi encoder is this piece of code which which generates the code to decode and encode all the the inputs and outputs from a contract so when somebody is sending data to contract it's encoded in this api data structure and that needs to be decoded and any response has to be encoded and the compiler um has two implementations uh of this uh code generator that one is um i guess api encoder b1 and the other one is abia anchor v2 um the main difference from the old one uh is that v2 generates yule code and the v1 just generates evm bytecode so it's it's kind of hard to to work with so the yule code is as much better maintainable and it also supports more types and probably that's the reason some of you have used it because it does support various features from structs which are not supported by the old abi encoder um but some of you may have also noticed that this v2 is a bit more strict than the old one and in some cases it may consume more gas um and this gas question may have been more more uh relevant um i guess early on when this was introduced but especially last year we have worked by last year i in 2019 and earlier this year we have worked quite a bit on the optimization capabilities for you um so i think actually the gas costs are not all that much off uh compared to the old one but it is way more strict um and because this um was a second encoder it had to be enabled by choice um so we had this um experimental pragma for abi anchor v2 and for a long while um i mean this has to be added in the source code in every single source code you want to use it and if a given source code doesn't have it and you mix these together um that is also working um and then for a long while whenever anyone specified this experimental pragma the metadata also had an experimental flag to signal that this may not be a production ready software and however we have removed this experimental flag from the metadata last year with the zero six release but we still kept the experimental fragment and now with zero eight we are changing this it is going to be enabled by default um but for those who still want to use the old one which i don't see any reason to but if you still want to use the old one you can do that we are introducing a new pragma here called ab encoder and it has two options v1 and v2 so if you want to keep using the old version you have to introduce this extra line um you can also explicitly use this new one but it is enabled by default um and to make life a tiny bit easier um probably we are going to keep supporting the experimental pragma but it's going to emit a warning now that is all about the zero eight i wanted to highlight but there's of course a lot more if you have a project in github i haven't linked here um but i guess i can show it to the q a if you have time and that project we use to rank and sort different proposals and discuss them um and that project is just basically working of these labels and what i'm trying to show here is that we have two important labels we work with the language design and the breaking change and you can see that there are 126 open language design issues so that's quite a bit of changes um and that means of course these four changes i mentioned are not the only ones which we are discussing um obviously it's not possible to discuss all the 126 changes uh you know every week but we do pick uh from these issues um and here i picked actually four different issues i wanted to highlight which are important at least in my opinion in the medium term so whatever i said regarding 0.8 is is probably what we agreed on as a team but this part of the talk is is more like an opinion piece it's not like a final decision from the team and and i'm not trying to to make it look like so um but i think these four issues i'm gonna briefly talk about are really interesting and important for the future um i'm sure you have heard about this solidity to dual code generator for a long while because we have been saying this for years that yeah we're gonna have this dual code generator done and um yeah actually we are quite close to that um so we have a project board a separate project board not the one i mentioned um just for this solidity to your code generator um and this project board is becoming rather empty um so it would have like five different columns from icebox to in progress to in review uh to done and we only have a handful of issues in the icebox and over 50 issues in the done um but unfortunately it's still not hundred percent uh complete um we have two major things to finish one is support for libraries and and some cases of copying between memory and storage um however we at the same time trying to maybe consider moving off libraries so i'm not sure what what's going to happen with this here the main goal of of having this sold to you conversion is to have better maintainability um and also because the abi encoder v2 generates fuel um it it provides a much better integration so one could imagine that if uh if you're using this salty yule and api encoder v2 then we have the entire contract generated in yule and we can apply optimizations on yule itself then we can translate the dual code to evm and then we can also apply optimizations on the evm byte code um compared to that today it's a bit different because if you compile directly to evm in the compiler and then use debian v2 what that means is one needs to compile the api encoder v2 output to evm and then consider the evm code so by moving to this intermediate step you're going to have much better possibilities for optimization and it also going to finally give some solution to the stack2d power and there is actually a piece of code implemented called the memory escalator which can move um variables from the stack into memory and back and forth um and that is implemented on yule so hopefully that is also going to be fixed by this i don't really give any deadline when this is going to happen but yeah we're really hoping to to get this down uh fairly quickly um so this salty yule project this feature can already compile a bunch of contracts that can compile the unit swap um um factory as well i believe um and it can also compile the e2 deposit contract and it can almost compile diagnosis if in the multisig wallet there's only just one feature missing in each another i think rather interesting functionality we are discussing and here's the link for the discussion is enums well not with metadata um yeah enums with data or algebraic data types um so here's here's a small example um as you can see we are using the enum syntax and and it is possible to to have various um oh why why is the okay um yeah there should be a column um a semicolon there a comma there um um anyway this is the current syntax this is not implemented this is only under discussion um i think what i wanted to to actually highlight here so you should rather just go to the issue because it's um a lot to discuss um but this is a simple example um and what can be i guess seen in the next slide is that we don't have a syntax for matching yet so basically one would need to have a long uh if else chain and to evaluate all the different types and the current conversation is really uh just focusing on on how to encode this uh in in the api and the storage um and i guess once we have that done then we could talk about the matching but anybody is invited to to come up with any suggestions and especially i would be interested to see if anybody is really interested in this functionality and how would you use it um another really highly debated topic is the templates um i think this issue was created in 2016 so it uh maybe even 2015 so it it exits for a long time and it has been discussed uh for a long while uh on the issue actually there are a couple of links to different github guests or just which have a variety variety of examples and i'm not going to go into too deep into that but here's a simple example from how to do typecasting um it's it's kind of like a great example um but it shows the syntax i mean it's nothing really uh strange or unfamiliar it's kind of similar to c plus plus and rust um what we are more um i guess busy with regarding templates is writing more examples to to find potential problems um and by doing so we also figured that we would need a lot of different introspection helpers for types um and this is somewhat related standard library is um is something we also dislike the fourth topic we also have heavily discussed um i want to i want to make sure everybody understands you're not trying to compete with open zeppelin um so it's not a standard library for ercs and and higher level uh protocols and um functionality it's rather a standard library for moving more features uh from outside of the compiler code base and to also maybe decouple the evm specific behavior a bit more from the compiler i gave you two different examples um so one thing what could happen with uh having a standard library is removing the need for global functions we have um now this here it doesn't really say anything more where where this standard library lives it just means that by default in the namespace there wouldn't be an easy recover as it is today but rather it has to be explicitly imported um and one could imagine that maybe this standard library would be still part of the compiler and all this means is just cleaning up the namespace um which is i think already a useful step to make but we could also implement some of these helpers in solidity itself um this is an actual implementation for easy recover even if it doesn't look nice but it is possible to move um functionality out of the compiler and i think this is going to be some of the the really interesting steps to do and um some of these examples i gave prior like the templates and algebraic data types these actually play quite well in to the standard library discussion and now we got to the very end is what the the long term uh going to be like for solidity um so this just has a bunch of different questions um and i feel i have some answers to them but i i don't think we have enough time for that um but one question is will we have different targets or different dialects of the language uh will we support uh roll-ups different roll-up systems in the compiler really support some kind of sharding where we will support e-wasm just a brief answer is what i discussed about this soluble stage is that yule is an intermediate language which not only can out can be converted into evm but it can be converted into other byte codes as well um so internally in the compiler we have a piece which converts it into e was a more just web assembly um but we also had a a discussion with the the ovm team and it would be possible to translate it into ovm bytecode however that hasn't been implemented um and the importance of dialects or targets would be to uh have the capability to disable features in the the source code which would be specific to a different specific target yeah i'm not sure if we have time maybe for one question but i think i feel that the 30 minutes um so yeah that's that's what's i guess next for solidity great thank you alex um yeah we are perfectly on time so we don't have that much time uh left for questions but um i wanna ask one question before we wrap it up um so basically all of this was more or less about the future language design of solidity um are you currently happy about the setup and process how it's working or if you could make a wish who would you uh wish to have participate in the language design more everyone yeah i think definitely the participants we have today is mostly auditors and some people who have been around in in uh ethereum quite a long time and and maybe those people who have been around since 2016 uh when the the community was tiny and they they don't really feel anxious to reach out to the projects because they feel like they're on the same level um and i would encourage everyone that you know we are not like some some some videos hidden somewhere we are just like you so we'd like to talk to you you know whether you start your first hackathon or whether you have deployed your d5 project we want feedback from all of you guys that are nice closing words thanks so much alex and