What is Next for Solidity — Nikola Matic | Argot Collective

All right, so I might ramble a little bit but I have the slides in front of me which is very nice. But yeah, I'll basically I'll I'll turn this into kind of a two-part talk. One is going to be about the current solidity that you know, you all know and love and maybe hate from what we hear. And the other is going to be about core solidity which is essentially the next iteration of the language that we have also been talking about for years now. Um but um as you as most of you probably know the language is very old.

It's been around for 11 years now. It's essentially a dinosaur in terms of the ethereum ecosystem and crypto languages in general and it was maintained by the ethereum foundation um well, since the beginning almost but about a year a year and a half ago we spun out of the ethereum foundation solidity the team that I work on as well as several other teams like phase source a fire EVM act none of them are here eat the bug George is here. He works on that as well. And we essentially created our own collective and we're very graciously financed by the ethereum foundation and they gave us several years of runways so that we can continue to maintain these projects including solidity. Um

[clears throat]

and we're essentially independent non-profit fully open source democratic governance all of that really nice stuff. Um so in terms of solidity again I might not follow the slides to the letter but those of you who have used the language of probably notice that we don't make too many changes to it and there are a ton of outstanding issues that have been around for years now pretty much since the beginning. Now obviously over time you have hard forks the language keeps growing but one of the one of the kind of main points of contention and we have this developer survey that we do every year. And we do it with the exact purpose of trying to get feedback from the community because the vast majority of people that actually join our design calls are, you know, your super users, experts and whatnot. But we get very little feedback from your typical, you know, Solidity contract developer that uses the language on a daily basis.

So we have these developer surveys and one of the main pain points is stack too deep. Those Those of you who have used the language are probably very familiar with it.

[clears throat]

It's somewhat our fault, mainly our fault I would say. There's also quite a bit of blame that lies in the EVM because it only lets us access 16 stack slots, but that's going to change fairly soon in Amsterdam. So what we did was we introduced the new pipeline via IR and the plan for that was to make it default like three years ago. That did not happen obviously because it's extremely slow to compile. And one of the reasons it's very slow to compile is that when it was initially when it was initially created we didn't use the SSA form which is a very standard technique when it comes to implementing compilers.

So to not get into too much detail one of the main issues is that we have to track all of the data dependencies manually and that basically eats up like 80% of the compilation time. So for a, you know, a project that would take maybe 30 seconds to compile with the current default straight to EVM as a pipeline via IR can take, you know, five, six minutes which obviously is unacceptable for everyday development. Um So, what we did and what we're currently working on is the SSA CFG pipeline, which essentially tags onto the IR pipeline. Uh

[clears throat]

And my colleagues, uh Moritz and Martin, are uh working heavily on that. Uh it's also an experimental feature. Uh we introduced the experimental flag to kind of explicitly um ex- explicitly block certain features and make sure that they are uh very much experimental and cannot be used by mistake. Uh but the SSA CFG pipeline essentially tags onto the end of the Yul pipeline. Um Converts everything into the SSA form, the single static assignment form, uh in as uh as a control flow graph.

Um And then performs memory spilling, which uh we actually released in the in 80836. Uh so, that's something you can try out today. Now, the compilation times uh have most certainly not improved because the issue with the IR pipeline before that is the optimizer, uh and that still runs, but the end game uh is essentially to move all of the optimization steps from the IR pipeline uh to the SSA CFG one. Uh and hopefully by the end of the year the SSA CFG pipeline will be stabilized without optimizations, and then next year uh the the goal is to essentially move all of the optimizer steps to the new pipeline and hopefully make it default much faster uh and also better in terms of gas and memory spilling, which should alleviate stack to deep almost completely. Um And yeah, basically, yeah, that's pretty much what I spend all my time talking about now.

Um so, yeah, not exactly following the slides to the letter, uh but also the Glasterdam Wait, what? Uh the Glasterdam uh hard fork is going lot more accessible stack slots, uh, which is also very, very nice and makes things much easier for us. Um, but yeah, that's basically one of the pain points of the current, uh, back end of the compiler suite. Um, now to the front end. Uh, we've generally been fairly conservative when it comes to adding features to the actual language itself.

Um, mainly because as I mentioned, Solidity's a bit of a dinosaur. Um, and the development initially was very quick. Uh, things were just kind of slapped one on top of another and the type system itself, uh, from a theoretical perspective, you might not even be able to call it a type system. It would be very difficult, if not impossible, to actually formalize. Um, it's just a combination of all of these things that were done over the years.

