Solar Invictus - DaniPopes

Transcript

All right, thank you for sticking around this long. I know it's pretty late, so I'm going to keep it pretty light. Uh, so I'm Danny. I'm going to present to you today our new Solidity compiler uh called Solar. So, a bit about uh me as a background. I started programming actually in smart contracts in 2021. So um um at the time there was no foundry. Um uh the best toolkit that we had at the time was hard hat. Um and we had a lot of problems. Um at least uh some some smart contract developers had uh problems with the fact that testing was uh pretty slow and um the iteration loop

was slow or other things made it uh hard to develop smart contracts by using hard because of the separation of the languages um uh used for in production solidity and the testing language uh using JavaScript. So um at the time this is we uh the only thing we had but we had these problems um and uh so Foundry came out when Foundry came out I would say that it improved 100 times the devx at least for some people uh this might be maybe uh too big of a number but um makes for a good slide. So um as you can see here this is um the gif we have on the rhyme just running force test on so lady

taking well like a second to run a thousand tests or how many um so this was a massive improvement at least for me at a time when I was just doing smart contracts um so um this is kind of like foundry setting the bar higher for everyone else um so I was really amazed by this um at a time. So I decided to look into how it actually works and why is it so much faster? How how do we actually have solid test in the first place? Like how does that work? So um I started uh looking into the actual codebase, the libraries that it uses and started contributing to it. Um

and eventually I managed to join the team. So I'm part of the foundry team. uh more broadly the open-source team that uh is currently uh at Temple. We maintain RT foundry uh and of course our new um project that I'm going to talk about later solar. So as Foundry got more uh adoption um and Foundry being kind of uh the leading um uh toolkit used in smart contract development uh in terms of performance.

um we started to get more and more uh projects using it of course but also meant that existing projects became larger and um uh existing test suites became larger as more complex contracts need more complex tests to test them etc. So what happens is that um as more solidity code is being written, we're kind of like testing one part of the solity compiler that we never uh really had to worry about because the the contracts that were developed initially for example think in 2015 we didn't even have ERC20. there were like simple super simple one file contracts that never

really got to exercise the performance and other characteristics characteristics of the solid compiler. So as more as projects became more complex and bigger um we started to get complaints in Foundry that hey my project is taking one minute or two minute to compile from scratch and when I'm at a console log to say uh start like debugging a failing test um I I have to wait like a minute to recompile the project. So this is something that that was never really an issue at the beginning but uh as foundry became uh got more adoption we started getting this this this complaints and so this is kind of like a newerware thing uh with

solidity that was never um really uh thought of before. Uh another thing of course is the infamous stack to deep error. You've heard it the entire day. Uh there's many fixes now uh and in the future, but um this is one another thing that that was just never exercised because the the contracts were never really that complex and especially the tests being in a different language, you never had to write a large uh solidify files in the first place. So um as we um started to tackle these issues, we uh implement some workarounds. For example, at the foundry level, uh we implemented caching, smarter caching, um requesting less

stuff from the compiler that we never uh that maybe don't use by default. For example, um requesting IR output in the JSON uh output from the compiler, we never really used it. So just by trimming the amount of stuff we request from the compiler, we got five star compile times. Um but these are really just like not temporary workarounds but they don't really tackle the core issue itself. Um another workaround is dynamic linking that I want to highlight really quick. Um this is a feature that we implemented recently in Foundry where um for examp uh like uh decouples tests from source files uh leading to potentially 100x

speed ups uh and computation times. Uh this is part of the blog post we released um about this. Um so these are many workarounds but they don't really tackle the core issue of the compiler itself having these performance issues. So what we developed um in started development internally um of course uh dynamic linking is um implemented using this tool. Um so what is this tool? It's solar. Uh we released solar um actually a year ago. Um since then uh we've uh implemented um more features into it and

also um integrated more in foundry itself. Uh one of the features of course being the dynamic test link I just described. Um so uh what what is solar? Uh so solar is our new solity compiler. This is uh a compiler um this is not sol this is a separate binary that we develop ourselves. Um this is um written entirely from scratch uh in Rust u from the ground up with performance in mind of course tackling these issues that I just described. So the way we do this is um here's a few like small points but um for example data oriented design where

like um uh we we encode like the performance uh into our data structure. So for example um uh the whole compiler is structured around multiple levels of IR instead of a single monolithic um a for example that this lets us um implement um smaller functions and um u lets us be able to uh operate on this multiple IRS in parallel. uh whereas in S C for example everything is done uh on a s in a on a single data structure that

is mutated and iterated upon sequentially. Um just just this fact alone u being able to multi-thread the compiler uh lets us uh get uh serious speed ups. Uh but of course like the whole structure of the compiler is um designed with performance in mind. So um for example also um in the future we will also be able to uh implement incremental compilation uh where um calling compiler multiple times not even caching uh at the foundry level but directly at the solar level at the compiler level where um computation can be reused from previous um attempts.

