Skip to main content Link Search Menu Expand Document (external link)

Hyperledger Solang Proposal

HIPs/solang.md

HIP Identifier

Hyperledger Solang v0.1.12

Sponsor(s)

Abstract

Solang is a portable compiler for the Solidity language that targets Solana, Substrate (Polkadot), and ewasm. It is written in Rust, and leverages the LLVM infrastructure for the compiler backend.

Context

The Solidity language is the most popular programming language for smart contracts. However, the existing Solidity compiler only targets the Ethereum virtual machine. The Solang project aims to make Solidity available for other blockchains, and focuses on maintaining compatibility with Solc, so that developers can use their existing codebase for blockchains other than Ethereum with minimal modifications.

The purpose of Solang is two-fold: first of all, developers with solidity language knowledge can develop new smart contracts for non-ethereum blockchains in Solidity, so they do not have to learn a new language. Secondly, there is a large amount of existing Solidity contracts available, which can be recompiled for a different blockchain.

Currently, Solang targets the following blockchains:

At the time of writing, these chains are the 2nd, 9th, and 11th by market capitalization according coinmarketcap (the coins are listed by market cap).

Note that public Ethereum does not currently support ewasm, however work for ewasm support on Ethereum is underway.

Any other blockchain that wishes to have Solidity language support is welcome to a new target to the Solang project. The cosmos blockchain grant foundation has said it would support a grant for adding CosmWasm support.

Dependent Projects

None

Motivation

The existing Ethereum Solidity compiler is written in C++ and does not use modern tooling like parser generators or the LLVM infrastructure for code optimization and generation.

A new compiler, written from scratch, like Solang, offers the following advantages:

  • It can target any blockchain, not just Ethereum.
  • It generates efficient code using the world-class LLVM compiler backend.
  • The Solidity language can be extended to support blockchain specific features.
  • The development is streamlined to only a frontend compiler, which deals with parsing, semantic analysis and intermediate code generation.

There is a similar Solidity compiler project, called SOLL but development has stalled on this project. There is also the Ethereum Solidity compiler.

Status

Solang can virtually parse anything Solc can and generate code for the majority of Solidity construcuts. The maintainers are focused on providing full compatibility for Solidity on both Solana and Polkadot blockchains. There is a tentative roadmap available on the repository’s README file.

Improvements in performance and code generation are gradual and the project has mainly attracted Hyperledger mentees to work on such tasks.

Solang would move into incubation, if approved.

Solution

Solang supports Solidity v0.8, the latest language version. With a few minor exceptions, Solang supports all the language constructs that Ethereum Solidity supports.

Solang is a compiler, and does not know anything about building transaction or deploying contracts. The compiler merely outputs the binary contract and the metadata; other blockchain specific tooling is required to interact with the contract on the blockchain.

The compiler has the following stages:

Parser

The parser using an LR(1) parser generator and a hand-written lexer. This component has been spun out into its own rust crate Solang-parser. The parser has been tested against a huge corpus of Solidity test contracts, including the ethereum solidity’s own testsuite, which runs on Solang CI.

This crate is being used by Foundry’s forge fmt command for a rust-based Solidity Code formatter.

SEMA

This is the semantic analysis stage. The parse tree is validated, and diagnostics (errors and warnings) are generated for invalid syntax. The output of this stage is a fully decorated Abstract Syntax Tree (AST) of the source code.

The sema stage is the essential piece of the Solang language server, which powers the Visual Studio Code Solang Solidity Compiler extension. This extension gives squiggly lines for errors and warnings, and information for tokens (e.g. variables) when hovering over them. This was developed under the first Hyperledger Mentorship.

Code generation

This stage transforms the AST into a control flow graph (CFG). Solang uses its own intermediate representation of the code in CFG form. The advantage is that we can do flow analysis passes on a higher level than LLVM can do. For example, accessing state on a blockchain is expensive and we remove redundant state stores or state loads from the generated contract code. Here is an overview of all the passes Solang has.

The 2nd hyperledger mentorship implemented two additional passes for improved code generation.

Emit

The last stage transforms our own intermediate CFG from into LLVM IR. This stage is fairly straightfoward.

Solang is licensed under the Apache-2.0 license.

LLVM Backend

The LLVM backend is used for a selection of optimization passes, and generates the correct code for the target chain to create an in-memory object file. This is then linked using the LLVM linker into the final file.

Testing

