Melina Pottenger RBOJ

Making the move from EVM to SVM (Solana) requires understanding several key differences between the virtual machines. This article will walk through several of those differences, including accounts, fees, transactions, smart contracts (programs), and more. It will also explore developer setup including tooling and SDKs. 

By the end, developers will have the knowledge needed to start their Solana journey.

Understanding the Core Differences 

To start, let’s look at the most significant difference between EVM and SVM—the account model design.

Account Model

Unlike Ethereum, Solana was designed to take advantage of multiple cores and support parallel transactions. To achieve this, Solana uses an account model.

An account on Solana is a record in the Solana ledger that either holds data (a data account) or is an executable program (a smart contract or program on Solana). 

Like Ethereum, each account has an address identifier. 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. State must be passed to accounts for them to execute on.

Let’s look at a code example. In the Solidity code below, state is tied to the smart contract with the line int private count = 0.

With Rust (Solana) there is a struct within the smart contract stating initialize_counter. This initial counter creates an account with a count of 0. The account is passed to this counter to increment the count. This keeps state from being kept within the smart contract itself.

With Solana, data is stored in separate accounts outside of the program. To execute the logic in a program, pass the account to be performed on. 

In the case of this counter program, pass a counter account to the program when calling the increment function, and the program then increments the value in the counter account.

Benefits of the Account Model Design

One of the primary benefits of this account model is program reusability. 

With the ERC20 interface on Ethereum, every time a developer creates a new token, they must redeploy the ERC20 smart contract to Ethereum with its specified values. This redeployment incurs a high cost.

But with Solana, it’s not necessary to create and deploy a new smart contract in order to create a new token. Instead, create a new account, known as the mint account, using the Solana Token Program, passing details such as number of tokens, decimal points, who can mint, and more.

And this can be done by simply sending a transaction to the Token Program. Using the Solana Program Library CLI, for example, it’s just a single command:

Local Fee Markets

Another benefit of the account model is that fee markets are local per account. 

On Ethereum, fee markets are global. If an NFT collection goes viral and everyone is minting—fees go up for everyone. But on Solana, since fee markets are local per account, only people minting that NFT collection pay the elevated fees. Users not participating are unaffected.

Fees

Let’s dive deeper into fees. On Solana, fees are broken into three categories: base fee, priority fee, and rent. Let’s look at each.

The base fee is calculated based on the number of signatures in a transaction. Each signature costs 5000 lamports (0.000000001 sol = 1 lamport). If a transaction has 5 signatures, the base fee is 25000 lamports. 

The priority fee is an optional fee that can be added to a transaction to give it priority. This fee is based on the amount of compute units used in the transaction. Similar to Ethereum gas, this fee is a simple measurement of computing resources required for the transaction. 

The final fee, rent, is more like a deposit. When developers create accounts or allocate space on the network, they must deposit SOL for the network to keep their account. Rent is calculated based on the number of bytes stored on the network, and an additional base fee is charged for allocating space. 

Transactions

On Solana, program execution begins with a transaction being submitted to the cluster. Each transaction on Solana consists of four parts:

One or more instructions. Instructions are the smallest execution logic on Solana. They can be thought of like function calls on an Ethereum smart contract. They invoke programs that make calls to the Solana runtime to update the state (for example, calling the token program to transfer tokens from one account to another).

An array of accounts to read or write from

One or more signatures

A recent blockhash or nonce. Instead of using an incremental nonce as on Ethereum, on Solana a recent blockhash is pulled from the cluster. With this blockhash, the transaction is only valid for 150 blocks, preventing long-living transaction signatures from being executed at a much later date.

One other significant difference between Ethereum and Solana is that with Solana, transactions can have multiple instructions (function calls on Ethereum). This means it’s not necessary to create custom smart contracts to chain functions in a single transaction. Each instruction can be a separate function call, done in order in the transaction. Transactions are also atomic: if an instruction fails, the entire transaction will fail.

Transaction Limitations

Like with Ethereum gas limitations, there are compute unit limitations on Solana transactions. 

Other limitations include:

Each account referenced may be at most 12,000,000 compute units used per block.

Instructions can only be called at a depth of 4 before the transaction reverts.

Mempool

