A sneak peek at Core Solidity

Transcript

Every contract, all the protocols that run on chain that move billions of dollars, most of it started life as Solidity. Our next speaker, Yacob, uh works on the compiler itself. And since Solidity just turned 11, he's here to give us a preview of what that future looks like. Let's give it up for Yacob. >> Hello everyone. I'm Yacob. Um I think I've been to all Devcons, but this is actually the first time I'm speaking at one. So, thank you for finally having me.

Um today I'm going to talk a little bit about what uh what we're doing at Solidity and what what's next. Uh so, I wrote my first smart contract in 2015. I don't know if you can read it, but uh it's the one on the uh some of it is here on the right. And the language looks fairly similar still. Of course, it has changed, but yeah, the tooling back then was almost non-existent. Uh I think we used LS Zero if anyone remembers this uh to deploy the contracts. It was pretty terrible. Um since then, I've done a bunch of things uh in Ethereum. Uh my whole professional life has been

uh contributing to Ethereum. And now I'm the DevRel at the Argo Collective, and we are um uh I'm contributing to the Argo Collective. I'm and I'm the DevRel for Solidity. Um Solidity has been in production for 11 years. Um and we had the last uh release was um in April. It was the 0.8.35. And as I mentioned, it's um maintained and developed by the Argo Collective and has been since uh 2025, but the people uh working on Solidity in the Argo collective all used to work in the Ethereum Foundation.

So, it's the same team, but we are now a separate entity that works on Solidity amongst a couple of other projects such as Solidity, Fe, EVM, Act, and EthDebug. So, a little bit about what hurts in the language. Um We recently had our or not so recently, but we had our results from the developer survey from 2015, and the biggest pain points that people point out is the stack too deep.

Um and I just will cross-reference it on on on some of the numbers, and like the more people self-pro- self-proclaimed to be experts, the the more they experience this as a as a pain point um and have been doing this for some years. So, it is definitely something that should be addressed and that we are addressing. Um and how we do this is currently with Okay, I'll go back. Like, so what is in the the 0.8 35 release is one of them is we have the first compile time built in.

Um so, that's a a step in in in the direction of of having more compile time built ins, and this will also carry over to like future work that we'll be doing on Solidity that I'll talk a little bit more about later. Then we have the experimental flag that we introduced, and this experimental flag means that we now have all the experimental features that we can have as part of the the language, but they are like you should not use them. They will break. They will change. Um and the biggest um feature that we added under the experimental flag is via SSA CFG, which is what will be solving stack too deep, and it will also eventually speed up compile times.

Um so, how does this work? Um I'm not going to go too much in depth with it. We did an another presentation on Monday, my colleague Moritz, where he goes uh in depth with this. Uh but yeah, as I said, it's the number one complaint. Um at its root, you could argue that it's an issue with the EVM and not with the Solidity. I'm not going to go too much into uh taking sides here, but what we're doing to fix it is the SSACG code gen code gen that will do memory spilling and through that allow to have more um items in the stack um or rather same amount of them, but yeah, we do have memory spilling.

Um and we target that for uh basically at the Q2. Um I believe that we have it in the develop branch, but not yet um in in a release. And then, what else is going on is the EIP-8024, which introduces dup and swap and and exchange opcodes that basically gives uh access to more items in the stack. So, instead of the 16 uh that you currently can access, you should have access to something like 272 items. And it is not just proposed for Glams to them. I believe it is also scheduled for inclusion.

Um but you can only uh you can only patch your way out of so many things. Um and as I mentioned, Solidity as a language is 11 years old and back when it was being designed, maybe 13 years ago, uh we had no idea or people had no idea how we were actually going to use Solidity and how we would like write smart smart contracts. So, yeah, a lot has changed in the programming language landscape since then, uh which is why we are also working on what we call so core solidity, which is um um a redesigned smart contract language that still uses the same uh back end as uh classic solidity, but probably looks

