Solidity: Then, Now, & the Future! by Vishwa Mehta | Devcon SEA

[Music] all right so we're all set uh hi I'm Vish um I'm a developer Advocate at solidity um which is now a project that's part of the newly formed Argo formerly EF um I focus I've been part of the team for a little more than a year now um I mostly Focus current ly on external Communications helping the team um work on and maintain documentation um relaying internal and external important feedback to the engineer so that they can focus on shipping the right features for the community and also some really cool special projects like solidity Summit and the annual solidity developer survey Etc now that we have the boring introduction out of the way uh let's talk a little bit about my talk um as the title suggests I will be talking about how we started as solidity some of the past highlights um the state of the current language and um the recent feature developments and where we are going with it so for how it started I wanted to make a little call back to Devon 3 um from 2017 one of our team leads former team lead now uh talk Al about um uh you know like the initial goal for solidity and the cost of moving fast with features um and then the path forward for a language like solidity so I think when we started um solidity as a language uh the initial goals were something very simple for a language like um a smart contract language like solidity like we wanted more people to write contracts and not just write them but write them correctly so unit tests and formal proving Etc right and we also wanted more and more developers to start writing smart contracts and solidity so similarity to a language that they knew like JavaScript was important so that was one of the goals and type safety blah blah blah when solidity was started all these many years ago I think it was like 9 10 years ago um the initial goal the overall goal was also to make the language generally usable for people um as a high level language as fast as possible which led to certain decisions that in hindsight we would like to do differently and that's also part of something that I will be talking about in this talk the language is now on a path to make some important changes and um we will be covering that in the final section uh this is a really cool screen grab that I got from that talk that I mentioned um inside the compiler this is how the code used to look like and then when we introduced ulia which is now called Ule that's how it changed a little bit from more convoluted code we got to something that's a little more readable um and I wouldn't want to go in depth into this but this is to say that the language has constantly been um evolving a lot and I'd like to talk about some really cool features that we've um released recently but before we move on to that I'd like for you folks to meet the team so meet the solidity team now we've also the team has also evolved quite a bit on the development side of things we have Alex Daniel our team lead um Camille matus morit who has recently joined us Nicola and Rodrigo s um franzy and I work on community and ecosystem uh we have Nick who leads the eth team debug the new debugging format um smt Checker we have Martin uh parava helps us with fuzzing every now and then um Marin and Rigo are have recently been working very actively um with us on language research and we've also been collaborating with external teams like fee and formal verification that are now um part of the larger Argo Collective with us um including other teams such as sourcify all right so moving to the main um juicy bits the recent features and language developments talking about new features uh Transit storage has been one of the longest awaited features on the evm level um just as a quick definition Transit storage is a new introduces a new data location which behaves similarly to storage but as a distinction it is not permanent rather it um is only scoped to the current transaction um we saw a lot of interest for support for Trans and storage so um we began rolling out this support for Trans and storage with the release of solidity version 08.24 using two op codes um in inline assembly um namely t- store and tload that you can use to access the data stored in these locations um over the course of subsequent years um uh sorry months we also saw an influx of interest for support for Trent storage on the um language level uh the high level language support so we introduced parsel support for Trans and storage variables in 0.827 followed by full support for Value types in 0.8.2 um speaking of interest from the community uh the support for specifying storage locations for for storage variables was one of the most discussed um issues in the past few months that we got uh it's it's an external issue that you can see linked um in the first link proposal to allow specifying storage locations and this progress was triggered by the EIP 772 so if you know the EIP um it it would be nicer if we have um if we allow users to specify storage locations to avoid conflicts we shared a proposal for explicit storage layout Syntax for feedback because we saw really active participation by the community to push these discussions forward and then further selected a candidate for implementation so if you see the proposal and I hope that these slides will be shared with the audience somehow um if you see the proposal there are a couple variants and we selected variant two um and you can read the rational and specific uh the specification under the original issue but this is how some of the implement ation uh of that could look like another one of the most requested features from our user Community was required with custom errors um and we rolled support for that in uh 08.

