5 min read
Overview
The Solana developer ecosystem continues to evolve. Recently, two projects have emerged that allow developers to write smart contracts in Solidity and deploy them to Solana. These projects are Solang and Neon. This guide will provide an overview of these two projects, compare and contrast them, and show you where to go to get building.
What You Will Need
- General knowledge of Solana will be helpful but is not required (Fundamentals Reference Guide)
- Experience with Solidity will be helpful but is not required (Guide: How to Write a Smart Contract with Solidity)
Solana Basics
Before we jump into Solang and Neon, let's level-set on a few features of Solana that will be helpful to understand (if you are looking for a deeper dive into Solana, check out our Reference Guide).
- Most elements on Solana are Accounts including user wallets, programs, data logs, and even system programs. Accounts are like files in a traditional operating system--they can be created, modified, and deleted. They can hold data or process data.
- Smart contracts are called "programs" in Solana. Programs are accounts that store the executable code that processes transactions and updates the state of the blockchain.
- Solana programs are stateless (compared to EVM contracts, which are stateful). This means that Solana programs do not store state. Instead, Solana programs store state in accounts.
- Solana accounts can store up to 10 MB of data.
- Solana programs are upgradable.
- Solana account addresses use a 32-byte public key (compared to Ethereum's 20-byte public key).
Why Build on Solana?
Solana offers a number of benefits to developers, including:
- low gas fees (< $0.01 per transaction)
- high throughput (consistently serves > 3,000 transactions per second)
- fast confirmations (~400ms)
- access to a growing ecosystem of NFT & DeFi protocols and tools through composability
By building using Solang or Neon, you can enjoy the benefits of Solana's speed, cost, and userbase while leveraging your existing knowledge of Solidity.
Solang and Neon
Because state and account architecture is different in Solana than in Ethereum, it is not possible to simply deploy an Ethereum smart contract to Solana. Solang and Neon are two new tools that abstract much of Solana's differences with Ethereum. This allows developers to write smart contracts in Solidity and deploy them to Solana.
At a high level, Solang is a Solidity compiler that compiles Solidity smart contracts to Solana programs. Neon is an EVM implementation (installed in a Solana Account) that runs on Solana and can interact with the Solana blockchain. Since they are quite different, let's look at each one.
What is Solang?
Solang is a Solidity compiler that compiles Solidity code into Solana programs. Most Solana development is done in Rust and compiled to be useable by the Solana runtime in bytecode form. Solang is an alternative approach that uses the LLVM compiler framework to compile Solidity code into Solana Solana Bytecode Format contract code. This means that deployed programs are directly accessible to the Solana runtime.
Key Features:
- Solang supports Solana's System Program and SPL Token Program
- Clients can interact with programs using Solana-Web3.js just like they would any other Solana program
- Solang requires development using Solang Compiler or Anchor, a common framework used for Solana development
What is Neon EVM?
Neon is an Ethereum Virtual Machine deployed in a Solana executable account (the entire EVM execution layer in Solana smart contract). This is achievable because the EVM is only 2MB, and Solana accounts can store up to 10MB of executable data. Neon is not an L2 solution or a sidechain--Neon is a full EVM implementation that runs on Solana. An analogy for Neon might be WSL, which allows you to run Linux on Windows while still using Windows applications. Here's a simplified diagram of how Neon works:
(Source: Neon Docs)
To enable an EVM-like experience on Solana, Neon abstracts many nuances of Solana accounts and transactions to users. This means a single Neon transaction can generate and effectively wrap many Solana transactions. For example, a Neon transaction that calls a smart contract function might generate a Solana transaction to create a new account, a Solana transaction to transfer tokens, and a Solana transaction to call the smart contract function. You can see this in action in the Neon Explorer transaction browser:
Key Features:
- Neon provides an ETH-like experience for users and developers on Solana, meaning both can use their existing tech stack (e.g., Solidity, Hardhat, etc.), wallets (e.g., Metamask), etc.
- Users can utilize ERC20 tokens (The Native token, NEON, can be used to pay for gas fees--get testnet NEON here)
- Neon supports EVM JSON-RPC calls (e.g., ethers.js)
- ETH L1 compatible (code should be portable from ETH as is)
Solang vs. Neon
Let's take a look at Solang and Neon side by side:
| Attribute | Solang | Neon |
|---|---|---|
| Explorer | Any Solana Explorer | Neon Explorer |
| Supported Tokens | SPL Tokens | ERC20 Tokens & Wrapped SPL Tokens |
| Dev Tooling | Solang, Anchor | Solidity Tools (e.g., Hardhat) |
| Wallet | Solana Wallets (e.g. Phantom) | EVM Wallets (e.g. Metamask) |
| Gas Token | SOL | NEON |
| Client Tooling | Solana-Web3.js | Ethers.js |
| Account Address | 32-byte public key | 20-byte public key |
| Settlement Layer | Solana | Solana |
| Settlement Speed | ~400ms | ~400ms |
Security
It is important to remember that Solang and Neon are both new tools. While they are both open source and have been audited, they are still young. As such, it is important to be aware of the risks of using these tools. When deploying Solidity smart contracts to Solana using Solang and Neon, it's essential to recognize a few areas of consideration (Note: this list is not exhaustive. If you are planning to deploy a contract to production, please consult with a security expert.).
- Compiler and Implementation Integrity: Be mindful of how your Solidity code compiles and translates to Solana's architecture, especially when using Solang's compiler or Neon's EVM implementation.
- Compatibility with Existing Tools: Neon's compatibility with traditional Ethereum tools like Metamask might have nuances that should be considered in the development process.
- Smart Contract Best Practices: As with any blockchain, adhering to the best practices in smart contract security remains vital.
Both Solang and Neon have been audited and are open source, reflecting a community commitment to security. Keeping an eye on updates from the developers, reviewing the audit details, and engaging with the community can help developers leverage these tools while being aware of the associated risks. Links to the audit reports and further information can be found below:
Building with Solidity on Solana
Get Started with Solang
To start with Solang, check out our Guide: How to Create a Solana Program using Solidity and Solang. The guide will walk through initiating a new project with Anchor, using key Solana concepts like Program Derived Addresses and deploying a program to Solana.
Get Started with Neon
Check out Neon's Quick Start Guide here to walk through setting up a Neon project, deploying a smart contract, and interacting with it using Metamask:
So much to learn!
You now have a solid understanding of Solang and Neon and how they can be used to build on Solana. So what are you waiting for? Get out there and start building!
We are still in the early days of seeing what can be done with Solidity on Solana, so we are excited to see what you build. Share what you are up to on our Discord or QuickNode Forum and keep up with our latest updates on Twitter!
We ❤️ Feedback!
Let us know if you have any feedback or requests for new topics. We'd love to hear from you.