There is a mock implementation of the Solana, Substrate, ewasm, that serve to implement runtime tests and assert the correctness of the compiler’s output. There are also integration tests which use the actual chain for end-to-end testing: compile solidity, deploy it to a node of the blockchain (running in a container), and call various contract functions.

Effort and Resources

The aim for Solang is to be a portable compiler which supports multiple blockchains. Therefore hosting it at Hyperledger makes sense, as this is a neutral space where competing vendors collaborate.

Initial funding for Solang provided was through two grants from the Web3 Foundation and another grant from the Solana Foundation.

Currently there are three people working on Solang full time:

Solana Labs:

Parity Tech:

It is expected that the integration with Solana will finish end by the end of 2022, attracting more users and more relevance for the project. As the compatibility with both Parity and Solana matures, the development focus is supposedly shifting to performance improvements and new features to the Solidity language.

The Web3 Foundation funds gitcoin bounties for certain issues. These are small bounties (about 400US$) for small issues.

How To

The source code is hosted on github and the documentation is extensive. There is documentation on how to run Solang on the command line, and blockchain specific instructions for Solana, Substrate, and Burrow.

References

N/A

How does Hyperledger Solang meet the incubation entry considerations?

Codebase

  • Code should exist as open source software in some form. Previous accepted projects have come up through labs (e.g., Cactus, Ursa); while others previously had stand alone governance prior to joining (e.g., Besu).

    Solang has been in Hyperledger Labs since December, 2018. This is where the project started.

  • DCO sign off should exists in the code repository. If not 100% ready, the code must be capable of becoming compliant upon entry (i.e., squash commit).

    Solang has required DCO signoffs since entry into the Labs

Maintainers

  • The project should have multiple maintainers. These maintainers need not be from different companies; however, having maintainers from different companies is seen as a positive sign. Proposals with only one maintainer have been rejected by prior TSCs.

    The maintainers can be found listed in MAINTAINERS.md. Multiple companies are represented in the list.

  • The project should have demonstrable examples of POC/production uses publicly available.

    Solang is being used for multiple Web3 engagements on Polkadot and Solana, none of them public yet. One engagement is aiming for production in the October 2022.

  • The project should have the backing of more than one organization/individuals (i.e., the project proposers should be able to demonstrate significant, long term contribution in codebase).

    There have been commits from at least 23 separate individuals during its lifetime.

Community

  • The TSC is more likely to accept projects that have contributors familiar with open source practices. Participating in existing projects or starting in Hyperledger Labs is a great place to grow this experience.

    **As mentioned previously, Solang has been operating in an open source model since being brought into Hyperledger Labs in 2018. Solang also utilizes all of the Hyperledger community channels for answering questions and hosting meetings. We have a daily public call, use github, and discord.

    We’ve had conversations with Hyperledger Staff about how to leverage their support for further community building, should Solang be accepted into incubation.**

Sponsors

  • Sponsors are advocates for the project. There should be more than one sponsor, and they should be from different organizations. They may or may not be committing resources to the project.

    Multiple sponsors exist for the project as listed at the top of this document, including sponsors who are contributing and using solang.

  • Trademark concerns – project names should not be trademarked by a contributing company or if it is, then the trademark will need to be handed over to Hyperledger. Project names must be approved by the Hyperledger marketing committee

    There is no trademark that we are aware of for solang. We would the project to be called either Hyperledger Solang or we would like the Hyperledger marketing committee to propose a name for the project.

  • Projects do not require a name prior to being submitted.

    Hyperledger Solang for now but we are open to suggestions. The idea behind solang is many languages are called something-lang, golang or clang.

  • Codebase should be Apache 2 licensable, without encumbrances
    • Non-Apache 2 licensed code is possible, but requires Governing board approval (Section 12 subsection d of the Hyperledger Charter)
    • Special examination should be given to copyleft and non-licensed code.
    • Required patent licensing issues have prevented projects from entering Incubation.
    • GPL licensing issues have prevented projects from entering Incubation.

    The source code is Apache 2 licensed.

  • If code does not already have copyright, the code should be modified to include copyright as per Copyright and License Policy prior to being brought into Hyperledger.

    The team is working on adding the copyright information to the files.

Closure

The goal of Solang is to bring the Solidity language to as many blockchains as possible. Writing a production quality compiler is a complex task, so colaboration between blockchains will be hugely beneficial.

The success of the project can be measured by the number of projects that use Solang as a compiler.