What would Solidity 1.0 and 2.0 look like? by Alex Beregszaszi | Devcon Bogotá

foreign [Music] yeah you can hear me right and I hope this works as well okay it does um yes Francie said uh thank you for the intro and I wanted to also make sure that um a lot of this stuff is my opinion it's not like the opinion of the team I have been working on solitary since 2015. and in the past year I've been kind of like taking a break and uh did write a lot of code in solidity itself and I think some of this is like a culmination of of you know my experience using the language but I hope some of these things are mentioning may come to infusion okay so 0817 is the latest release it's a hundred second release we already had more than 100 releases that is just insane and we probably have more than like a thousand night leads which is just crazy basically we had eight breaking releases a bunch of feature releases and sometimes we do have like bug fix releases as well um in some of the years we had releases every two weeks I think lately it's more like monthly um and I hope that's going to come to you maybe you're gonna get back to like bi-weekly releases but at least want to release this and I'm saying this just to show that how active the development of solidity is I'm not gonna go through all of these um you can find this really nice chart on the solidlank.org website and it shows you all the interesting milestones we have accomplished since the beginning however it doesn't show anything past 0.6 because he made this two years ago but as you can see it's it's a lot of stuff going on and based on like having over 100 releases you may ask a question when do we actually get to 1.0 and you may not be alone asking that question we do get that question super frequently last year there was like this big debate um this particular issue I'm looking here the issue is much longer the description is maybe 10 times as long and the author of the issue provides a bunch of different reasons why he thinks solidity should be at 1.

0 I summarize like three different discussion points we have been debating on this issue the others that or had the opinion that the current scheme doesn't actually allow breaking releases the separation of breaking release and non-breaking releases in his opinion on every single facility release is a breaking release he also argued that the languages widely used it is it has been for a couple of years and so it should should be a 1.0 because that signals that it is ready to be used um in fact you know when 1.0 was released we never signaled a 0.1 was released we never signaled that it's ready for usage but the nature of blockchain it just started it people just started to use it and it's there it's always going to be there um but also the team had some concerns about this 1.0 stuff basically we have the impression that 1.

0 kinda implies that we have to have a long-term maintenance of that version we have to add new features non-breaking features um and all kind of changes and if we still want to do braking changes that's going to be like 2.0 and then suddenly we have to like maintain two versions or we're not gonna make breaking releases so that that is the reason we kind of wanted to avoid going to 1.0 I'm not sure how many of you actually know how the versioning system works um do you want to like give hands on are you a developer first of all so many of you are using solidity are you using anything but solidity not many any other language besides solidity nice so I think you should you ever had this versioning system works um we've learned the impression that it is semantic versioning turned out it is not um because anything below um the major one so major zero is a breaking change however we did assume that um you know the three three numbers in the version is major minor patch and we assume that if we bump the the minor that is a breaking release if we bump the patch that is a non-breaking release so it's not actually in conformance with semantic versioning but it kind of works for us um here's just an example you know how this would look like and now suddenly you know once we know what 1.0 could mean maybe we should talk about how could we get there here's an example contract um with the latest release this is actually the solidity stocks contract which is on mainnet you can use it to make socks both the land and the right hand side if you're lucky you can you can win both and uh I think the stocks are gone at this point but you could have gotten them a physical version of the stock at the solidity stand um I think on the floor above I'm not sure now this is 0 8 17. it is 1.

0 do you see any change yeah I kind of think that actually for the users you're not going to see too many changes at 1.0 we may actually have some changes okay so that was the the non-changed version skipping one okay this is an unchanged version and this has a few changes they're not important yeah um where is it like this stuff this stuff all of none of this is agreed on but there may be tiny changes but I don't think they're going to be big changes um so no major difference is if you're a user but giant difference is if you are writing a library um I listed a few things on what you would be able to expect in libraries we should have like operator operators and letters to use the defined types standard Library generics um you know data types I just gave you a few examples now but actually Daniel from this already team had an extremely good talk which you should watch and I'm going to share the QR code for the video as well so here's an example of user defined operators I cannot see that I actually like the syntax but the team kind of agreed on it so without tests you have to use the usual function chaining but once you have user-defined operators you know what you can expect you can just use them fairly easily so I think the team kind of agreed that this is going to be in uh this is going to be a focused project and I believe this is needed for like 1.0 another major thing is a standard Library which we have been talking about for years and the main goal of the standard library is to move out the majority of the compiler code into solidity itself but it is also really good exercise doing it because it shows us what kind of language features are missing so here's one example this actually doesn't require anything major the only thing it requires is this pragma standard lab and what it does it just disables the built-in functions because if you don't have this primary standard lib this function definition is going to fail because there's already a shot 256 implicitly in the language if you have this it's not going to be there so you can define it this is the simplest example in the standard library and this works doing anything more complicated going to require a lot of language changes here's one example what we will require for the language changes it is just generics there's a this is an extremely old example and in fact I copied this example from my talk from two years ago from this holiday Summit you're already seeing the same things back then so I'm not going to go any further if you want to take a um a photo of the QR code this is the talk from Danielle it is a full 30 minute talk and it did a really good job at explaining the reasoning Behind These features and how they're going to work okay now taking a tiny break these were the changes the team wants and the team agrees on but I kind of want to ask you all of you to look at the Repository this these are all the it's kind of hard to see but these are all the issues Tech language design and we have 237 issues open those are the issues people want want as a feature and I think many of them actually are kind of obsolete at this point um but I ask you to look at this repository look at all of these issues or you know a tiny subset of them find something what you like and leave a comment if you want to have it or leave a comment if you think it is a bad idea you know besides these features that the team wants I think it would be nice to know what you guys actually want so I think that's what 1.0 gonna be like um not many like visible changes for the user side if you're just writing like a token contract NFC contract Etc but if you're writing libraries it's going to be entirely different you know one 2.0 that is a crazy topic and uh we have been actually talking about this for a couple of months at this point on and off and actually 2.

