📝 Draft Project Idea: Alternative Solidity Compiler

[smartcontracts]

What is a Draft Project Idea?

A Draft Project Idea is a concept for a project within the Optimism ecosystem that is generally considered valuable but has not yet been fleshed out into a clearly defined product. Draft Project Ideas may be converted into Ecosystem Project Ideas as they are explored further and more thoroughly specified.

---

Summary

Solidity is the primary programming language for most EVM-based applications. It currently has a single compiler, solc. Just like client diversity is important for the robustness of Ethereum, compiler diversity is important for the robustness of applications built on top of Ethereum. By introducing new compilers we can eliminate single points of failure and create competition that improves the Solidity experience for everyone.

Impact

• Alternative compilers remove the single point of failure in the current codebase
• Alternative compilers can improve the compilation process and the development experience
• Alternative compilers may be able to make optimizations that the current Solidity compiler cannot.

Resources

• Solidity
• solc

[0xJepsen]

This is a big effort, i think would be really sweet to build a better intermediary representation (IR) first rather than a whole new language + compile. A strong IR imo would be the first step towards a better compile ecosystem for the EVM

[David-Web3]

I really like this idea, just have following ideas:

• The frontend, I think the baseline is to be fully compatible with solidity language, so maybe it is good idea to reuse the lexer/parser of solc and to keep sync with it? Moreover, is it possible to have more language support so that maybe OP stack could have more wider ecosystem by having different languages running on top of it in long term?
• The backend, especially the IR, I totally agree with @0xJepsen, it must be expressive enough to support different language features and also be simple enough for introducing advanced optimizations. Considering L2 scenario, I would say that compiler optimizations might have great value to help the execution engine of OP be competitive enough at performance. Moreover, LLVM IR might be a good candidate here as it has been used commonly as a IR and lot of optimizations has been implemented, although I am not sure whether it is too complicated / flexible for EVM bytecodes from the security and functionality perspective.
• The toolchain, by having a compiler, it is not hard to introduce other tools such as debugger, tracer, static analyzer, instrumentation tools, which I think is also important for helping OP to attract more developers and hence enlarge the ecosystem.

I am really interested in this topic and I would like to learn more if there is any discussion.

[jommi9]

We have also been internally discussing this idea at EQ Labs. We first though of introducing other languages like @David-Web3 mentioned, but maybe this specific project idea is not about that?

[MeerKatDev]

Maybe this RFP should be about joining forces with this project?

[David-Web3]

Maybe this RFP should be about joining forces with this project?

IMHO, solang is a good compiler trying to have solidity running on different blockchains where EVM is not exist. It translates solidity to LLVM IR (or wasm) and then leverage the LLVM backend to generate binary for different environment.

Another method is to translate EVM opcodes to LLVM IR, and this way may be good at supporting all languages that targets to run on EVM.

also there must be other chain-specific considerations for supporting EVM language to run on non-EVM platform, as there is huge difference for account / storage/ memory accessing design and implementations.

[pewulfman]

Hi all, I totally new to the Optimism project and community. I have been working on the Ligo Languagecompiler for the the past 4 year, internal + toolings, for the Tezos Foundation Some former collegues and I would definitly be interested develloping a new solidity compiler.

How can I know more about this project ? @smartcontracts Is there someone at the Foundation I can contact about this ?

Best

[pewulfman]

This is a big effort, i think would be really sweet to build a better intermediary representation (IR) first rather than a whole new language + compile. A strong IR imo would be the first step towards a better compile ecosystem for the EVM

You don't have to change the syntax, but if you change an AST (IR) you still need to adapt the part before and after. In your opinion, what should be improve regarding the current IR ? I skimed through the code, the sol AST looks fine to me, except it's a CST. The Yul AST, well upon closer looks, it as no multiplicative types and suprissingly few litteral and no collections...

Just trying to understand, I am not very familiar with solidity yet