Support for Compiling Solidity to LLVM IR to Facilitate zkVM Adoption?

[YancyParker]

Abstract

The current Solidity compiler (solc) primarily targets the Ethereum Virtual Machine (EVM) bytecode. However, there is an increasing interest in using Solidity for other platforms and in other contexts where EVM is not the execution environment. One way to enable this broader use of Solidity is by supporting the compilation of Solidity code to LLVM Intermediate Representation (IR).

Motivation

If Solidity could be compiled to LLVM IR, it would greatly benefit the development of zero-knowledge virtual machine (zkVM) projects. Many zkVM projects currently need to design their own high-level languages to interface with their custom VMs. By enabling Solidity to compile to LLVM IR, these projects could instead adopt Solidity as their high-level language, leveraging its existing ecosystem and developer familiarity. This would streamline the development process for zkVM projects and potentially accelerate the adoption of zero-knowledge technologies.

Specification

Parsing and AST Generation: The existing parsing and abstract syntax tree (AST) generation phases of the compiler would remain largely unchanged.

Intermediate Representation: The compiler would need to be extended to convert the Solidity AST into LLVM IR. This would involve mapping Solidity constructs to their LLVM counterparts and handling Solidity-specific features like storage layout and contract inheritance.

Code Generation: The final code generation phase would output LLVM IR instead of EVM bytecode. This would involve interfacing with the LLVM libraries to generate and optimize the IR.

Backwards Compatibility

Adding LLVM IR as a target should not introduce any backwards incompatibilities, as it would be an additional option rather than a replacement for existing functionality. However, there may be challenges in ensuring that the semantics of Solidity are preserved accurately in the LLVM IR, particularly for features that are specific to the EVM execution model.

[mw2000]

This is a pretty interesting proposal. Mainly because this extends solidity as a language, and separates it from EVM, allowing it to thrive on its own. My only pushback for this is:

• Most solidity libraries are built with EVM-specific features in mind.
• Much of dev tooling that exists for solidity is EVM-specific
• zkVMs are better served porting to Rust, or a custom variation of Rust, that arguably has similar or better tooling

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.