 So yeah, my name is Alex, I'm part of the Solidity team. And in this talk, I will go through why I think Solidity needs to evolve rapidly. And we'll also bring some examples to show that it did evolve rapidly in the past. And I think this is very useful and it's actually needed. But before we get into some of these details, I will provide some reasons why I think this is like a truthful statement. But before we get into that, I brought some interesting trivia by digging through the changelog. And I think this will show some interesting things. At this part, feel free to maybe interrupt me like once or twice, but there will be a longer time available at the end for a Q&A. So the main net of Ethereum kind of launched in July, August. And the first release of Solidity, according to the changelog is 010. However, it's not even tagged in Git and there's no build anywhere. So I'm not even sure if it exists. But 011 is the first one which actually exists in terms of a Git tag. And it's part of the binary releases, but it's not on the GitHub release page. It was only the X-release, which is present on the release page. Now, going into changes in the language, the first actual new feature introduced was in 2015, September, it did throw statement. Does anybody remember that still? Yeah, I'm glad it was gone, but we may be able to bring it back for a different reason. Now, in the same year, we had the first two breaking releases. So still in 2015, 015 was the first which broke, I guess the ABI, it broke the encoding of storage. And also this was the first version I ever used of Solidity. And then 0.2 was the first one which made a break in the syntax. The reason for this change here was is it was kind of ambiguous how to parse the old version without the parent uses. Now moving on to the next year. Quickly, I mean, this was just like three months after there was a new breaking release with 0.3.0 which made some preparations for assembly and also made libraries usable. And then moving on, still in the same year, roughly another like six months later, we had another breaking release. And this had quite a few breaking changes. I didn't list them here, but I counted at least 16. And you guys can see, it's already had two familiar features of today, the version pragma and the payable keyword. And also by 0.36, does anybody remember the old formal verification backend? That's also gone for a long while. And then we had the metadata and just going on to 17. All these features are really familiar to everyone. And as you can see, we had like a really, up to this point, we had a really steady, really schedule. We had major improvements every few months. And you can see a big break here. So end of like 2017, we were midway through the 0.4 series. And of course in 2017, the ecosystem exploded. A lot of people came into the space. A lot of new projects were spawned. So at this point, we got a bit more careful about making breaking changes. And this carefulness resulted into looking back, like two slides back. September, 2016 was the last breaking release. The next one was November, 2018, two years after the previous one. And this was because of this carefulness that we didn't want the two to make breaking changes because people would complain, people wouldn't be happy, and we didn't want to just slow down anyone. But actually what we ended up doing is slowing down people even more because the 0.5 resulted in 60 breaking changes and people didn't want it to move on. It took quite a few releases into 0.5 until people finally started to move on. And this was also the first time we ended up releasing a 0.4 like a previous version after 0.5. So we had a 0.4.26 release with serious bug fixes because people were still heavily using it. And somehow we managed to repeat the same mistake with 0.6, release last December. It took a year after 0.5 and not 60, but 30 breaking changes. So these were some interesting 3D I like, but let's go into the actual reasons. Well, I think all of these changes are actually happening. So reason number one is the goals of the language are kind of shifting. And initially we wanted to have a really friendly language to attract a lot of people to the space because both Ethereum as a protocol in this system and both Solidity as a language were brand new and basically the concept of smart contracts, they did exist prior to Solidity, but this was really the first language which made it usable and friendly to people. So the goal was to be friendly and to invite a lot of people. So because of that, we choose a design which looked like JavaScript and did a lot of weird implicit things and was kind of easy to learn. So this is what we ended up with people doing an example from 2015. It's such a lovely piece of code. So this interest, do you guys can, I guess you can see my mouse. So this is an interesting line because we didn't have the new keyword for bytes. There was no way to allocate bytes here. So because of that, there was this nice predefined allocation in terms of spaces. So this was the one of the features missing. The second feature missing is we didn't have shifts as it can be seen here. And also there was like a weird bug. The comment is wrong, but the bug was that if iterating the other way around, then some fields, the last field I believe was overwritten by the last store. So this is an example that we didn't have too many features and we were super explicit. Moving on to 2016, here's another like interesting piece of code. What is this doing? It's trying to concatenate strings. And we had no such feature at all. Interestingly, we still don't have a feature for concatenating strings, but there's this side effect of ABI in code packed introduced two years after this code was written, which can be used to concatenate strings. So still at the reason one, the goals have shifted and this is what we had in terms of language. And I think at this point, we're not trying to be a super friendly language for people familiar with JavaScript. Rather, we're trying to be a safer language while at the same time, also trying to stay friendly in syntax. But the goal is safety. So because of that, we have a lot of verbose syntax, a lot of explicit syntax, and we really try to highlight constructs for people which would be risky. So as an example here, anything which would cause abandoned gas usage is a huge risk because you could end up with a lockup. So for example, there will be tomorrow a session about an explicit copy syntax. So that could be one of the cases where we try to highlight all of these riskiness. So that's like reason one. Reason two is that Ethereum is still learning. The protocol and DVM is evolving. The new feature set is one example, create two was introduced quite a while back, but to fully exploit the benefits of create two, we needed language support. And that also took a while to integrate because of deciding what the syntax should be. Also these protocol developers create a lot of new restrictions every now and then. And they also reprise instructions. And all of these have like a profound effect on the language because structures and features suggested prior may become unusable or may become a bit risky. As those changes are enacted in the protocol. And lastly, even bigger changes are coming. There are the new protocols being developed. One example is E2.0. That also has like a huge effect on the language because it introduces such features which have no concepts in the language right now. Reason three is that the ecosystem, the developers, they're still really learning how to use this language and how to use the whole system. And they're doing like all sorts of interesting and weird and maybe sometimes dumb things. And we have to really find a careful balance here in the language between providing them good features. So they shouldn't be just running around and trying to implement everything from scratch, but we shouldn't be too restrictive. We shouldn't just tie the hands. It's really hard to find this good balance between providing enough features but not being too restrictive. And we are constantly trying to figure out this balance. And I don't think we have found the balance yet. Reason four is that experts or auditors, they're also learning. I guess like in 2015, 16, when all this started, probably it would have been possible to count the number of experts in EVM or Solidity in terms of capable of auditing code. I would have been able to count it by hand. Maybe it was only like eight or 10 of them. But today it's like quite a healthy ecosystem. We probably have a handful of companies with a lot of people in each who are experts in the complexities of Ethereum, EVM and Solidity as well. And it took quite a while for these people to build audit tools, which are needed to aid their work. I want to reflect back here to the three earlier talks we had today from Ricard, Akash and Muli. These tools are really valuable and important. Because you guys mentioned that you have found issues in the language and issues in the compiler itself. And I think that's really important that we take all of this advice and reports from you guys seriously and we consider the implications on the language and we should change the language if that's the right thing to do based on those findings. And the fifth reason is that the Solidity community itself is still learning a lot, have to do things right. We are trying to figure out which are the features which language should have and which are the features the language shouldn't have but we should enable people to build those features on top of the language. But I don't mean here that we want everybody to reimplement the same things. We want some kind of modularity and it's really hard to figure these things out. Also we still don't know what are good syntactical options and what are bad syntactical options. We're trying to first choose something which looked okay at the time but probably realize a few months in that together with some other features it may not be the best way to do it. So it's nicer to change it. And also it's really hard to find a balance between how we're both the language should be or how implicit the language should be. And I think right now we have decided to be on the really explicit side of the spectrum but it's still unclear whether this is the right approach to take. I think we have to experiment and find out what is the best approach. And lastly just the way delivering these changes to the actual depth developers. That's also something which was a bumpy ride so far. So just going back to zero for zero again. Another reason probably zero for zero took quite a bit because developers rely on frameworks. They don't use a compiler directly and they shouldn't be using the compiler directly. These frameworks are really useful and helpful for them. But I think at the time like in zero four so like 2018 ish a lot of these frameworks were still early and they may not had like options to rapidly deliver a new compiler versions. I think we have learned over the past like two years how to deliver new compiler versions more rapidly to developers. Which also really is really important. And I guess one more note on that is which probably nobody has heard about but we do have a tool called solidity upgrade or update. I think it's upgrade, which can be used. This exists for zero five and zero six and it can be used to automatically transform in the case of the zero five, a zero four piece of source code to the zero five syntax. Of course it cannot do everything but it can do a lot of the manual work. So I think we learned quite a bit how to deliver these changes more quickly to developers. So I think these five reasons show that we need all of these changes and we need these changes to happen fast because we're still really early in terms of the protocol, the language and the ecosystem. I think we're also quite lucky lately that it turned out that solidity is extremely popular and this is also showed by the two new compilers which have surfaced for solidity. And we're also lucky to have these two new compilers to take part of the summit. Today I think Sol will have a talk later on and tomorrow Solang will also introduce your compilers. And I would like to take the opportunity here for to reach out to you guys to say that it would be really nice to work together on the language design because it's important to have a consistent language across all of these compilers and it's important to have the feedback from everyone. So I guess what remains now is just to show how any of this design is happening because probably not everybody is aware that the design process is quite open. You may think that this is something restricted and we are like in our dungeons and we discussed in hiding but it's extremely not the case. All of the discussion, all of the important discussion is really happening on GitHub issues on the ethereum slash solidity repo. Unfortunately some of these issues go back to 2016 and it's really hard to get feedback to some of them and to engage people a lot more. But we do have sometimes we do have ad hoc discussions on Gitter Gitter or we do have in the team two weekly meetings on Monday and Wednesday. And in many cases we do discuss some of these features in like a more fluid manner on these two mediums but in every single case when we do that at the end of the discussion we do record our findings on the issues. And lastly we do have to submit here with the main goal to discuss actual language design questions. But let's see how could we move on to the future? So I collected like three different options for going into the future. And the first one is we could have some kind of a focus group which still tries to have a similar development cycle as we have today. And this practically would mean to have regular meetings to brainstorm some of these issues. So you can think about this as kind of like a mini-solidity summit on a regular basis. I guess as we move much more into the future we could have more structured proposals just like Python, perhaps, or the Swift evolution. But I think this might just slow down development right now too much. But I think we can take some learnings from them. And finally, I guess in the really far future we could have some kind of a language committee but I wouldn't advise to consider that for now. So my conclusion is that we need to keep all of these. We need to keep making these changes at the current pace and maybe we should consider just this focus group. I think I don't have too much time maybe for one question but I will be hanging out on Gitter to answer any questions. Thank you.