26 um it is a gas um it is a gas efficient way of letting the users know why an operation is failing right to make it more intuitive and we do this by introducing a new over overload so what you can do is you can um it actually lets the user uh Define a custom error message as um a second argument to the requir function and that's a little example of that of how you can use it all right so one of the bigger chunks of the talks um yir that was also a major update that we made to the compiler um how many of uh you people here know about yir that's a few people nice how many of you have used it for compilations of your contracts it's also a good amount nice so for those of you who do not know Y is okay stuck again all right it's a new compilation pipeline in solidity which introduces um another intermediate step um by first translating the solidity code into an intermediate represent presentation in our case Ule instead of directly compiling solidity code into evm bite code um it is a more Modern Way of compiler design and it uh gives us a couple of couple of advantages we've been talking about yir for a while now and we have limited time so I will try to zip through um these advantages but of course like if you are aware of um how an intermediate representation sort of helps compile a design line it adds this like layer that allows for powerful optimizations um transparent and auditable code Generation Um obviously better gas efficiency and also eliminating stack Tod barrers which was according to our solidity survey um one of the main pain points over the past few years so we're happy to be working on that it also gives us feasibility of multiple backends and front ends um to clarify a little bit um it is designed the intermediate representation is designed with the goal to serve as a backend for multiple compilers um a major example is the fee language uh it also targets multiple backends initially evm and ewm and now e eof ethereum object format it is intended to be a back in for experimental solidity will experimental solidity is supposed to be a thin layer of um type system over U it only makes sense that it is um the backend the intended backend for experimental solidity all right recent performance optimizations we are well aware that the compilation um using the Y pipeline is not the fastest right now but the team is constantly working on making it faster and more optimized um with every release and I'd like to talk a little bit about it um we to make the compilation V faster we've been um working on certain features the first one was released in 08.26 not so much as a feature but an update that uh changes the U Optimizer step sequence to make it newer and faster we also started caching optimized IR to make um the compilation times a bit lower um and this was released in 0.8.2 7 followed by generate Json artifacts of U ests only on demand to make memory usage more efficient um and that was released in 0.828 there have also been um a couple of other um smaller optimizations but based on our benchmarks and our data we've seen that um we only started making significant changes in the reduction of compilation times and efficiency um in 0.

8.2 one and further yeah so this is a little uh plot that we've U made to sort of represent what it looks like what the changes look like and the improvements look like um the three projects that we've used for the benchmarks are open Zeppelin Unis Swap and IG layer overall this has been um uh the change in compilation time of Benchmark projects across compiler versions and this has been compared to soulc version 0.8 .18 so to summarize what was in the graph compared to solidity version 0.818 compilation times yir were R reduced by 50% for open Zeppelin 69% for UNIS swop and 81% for igon layer um now ongoing work on compilation via IR um of course there is eth debug and if you did not listen to Nick's talk on eth debug and his current work around it um it would be really cool if you folks um checked out the live stream or the talk when it's up later but it's going to it's a new debugging format that makes debugging better for the IR pipeline specifically we have also been working with project Gray from University of Madrid so huge shout out uh to project gray members for helping us making um transformations for of the U IR um to evm bite code Transformations improved and more efficient they use ssfg optimizations to speed up um compilation time and to help us improve this so we are still working with them to investigate how this is going to make our work around this better all right what's next with yir well we talked about um making yir the default by default pipeline um back in solidity Summit 2023 um so I'd like to give a quick update uh that sorry uh I'd like to give a quick update that we've decided to tie that upgrade with eof for a few reasons two main reasons being that eof has certain features that it um like unlimited swaps and dupes that make U to evm transformation significantly simpler and more efficient and this will help us um eliminate some of the remainings St to deep errors that is one of the main goals for us to make yir default um since the vir and euf upgrades are both containing minor semantic changes and the um uh update will require it to be break a breaking change combining combining the release will make it um easier for us to reduce the upgrade burden on the solidity solidity ecosystem and the community um we've had a full implementation for eof for a while now which has been on a branch but unfortunately it hasn't been approved by all c devs for a merge in the hard folk so we really hope that um for instance the iepsilon team has been working on an extension of eof which makes it um more powerful and we hope that that can be merged in um what is now scheduled for the Osaka upgrade we wrote an explan explainer about yir and everything around it uh also tying it to EF so if you want to go check that out that's up on our blog and now one of the main um sections which is where we are going and what is the solidity future before we jump into what is planned for the future let's take a look at what current solidity looks like and what are the issues with it as we learned in the beginning of the talk solidity has sort of naturally grown as a language which is a set of features that were requested by um the community and um all of these like various features um that we've worked on it hasn't been worked on in a much logical manner um this kind of compiler hardcoded functionality can sort of increase the complexity of the language the more and more features that you add to it the language is also not extensible at the moment so that is also a major issue and it makes adding newer future features to it come at a high cost um and at higher risks so we cannot move faster with feature requests from the community what's missing generics there is currently no concept of generics in solidity which would be nice to have it would also be nice to have formally defined semantics that's currently missing um and that that the reason for that is that because we have so many features that poses special cases that the um semantics cannot cover or makes it difficult to do that um we don't have formally defined semantics that we'd like to have which would be important for something like solidity as a smart contract language and all of these problems combined mean that we also have a lack of feature um lack of a set of features that users actively request or need um that the language cannot express at the moment without taking major risks um and compromising on Simplicity um like immutables of reference types and we've also currently having the similar same concerns um for support with Trends and storage especially full language level support for that um going forward there can be two parts that we can take in designing a language like solidity um the current current path which is path a um that you can do by extending the language with compiler hardcoded functionality which will further increase the complexity of the language and make it um uh more um higher in Risk so you can move faster in short term with feature development but the risks are much higher and the cost as well path B um we've been evaluating if this can be the path moving forward where moving we move solidity to a to become a leaner core Language by reducing language complexity by moving feature development and types to a standard Library this would make it safely extensible um and the extensibility can become a first class priority of the language this would also make um faster implementation of important features easier for the team and this will be the path forward that we are calling experimental solidity um time is running out so I will zip past the design goals that we have for experimental solidity which is simplified core language that is extensible allows for formal semantics as we covered earlier no hardcoded features in the core language because we move it to a standard Library um and one of the main goals would be to maintain the look in feel and the usability of the language as the current language the advance vages of having something like that would be that the core language changes are rare and any feature development will not drastically change the core language and maintaining a lean core language like that would mean that auditing and formal verification becomes easier further meaning that the security improves and then it makes moving Faster by delivering Community features easier because we invite we are then able to invite the community in this uh to be a part of this process um and that is important for everyone we will also delegate Community stewardship over the standard library and have a formal process for changing the standard Library this is also what current timeline looks like for um experimental solidity ongoing business has been existing uh developing existing prototypes that are able to reconstruct simple contracts um in the course of 2025 we hope to work on a more complete Baseline standard Library um and roll out fully functional prototypes that we can test and get more feedback on and also sort of have initial syntactic sugar so that we can reinstall the look and feel and usability of the language as the current language um in 2026 we want to stabilize the all of this process and also um formalize a process for making changes to the standard Library by taking proposals from the community and moving forward from prot prototypes to production capacity few quick resources before I conclude if you want to know more about any of the things that I spoke about the features or want to dive deep into them we have a lot of explainers and release announcements on our blog there's obviously the official docks and if you want to have deeper language uh design discussions then you can reach out to us on the Forum and leave questions there and also engage with the rest of the community on the Forum do follow us on Twitter to stay updated and a quick plug to the uh newly formed and announced Argo Collective uh and you can see the website and the blog there that's all from me thank you so much for being here thanks [Applause] ton thank you thank you wish for this amazing talk I guess everyone in the room and watching us live has a better overview of where Sol is heading if not feel free to uh give us your questions through Marat uh we'll be answering them one by one uh I'll be starting with the topmost one are there plans to change the storage layout spec for gas optimizations after verle State released um I'll be giving the floor for to Daniel the team need of solity for the question I guess yeah yeah I'm here to answer technical questions that's a tough one I'm regretting it uh so yeah uh of course we need to do something about workl tree State um in an Ideal World we would have experimental solidity and could adjust standard library implementations of storage layouts at the time that veral trees would uh happen but yeah I mean the timelines may not work out for that so we will be working on yeah seeing what we can do earlier than that if necessary next next up what current feature is considered hardcoded all of them quick one um are there plans to change the storage layout spec for gas oh sorry this was already asked when 1.

