Solana Intro
Explanation of core concepts of Solana, mainly how it's different from EVM chains.
Last updated
Explanation of core concepts of Solana, mainly how it's different from EVM chains.
Last updated
We won't compare Solana to other blockchains in metrics like transactions per second, gas fees, level of decentralization, scalability... There are many articles on that topic. The ultimate goal of this section is to help you understand how Solana, as a smart contract platform, works under the hood.
Solana is so an exhaustive topic it's hard to select just a few things to mention here. Our goal is to be concise and to the point.
The Ethereum Virtual Machine (EVM) is the computation engine for Ethereum that manages the state of the blockchain and enables smart contract functionality. EVM is used in many blockchains, all denoted as EVM Chains. List of EVM chains on ChainList.
Ethereum is the first smart contract platform - there was nothing like Ethereum before Vitalik Buterin launched Ethereum on July 30, 2015. Many web3 developers (including Excoms team) have started developing on Ethereum. Maybe that's the reason why Ethereum concepts stick to our heads so much.
The community behind Ethereum is huge, it has built an amazing ecosystem and it's pretty easy for anyone to jump in and start building there. From all the resources available, we'd recommend reading Mastering Ethereum, an initiative of Andreas M. Antonopoulos, that's also available on GitHub.
Solana is a global state machine that's open, interoperable, programmable, and decentralized. It's a smart contract platform just like Ethereum. Solana isn't an EVM chain, but it's EVM compatible meaning it can run anything EVM chains can and more.
There are many great resources on how to get started with Solana.
Official Solana Docs
Docs by QuickNode
This blog summary
Differences between EVM and Solana transaction on Medium.
Solana Cookbook
Solana WhitePaper
Solana accounts are like files in an operating system. They have
unique address (public key, much like a file path)
lamports (amount of Solana they hold, 1 lamport is one billionth of SOL)
owner (who controls the account)
executable (if true, account is a Program with executable code)
data (any additional data account stores)
rent_epoch (described in Fees Section)
There are 2 main types of accounts on Solana
Accounts storing information and state of the network
System-owned accounts (example: user wallet)
Program-derived accounts (PDAs) (example: user's token account)
Program accounts that hold executable code
To demonstrate accounts further, we need to introduce Programs and rent exempts first.
That's what smart contracts on Solana are called. Program accounts (Solana accounts holding Program executables) are stateless, which is a crucial difference from EVM. If a program wants to store some data, it has to do it through PDA (i.e. create new accounts, that will hold the data).
Anyone can create their Program, but many use cases are already covered by programs in Solana Public Library (SPL). These programs are deployed on Solana mainnet, come with a Command Line Interface (CLI), and can be used by anyone, without a need to program or deploy anything. Token Program is one of the programs in SPL.
Let's go through the process of creating a new token to demonstrate how accounts work.
create Mint Account (PDA owned by Token Program), that holds information like mint authority, supply, decimals. In this PDA, Token Program stores info about a new token. Mint Account address is like an address of deployed ERC-20.
create Token Account (PDA owned by Token Program), that holds information like mint address, owner and amount. In this PDA, Token Program stores token holdings (token defined by mint address) for given owner.
you can use Token Program to mint new tokens, transfer tokens between token accounts, burn tokens...
create Metadata Account (PDA owned by Token Metadata Program), that holds information like mint, name, symbol, URI. Note that this PDA is created by a different program (that's not part of SPL).
Solana defines instructions as "The smallest contiguous unit of execution logic in a program." (source). An instruction specifies which program it is calling, which accounts it wants to read or modify, and additional data that serves as auxiliary input to the program.
Transaction is one or more instructions signed by a client using one or more keypairs and executed atomically with only two possible outcomes: success or failure.
If you want to send some of your tokens to a new recipient, you need to call two instructions on the Token Program, which you can do in a single transaction.
create a Token Account for the recipient (optional)
transfer tokens
Each transaction cannot be larger than 1232 bytes, so there is a limit to the number of instructions a transaction can have. It's still possible to transfer SOL or token to 10 different recipients in a single transaction without creating your own program (smart contract).
Compared to EVM chains, instruction must contain which accounts it wants to read or modify. Including this information into every instruction makes life for devs more difficult, so why the hell did Solana come up with that?
The answer is parallelization. Remember, Solana Programs are immutable so the only thing transactions can modify are system-owned accounts and PDAs - and each instruction will tell ahead which accounts it will read and which modify.
Thanks to this, Solana nodes can execute transactions (update the global state) in parallel which is important for Solana's scalability.
There are two types of fees on Solana
fixed fee
rent fee
The fixed transaction fee is 0.000005000 SOL per transaction signature. Each transaction has a compute budget, which corresponds to EVM gas. On Solana, you don't pay for gas (to be precise, the gas fee is worth practically nothing). Instead, you pay for rent.
The rent fee is a fee you pay to create an account (that stores data). The more data the account holds, the more SOL is needed to pay (by transferring it to the account). In most cases, you want your data to be stored permanently, so you pay so-called rent-exempt fee.
Rent-exempt fee is the amount of SOL account has to hold to be exempt from paying rent. Rent-exempt fee for a Token Account (size of 165 bytes) is 0.00203928 SOL. Rent-exempt for an account of size 1 MB would be 6.96089088 SOL.
Note that once the account isn't needed anymore, you can destroy it and release rent-exempt back to you.
On Solana, you don't auction for limited computation power. There's enough computation power for everyone. Instead, you pay validators to hold your data.
Solana nodes come with JSON-RPC API that allows a very convenient way to get information stored in PDAs.
Do you want to get all your token holdings? No matter if you own 50 different fungible tokens and 1000 NFTs, you can ask RPC to get all Token Accounts created by SPL Token Program where the owner is your address and you get all PDAs with their content - all your token holdings in a single call.
There are many use cases for PDAs that make life for devs much easier. We'll reveal some of them in Excoms' Products.