Unlike Ethereum, Solana does not have mempools. Solana validators instead forward all transactions to up to four leaders on the leader schedule. Not having a mempool forces the transactions to hop from leader to leader until blockhash expiration, but it also reduces the overhead of gossip across the cluster.

The Solana Developer Environment

Now let’s look at some of the developer tools on Solana.

Programming Languages

While Ethereum primarily uses Solidity for writing smart contracts, Solana uses Rust. If moving from Ethereum, consider the Anchor framework or Neon, both of which can help developers get started faster by allowing them to build in Solana using familiar EVM tools. 

Like Ethereum, there are client-side SDKs available for many of the most popular programming languages, including JavaScript, Python, and Java.

Developer Tooling

Solana does not currently have an equivalent to Foundry, but it does have a wide set of tools equivalent to those used for Solidity. 

For a deeper dive, here is a broader list of developer resources.

Creating Smart Contracts

When creating programs on Solana (or when migrating existing Ethereum smart contracts) there are several core differences—too many to cover here. But let’s look at a few of the most common:

Mapping does not directly exist on Solana. Instead, use program-derived addresses. Like mapping, program-derived addresses give the ability to create a map from a key or account to a value stored on-chain.

On Solana, programs are default upgradable. A smart contract can be upgraded by a simple CLI command solana program deploy <program_filepath>.

When writing a solidity smart contract, it’s common to check for either msg.sender or tx.origin. There is no equivalent to this on Solana. Each transaction can have multiple signers, and the person sending the transaction is not necessarily the one who signed the transaction.

For more information on programs and how to deploy, check out this guide.

Learn More

Those are some of the most critical differences between developing on Ethereum and Solana. There is much more to learn, of course. And the best way to get started is to jump right in! Here are a few resources for next steps:

The Solana Playground where developers can write, build, and deploy Solana programs from the browser

An intro to Solana development using the Solana Playground

A more detailed look at the differences between developing on Ethereum and Solana 

The Solana Bootcamp

“I come from Latin America, from a small town. I have seen what it is to have a broken financial system,” says Fernanda Orduña Rangel, cofounder of Decaf. “So when I saw this new technology, it was very clear how I could use blockchain to solve a problem that I have experienced, one that I know exists not just in my town, but everywhere.” 

Decaf is a wallet built on Solana that provides financial freedom for people all over the world — especially in places with unstable economies that are not inclusive to everyday individuals. The app allows users to transition between fiat and crypto with the ease of a tap. As of March 2024, Decaf supports over 184 local currencies that can be redeemed at over 350,000 Moneygram locations, bridging the gap between crypto and real world transactions. 

“We’re trying to onboard the next billion people onto Solana and into blockchain,” explains Rangel. “With Decaf, you are able to cash out your stablecoins into pretty much any currency. We’re overtaking traditional systems, using blockchain to provide more freedom and more accessibility.” 

Emerging economies are leading the way in crypto adoption worldwide. That’s because people are seeing the valuable role the technology can play in protecting their hard-earned wealth and spending power. “My cofounder went to Argentina. The taxi driver was telling him it is so hard in Argentina right now because inflation is so crazy. They’re able to buy less and less every time [they go to the supermarket],” explains Rangel. That’s where Decaf comes in. “They saw the solution in blockchain. Now, they are able to protect themselves from inflation and have money to actually live their lives.” 

While many apps built on Solana cater to the cutting edge of web3, platforms like Decaf focus on lowering the barrier to entry for newcomers and creating a seamless experience between the internet, the real world, and web3. “We make the onboarding experience as easy as possible, and then slowly start teaching our users to do more,” says Rangel. “We give them access to a stable currency, but also we let them access investments, so they’re not just protecting themselves from inflation and devaluation, but they’re making money, improving their lives, and [working towards] financial freedom.”

Because Decaf’s user base is made up largely of newcomers to web3, it requires a blockchain that enables accessibility and convenience, one that doesn’t get in the way of user experience. “Decaf is only possible on Solana because of its great composability and performance,” says Rangel. “Solana’s speed and low fees mean we can offer an experience that looks like a web2 product, but is actually cheaper and faster. People don't even realize they’re using blockchain. That is the game-changing thing about Solana.”

Seamless finance for everyone all over the world is only possible on Solana.