Introducing Solar

Smart contracts empower developers to move value across the internet with few lines of code. That is really powerful, however developers are only able to iterate at the speed and safety of their tools. That motivated us in 2021 to build Foundry, the all-in-one toolkit for smart contract developers.

Today, we are excited to announce Solar ☀️, and our vision for a blazing-fast, modular, and contributor-friendly implementation of the Solidity smart contract language, in Rust; licensed Apache/MIT. Solar is built for the future of smart contracts, in a world where developers seek customization, and assume great performance, safety, and developer experience.

Solar is currently just a compiler frontend, and it is able to parse, lex and emit solc-compatible ABI, outperforming solc by >41x when benchmarked on that task against the popular codebase Solady.

We are looking for contributors to help us ship the compiler middle-end optimizers, the backend for generating code for legacy EVM and EVM Object Format, and tooling for ensuring the mission-critical correctness of our generated bytecode.

Solar is built to fix Foundry’s limitations.

We built Foundry in 2021 to empower developers to write idiomatic, safe Solidity code with unparalleled productivity.

Under the hood, Foundry leverages advanced simulation infrastructure to provide extensive test coverage, fuzz testing, interactive debugging, traces and more. Developers loved that, and started porting their entire codebases to be in Solidity, which meant that new problems surfaced!

Over time, we realized that testing no longer was the bottleneck. It was the compiler:

1. Compilation times started getting longer and longer as people wrote more complex smart contracts.
2. Writing tests in Solidity meant that the infamous “Stack Too Deep” error started becoming more and more prevalent.
3. Developers got better at writing Solidity and started observing that the compiler was emitting really gas suboptimal code.
4. Foundry features like forge fmt or other “solc-as-a-library” uses were too slow. The library support is particularly important to us, as we had to hand-roll our own AST visitors and implementations to achieve what we needed.
5. Innovating on the EVM layer is not effective if it cannot be exposed to developers, e.g. with new EOF versions, opcodes, or precompiles.

After a long time of creating workarounds for the above problems, we decided it was time to fix these by writing our own compiler using modern compiler techniques that inspire us from no other codebase than the Rust compiler. Meet Solar ☀️.

Solar is built for the future of smart contracts.

Solar will enable EVM developers to be 10x more productive in their day to day, write safer code via clippy-style lints, and excitingly, be able to write gas efficient-by-default smart contracts without needing to drop to in-line assembly for table-stakes optimizations.

Solar is not intended to support Solidity code pre-0.8. It is meant to be compatible with the Solidity language and we have no plans to diverge. In developing Solar, we will be focused on safety and robustness and differentially testing and verifying the behavior of its bytecode against Solc to ensure correctness. We think this is one of the most critical areas to get right.

Today, Solar is just a frontend that parses and lexes Solidity. Our benchmarks on the compiler’s frontend are very encouraging, albeit early and preliminary: Solar outperforms Solc at emitting ABI for Solady by 41x. We also provide a wide benchmarking suite which compares solar with solang, slang and solc, and we outperform them in all lexing and parsing benchmarks.

You can use Solar as a parsing library as seen in our examples here. We intend to use that in Foundry as our first integration point. Solar can also be used as a CLI compatible with solc’s format: $ solar $(forge re) src/Contract.sol

We built Solar to be easy to extend, so that we can experiment with new bytecode formats, new precompiles, and opcodes, or other features oriented for the future of crypto like interop (e.g. what if the language had async/await or coprocessor support?). We are looking for input on what experiments people would like to see behind unstable flags.

There is still a long way to go, beyond parsing and lexing, into the long journey of generating secure and efficient EVM bytecode.

Solar is early in its roadmap and we are looking for collaborators.

We are releasing Solar today to gather community feedback on our approach. Solar follows a modern compiler architecture which separates the frontend from the backend with an intermediate representation (IR) for optimization and for separating the code generation from the language’s frontend. This allows us to scale development by separating concerns.

Our roadmap can be found on Github, alongside the rest of our code and benchmarks. The frontend is mostly done, and we’re now moving towards the IR and codegen layer. We are excited by existing approaches like Venom or Sonatina and see benefits to standardizing and creating a shared middle layer for EVM languages.

If you’re a great compiler engineer looking to work on Solar, please reach out to georgios@paradigm.xyz or join@ithaca.xyz.