0 when the new system of having a standard library and its more cor language is stable um when um I'll be skipping the next one because we talked about the next features uh how does the Sol team collaborate with the Fay and formal verification team um significantly I would say I mean f is working on uh language Frankin that have properties that we want for experimental solidity formal verification has a lot of uh knowledge and expertise about The Logical structure of that t t an English needs to be consistent and uh formally verifiable Fe also has uh working has been working with experimental backends which we can use uh which induces knowledge that we can potentially use for making the Y pipeline uh faster so there is a lot of synergy between the themes nice that's great to hear um next up when moving stuff from core language to a standard Library will that be detrimental for to compile times or make run time less gas efficient we hope neither of that will be a large problem uh currently the high level language is not a concern in performance it will take more time to do parsing and type checking on the high level language in the future we will see when the prototypes are finished how bad that will become but the most time spent by far at the moment and the most complex thing is optimization and uh and code generation for the evm if we don't have UF so we hope that it won't become a major issue if some functions move to standard Library do we need to include that Library code into Soul C Json uh I would say no I mean each compiler version ships with a version of the standard library that can be referred to by an internal yeah mechanism um next one is I think partially answered but I'll ask again in EF the stack to deep error doesn't exist exist anymore do you think why a still makes sense for E uh it doesn't exist anymore is maybe an overstatement it because it's less likely because we have I mean we don't technically have unlimited Swap and up space we only have 26 bit access which is much better than 16 bit 16 slots but uh still not infinite it and uh avoiding St of deep errors is not the only reason for V it's also making the compilation more simpler making the compiler infrastructure simpler making the results of the compilation inter spectable by Auditors by as a target for formal verification and so on and so forth so it will definitely still be useful the biggest bottleneck in sheet contract development is auditing is it a priority to make formal verification easier or automated yes I mean yeah we've talked about that a lot experiment solidity hopefully will help a lot uh intermediate representations help with that there is only so much we can do I mean uh verification will remain hard yeah we'll try to do as best as we can with our collaboration with the formal verification team as well uh I guess this will be the last question will experimental solidity have inline assembly yes uh the idea is to treat inline assembly in experiment solidity to a similar degree to unsafe blocks and rust actually the Senate Library will encapsulate implementations in assembly in a safe abstraction that will then be usable but it can be extended by still using in assembly and providing new such abstractions if necessary all right is Fay also working on a new back backand let's keep it short uh I mean that's for them to answer really but I mean yes it's an atina which is an uh is an closer to llvm uh uh designed uh ssab based control flow graph representation that's similar to what we use to translate Ule to evm in the future so there is yeah some similarties there but yes all right that concludes our Q&A session if you have more sessions feel free to catch Daniel or wish and let's give a big round of applause for both of them [Applause]