0 it's two different things and it has been like super confusing at the team even talk about it because you know some people meant the one or the other and I just want to highlight it again you know nothing is decided here a lot of this is just uh you know my idea what I want to have um but I hope some of this is going to happen so first I can talk about like this compiler rewrite where it sounds crazy right um how many of you actually know the compiler how does the compiler work or a compiler in general not many of you um basically a compiler has multiple stages you know we take like the source code we process the source code into some internal representation uh we do a lot of different analysis on that representation once we are happy with the code that it is sound that it works uh we are generating some kind of a next stage in the first version of the compiler this generation was directly into evm in the current stage we already have we we still have this but we also have a second pipeline where instead of uh directly generating to evm we generate it to Yule which is our Intermediate Language um but you must be familiar with you because it is a line assembly basically and then we take fuel and generate evm byte code so that is the the pipeline and then these are the different libraries we have in the compiler itself so this one is just really tiny helpers I'm going to move to the other side um so these are just helpers used by the others the assembler is a kind of separate it's it's standalone it takes in a data structure like the representation of the the assembler source code you want to assemble um byte code but it also has optimization steps then we have this separate helper for it's called language utilities but it's really just helpers for the parsers because we have two different parsers we have the solidity parser and the yield so Lang duties is used by both of these uh the Libya has a parser has a code gen has another kind of optimizer and then lips solidity is a big one uh it's the it's a monster it is it's already departure um does all the analysis I mentioned and does these two different pipelines for code generation and then we have two smaller libraries the smt library is just for the SMD subsystem but I think that that is also split up so some of it is here some of it is in this lip solidity directory and lastly the smallest one is lips we'll see which is a tiny binding that is the only Library which is C has a c API everything else is C plus plus so this basically is a wrapper between C and C plus plus and that is uh what is compiled to M script and into JavaScript if you happen to use any kind of a web app that has related it would be used few maybe some benefits as well but you know one of the bigger problems we are getting into is these libraries while physically separated into their different directories um they may not be like super well separated conceptually or even like interface wise um one example I can give which which is I kind of hit it's not like a you know logical like um issue in there it's more like just a source code issue but we have a a loop between libu leap evm ASM um and the front end they're interdependent on each other um which is kind of bad if you want to separate these things nicely major components they do have some kind of a clear boundary but it's everything is in C plus the the clearest external boundary happens in two places the assembler has a Json Import and Export feature the export feature has been there forever the import feature is still not merged but it kind of works and then solidity itself has this Json AST import export I think some tools like Scribble may be using it um basically you can skip the parser no scribble uses a typical parser but yeah some people we wanted people to use it some people use it but they ended up not using it at the end um but the main issue I kind of see here all of this is C plus plus which is kind of hard to integrate with other kind of languages it is hard to integrate with with like JavaScript we have this m script and layer and we have the C wrapper it is hard to integrate with rust you need to see layer as well although rust does have like a C plus plus binding generator it is not really stable if you want to integrate this into go it's the same case all of the all of the languages they only work with C they don't work with C plus plus so I have a few you know ideas how could we resolve this and first of all we want to just improve the the separation of these libraries we want to have like clean interfaces between them and maybe reduce the number of like C plus plus features that the interface they're using to make them more compatible with c then parallel to this because this this can happen on the existing code base prior to this we could start working on components in Rust and we in fact already have components in Rust um we have sources rust which is used it's used by Faye actually and I think at some point fan reused it but they were annoyed by by the size of the binary and compilation pipeline so that they're not using it anymore but we do have a bunch of like libraries new libraries in Rust which is also used by Faye and some people in the team now are working on some crazy features on top of it the first useful step could be rewriting the assembler and the reason behind this is the assembler is one of the oldest components we actually never changed the parser itself has been mostly Rewritten or at least significantly improved um I think the type system that is also kind of old but it had more maintenance but the assembler that is the oldest component which has never been significantly improved on it would be a really good task to rewrite it and by rewriting it it may or may not even need to be Rewritten by us but we could use an existing assembler and in fact etk the evm toolkit evm assembly toolkit I don't know the what the acronym is for but it is an assembler toolkit basically for evm it's written in Rust we could just use that in any case once we have some of these components we could think about creating a compiler skeleton so basically just a driver which drives the completion process and this doesn't mean that we would need to rewrite the compiler all we would need to do is provide trust bindings to some of those components and then have this driver which just uses those components and once this work it works we could swap out parts of those components for example the assembler um because they are just components and once this this would be working the biggest change uh would be actually doing a major rewrite of the front end in Rust and the front end by the front end I mean mostly the parser the analysis and the type system Etc and while the code generation is wrong that is an insane project and why would you want to do that well you likely don't want to do it for 1.0 but you want to do it for something else so what is the reasoning behind all of this um the main reason is that we kind of or at least me when I turn solidity all this code into reusable compiler framework I want to make sure that all the you know the optimization steps we have all of these features they're not just wasted they're not just there for solidity but they can be used by other languages imagine if we would have had like this compiler framework earlier on you know it came to like llvm4 evm you know how how long would it have taken to Forfeit to to come to fruition or like half for any of these other languages if you could just use any of these components I listed a bunch of different projects which are already in the evm space working on Rust compiler components so of course we have fa we have the two other solidity compiler slash parsers so solang solank is a full featured compiler from solidity to webassembly targets well actually llvm targets they started with webassembly but they also support like BPF like Solana and a bunch of other targets the one thing they don't support is evm and in fact solang I believe is used by Foundry for parsing solidity because it's in Rust so they're not using solidity solidity s-lang is a project by hardhead they're trying to write a compiler as well the motivation is slightly different they want to have a person which is flexible and supports every single version of solidity because they want they don't want to like certify the compiler you know mid compilation and that's the problem with the color and compiler it only supports a single version so why would we want to do this because I want to attract more people to solely compiler development and it seems like C plus plus is not like a language people like or people are interested in it has been kind of hard to attract people to to write C plus plus code and it seems like trust is extremely thriving every other project is in Rust I've been using rust for a long time so I would be happy for this to happen and if you do some kind of a re-architecting like this that would mean that we have an opportunity to actually improve the architecture of the compiler and maybe improve the language itself so that is the next one I'm going to talk about is what kind of language could we have here you're really surprised or not but the fact is we have been talking it like this um you know rust inspired changes to the language since 2019 way before some of these are arrest inspired evm languages came about oh it's actually another sign um I think the main motivations the main reasons those discussions were started because there are a few issues in solidity itself or at least a few issues I think should be at rest one of them is really the storage and implementation itself is not really separated so the other thing we have right now is this contract construct it can have storage defined anywhere it can functions defined anywhere it can inherit other contracts which also Define storage and functions anywhere and you never know where storage is it could be handled by any of these imported libraries it would be nice to actually make this more clear the other thing would be nice to kind of make clear when State changes or state access can happen we do have some of this in the language today um you know via payable we have View and pure functions but that's about it it would be nice to you to have like more clarity even within the functions when is a state change taking place functions can be quite long I think good code bases started to create small helpers and limit the scope of like State changes to those smaller helpers but it's still people can write no matter what you do people can write really bad code but in solidity especially people can write like giant pieces of coding would be nice to have like Clear View whereas State access and state modification taking place and lastly if we you know take such a big step um we could even consider removing like inheritance or looking at like a different way of composing the source code um and in fact if we have like more clear control about the storage maybe we also have more clear control storage layout which has been like a really annoying question and I know many of you have open issues how can we like set like slot numbers Etc um some older contracts have like these padding storage items it's insane okay now finally what would it what could it look like so here's an example I'm not sure if any of you recognize this it looks like trust but more specifically no it's not sway it's Faye this is actually say and uh they started to basically do all these steps um we were discussing um which means having a context which is like a clear separation of State access um okay this is what's on the website but um yeah this is another one which is nice um you know not having like special constructs rather have it tied into State access um and I think they also like changing it from having a contract and all these things to having uh separate pieces now here's a real example of what is more like what we discussed under like thrust solidity um do you have like a separation of this could be contract could be struck people leaning towards struct so this would be really just the data and then that would be the implementation I mean it's not too different to what the uh fee is trying to do now and this is the distal contract I had as an example before yeah I mean that's it really I only have 10 seconds left [Applause] [Music] thank you I guess we can take one question if somebody has a question please raise your hand so that the mic can find you hey Alex so just a simple question you got you're talking a lot about rest but have you guys give a talk to the Cabo that's like the new language that they are going to upgrade C plus plus carbon it's interoptable so you guys could like reviews oh yeah yeah the C plus the new C plus plus right yeah yeah experimental yet but guys would be able to use everything that's written so far I'm not sure what benefit that would bring um it's worth a thought yeah yeah I think we I don't think we had a look but we heard about it unfortunately time's up but thank you so much Alex