Uh, and at this point, adding anything to the language, um, is extremely, extremely time-consuming, uh, and very error-prone. And we've been kind of, um, thinking about implementing a new language, a new front end, if you will, that will be the successor to Solidity. Uh, and in the past year and a half, once we, once we actually spun out of the Ethereum Foundation, uh, we started working on that quite seriously. So, there's an entire team of researchers dedicated to actually, um, implementing the type system. Uh, and

[clears throat]

at this point, what you're seeing is the latest syntax, which is, uh, much nicer than what it was, uh, a few months ago. Um, but basically, what you have at the moment, uh, for instance, you just have like a struct and you want to pass it to a function and just, uh, do a um, match case or a switch case. Can't really do that properly in Solidity at the moment. You've got to do if else if. And the moment you add another enumeration to it, well, it's essentially up to you to make sure that everything is covered because the compiler will most certainly not complain.

Um however, with the new type system in place, um all of that is essentially done automatically for free by the compiler. Um and if you can if you see here like the first of all, the implementation itself is significantly more elegant uh and much easier to review. Uh but not only that, if you were to add another uh enum value, uh the compiler would most certainly complain if you were to not actually cover it. Uh and at this point, it gives a non-exhaustive pattern match error. Um now, the the new core Solidity is going to be a pattern matching compiler, which is what actually allows for this to uh to be done.

Um but it's also going to have full-on generics. Um I remember when I I I think this was this was like 5 years ago when I first encountered Solidity uh before I even started working on the team, and I just wanted to play around and write a little library. Um and I was a little bit confused coming from, you know, standard general-purpose uh languages, most of which have some form of generics, um that you have to actually copy paste uh every function for each uh type combination. Uh so, for instance, um the the Forge console um file has 300 and 381 uh log functions, which is absolutely ridiculous. Uh and I never understood why we didn't even just add a kind of a jerry-rigged uh template mechanism into current Solidity, but uh that would have been significantly more difficult with the type system that we have.

Uh so, instead of having, you know almost 400 functions for logging uh with core it's basically replaced by you know 10 15 lines. So that's a that's a very nice thing. And then obviously the rest of the language is going to be a little bit significantly more functionally functional oriented. I think I believe it uses the Hindley-Milner type system similar to Haskell a little bit. Rust uses quite a bit of that as well.

The major major change syntax and semantics wise I guess to an extent is going to be the removal of inheritance which is an absolute bane of our existence and probably for many of you as well. So that's going to be replaced with composition. Which is very nice and of course with the Hindley-Milner type system you get type inference essentially everywhere. Which is also quite nice. Now of course the fact that you do get it doesn't mean that you shouldn't explicitly write types where you can.

Don't be like that but you do get it for free. And um this is a bit of an implementation detail if you will but the actual the actual examples that I that I've shown here which do kind of feel somewhat familiar if you've ever used Solidity. I mean they look almost the same except for the match case mechanism which doesn't really exist. But the front end itself is such where what you're seeing as an end user and as a smart contract developer is the sugared version of what we call sale which is kind of like a core of Solidity core. Think of it almost like a higher level Yul if you will which has basically a slightly lower level of abstraction Uh, the entirety of the type system and all of the functionality is basically just sale underneath.

Uh, and also standard library with modules is going to be implemented in sale. Uh, so the actual language and the type system itself is going to be very very small. Uh, and the vast majority of things that for instance today are built-ins um, like SHA-256 or ketchup ketchup or things that you use on a daily basis are going to be implemented in a standard library that you'll be able to import as a module. You'll also be able to export uh, things as modules as well. Um, and that's going to be one of our Uh, let's see if I get that on the next slide.

Uh, pattern matching blah blah blah blah. In any case, the standard library is going to be mostly implemented by the community as well. Um, because again one of the one of the issues we have at the moment with solidity is that uh, we kind of have a a complete monopoly on the Ethereum ecosystem. Uh, and it's incredibly difficult for us to actually figure out what it is that regular users want. Um, there's no competing language unfortunately.

Um, that has maybe 20 or 30% of market share to the point where uh, if this hypothetical uh, competing language were to release a feature that people absolutely love, uh, we could see that and go, "Hey, people actually want this so this is a worthwhile time investment." Uh, instead what ends up happening is that we somehow decide that we want to introduce a feature that we think users will love or sometimes it's actually the uh, you know, creme de la creme expert um, super users that suggest these changes and we end up you know, spending a year uh, working on it and then it turns out that no one really cares that much about it and people don't use it. Uh, but at the same time certain things that are you know, a week or two uh, of pull request reviewing that gets merged and released very quickly that we think nothing about that we don't write a blog post about. Uh, it stays essentially it's just like a tiny little change log entry. Uh, turns into the best hard-hitting feature that people people are very excited about.