more like what you'd expect a modern uh smart contract language to look like in 2026. Here's a small uh example of a classic and a core implementation of um a payment handler where you can see some of the the features of uh core solidity versus classic. We have uh a struct called payment that has like different um values that can kind of be used to identify a payment type. Um but there's not really any way to guarantee what uh a payment struct actually holds. So, we have to have all these if statements to figure out which type it is, and then we can do stuff based on that. And for some

reason uh we have also have to return zero uh because that's uh like if nothing matches, we have to return zero because we have to return something. Um and if we add in a new type like ERC-1155, there's also nothing in the compiler telling us that now we are not dealing with this uh case any longer. Whereas in core, we will have uh um ADTs and um and pattern matching, which makes this uh specific case quite trivial. We define the three different types of payment.

Uh and then we pattern match on the type. And if we were to add in then an ERC-1155 payment type, the compiler would warn us everywhere that we are not handling this case. So, we would not even be allowed to compile it, and um we are forced to handle all cases, which I think is uh pretty amazing, and I think it will help uh or solve quite a lot of like bugs that you'd otherwise only find find after deployment maybe or later on. So, it can save you a lot of time, and it makes it harder to make mistakes, which I think is something we should always strive for because people will do or will make mistakes, but we should make it as hard

as possible for them to make the mistakes. So, that is some of the thinking that goes into to uh designing this language. Some of the Yeah, this is basically what what I said here that like if you miss a specific case, the compiler will tell you and kind of point you in the direction to where to fix it. Um And this pattern matching also comes at zero at added runtime cost. You could write the same thing uh in a switch statement in in Yul. Um And basically all wrapper types are are are erased uh so, you don't you don't pay anything extra for this. It all is handled during um compile time.

We also have generics. Uh so, right now I think it's like 380 different handwritten uh functions for log in um like Forge standard library um and in core, you could handle this with uh one generic function per arity. So, this will also be uh more elegant, easier to to to do. And yeah, again, no additional runtime cost for this. It's handled during compile time. Um quickly running over some of the the other things that we will have in core.

Um The biggest thing that we get a little bit of pushback on is that we are removing inheritance as as as you know it. So, uh we'll have to do reuse through traits and uh composition mechanisms. Um you have first-class functions and closures and type inference almost everywhere. And again, we'll have compile time evaluation, as I mentioned, uh, used more frequently in the language, and the first step was in, uh, ECE uh, 7201, uh, compile time that I mentioned earlier.

And, okay, it's a little bit small, um, but this shows which other, um, core Solidity features that people want. Um, they want better error handling. You get You get that from the pattern matching. Uh, they want better delegate call. That's basically what you can do from the the composition. Um, and what powers core Solidity? Um, underneath it all, we have a small language called Sail, um, which allows for some, uh, pretty nice things, I would say. So, Sail consists of eight primitives and one type.

And right now, in classic Solidity, uh, we don't have a standard library. So, every time we want to have something like ABI encode, we have to add it in the compiler and touch parts of the the code base that are quite critical and even the smallest mistake could, uh, have pretty bad consequences. So, instead, we are designing core Solidity to be as small a core language as possible, and then have a standard library on top of it that is separate from the compiler itself, so that people can also define these things, and we can have a community process in place for figuring out what we should have in the um, standard library.

Um, so, yeah, it will be easier to read and audit and debug the standard library. You can actually see what's going on instead of, uh, reading thousands and thousands of lines of the C++ code, um, and as I mentioned, I think the fact that we can split, uh, or separate the the the language from the compiler. Also, means that we can have two different processes and we can move faster with implementing new features to the language without having to make a new release of the compiler. Um and you can more or less Yeah, basically if you disable the standard library, you just have typed Yul left.

Um which I think is is quite um powerful and as I said, the the language is small. Hopefully small enough that it will not be too difficult to formally verify it and it is something that we are um planning on doing as well. So, what uh what is the current state of uh core Solidity? And what's what's next? We have recently had quite a lot of um um contributions.

