In this article, we dive into the key differences between developing on Ethereum and Solana, guiding you through how to build on Solana. Coming from Ethereum, Solana will look and feel much different and have a diverse toolset to use as you develop. This article will arm you with all the tools necessary to build on Solana from an Ethereum background.
Account Model
When developing on Solana, the most significant difference will run into is the account model design. It is helpful to understand why Solana’s account model was designed differently. Unlike Ethereum, Solana is designed to take advantage of the multiple cores in high-end machines. There is a trend in computing resources where the amount of available cores increases over time and becomes cheaper for people to purchase. Considering this, the account model is designed to leverage multiple cores, creating a system that parallelizes the transactions with each other. This parallelization creates further optimizations, such as local fee markets and faster throughput, which we will explore later.
So what is meant by the “account model”? On Solana, accounts are like objects containing some arbitrary data and specific rules for modification. Everything is an account on Solana, including smart contracts. Like Ethereum, each account has an address identifier to help locate an account. However, unlike Ethereum, where each smart contract is an account with the execution logic and storage tied together, Solana’s smart contracts are entirely stateless.
Smart contracts on Solana carry no state of their own and must have the state passed to them to execute on. To illustrate this, let’s take a look at two smart contracts for a counter, one in Solidity on Ethereum and one using Rust on Solana.
Ethereum Counter Smart Contract
contract Counter {
int private count = 0;
function incrementCounter() public {
count += 1;
}
function getCount() public constant returns (int) {
return count;
}
}Solana Counter Program
#[program]
pub mod counter_anchor {
use super::*;
pub fn initialize_counter(_ctx: Context<InitializeCounter>) -> Result<()> {
Ok(())
}
pub fn increment(ctx: Context<Increment>) -> Result<()> {
ctx.accounts.counter.count = ctx.accounts.counter.count.checked_add(1).unwrap();
Ok(())
}
}
#[derive(Accounts)]
pub struct InitializeCounter<'info> {
#[account(mut)]
pub payer: Signer<'info>,
#[account(
init,
space = 8 + Counter::INIT_SPACE,
payer = payer
)]
pub counter: Account<'info, Counter>,
pub system_program: Program<'info, System>,
}
#[derive(Accounts)]
pub struct Increment<'info> {
#[account(mut)]
pub counter: Account<'info, Counter>,
}
#[account]
#[derive(InitSpace)]
pub struct Counter {
count: u64,
}While in Solidity, you have int private count = 0;, you have a struct within the Rust smart contract stating initialize_counter. This initial counter creates an account with a count of 0, which you then can pass this account to increment to add to the count. This is not to have state within the smart contract itself.
There are separate accounts that store the data outside of the program. To execute the logic in a program, you would pass the account you want to perform on. In the case of this counter program, you pass a counter account to the program when calling the increment function, and the program will increment the value in the counter account.
What are the benefits of the Solana Account Model?
One of the most significant benefits of the Solana Account Model is program reusability.
Take ERC20 for example. ERC20 defines an interface specification on Ethereum for tokens. Every time someone wants to make a new token, the developer will have to redeploy the ERC20 smart contract onto Ethereum with its specified values, incurring the high cost of the redeployment.
Solana is different. You do not have to redeploy another smart contract onto the blockchain when creating new tokens. Instead, you create a new account, known as the mint account, off of the Solana Token Program, where the account defines a set of values to give the number of tokens in circulation, decimal points, who can mint more tokens, and who can freeze tokens.
You do not need to write any Rust or smart contracts to deploy a new token on Solana. Send a transaction to the Token Program to create a new token in your language of choice, and the token will then appear in your wallet. With the Solana Program Library CLI, you can do this in a single command:
$ spl-token create-tokenLocal Fee Markets
Another fortunate side effect of having the Solana account model is the ability to model fees based on state contention. As mentioned earlier, transactions can be executed in parallel. However, they are only executed in parallel based on what accounts are being written to. For example, let's say there is a popular NFT mint going on Solana. Typically, this popularity would increase the prices for everyone using the chain, but instead, everyone not participating in the NFT mint is unaffected.
As the name suggests, fee markets are local per account. If you're sending a transfer of USDC to someone while everyone else is minting the hottest new NFT, you will be unaffected and continue paying the low fee you're used to on Solana. This works with any application in Solana, avoiding the common global fee market you're used to on Ethereum while lowering everyone's cost.
Solanaにおける手数料の仕組みは？
Solanaの手数料はいくつかのカテゴリに分けられます：ベース手数料、優先手数料、そしてrentです。
ベース手数料はトランザクション内の署名数に基づいて計算されます。各署名のコストは5000 lamport（0.000000001 SOL = 1 lamport）です。トランザクションに5つの署名が必要な場合、ベース手数料は25000 lamportになります。このベース手数料は、より計算負荷の高い処理のひとつであるクラスターの署名検証に対する経済的な負荷分散として機能します。ベース手数料の半分はバーンされ、残りの半分はvalidatorへの報酬となります。
優先手数料は任意の手数料で、同時に実行される他のトランザクションより優先順位を高めるためにトランザクションに追加できます。優先手数料はトランザクションで使用されるコンピュートユニット数に基づいて計算されます。コンピュートユニットはEthereumのGasに相当し、トランザクションに必要なコンピューティングリソースのシンプルな指標です。Ethereumと同様に、トランザクションの優先度はコンピュートユニット価格とコンピュートユニット使用量の積で計算されます（優先手数料 = コンピュートユニット × コンピュートユニット価格）。ベース手数料と同様に、優先手数料の半分はバーンされ、残りの半分はvalidatorへの報酬となります。
最後の手数料であるrentは、手数料というよりもデポジットに近いものです。ネットワーク上にアカウントを作成したり領域を割り当てたりする際には、ネットワークがアカウントを維持するために一定量のSOLをデポジットする必要があります。rentはネットワーク上に保存されるバイト数に基づいて計算され、領域の割り当てには追加のベース手数料が発生します。重要な点として、rent手数料は消滅するものではありません。アカウントを閉鎖し、割り当てられた領域をクラスターに返還することで回収できます。
Solanaにおけるトランザクションの仕組みは？
トランザクションの実行時にそれぞれの手数料が支払われるため、トランザクションの仕組みを理解しておくことが重要です。トランザクションは以下の3つの要素で構成されます：
- 1つ以上のinstructions
- 読み取りまたは書き込みを行うアカウントの配列
- 1つ以上の署名
- 最近のブロックハッシュまたはノンス
instruction はSolana上で最小の実行ロジックです。instructionsはSolanaのグローバル状態を更新するための呼び出しです。instructionsはSolanaランタイムを呼び出して状態を更新するプログラムを実行します（例：Token Programを呼び出して自分のアカウントから別のアカウントにトークンを転送する）。instructionはEthereumスマートコントラクトの関数呼び出しと同様に考えることができます。
EthereumとSolanaの大きな違いのひとつは、instructionsの数に起因する1つのトランザクション内での関数呼び出しの数です。1つのトランザクションに複数のinstructionsを含められることは、開発者にとって大きなメリットです。単一のトランザクション内で関数を連鎖させるためのカスタムスマートコントラクトを作成する必要がないからです。各instructionは個別の関数呼び出しとして、トランザクション内で順番に実行されます。トランザクションはアトミックであるため、いずれかのinstructionが失敗した場合、トランザクション全体が失敗し、支払うのはトランザクション手数料のみです。これはEthereumで正しいスリッページを設定しなかったためにトランザクションが失敗するのと似ています。
もう一つの重要な違いは、トランザクションにインクリメンタルなノンスではなく最近のブロックハッシュを使用する点です。ウォレットがトランザクションを作成する際、有効なトランザクションを生成するためにクラスターから最近のブロックハッシュが取得されます。この最近のブロックハッシュは、取得されてから150ブロック以内のみトランザクションを有効にします。これにより、古いトランザクション署名が後日実行されることを防ぎます。
What are the limitations of transactions on Solana?
Like Ethereum gas limitations, there are specific compute unit limitations on transactions for Solana. Each limitation can be found below:
| Ethereum | Solana | |
| Single Transaction Compute Cap | 30,000,000 | 1,400,000 Compute Units |
| Block Compute Cap | 30,000,000 Gas | 48,000,000 Compute Units |
Solana has a few additional caps placed on transactions. Each account referenced may be at most 12,000,000 compute units used per block. This cap prevents people from write-locking a single account too many times in a single block, further preventing the local fee markets from being overrun by one account.
Another limit on transactions is the depth of instruction calls you can make in a single instruction. This limit is currently set to 4, meaning you can only call instructions at a depth of 4 before the transaction would revert. This makes re-entrancy issues nonexistent on Solana compared to something you’d have to worry about on Ethereum.
Where is the Mempool?
Unlike Ethereum, Mempools don’t exist on Solana. Solana validators forward transactions to up to the following four leaders on the leader schedule. While Solana doesn’t have a mempool, it still has priority fees to help order transactions. Not having a mempool forces the transactions to hop from leader to leader until blockhash expiration, but it reduces the overhead of gossip communicating the mempool across the cluster.
Where can I find smart contract code?
In the EVM world, most are familiar with finding smart contract code on Etherscan when viewing the smart contract address. However, viewing smart contract code on an explorer in the Solana ecosystem is relatively new and needs to be established compared to EVM standards. At the time of writing, Solana.fm is the only explorer that supports viewing smart contract code based on verifiable builds.
You can find the smart contract code by visiting a smart contract address the explorer. For example, going to the Phoenix smart contract, you can find the smart contract’s code under the verification tab. From here, you can analyze the code and understand if the smart contract is something you want to interact with.
What are the differences in the developer environment?
Programming languages
EVM primarily uses Solidity to write smart contracts, while Solana uses Rust. There is a framework called the Anchor framework that allows you to build in Rust with many of the tools you are familiar with from EVM, but it is still Rust. If you want to stick with Solidity while building on Solana, a project named Neon enables using Solidity. Neon comes with many of the tools you are familiar with, such as using Foundry or Hardhat during development. Using Neon may get you up and running faster, building on Solana, but you would need more composability outside of the Neon ecosystem with other Solana projects.
Like Ethereum, on the client side, you can find comparable SDKs for all your favorite programming languages on Solana.
| Language | SDK |
| Javascript | solana/web3.js |
| Rust | solana_sdk |
| Python | solana-py |
| Java | solanaj |
| C++ | solcpp |
| C# | Solnet |
| GoLang | solana-go |
Where are the tools I’m familiar with from EVM?
As you migrate from EVM to building on Solana, you may be looking for the tools you are familiar with. Currently, the Solana ecosystem does not have tooling equal to Foundry but has a decent amount of other equivalents to the tools you are used to.
| Tool | Solana Equivalent |
HardHat | Solana Test Validator |
Brownie | Program-test, BankRun.js |
| Ethers, Wagmi | @solana/web.js |
| Remix | Solana Playground |
| ABI | Anchor Framework's IDL |
| Etherscan | SolanaFM, XRay |
| scaffold-eth | create-solana-dapp |
スマートコントラクト開発の違いは何ですか?
Solana上でプログラムを構築する際、またはEthereumスマートコントラクトを移行する際に注意すべき点がいくつかあります。
例えば、Ethereumスマートコントラクトで使い慣れているマッピングのような機能を探している場合、このタイプはSolana上には直接存在しません。代わりに、プログラム派生アドレス(略してPDA)を使用します。マッピングと同様に、Program Derived Addressを使えば、キーやアカウントからオンチェーンに保存された値へのマッピングを作成することができます。ただし、マッピングの方法はEthereumとは異なります。
例えば、ユーザーアカウントをそれぞれの残高にオンチェーンでマッピングしたいとします。Solidityでは、以下のようなコードを記述します:
mapping(address => uint) public balances;With program derived addresses, you instead have to do the following:
Client:
const [BALANCE_PDA] = await anchor.web3.PublicKey.findProgramAddress(
[Buffer.from("BALANCE"), pg.wallet.publicKey.toBuffer()],
pg.program.programId
);Program:
#[derive(Accounts)]
#[instruction(restaurant: String)]
pub struct BalanceAccounts<'info> {
#[account(
init_if_needed,
payer = signer,
space = 500,
seeds = [balance.as_bytes().as_ref(), signer.key().as_ref()],
bump
)]
pub balance: Account<'info, BalanceAccount>,
#[account(mut)]
pub signer: Signer<'info>,
pub system_program: Program<'info, System>,
}
#[account]
pub struct BalanceAccount {
pub balance: u8
}The map's key is derived from the combination of the "balance" string and the signer's public key, while the program derived address provides the location to look up the map's value. Program derived addresses have more functionality than just providing a map; we can learn about that later.
In Solidity, the ability to upgrade your smart contracts using proxy contracts has become the norm. On Solana, programs are default upgradable without any special work involved. Each smart contract can be upgraded by a CLI command solana program deploy <program_filepath. While programs are default upgradable, you can still demote their status to immutable with solana program set-upgrade-authority <program_address> --final. Once immutable, the program will be flagged as not upgradable on the explorers.
A common thing you do when writing a solidity smart contract is check for either msg.sender or tx.origin. There isn't an equivalent on Solana because each transaction can have multiple signers. Also the person sending the transaction is not necessarily the one who signed the transaction because you have someone else pay for your transactions.
Let’s take a look at this basic Solana Program:
#[program]
pub mod gettingSigners {
use super::*;
pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
let the_signer: &mut Signer = &mut ctx.accounts.the_signer;
msg!("The signer: {:?}", *the_signer.key);
Ok(())
}
}
#[derive(Accounts)]
pub struct Initialize<'info> {
#[account(mut)]
pub the_signer: Signer<'info>,
}This will output a signer of the transaction as part of your program logs. As mentioned before, you can have multiple signers:
#[program]
pub mod gettingSigners {
use super::*;
pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
let the_signer: &mut Signer = &mut ctx.accounts.first_signer;
msg!("The signer: {:?}", *the_signer.key);
Ok(())
}
}
#[derive(Accounts)]
pub struct Initialize<'info> {
#[account(mut)]
pub first_signer: Signer<'info>,
pub second_signer: Signer<'info>,
}The above example shows that this specific program has multiple signers, first_signer and second_signer. We cannot necessarily tell which one is the payer, but we know both have signed the transaction. You can learn more about getting signers on Rareskills.
How do I build my EVM project on Solana?
Let’s take a simple project built in Solidity and go through the process of building the same project on Solana. A common first project you run into is a voting project. The Solidity smart contract would look like this:
pragma solidity ^0.6.4;
contract Voting {
mapping (bytes32 => uint256) public votesReceived;
bytes32[] public candidateList;
constructor(bytes32[] memory candidateNames) public {
candidateList = candidateNames;
}
function voteForCandidate(bytes32 candidate) public {
require(validCandidate(candidate));
votesReceived[candidate] += 1;
}
function totalVotesFor(bytes32 candidate) view public returns (uint256) {
require(validCandidate(candidate));
return votesReceived[candidate];
}
function validCandidate(bytes32 candidate) view public returns (bool) {
for(uint i = 0; i < candidateList.length; i++) {
if (candidateList[i] == candidate) {
return true;
}
}
return false;
}
}We quickly noticed a few things that were not available in Solana programs. View functions and mapping need to be done differently. Let’s start building this program on Solana!
Let’s create our very basic Solana program shell:
use anchor_lang::prelude::*;
declare_id!("6voY4gV7kzuGr4hE2xjZnkdagFGNhEe8WonZ8UtdPWig");
#[program]
pub mod voting {
use super::*;
pub fn init_candidate(ctx: Context<InitializeCandidate>) -> Result<()> {
Ok(())
}
pub fn vote_for_candidate(ctx: Context<VoteCandidate>) -> Result<()> {
Ok(())
}
}
#[derive(Accounts)]
pub struct InitializeCandidate {}
#[derive(Accounts)]
pub struct VoteCandidate {}We have two functions in our voting program, init_candidate and vote_for_candidate. The init_candidate function maps directly to our constructor in the Solidity smart contract, while vote_for_candidate maps one-to-one with voteForCandidate in Solidity.
One problem with init_candidate today is that it can be called by anyone permissionless, unlike the constructor in Solidity only being called by the contract deployer. To solve this, we will employ a similar feature to onlyOwner from Solidity. We set a specific address on the Solana program that is the only one that can execute the instruction.
Let’s say our publicKey is 8os8PKYmeVjU1mmwHZZNTEv5hpBXi5VvEKGzykduZAik. By adding a reference to this publicKey in the Solana program and requiring the signer to match, we effectively emulate both onlyOwner and the constructor.
use anchor_lang::prelude::*;
declare_id!("6voY4gV7kzuGr4hE2xjZnkdagFGNhEe8WonZ8UtdPWig");
const OWNER: &str = "8os8PKYmeVjU1mmwHZZNTEv5hpBXi5VvEKGzykduZAik";
#[program]
pub mod voting {
use super::*;
#[access_control(check(&ctx))]
pub fn init_candidate(ctx: Context<InitializeCandidate>) -> Result<()> {
Ok(())
}
pub fn vote_for_candidate(ctx: Context<VoteCandidate>) -> Result<()> {
Ok(())
}
}
#[derive(Accounts)]
pub struct InitializeCandidate<'info> {
#[account(mut)]
pub payer: Signer<'info>,
}
#[derive(Accounts)]
pub struct VoteCandidate {}
fn check(ctx: &Context<InitializeCandidate>) -> Result<()> {
// Check if signer === owner
require_keys_eq!(
ctx.accounts.payer.key(),
OWNER.parse::<Pubkey>().unwrap(),
OnlyOwnerError::NotOwner
);
Ok(())
}
#[error_code]
pub enum OnlyOwnerError {
#[msg("Only owner can call this function!")]
NotOwner,
}We added an access control function check that will check if the signer of init_candidate matches the address listed in the smart contract. If the signer does not match, the OnlyOwnerError will be thrown, and the transaction will fail.
Let’s move on to the next bit in the Solidity smart contract, candidateList and votesReceived. While you can use a Vec in a Solana program similar to bytes32[], managing the payments for changing the size can be a bit of a hassle. Instead, we will utilize Program Derived Addresses given specific candidate name, with the value found at that address being the votesReceived by the candidate.
To use Program Derived Accounts in a Solana Program, you use seeds and bump in the account. First, let’s create the account to track votesReceived.
#[account]
#[derive(InitSpace)]
pub struct Candidate {
pub votes_received: u8,
}#[account] denotes the struct as a Solana account, while the #[derive(InitSpace)] is a useful macro for auto-calculating the space required to allocate for Candidate. The votes_received can hold a count just like votesReceived in the Solidity smart contract.
Expanding the InitializeCandidate and VoteCandidate, we get the following:
#[derive(Accounts)]
#[instruction(_candidate_Name: String)]
pub struct InitializeCandidate<'info> {
#[account(mut)]
pub payer: Signer<'info>,
#[account(
init,
space = 8 + Candidate::INIT_SPACE,
payer = payer,
seeds = [_candidate_Name.as_bytes().as_ref()],
bump,
)]
pub candidate: Account<'info, Candidate>,
pub system_program: Program<'info, System>,
}
#[derive(Accounts)]
#[instruction(_candidate_Name: String)]
pub struct VoteCandidate<'info> {
#[account(
mut,
seeds = [_candidate_Name.as_bytes().as_ref()],
bump,
)]
pub candidate: Account<'info, Candidate>,
}Wow, that’s a lot of new code in the accounts. Let’s unpack it.
First you’ll notice #[instruction(_candidate_Name: String)]. This means the context for InitializeCandidate expects a string _candidate_name to be passed into the instruction. We can see later this is used in seeds = [_candidate_name.as_bytes().as_ref()]. This means that the seed of the PDA will be _candidate_Name, and the value stored at the PDA will be the candidate’s votes_received.
Next you may have some questions on space = 8 + Candidate::INIT_SPACE. The Candidate::INIT_SPACE is how big the Candidate account is + 8, 8 being the bytes added at the beginning of Anchor framework accounts for security checks. pub system_program: Program<'info, System>, is required when you’re creating an account, which is denoted by init. This means that any time an instruction using the InitializeCandidate context is called, the instruction will try to create a candidate account.
Now let’s add the business logic found in voteForCandidate from the Solidity smart contract.
pub fn vote_for_candidate(ctx: Context<VoteCandidate>, _candidate_name: String) -> Result<()> {
ctx.accounts.candidate.votes_received += 1;
Ok(())
}Here we take an additional parameter discussed earlier, _candidate_name . This will help match to the exact account we’re referencing for the candidate. We then increment the votes by 1 for that candidate.
That’s all we need to complete on the Solana program side, with the final Solana program looking like this:
use anchor_lang::prelude::*;
declare_id!("6voY4gV7kzuGr4hE2xjZnkdagFGNhEe8WonZ8UtdPWig");
const OWNER: &str = "8os8PKYmeVjU1mmwHZZNTEv5hpBXi5VvEKGzykduZAik";
#[program]
pub mod voting {
use super::*;
#[access_control(check(&ctx))]
pub fn init_candidate(ctx: Context<InitializeCandidate>, _candidate_name: String) -> Result<()> {
Ok(())
}
pub fn vote_for_candidate(ctx: Context<VoteCandidate>, _candidate_name: String) -> Result<()> {
ctx.accounts.candidate.votes_received += 1;
Ok(())
}
}
#[derive(Accounts)]
#[instruction(_candidate_name: String)]
pub struct InitializeCandidate<'info> {
#[account(mut)]
pub payer: Signer<'info>,
#[account(
init,
space = 8 + Candidate::INIT_SPACE,
payer = payer,
seeds = [_candidate_name.as_bytes().as_ref()],
bump,
)]
pub candidate: Account<'info, Candidate>,
pub system_program: Program<'info, System>,
}
#[derive(Accounts)]
#[instruction(_candidate_name: String)]
pub struct VoteCandidate<'info> {
#[account(
mut,
seeds = [_candidate_name.as_bytes().as_ref()],
bump,
)]
pub candidate: Account<'info, Candidate>,
}
#[account]
#[derive(InitSpace)]
pub struct Candidate {
pub votes_received: u8,
}
fn check(ctx: &Context<InitializeCandidate>) -> Result<()> {
// Check if signer === owner
require_keys_eq!(
ctx.accounts.payer.key(),
OWNER.parse::<Pubkey>().unwrap(),
OnlyOwnerError::NotOwner
);
Ok(())
}
#[error_code]
pub enum OnlyOwnerError {
#[msg("Only owner can call this function!")]
NotOwner,
}Now you might think, “But wait, what about totalVotesFor and validCandidate from the Solidity smart contract?” validCandidate is already accounted for because vote_for_candidate will fail if you pass an account that does not exist. totalVotesFor can be done client-side with Typescript and does not need to exist within the Solana program.
Now that we’ve built the Solana program, let’s interact with it.
Loading the program into Solana Playground, I can build and deploy it to Devnet. Once you build and deploy the program, you’ll find that you can run tests with the instructions on the test tab.
This is akin to using Remix to test your Solidity smart contract. Opening up initCandidate and entering the name John Smith as the candidate name, we now have to generate the PDA for John Smith. Click on the candidate account finder and select From seed. Select the custom String and input John Smith, and finally click generate. Congratulations, you just found your PDA for John Smith! Now hit Test to execute the instruction.
If all is successful, you should see the following program logs on the test transaction.
Now let’s vote for John Smith ! Opening up the
voteForCandidate instruction, type in John Smith and
generate the same PDA again. Hit Test to vote for your first
candidate!
Now that you’ve voted, how can you check how many votes the candidate has?
Head on over to Candidate under Accounts on the test
tab and hit the button Fetch All. This will grab all valid
candidates and their votes. From there you’ll receive an array of the
candidates, their account addresses, and their votes.
Congratulations! You just took the voting Solidity smart contract and translated into a Solana program. You can use a lot of the same techniques on other Solidity smart contracts to build what you have on EVM on Solana. If you’re interested to learn more about Solana, check out the documentation and get started today.