So, uh, essentially moving as much of the implementation to the standard library uh, and having users contribute to it uh, would be significantly better for us at least as uh, language designers. Uh, because we could get a lot more input than we do at the moment. Uh, and also from a user perspective you can just pop open the library, see how it's implemented. Um, make changes if you want to implement your own. Uh, and of course anything that goes into the standard library is going to be um, verified and audited.

Uh, so yeah, that's one one of our ways to both make our lives easier to also kind of um, extend a hand to the community and uh, let people let people join. Um, also yeah, this is a page this is one of the more more concerning things for a lot of people. Uh, what we have at the moment is something we refer to as classic Solidity. That is the Solidity everyone is familiar with. Uh, and then core Solidity is a thing that we're implementing on the side.

And when it comes to shipping it's just basically going to be implemented as a new front end in parallel. And it will be shipped with Sol C. It will use the same mid end so Yul uh, and the same back end as current Solidity. Um, and we're fully aware that the community is quite conservative when it comes to picking new technologies, new languages. Um, it's one of the reasons we even have the monopoly because it's just simply this momentum of people wanting to use what's uh, proven to be safe.

Uh, there's obviously the the the largest amount of smart contract developers are Solidity developers. So, if you want to implement a project, uh you'd prefer something that is safe, known, and where you can actually find people to implement it. Um so, our goal with this to essentially try to earn trust and nudge people toward uh using Core Solidity is to ship them together. Uh and then obviously you as a user can choose which flavor of language you want to write in. If you choose Classic Solidity, that's just what we have now already.

If you choose Core, it's going to be this new front end with a new type system, but underneath in terms of code gen, uh it's the same as Classic Solidity. Um So, hopefully hopefully it won't be too much of a burden, and hopefully people will start moving away uh from Classic Solidity at a certain point in future so that we can actually um spend time introducing new features and implementing them more easily because at this point uh it's extremely cumbersome and it takes very long. Uh and very frequently it turns out to just not be worthwhile of our investment. Um but yeah, that's that's how it is. So, very exciting and something that we're very much looking forward to.

Um now, this is going to take a long time. It's obviously a new language. Uh the core of the language, so the core of Core Solidity is going to be very small. So, the end game is for us to have it formally verified with Lean. Um That also is an absolutely epic undertaking as well.

Um but it is what it is, and having it formally verified would be incredibly useful. Um Now, in terms of the actual things that you can try out today, when it comes to the SSACFG pipeline, I already talked about it before. You can That's in the currently latest release versions. You can play around with that. Try to compile your contracts.

Uh when it comes to core Solidity, uh there's obviously the sole core GitHub repository. Most of that is in Haskell, so not sure how how much people like that. It won't be in Haskell in the end once we actually ported it to the compiler, but at the moment the actual type system prototype is in Haskell. And then there's the pattern matching post by a colleague of ours, Rodrigo Ribeiro, who's a professor of programming languages in Brazil. The most interesting thing by far I think here is the the third very very extremely cumbersome link solcore.

rs.preview.solcore.rs.team.

worker.dev. Um But that is essentially the playground. Think of it like Remix for core Solidity. It has the latest syntax.

It's going to keep getting updated obviously, but that's something that you can not only try out, but there are actually I think six or seven examples that I directly borrowed from for this presentation. So generics, pattern matching, and so on and so forth. Um And there's also for those of you who have been in the community for a long time, you probably know who Axic is, Alex B. He used to be a team lead at Solidity. He also wrote the deposit contract in Solidity.

And he's also now helping us test the language from a user's perspective. Um So you can take a look at his little article, if you will, if I can call it that, although it's more akin to a blog post, where he kind of directly compares implementing certain things in core Solidity compared to the things that he implemented in standard Solidity years ago. Um And of course, if you do try it out, or if you just generally have any ideas, you can always Um, you can always reach out at the Solidity Forum. Uh, we do have a Matrix channel, which we typically use for communication. You can read that up on the contributing page of our docs.

Um, that one is fully open. Uh, you just need a Matrix account. Um, but yeah, essentially that's our long-term game. Uh, and hopefully once once it lands, it's going to kind of reduce the the surface area for breaking changes and things like that. Um, and we'll hopefully have a much happier community.

Um, so yeah, that's that's the end of my uh my presentation. Thank you very much. Uh, if you have any questions, feel free to ask.

Thank you for your