One is that we had a a former um Solidity team member implement the beacon chain deposit contract. So, um porting that and writing it in core Solidity and from that we had a lot of uh issues opened and PRs merged that kind of make the the language uh more pleasant to use. Um I would say that the the syntax you've seen so far, it's not something that's set in stone. It's developing and it will be changing. Um and we also had a multi-sig implemented um in core Solidity.

Which is kind of quite cool because in this uh code example, you can really see how how a state machine like how you can easily represent like the different states of a transaction's life cycle, so to speak, in a multi-sig with the the pattern matching uh and and different like kind of a state machine there. Then, another external contributor um implemented the Uniswap V2 pools um and provided with a bunch of provided us with a bunch of nice feedback in the in the forum.

So, that makes me uh happy and also the team, of course. But, it's always nice to get early feedback from people uh who use your your language and who have opinions on it. We recently also released a blog post on the idea of like pattern matching and how it will work in core Solidity. Because it will be a new concept for normal Solidity developers, they might not know or at least are not familiar with using uh pattern matching in their daily day. Um We also have like uh recently the first version of the module system that landed. And as I mentioned, the stuff that comes with the experimental

flag in the latest release uh will also carry over uh to the work that like to it will be relevant for core Solidity as well since we use the same back end, which I think is also an important thing to know. It's like it's not like we're doing everything all over again. We are reusing as much as we can that makes sense and we do have a pretty battle-tested back end for Solidity. So, it definitely makes sense to to reuse. You can try it out. Um it's possible to write contracts and compile contracts.

Please don't use them for anything production wise. That would be uh unwise because there are bugs. Um but, we'd love to to hear your experiences and any feedback that you you might have. Um and yeah, as I said, try it out. Um you can do that on uh in the Solcore repository. We are also working on having a playground like a browser playground so you don't have to install Haskell and whatnot to to actually get it get it going.

Now, I mentioned Haskell. That's the the language we are currently using for for like designing the language, but we will be using a different language for the actual production implementation. Um we are starting to design the core the sorry the the standard library. If you have opinions or ideas or feedback for what should be in there, um please reach out. Um I'd love to to hear what what you think is is important to to to have in there. Um we are not going to have a production-ready compiler for this in 2026, but we do hope to have at least something like an an alpha version of the production

implementation um before the end of the year, but no promises. And uh yeah, all feedback is welcome in the Solidity forum. I think that's all I have uh today. Please uh reach out or come find me after the talk if you have any questions or feedback. I would love to to hear what your thoughts are on um core Solidity. I think uh I think that's all. Thank you for listening. >> Thank you very much.

Uh please do we have any questions from the audience? I think we have time >> the middle. >> We have one in the middle. Uh do I see any more hands up? >> Uh so, you said like um stack to deep is pain right? And why um reading external contract storage is not not able to read is not a pain? Why we should not have like ext uh as load up code?

External storage up code. >> Why we should have it or not have it? >> Why we should not have it cuz we don't have it, right? >> Yeah. >> I able to read storage on the of my contract but not external one. And if it doesn't expose some view function, right? For specific storage slot I'm interested in, then it's not reachable from the my own, right? So >> But is that is that an EVM specific question and not a >> Yeah, it's an EVM up code. I'm >> Yeah. >> I'm curious why we don't have it. >> Me too.

And we we don't really have we we don't like we we give input on ideas to change the EVM as long as they would be relevant for for the Solidity language, but >> From time to time someone asks new up codes to the EVM, right? >> Yeah, of course they do, but I I like I cannot really reply or answer why it's it's it's not there because we are not the people making decisions for the the EVM unfortunately. Um >> Okay, cool. >> Is it time for one more or >> Do we have any more >> Is there one more?

>> No. Perfect. Thank you so much. Let's put our hands together for Jacob. >> Thank you.