From Classic to Core Solidity - Kamil Sliwak

Transcript

Okay. Hello everyone. In today's talk, we'll I will take you in a short trip to how we plan to navigate the transition from class soy to core solidity. First uh a little about me. I'm Camille. I'm from the solid compiler team. I've been the team since like 2020 and for time some time I've been uh co-leading the team with DOA. uh we have recently transitioned to from Ethereum foundation to Argo the structure is more flat so the responsibilities got more dispersed um my focus is mostly I'm working mostly on core solidity and my current focus has been on road maps designing classic solidity and getting us through this

transition so let's go uh and for some context in case um you haven't uh noticed we started publishing a series of uh blog posts on our blog. Uh they talk about our long-term road map. There's one about core solidity. I think that will be most interesting to to uh most people here. We are planning more and one of them will be basically about what I'm talking about but in more detail. So if you don't uh uh catch something uh you'll be able to read about it later. Uh yeah. So what is our goal? Our goal is to make a smooth transition and avoid making mistakes uh

of other product. The famous transition from Python 2 to Python 3 to like the whole decade and no one was satisi satisfied with that. We're going to try to avoid that. Uh still we are not going for full perfect backwards compatibility because this means keeping a lot of stuff in the language that we're not satisfied with. We want to improve. uh on the other hand we're keenly aware that uh breaking changes will lead to friction for users so we'll have to strike the right balance whether we manage or not we'll see but we're very aware of it uh so I'll walk you through four mechanisms that will make smooth

trans possible the first is uh syntactic sugar in c solidity the second and the possibility to convert the syntax of classes to towards score a little. Then possibility of automatic translation tools and finally our main pillar of uh of uh making the transfers move interoperability between the two languages. Uh syntactic sugar uh cross solidity is actually two languages in the French code. Uh the first one is sale. is really quite low-level language that has very expressive type system. It provides the things we always wanted to have in

classicity which is like generics type classes, algebra data types, first class functions, type inference, but aside from that is really minimalistic. It has absolutely no uh high level contact abstractions. No things like events errors uh ex external functions. No arithmetic operators. All arithmetic has to be done via inline assembly. No loops. The only contract uh control uh flow constructs are ifs and pattern matching. Uh the only built-in type is uh warp which represents basically e variable or stack slot however you look at it and it relies heavily on uh inlay assembly to do anything. Uh then cross

solidity is sale plus standard library plus sugar. uh you can all use all the syntax direct all sayings directly in core but uh you have all the code that has that was hardcoded in the compiler as you utilities is now a start library and we have extensive uh fugaring layer that would make the syntax really close so the language will be marked closer than you may expect most of the features of uh classity will be replicated exactly in core We expect that should make it much easier for people to transition than than we expect. Uh we do have some deliberate deliberate omissions like

inheritance, try catch and libraries. Those will not come over. We have other they have replacements. Uh there will be superficial changes like switch to pot fix types. this small syntax changes and there will be of course the library which uh all the things that were sending in global namespace will have to be imported. Uh but yes, swearing is very powerful in core solidity and technically if we really wanted to we could basically port core classic solid to on top of sale. We don't really want to because one of our goals is fix long-standing issues we've seen in classic solidity. So some of the things we would not

translate over even if we translated them we want to remove them in some breaking release. uh that would be counterintuitive counterproductive because uh you would be spending time revealing them just to remove them later. So it will be slight to breaking and um the next mechanism that we could use to make language calls is convergence of syntax. uh we [clears throat] already had uh a lot of significantly breaking changes solidity examples like in 05 we had um the var keyword that was like early version of type inference in 08 we had like checked arithmetic uh there was conver conversions still don't know how like scoping of

variables changed which kind of is very inclusive change for for language like that uh we still went through them so core will be not a big departure from that. Uh and yeah, one way we could make the language we could bring language closer is not only not change core but also change classic solidity slightly to make the syntax closer. For example, we could one big example we could do is like introduce postfix types rather than classic in our breaking list. Uh the question is is it worth it? Um we're not sure. Uh it will be less painful but it will make longer. So we aiming not to do with this but there's a possibility.

One thing I wanted to um also underscore is like what what do 36 plus 6 types really mean? Uh if you look at the example it's really simple. You can have typed before or after does it really matter that much? Turns out yes because it prefix types uh are infamous for for causing paring ambiguities. For example, if you look at the example at the example at the bottom, you have s of three and you cannot really tell if it's like an array of three elements uh or like indexing of an array. By the way, this small mistakes will be for element.

But yeah, uh one way to uh the way solid classic solid fixes that is basically by uh not allowing you to use two complex types. Um that's very limiting and uh the way other languages sometimes solve this is the lexer hack which means they have to have this feedback between parsing analysis feeding information what is what this makes compiler complex uh modern languages don't do that the better solution are posics types which means simply switching the order which means that you know that you have the in front you can parse it parse it an ambiguously and uh that's easier we could port that basically port that to uh class in the part of the transition earlier but

