 Hello. So, yeah, welcome to our talk. My name is Eric, and my name is Matthias, and yeah, we are going to run you through some new features and solidity that we worked on on the past month. And so we have the link to the slides on the slide itself and also this QR code. We are quite curious if this works for you. We tested it numerous times, but you never know, and every phone special works. Yeah, but I mean, at least it looks nice. No, it did work apparently. At least one person managed. Yeah, so I will quickly run you through the agenda. So, first we want to talk about some language features, the most prominent ones. Also, we have introduced some compiler features, like some changes there. Okay. So, and then the next point is like future development. What are we like planning to do in the future? And yeah, so we will also have a Q&A session afterwards. And so let's start with the language features. Yeah, quite exciting stuff going on there. Yeah, we spend quite a lot of time on a new inheritance system. And my mic just went out. Okay, a new inheritance system, which doesn't actually mean like, I don't know, actual new features. We added keywords and checks that you can program in a more safe way that the compiler does more checks. So, starting with override and virtual, you know them probably from other languages, C++, etc. Here you see a contract written in the pre-06O version. There's nothing special to see here. You see we're overriding the contracts three times to the total supply function. We always call the base function of the previous one. And yeah, nothing special here. This changed in the new version to look like this. So you see we have a virtual keyword, which you need to specify if you want to override a function, otherwise you can't override it. And similarly, you have to specify override in the function that you're writing and virtual if you want it to be overriding. So it's not implicitly virtual again. And the final inheritance here, we didn't specify virtual because we don't intend to override again. Yes, and so far we have multiple inheritance. And pre-06O, it looked like that. There is again nothing especially exciting to see about this. We have the RSC777 contract, which implements also RSC20. We just showed the total supply function here with one implementation. And in the new version, you now have to, yeah, again, hold on a second. I'm slightly confused. Right. Okay. So you see, it's an interface. That means you don't need to specify virtual because it's an interface. It can't have an implementation and it must be overridden. So no virtual required. In the deriving function, you need to specify all the contracts or interfaces that you want to override. If you leave out one here, it will be an error and the compiler will yell at you. Also, if we were inheriting from two contracts with their own implementations, then you still need to override it explicitly. If you leave out the whole implementation that arrived class, it will also be an error. So we want you to be explicit and to know what you're actually, which base implementation you're calling or doing your own implementation. Then we're moving on to abstract contracts. In pre-06O, again, a simple example here. We have total supply defined but not implemented. And this, well, it compiles. It gives you no error. No code is generated for the total supply function because there is none. And you will get an error if you try to new this contract, but not before. So you might have silently not working code and your compiler would not tell you. And in your code base, you wouldn't notice. Now, after06O, we introduced the abstract keyword, which you can see at the top. And now, you will get an error, as shown here, because you haven't implemented that function. And you must specify abstract if you have an abstract function, like without a body. So it tells you here that you should either make this contract also abstract or you provide an implementation. This propagates more safe code and you catch mistakes earlier in the whole process. Then a small new thing regarding interface inheritance. You can now inherit from interfaces, which wasn't possible before. So you can easily show that the interface for ERC777 is also an interface for ERC20. And, yeah, those are so far the inheritance features. Moving on to fallback and receive split. Thanks. So in the fashion of being more explicit in your contracts or in contracts in general, we also decided for a fallback and receive split. So I will show you what that means. So this is a pre06O contract with a fallback function defined. And this is called for both, so for non-existing function signature or if there's any ether received. So what's happening here? So if you send any ether, the transaction is successful and the contract keeps the ether. So we decided to split it up into the first part, which is receive. So we introduced a new receive keyword here. The function signature of the receive function looks kind of similar, but without the function keyword. And receive is being called if you send any ether to the contract via send or transfer. And this contract reverts if you call a non-existing function. And to handle this part, there is the fallback part of it. So just before the talk, we talked quickly about the proxy pattern. And so I'm quite happy that we have this example here. I mean, that's the pre06O version of it. So there's the fallback function. And in there you have an inline assembly code, which then has the delegate call magic. And this is called for both, or was called for both for a non-existing function or if any ether was received. And here we introduced a fallback keyword. So this contract then gives you a warning because there's no receive ether or receive function implemented. And the compiler, as I said, gives you this warning. And then you can just implement the receive and the fallback function. And then do in this functions what I'm going to do there. Just a quick wrap up. So the receive is executed if there's like a plain ether transfer and fallback is executed. There's a matching function signature or there's an empty data field and there's no repeat function. The next one might be a little bit controversial, but I think for the sake of clarity, it's a pretty nice feature. So we made the dot length member of Aries read only. So it's a little bit hard to come up with a good example here, but we just thought, okay, we will have this stack. It's a contract called stack and you can pass it a length via the constructor. And this is the pre06O behavior. And then you would have like a push and the pop function. So nothing special here. But it has some pitfalls. So I mean, first of all, you could pass like a very high number as length. And this could result into overlapping storage. And also accessing dot length looks cheap, but if you want to delete, then it's quite expensive. And so what I was what I said before is making this read only prevents multiple ways of accessing storage here. And this is the zero 060 version. So it should do the same. But here in the constructor, you would need to define a loop, for example, use an empty push function. And then push and pop are implemented similarly. And this code, we hope that it's more explicit because you would see the cost of it. Instead of just assigning to length, you would use this loop, for example. Yeah, I think that's about it. The next one, it's something we are really excited about. Try catch support. So just to give you an example how this could work. So we have a pre 060 contract here. And we have the contract consumer and it has a feed and a rate function. And now the thing is you want to react on the revert and the function data. But how would you do that? So there was no there's no way of doing that. So we decided to go for a try catch pattern that you probably know from other programming languages. And this is a 060 version of the contract. So again, the data and the body of the data function just revert. And here in the rate function, there is the new try catch pattern. So as you can see, you could just call the function again and then keep the return. Define the return values. And in case there is no revert or no, no assertion failing. This would in this example then return the value and flick the call as successful in this example. Because the rate function has you and then the bull as a return value. So for the actual value and the flick that states the success of the call. And in this example, so there is a reason given for in the revert. So revert reason. And the first catch block that you implement reacts on that. So in this case, because the function always works, we would reach the catch branch. And you could read out the actual string that was given. In this case, we return a 0 and mark this of like this as not successful. There's another branch that you could also implement. So just imagine you have a revert without the reason string or like I said, an assertion that fails. You could define another catch branch here that reacts on the low level data. And then here you could do whatever. And it's also possible to use both. So we just wanted to keep it out because then the example would have been too big. But usually you would implement both branches. What else to say? Yeah, I think, yeah, let's talk afterwards if there are any questions. Next are the function call options and Matias will take over again. Yes, function call options. You might know them as .gas and .value as shown in this example to transfer way or gas to the function that you're calling. We changed the syntax of this. This change was triggered by actually another feature that will come right after this. But I actually like the new syntax a lot. It follows the named arguments syntax. So you specify curly braces, the variable names and then the values. And I think it looks less confusing because before it looked like another function call, which it really wasn't. So I think this is a big plus. And it is also very consistent with the new feature, which is high level support for create2. So this is one I really like because if you wanted to create a new contract using create2, you had to do it manually in inline assembly as shown here. You first had to get the code from the contract you want to create, in this case product. Then we call create2 in low level assembly with 10 way. We specify the code. We specify the length of the code. And we specify an individual salt, which is creatively named salt in this example. We check if the creation succeeded. We revert if it doesn't. And there's actually a problem with this apart from being very low level. And some of you might see it, some don't. Does anyone see a problem here? All right. That's why we introduced this. I didn't see it in the beginning either. So here the new syntax really just call new in the contract. You use the named argument syntax from before for function call options. You specify the salt and the way you want to send. And the difference here is it's easier to pass arguments to the constructor, which we didn't even show in the previous example. But you notice we have now a constructor that is payable. We actually needed one, but the compiler couldn't check it before, because it didn't really know what we're doing in the low level assemble. Now this wouldn't compile if I hadn't added this constructor. And if you don't specify salt here, then it would be just a normal new, a normal create call, basically. And I think, yes, these are all the noteworthy mentionings of here. We have some miscellaneous features we also want to mention, but weren't big enough to variant whole slides. Eric, would you like to introduce? Yeah, so we have global enums and structs, so they don't need to be defined in the contract anymore. We also use every slices. Yeah, I mean the syntax, yeah, you probably know the syntax from other languages, so you would just define the begin text in the brackets. And finally we have a new asm statement, leave. You might know return, which basically ends the whole function call context. Leave just ends the current yield function, so you can be more precise where to accident, have more freedom in your control flow. We're moving on to a tool that Eric wrote almost alone. Yeah, so this tool is called SolidityUpgrade, and it came out of the necessity term. I'd like to just give you a quick look. In our testing pipeline we have some external projects, and therefore contracts that we always are testing with new compiler versions. So we want to see how changes that we're doing actually affect this existing code basis. So we have, for example, OpenSQL and we have NoSys. And developing these features we have to upgrade the contract. So, and as Matthias already told, we need a lot of inherent clarifications, we need a lot of manual updating of the contract. So, and just to cut this a little bit down, we decided to build this tool on our own, and it turned out that there was also some public interest in it. And then we thought, okay, yeah, why shouldn't we make this kind of public, and write some nice documentation on it. And so this is the reason why this tool ended up in our contract. And it's kind of simple, so it's based on lip solidity. So it's a C++ tool, and it just parses and compiles through lip solidity. And it's a hybrid solution. We are checking the errors that are like being reported by the compiler, and then we are doing like a simple textural source manipulation based on regular expressions on the contract itself. So for example, this is a pre-06.0 version, just like three contracts, and there's like some inheritance in it. And compiling this with the newest compiler version would lead to several errors that are being reported. But the tool is able to upgrade the contracts for you. Yeah, I will just quickly show you the command line and vocation here. So the tool, like SSH, is called solid upgrade. You would just pass a source, and the previous example, there are no errors being reported or no errors left, because there are no upgrades. So you could also have the situation that there are still errors, that the tool couldn't upgrade itself. So we implemented most of the 0.06.0 features that the tool is able to upgrade automatically. So for example, the inheritance features. But of course, because the semantics of an assignment to the length member of an array is not so easy, so we left that out. And we also experimented a little bit and integrated some 0.5.0 features. For example, the default ability for functions. And yeah, we would love to get some feedback on it. So if you're interested, just consult a documentation. There's a subsection in the compiler, in the section using the compiler. Yeah, and yeah, we're kind of interested if this is like useful for contract developers. Next one, compiler features. So I think we are running over them with a detail here. So the first one, which is also an interesting feature, is the JSON import. So before, I don't know, I couldn't remember which version was it introduced. I think it was introduced in 0.06.0, right? I think so too, yeah. So as you might know, it's possible to export the AST, an adjacent format. And now it's possible to import this again and then run the compilation on the imported AST. We also put a lot of effort into the wasn't back end. So every feature that is, do you know the intermediate representation called UL, like the Inland Assembly language? So yeah, as I said, this is the intermediate representation of our Solidity code. So everything that can be compiled through UL, like every Solidity construct that can be compiled through UL, can now also be compiled to wasn't back end, which is a WebAssembly subset for the EVM. Yeah, the ABI encoder version two is no longer considered experimental. We still need to specify the same old program experimental instruction to use it though, so that you don't have to update the contracts mainly. Not considered experimental means there are no warnings anymore if you use it and there is no experimental literally in your byte code when compiling it yet. Otherwise, the UL optimizer, UL is basically our intermediate end assembly language, is now also no longer experimental and is automatically activated when you specify the normal optimized flag before you had it had its own flag. We are going to have a short look into future things we're only working on, starting with the UL back end, which basically means final Solidity first to UL and then compile that to the EVM or whatever back end we want. Then I think this is your part. Okay, so we also looked into LSP implementations, so language server protocol. That's quite useful for IDE integration. We just started looking into the specification that comes from Microsoft and yeah, I think there is a prototype and because we have the feeling that the community is quite interested in this feature, we are also eager to implement that. Then there are some other things, but noteworthy, like what you mentioned here is the mutable and mutable variables that could be for example only assigned once in the constructor and are then constant, but this is also like an open discussion and if you feel that you want to contribute or participate in the discussion, you could just look through our issues and try to find the discussion there. Also, we have a mailing list. I think it was set up like a year ago. Right now we're trying to actually open up discussions there and it's a Google user group and there are some posts and some things going on and we would really love to see more people participating in the discussions there. The important thing to note here is it's about language development here, not about questions about Solidity or things like that. I mean, it's about Solidity, but it's mostly like language design. The next thing that we are very excited about is the Solidity Summit. At the end of April, we will have a two-day language summit here in Berlin. It's a two-day friendly-sized single track event with talks and workshops. If you're interested in attending this, then just navigate to the URL and sign up for it. We are happy to receive proposals for talks, workshops. It would be very nice to see you there. Otherwise, we're very approachable on various online and offline resources. You can post issues and feedback and feature ideas on GitHub. You can visit us in the Gitter Chat and you can participate in our Google Hangouts meeting twice a week where you can either just listen in, talk to us, ask questions if you want to do stuff yourself. We are always happy to help and direct you to interesting issues. Another thing we forgot to mention, if you have projects in Solidity that compile on the current version, please approach us. We would love to integrate them in our CI. Yes, I think, questions. Well, you can always approach us later. Thank you. Wait, there's a question. He asked how many people are currently working in the compiler. I think we are seven to eight now, but it's like only a few are full-time. And it's very spread over the week. Yes, I think eight to nine. I mean, there are people also involved in other projects in the foundation, for example, and they're just like coming in for a week doing some stuff there. And we also, I mean, we have some external contributions. We are always trying to see how to increase that. Yes, but I think like eight to nine should be fine. All right.