Uh another thing another design principle that we uh focus at solar is of course library usage. So uh being developed internally and using foundry we focused a lot on making the API pretty ergonomic and um improving on the existing uh APIs that we had before other libraries and maybe also soc as well. Um in terms of uh higher level uh operations for example um iterating on the a as in like traversing the actual source code uh of a file or having just like utility methods on common operations that you might need when uh

interacting with the uh the and stuff like that. Um essentially what we had in Foundry before was just a a bunch of different libraries. uh for example Solang which is I don't know if it's still maintained but uh it's a solar um a Solana uh solidity implementation uh that is separate from Sol and we use this library because it was written in Rust and it was just available uh but of course being u for Solan they had like different goals like we had to m make many workarounds to even uh support um to add support for it in foundry Um and for example in uh Chisel uh what we

had was um uh we were essentially re-implementing a compiler ourselves for the higher level um u operations that we we needed in Chisel for example to inspect an expression like we would need to uh given like a text input from the user in a ripple we would need to parse it and then uh add it into the context and check okay is this an expression what does this refer to how do we display the type of it and all of these things are essentially we were just like um reimplementing a compiler ourselves in foundry so we had this in many different places in forge

fmt in forge doc so all of these um different uh implementations of uh the solity and these higher level operations we uh of course uh bundle them together and uh put them in solar as a easier way to interact with. So uh I've uh we're not the only users of solar. Uh I've heard from many people using solar either a parsing or even the higher level or sorry the lower level uh more um complete uh and analyzed IR called HI. Uh people using this for

building static analysis tools. Um of course we use it ourselves in forge lint now. Um, so yeah, the main point here is that like we focus a lot on library usage. If you're using it as a library and you have any feedback, uh, feel free to contact me or open an initial GitHub. Um, so yeah, this is like an example usage from one of our examples of how you can use it uh in Rust as a library. Um this just simply parses a single file um and then just prints it uh to the console using the debug format.

Um of course focusing on performance I have a few numbers here 5 to 10x parsing. This is uh comparing against soul C um using the CLI. Um this is single thread performance on parsing. Um we also do parsing in parallel. So given 100 files all those 100 files will be able to be parsed in parallel. Um so numbers may vary there but uh just a single thread performance we've been able to achieve 5 to 10x par faster parsing. Um we also implement uh AI output. So um after parsing we analyze a bit the contract. uh we figure

out the structure of the of a contract and then we are able to emit the same exact uh AI format the JSON format that you all probably know um 50x faster. So this is um again like most of the structure of the compiler is uh done in parallel. So the numbers may vary from a large project being 50x faster or a super simple project being 5x faster. um we're generally seeing very large speed ups uh all across the board board. So um for bite code we don't have that implemented yet but we also expect similar numbers here um in terms of both like compiler performance as in uh time to time spent

in the compiler and also um performance of the generated bite code uh itself. Uh this is a graph of the benchmark that we uh maintain. We maintain a set of uh benchmark um uh of benchmark programs that we test against a bunch of different implementations. Uh solar here being the uh green uh bar and highest butter. Um you can see here the few different implementations. Um slang uh as maintained by I believe Foundation. Um so see Solang the one I just mentioned the Solana implementation and also tree sitter which is uh I think used by a couple of um uh VS code

extensions or something like that for like syntax highlighting and also the GitHub syntax highing for solidity. Uh this another uh CLI benchmark. I'm just testing here the solar API versus the C AI for a simple um sorry for so uh so I'm just passing the exact same arguments um just differing in the how we actually pass the AI argument. Um we're passing every file for source and test files. Uh and we can see here 40 to 50x faster on my MacBook.

Um so yeah I mentioned before forge lint uh this is powered by solar um we were able to build this relatively quickly uh as solar is also inspired by the ras compiler uh which uh as you may or may not know the rust compiler is uh renowned for its uh good diagnostics and um as in the errors and the warnings display but also the way that it's actually implemented it makes it very easy for someone to contribute a new lint or a new static analysis check uh in the compiler itself. Um so we took this inspiration from uh the Rust compiler and also implemented it in

solar. Uh what's coming up next uh uh directly uh in the next few months we're already working on the LSP. Uh this is the language server protocol essentially just a command on forge or solar that spawns a server and then um for example a VS code extension um can uh use this server to query the state of your project um implement uh various functionalities like go to definition when you click on a on a variable it takes you to the definition or uh stuff like that. Um another thing is um of course the diagnostics the same ones that you get in solar in the CLI you can