also allowing us to change things that would remove those part limitations. Okay, let's move on. The third mechan possible mechanism is automatic translation of code. Uh we actually uh tried that with uh you call upgrade. Uh it has uh some is good at some things especially simple superficial changes. Uh postix types happened to be one of those. It's uh not so good at changes that are semantic in nature or complex. For example, we change associivity of exponentiation in a way which means uh the code that uh works still works but will work differently. The tool could introduce parenthesis but that relies on

uh assuming that the code is correct and part of the reason for such changes is to uh make sure you make uh things explicit and check that also complex changes like inheritance are do not have one to one translation and that's usually too complex for such tool we had one we dropped it in 08 in 08 um we could uh reintroduce such a tool that's also an option but yes let's move on to the uh fourth pillar which is what we probably be focusing on.

Um first to make it clear the language like compatibility is uh something that all language usually strive for. So of course you'll be able to call XL functions across language but we'll make it more interesting. We plan to make it possible to just throw in uh lang sources in both language of the compiler have it just compile it and give you single output. You just have to use special pragma to make it possible to detect the language. Uh and that thing will not allow you import. You just compile independ independently but compile a man just for you making it transparent for frameworks tools uh which will the main [clears throat] benefit that that you will be able to

make very gradual transition. You'll be able for example to translate contracts one by one still having most of your project in classic and slowly shift to core. Uh and the final thing is interoperability at the function level. This means basically allowing eports between languages and uh allowing you to call internal functions. This is a bit more complex uh has some uh preamps that have to be uh met because uh both language will compile to you. We have to ensure that the language the memory layout is the same for example the free memory pointer and stuff like that and there are some challenges like can blocks because you have utilities uh in you on both sides and the optimizer has to make sure that

they duplicated uh the function is blackbox language so for example if you call it from if you have pure function one to another you don't know if it's pure you have to feed back analysis information back from the other compiler from the other side and linking at your level has the issue to that also the call is a black box. So the optimizer has to assume the worst uh side effects and cannot optimize it as effectively. This can be uh elevated by having some metadata annotations at but overall those trains are possible to overcome. This is also very powerful because it will let you have libraries that are still written in classicality and have code in a new language using it

all. So the transition will be really gradual and not a clean break that you have to basically switch everything. Yeah. And that's all. So to reiterate uh the main mechanism will be extensive in close that will make the language really close. The second one is interoperability. So that you'll be able to compile both both language in the same project and call each other's functions. And there are is a number of other mechanism we can still use to uh try to smooth it over in case those two don't work out. But we're very hopeful that this will be enough. So thank you and time for questions.

>> Thanks a lot Camille. Um we have exactly 3 minutes for Q&A. If you folks scan the QR code on the screen you can enter your questions. Um I would also suggest that at the be I can put the session on live at the beginning of each talk the session will be live and so you can already scan the QR code and have the questions ready by the time the speaker finishes their talk so that we don't have to waste a lot of time. Um but if you can send in your questions. Okay so we already have the first one. What are your thoughts on the idea that changing the syntax of the language invalidates all of the educational content built around solidity? How will you make it easy for new beginners to use the new

language? >> That is a bit of a problem. But like I said, the core solidity will be very close to fully sugared close core will be very close to classic solidity. So it doesn't really evalate all the knowledge. If you are beginner the transition will be really easy because you'll be use able to use most of the things. It's not like the whole language changing. That's uh the main point. The things that will be more important are like optimizations. You will have to be able to optimize differently because the code is different. But that's are more advanced topics and I expected expert and advanced users to be able to pick that better than beginners. So I don't think there'll be a really uh big uh problem here.

>> Okay. Thanks Camille. The next question is will we finally have switch in core solidity? >> Uh maybe I mean you'll have match which is pattern matching which is basically as some sugar over switch and I think uh that's uh what more people will use more so probably not but you have an equivalent mechanism. >> Okay awesome I see that there aren't any more questions for now. Oh okay, another one came in. Is core solidity considering the future migration from EVM to a risk VM based VM?

>> Uh that's actually not a cross concern because coroid is just a front end that will be more of the on the back end side. Um we are making uh some early moves towards model in the compiler making for example to swap out the back end. We still focus on course now and new language and still finishing the back end to make the AI pipeline fast and avoid stack too deep. So that is somewhere on the horizon zone but not an immediate concern. The transition is like way in the future. So we have like bigger problems to deal with first but we aware of that.

>> Amazing. That will be all for you Camille. Thank you so much for your talk and for answering all of the questions.