 Hello, everyone. Welcome to my talk. I wanted to give you some updates from the Solidity team. My name is Eric, and I just joined the team half a year ago, so it's a nice opportunity to actually be here and talk about what we did so far. First of all, I want to quickly give you an overview of what I'm going to talk about. First, I want to introduce some of our new team members to you. Then I want to talk about the audits that the compiler got. I also want to talk about Solidity 050, which is probably what you are going to be here. Then I want to talk about what's coming up, what we're currently working on, and what will be released in upcoming versions, and also how to contribute possibly to the project. So, okay, first of all, what happened to the team? You might know that for the last years, almost like Alex and Christian were working on the compiler and on the infrastructure, but now we grew the team to seven people in total. So we have another Christian that joined who cannot be here, unfortunately. Then we have Christian, you might know him, and then we have another Chris that joined, and he is our technical right arch, so he's mainly working on the documentation. Then we have Daniel, me, and Leo, and we're all working as software engineers in the team. Next one, what happened with the audits? So, last year, the compiler was audited by Coinspect for Augur, and this happened in the end of 2017, and they discovered 10 issues, fixed nine, and the last issue is part of the inheritance changes, and you can also find the report on Medium. So, the second audit that we got started in June was done by the people from Zeppelin. It was sponsored by the Foundation and by Augur, and they worked very closely with us, and they audited a specific compiler version, but the issues are being fixed and developed already, and so most of them will be part of 050. And there's also an interesting talk about that, about the audit itself. It's going to happen tomorrow at 1.40 p.m. at the ultraviolet room, and it will be done by Manuel from Open Zeppelin, and he will talk about the outcome of this audit. All right, so, Solidity 050. We're almost there, so Solci is ready, but Solci, JS, there are still some things to be done, but we are hoping to get this done in the next days, so, yeah, watch out for the new version. And, yeah, now I want to talk about what actually changed in the new version. So, we had some design goals there. So, we wanted to improve safety, that was the first and foremost goal, and we wanted to do that by requiring users to be more explicit by removing disambiguities or weird behavior, and also by adding runtime checks to the compiler. So, I picked some of the language features, some of the most important ones. So, first of all, we now have explicit types, so, and explicit visibility, explicit data locations, new scoping rules for function local variables. We had a new constructor syntax, we also introduced emit for events, and also the address table and some others, and now I want to, we'll go through all of them in detail. So, explicit types, what that does mean. So, here's an example of a contract. So, we have a loop there, and this example still uses var for variable type, and here is an issue, because the compiler deduced the type of the variable I to an unsigned 8-bit, and so the maximum is 255, so this condition will always be true, which means that this will result in an infinite loop. So, now you have to be more explicit about the type, and var is now disallowed, which means you have to declare the type of the variable I, and now it will be fine. So, next thing are explicit visibility. So, another example here. So, we have a contract here, and it has an owner, it has a constructor that calls an initialized function, and here in the initialized function, the owner will be set, the caller will be the owner, the caller of the initialized function. So, and now if withdrawal is called, there's a require that the owner has to be the caller, and then the balance gets transferred. So, the problem here is that the visibility of functions is public by default, so anyone from outside could call this initialized function, and then also the requirement would hold in the withdrawal, so it could be then also withdrawn. And we changed that. So, the visibility specifier is now mandatory. What does that mean? So, here the constructor got the visibility public, and the initialized function is now internal, which means it can only be called internally. So, that's, and then here you can see that the requirement of someone, if the withdrawn is called, then the requirement will be true here. All right, explicit data locations. So, I bought another example. So, here we have a contract, and you have a struct called data, and we have an array of this struct, and the function f. And here we're going to access this array and store it into the variable called member. And as I said, the location specifier is now mandatory. So, you have to use storage here in this case. Okay. So, storage references. It's the same example that I had before. So, we still have this struct, we still have this array here, and we have the function. And we are initializing here a member, and then setting the name that was given as a parameter to the function to the member name of the data. And then we're pushing this into the array. And now they have to be initialized. So, the background of this is that we have a component in the compiler that tried to find out if storage references were initialized before. And because in some cases, that was not possible. So, the decision was made to make it explicit so that you have to initialize storage members, storage references before using them. All right. So, let's look at the scoping rules. Before 0.5.0, we had JavaScript-like scoping rules. So, in this example, you have the variable i. And the three is assigned to it before it was initialized. And one of the goals was to be more explicit. We also changed that to block scoped C99 style scoping rules. Yeah. And so, here, for the two loops that you can see, the i is declared also in the for loop, and it's visible only for in this block. So, that's the reason why you have to re-declare it in the second loop. And then we introduced a new constructor syntax. So, what does that mean? This is an old example. So, I took the contract that you've seen before. So, here, you can see the contract is called old. And before 0.5.0, to define a constructor, you had to use, had to declare a function with the same name as the contract. But, again, to be more explicit about that and to prevent mistakes, we introduced a new keyword called constructor. And it has to be used to declare the constructor. And it's not allowed anymore to have a constructor that has the same name as the contract. What next? So, emit for events. Here, again, the example that you've seen before. So, we have a contract here that has an event called withdrawn. And so, we have the function withdrawn. It's from the example before. So, we have the require again. And we have the transfer call. And then the event is emitted. But this can also be confusing because it could also be a function call. I mean, there are coding guidelines that say that you should start your function with a lower case number. But if you don't do, so this can, there can be certain mistakes we're making. And, again, to be more explicit, event invocations must be prefixed. So, here, we introduced the emit keyword. And if you want to invoke this event, emit has to be a function call. So, here, we have an event called transfer on this target. All right. Next one, address payable. So, we split the address type. So, in this example, you have a target. And you want to transfer one ether. And call the address payable as required. So, that means that if you have an address type that is not payable, the transfer function would not be available on this type. Then there's a second example of implicit or explicit casts. So, if you want to convert this to an address type, you need to be explicit about it. So, you have to use a fallback function, payable fallback function, so that this, such that this example would compile. So, and then there are a few other things that we changed. So, with the IBI encode and decode changes, and also some changes to the call family. So, call, delegate call, K jack 256. Now, take a single byte parameter. And if you want to use it, then you have to call, have to use the IBI encoder before to encode and decode the arguments there. And also, we changed something to the view pure and view pure functions. Now, use study call with the exception that for library view functions, they use delegate call. And we also put together a list of breaking changes. You can find it in our documentation. And we also put together or compile the list of how you have to change your contracts such that they will compile with 050. Okay. So, what's coming up with the next versions? We have fuel, which is a very interesting topic I want to talk about. We introduced some formal verification in form of the SMT checker. We're planning to do some inheritance rule changes. Then also a contract metadata and the ABI encoder v2. So, what is fuel? I don't know who of you attended to Alex talk yesterday in the prism room. So, fuel is an assembly language and it's an intermediate representation internally in the compiler. It aids auditing the code base and generates code. It allows for a lot of optimization. And it also allows multiple backends. So, solidity could compile to fuel and then in the end to EVM. And also, solidity to fuel to E-wasn. That might be interesting in the future. And also, Viper could, and that's the emphasize use fuel to also then support EVM or E-wasn backend. And if you want to find out more about fuel, you can also consult or documentation. Or, yeah. And I also brought a short example so that you get an idea of how fuel does look like. And here's the power function. And we have high-level keywords like switch, case, default. But we can also, as you can also see, multiplication and also dividing. It's a representation of op codes and the more functional style. So, like I said before, this helps, this increases readability and also helps auditing the code. And if you want to find out more about fuel and also about the optimization that I talked about, then I would highly recommend you to join the talk today by Christian. It's at 4.30pm. And you will talk about the optimization that we put in already and also some things that we plan to do in the future. All right. So, coming to formal verification. So, we're using a technique called S&T, satisfiability modulo theories. And this helps seamless verification of safety properties such as under flow, overflow, division by zero, drivly conditions or unreachable code, and also assertions. So, verifying runtime checks at compile time. And we have a component for that. And it's called the S&T checker. So, this is one example. So, you can enable, the S&T checker is an experimental feature right now. And you can enable it using a pragma experimental S&T checker. And so, if you compile this example with the S&T checker enabled, you will get some warnings. So, the first warning is that the for loop condition is always true. So, I is initialized with 200. And that means that if I is greater or equal zero, this condition will always be true. So, that's the first warning. And the second warning is an under flow resulting in a value less than zero. And this is if I then gets incremented. So, at some point you will get an under flow here. Skip this example. And there's also a talk by our colleague Leo. And it will happen tomorrow at 4 p.m. on the ultraviolet stage. And he will talk about some details on how to actually use the S&T checker. What's coming up? So, we're planning to do some inheritance rule changes. And so, inheritance is a crucial part of solidity contracts. But there are some open questions. So, what about explicit shadowing, invisibility, our state mutability levels change. And there is an open poll request right now where a lot of discussion is happening. And so, we're hoping to get more people joined in this discussion so that we will come up with a cohesive set of rules that we can implement. What else? So, contract metadata. Contract metadata is generated for each contract. And it stores as a JSON object. And it contains all details needed to reproduce the compilation. And a swarm hash of this metadata is appended to the byte code. Unfortunately, it's not used by a lot of verification tools that are out there yet. And you can find documentation about the metadata also in our documentation. And this is how the contract metadata will look like. So, you have a contract version. You have the language. So, solidity. You have the compiler version is included. And also, some settings like compilation target, EVM version. And if the optimizer was enabled or disabled because this will result in different output. And here you can see the hatches that I mentioned. And this is then included. So, then the ABI encoder V2. What is the ABI? So, we have a contract ABI. And that's the specification how to exchange data with a contract. And for each public function, a decoder and encoder is generated. Currently, that's handwritten C++ code. And it's very ever-prune. And it's hard to test. So, that's why we introduced the ABI encoder V2. And this is written in UL. And it ensures safety properties such as short input, too short input or invalid values. And it also supports complex data types such as structs, multidimensional arrays. And you can also play around with the new ABI encoder and enable it via progmar, a very experimental progmar. All right. So, and then I want to quickly tell you how you could potentially contribute to the project. So, there are many ways to contribute. So, you can always request a feature. We have discussions on existing design issues and also including documentation improvements and also the examples that we have in the documentation. We are an issue tracker. We have introduced some labels. For example, help wanted or good first issue. So, if you go through all the open issues and see the labels, then you can probably directly start working on it if you want to. And also, you should watch out for Gitcoin bounties. And if you have any questions about that, you can always reach out to the Solidity Dev Channel. Yeah. And now we have some time for questions, if there are any. So, I think there are two microphones here in front of the stage. Okay. Doesn't look like there are any questions. So, thank you. Oh, there's a question. So, currently, if you declare that your Solidity functions returns, can you hear me? Not so well. Sorry. Beep, beep, beep. Hello. Okay. Okay. Sorry. So, currently in Solidity functions, if you declare a return variable that the function returns something and don't explicitly declare a return, there's no notices or errors about that. Are there any plans to change that for Solidity? Not that I know of. I mean, the team is also sitting there. So, if you want to add something to that. Yeah. I mean, there's an, I think there's an open issue about that. We do warn if the variable is not used at all. So, if you never assign to it and do not have a return statement, then you get a warning. Okay. But, yeah, there's an open discussion about how to, how and whether to change that. I have one more, one more question. So, currently, the function identifiers for the way that, like, how they're identified when you're calling them, they only check the, they only have the name and the parameters in the identifier hash, right? But this can allow where you can call a function that actually returns something or doesn't return something when you expect it to. And even though it should error in that sense, it doesn't because the identifier only checks the name and the parameters. Are there any plans to include the return variables into the function identifiers? Or no? Yeah, that's something that hit some people at the point where the compiler was changed to actually enforce the return size. Okay. That's a very tough thing to change. Yeah, right. I mean, the ABI is something you don't really want to touch. Yeah. Done that like that in the beginning, but yeah. Okay. All right. Thank you. Hello. I'm currently using ABI encoder version two to handle complex structure, which is a very nice feature to have in Solidity. You say it's on your roadmap for the next, next step. However, my question is how dangerous it is to use a current experimental version and how long do you have to wait to have a proof solution for that? For the ABI encoder return, you mean? Yes. So maybe like one more part of your question was missing because like, can you, can we repeat the question? Yeah, just I'm using it right now, but it's still experimental. So I want to know if it's dangerous to use that in production and if it's dangerous and it might change, when will I have a good version that I can deploy on the mainnet? I mean, that's hard to say. So it's an experimental feature. So I wouldn't recommend to use this in production at all. And because we have so many things going on, it's hard to say when this will be ready. But maybe Christian has in addition to that. Yeah. So we're pretty confident that it's not dangerous to use. One of the main reasons it's still experimental is because it's much more expensive. So the new ABI encoder was built in an extremely modular way where we have tiny functions for very simple tasks. And that helps ensure that it's correct. But it's more expensive because the EVM jumps around all the time. And if you want to, so, and we will take it out of experimental as soon as we have the UL optimizer that will, yeah, remove these inefficiencies, basically. Can I ask? Hi. So Solidity 0.5 has a lot of breaking changes, right? Lack of backwards compatibility. I've got contracts that are already deployed to the chain using previous versions of Solidity. And I'm running into some challenges trying to interact with those contracts using 0.5 because of the things, the way that they were written back in a day using const and various other bits and pieces. Have you guys thought about how to write code in 0.5 to interact with existing contracts? Is that a thing that you've thought about? Or are you expecting that everyone is just going to write all new contracts going forward? No. I mean, of course, we are expecting this that you have contracts compiled with different compiler versions. And so, I mean, there is a plan for that. So to... Sorry, Eric. I just have one addition to that. Probably the best way to do it if you write an interface for your contract and that interface is valid in 0.5.0. That's probably the best way. Hello. Thank you for the presentation. So currently, Solidity is 0.5, which is Alpha software. What do you think will it take for Solidity to become 1.0 software? And you mean in terms of time? Or, I mean, that's really hard to say. I mean, because, like I said, I just joined the project half a year ago and I joined it when it was in version 0.4.22. So now we're 0.5.0. So it might take a while, but it's really hard to say when it's like in version 1.0. Thank you. I mean, yeah, I joined the project only four years ago and I think it might still take some time to get to. All right. I think time is up, but maybe we have still one more question and no. Yeah. I would like to ask about the capability of the language in terms of returning multi-dimension arrays like array of struct or array of strings. And also about the capability of the string data type that has a limitation in terms of getting the length or doing some sorts of concatenation. So the question was when this will be changed. Yes. I mean, yeah, the point, like a question about multi-dimensional arrays, this will be included in the new ABI encoder. So if you want to interact with the contract and then if this component is finished, you should be able to use them. And how about adding the capability to the string data type? You mean regarding the length and concatenation? Yes. And I mean, is there anything that we plan for that in the future? Sorry, I have to refer to my colleagues. Is it working? Is it working now? Yeah. We're kind of reluctant to add features that have unbounded gas usage and string concatenation would be one of them. But you can use ABI dot encode packed on byte arrays that will do exactly byte array concatenation, which is something we discovered by accident or, yeah. It's a neat trick. All right. Cool. Thank you a lot.