have them in your editor etc. Um after this um we we're also um of course planning also to uh finish the compiler itself. So this means um implementing uh a back end. So right now solar is only a front end uh which means it can parse and analyze code but it cannot emit by code yet. Uh we're looking into various uh different backends and ways to actually implement this. Um of course uh you've heard from many people today about uh bite code generation and even solidity themselves with the soul core. Um, [snorts] so we're actively looking into how to um

hook into either an existing implementation or even implement it ourselves. Um, so this is uh something that's um up next for Solar. Um, yeah. Uh, this is all I have for you. Uh, if you have any questions, feel free to ask or DM me later. Thank you. [applause] Amazing. Thank you so much, Danny. Um, does multiple backend near you plan to multiple backend?

Uh, I think there might be something wrong with this question. Maybe I can. >> Maybe you can decipher it. >> Uh, [laughter] I'm trying. Um, how much has Solar improved the performance of the F forge formatter? uh we didn't actively test the formatter since it was already okay but I think it's probably 10 to 20x faster based on like also the uh previous benchmarks on uh solang so this apply uh this graph applies directly to forge fmt since fmt only needs to parse the source code and then uh it just u basically goes over the a and then like outputs uh pretty

printed version. Um, so yeah, looking probably at 5 10x faster on a decently sized project. >> Okay, since it's still work in progress, what are the current considerations for backends? For example, do you consider creating an EVM LLVM target? >> Uh, that is totally possible. um everything is still on the table like we've we know about for example you we can target uh Venom from the uh Viper team or even uh solex as pre presented earlier um for an LDM back end. So I think uh this is um in the future going to be relatively straightforward to uh

implement a conversion path between our internal IR and uh someone else's uh that also implements codegen and yeah this is one of the things uh that we're looking into. >> That makes sense. Um are there equivalent tests between solar and soulc >> um tests? I'm not sure what that refers to. Um I guess like since we don't produce uh bite code uh we cannot test that but um our goal is to essentially have equivalent um uh like semantics. So essentially like compiling your code with C and compiling your code with solar should be able to uh have the same

semantics since we're implementing the same language. Um for AI that we have already have right now is 100% equivalent. Yeah. People are also asking when back end. >> When back end um well I can't give a date. It's a very like kind of complex thing still. Uh but I would say I think end of Q1 we have at least a prototype ready next year. >> Okay. And then uh oh okay. So we have another spicy question obviously. Um, how does core versus class of solidity affect solar?

>> Um, well, uh, since core recently came out, I don't think we had many opinions on it before since we never looked into it. Um, but I think, uh, as of right now, like it's still a prototype, so we're not actively looking into implementing it. Uh, but if it's something that's eventually going to be like a Solidity 1.0 kind of thing. Um, yeah, then we're probably going to end up uh implementing it and uh just having the same goals in mind as a library usage and for >> Amazing. Um, how was the relative parse performance measured?

uh it was measured as a I believe as a microbenchmark as in you take the uh a single file. For example, here uh these are just single files of projects squashed into a single file. So flattened um for example while counter and VM are single files but optimism so these are larger projects squashed into one file and then just passed uh to the actual uh implementation. Um so for example for um solang tree sitterter these are libraries so they we just call the main parsing function and forc we just pass it through the CLI as a as standard input

>> and then in the end you have a kudos um we love a well performing parser job well done >> thank you >> thank you so much Danny for that final talk ah okay we have one final question >> oh >> quickly run with the mic Sorry, I actually tried writing it and it was too long for the field. >> Okay. it actually relates to the question that um has um a typo and uh so I'm going to read it without the typo. So does multiple backend mean you plan to support compiling solidity code to nonem chains?

Um that is possible yes with further with more effort for sure but um yeah the possibility is definitely there for example as we all know like the risk five efforts for um uh the next like EVM implementation um that that's definitely possible um the same as uh you will implementing a different backend we can also do the same yeah >> and now for my question Uh so contracts need to run on on chain. So they need to be compiled to EVM obviously.

>> But tests they never are never intended to run on on chain, >> right? >> So maybe uh are there plans to compile tests to x86 or ARM 64 and not have to play around stack too deep when you're just writing a test? It doesn't make sense. >> Yeah, that makes sense. Um we've haven't discussed this but that's definitely an interesting uh possibility. Um what we looked into before is compiling like jitting bite code right uh in a node for example where you have a very hot contract that is called millions of times. you can instead of interpreting

it every time you compile it once at the beginning when your node starts up and then you um you just execute the native code which is much faster. Um and I'm sure like this will be much easier when you have the full source code available of course for the contract. Um uh the trick the tricky thing there is making sure that the semantics are the same. Um you basically have to reimplement the EVM stack uh natively. Um, and I don't really know if that's um like a um good thing to do for tests since I mean I'm sure they they run already pretty fast since it's just uh everything is done in memory uh in the AVM. Um

uh but yeah, that's defin definite a possibility. >> Awesome. Um that will be it. Thank