Account Concepts on Solana

It has been several years, I didn’t write what I learned publicly. So today I want to try to write again and share my notes about Solana.

Solana

Here’s outlined what I want to share about Core Concept Solana from my perspective, maybe I’ll create several part stories about this:

• Accounts
• Program
• Rent
• Transactions

Accounts Structure

First thing first let’s talk about Accounts, we can imagine accounts are like containers or records on the Solana blockchain that hold data or tokens. The data itself on Account has a basic structure like Account on EVM.

Account Basic Structure :

• PublicKey: Each account has a unique public key that acts as its address on the blockchain it’s be used for receiving or sending like the address on EVM.
• Lamports: This is the unit of currency in Solana (similar to “wei” in Ethereum). Accounts hold lamports, which can be converted to SOL, Solana’s native currency. 1 SOL is equal to 1,000,000,000 lamports it same as Satoshi on BTC.
• Data: This is a section where the account can store information. The size of this data is defined when the account is created.
• Owner: Every account has an owner, which is usually the public key of a program that can modify the account’s data.
• Executable Flag: This indicates whether the account contains a smart contract (program) that can be executed.

Storing on Solana

Let’s say you are a student at a university and you have a locker (which we’ll refer to as an “account”) where you can keep your books, just like files on Computer. There is a tag (metadata) attached to this locker that indicates to everyone how long you can leave your book inside.

Now, you use a currency called “lamports” to pay for the locker instead of dollars. You must pay for the locker rental in order to keep your books in that locker and keep going using it. Here, Lamports are required for your account to remain active within the Solana network.

The employees, or validators, make sure that everyone has paid their rent on time. A locker is cleaned out (purged) if the rent isn’t paid and it runs out of lamports. On the other hand, you can receive a special pass (rent-exempt) if you place enough lamports in your locker from the beginning. This means you have paid enough rent to keep your apartment forever and are not required to pay it again.

To make it short, in order for your Solana account to function, lamports are required. It must pay rent in order to remain in the system; otherwise, it is deleted. However, you can stop worrying about rent payments if you have an adequate number of lamports.

Signers

The digital signatures on Solana using the Asymmetric Key same as the EVM the difference is Solana used the ed25519 keypair instead of using ECDSA (Elliptic Curve Digital Signature Algorithm). The concept of signing and signer is mostly similar.

Each of these addresses must be the public key of an ed25519 keypair, and the signature signifies that the holder of the matching private key signed, and thus, “authorized” the transaction. In this case, the account is referred to as a signer. Whether an account is a signer or not is communicated to the program as part of the account’s metadata. Programs can then use that information to make authority decisions.

example address of Solana and EVM

EVM      : 0xC69fb49a73ac2B9dE09cB22D98970Ec90777c6de
Solana   : 6AzhJQqax85X43PPPrk6WdLSVFmT4zjmofQr4StusY6A

Read-Only

In Solana transactions we can mark accounts that are created as read-only, meaning that the transaction will only read data from an account without being able to change it. Therefore, parallel account processing between transactions becomes possible or several transactions can work simultaneously on the account without waiting for each other.
If a program tries to change an account marked read-only, the transaction will be rejected by the system.

Executable

An account can be marked as “executable” in its metadata, it will be considered an executable program by including the public-key account in the program ID instructions.

If a program is marked as final (non-upgradeable), the runtime enforces that the account’s data (the program) is immutable. Through the upgradeable loader, it is possible to upload a totally new program to an existing program address.

Creating

SystemProgram::CreateAccount

An instruction to create an account by client generates a keypairs and registers the public key with a fixed storage size in bytes preallocated.

The maximum account data is 10 MiB (can be changed increased / decreased to 20 MiB per transaction). Size can be increases by 10 KiB per account and per instruction

SystemProgram::CreateAccountWithSeed, Pubkey::CreateProgramAddress

There are mechanisms for advanced users to create derived addresses by using(SystemProgram::CreateAccountWithSeed,Pubkey::CreateProgramAddress). By using these instructions, developers can generate a deterministic sequence of addresses based on a root seed or key, allowing for the management of multiple derived addresses within Solana applications.

Unlike EVM Solana have a programmatic interface that difference with Deterministic Wallet that we know, if we compare the mechanism on EVM or Bitcoin that used HD Wallets ( Hierarchical Deterministic Wallet ).

For refresher I will explain about Deterministic Wallet and HD Wallets.

Deterministic Wallet is a wallet where addresses, private keys, and public keys can be traced back to their original seed words.

Hierarchical Deterministic (HD) Wallet is a sort of cryptocurrency wallet that permits for the era of a hierarchy of keys from a single root seed. They are based on a standardized method portrayed in Bitcoin Improvement Proposal (BIP) 32

Hierarchical Deterministic Wallet

Let’s get back to Creating Accounts in Solana. Accounts that have never been created via the system program can also be passed to programs. When an instruction references an account that hasn’t been previously created, the program will be passed an account with no data and zero lamports that is owned by the system program.

Such newly created accounts reflect whether they sign the transaction, and therefore, can be used as an authority. Authorities in this context convey to the program that the holder of the private key associated with the account’s public key signed the transaction. The account’s public key may be known to the program or recorded in another account, signifying some kind of ownership or authority over an asset or operation the program controls or performs.

Account Types

Each account of Solana has a different purpose like features and function itself. You can see this diagram to see how our accounts interact with each other when we transact into Solana blockchains.

Accounts in Solana Networks

User Accounts:

• Purpose: User accounts are the most common type of accounts on Solana. They are owned by individuals or entities and are used for holding SOL (Solana’s native currency) and other tokens.
• Functionality: User accounts can send and receive SOL, participate in transactions, and interact with decentralized applications (dApps) on the Solana network.
• Each user can have one or multiple User Accounts.
• User Accounts can own multiple Token Accounts, Stake Accounts, Program Derived Accounts, and Associated Token Accounts.
• User Accounts connect to the Solana Network for transactions and interactions.

example User Account on Solana

Program Accounts:

• Purpose: Program accounts contain the compiled code (bytecode) of smart contracts or programs deployed on Solana.
• Functionality: These accounts are marked as executable, and the code they contain can be executed by the Solana runtime. They enable the functionality of dApps and various decentralized protocols on the network.
• Contains the code for smart contracts.
• Can generate Program Derived Accounts for specific functionalities.

Token Accounts (SPL Token Accounts):

• Purpose: Token accounts are used to hold SPL tokens, which are Solana’s equivalent of ERC-20 tokens in Ethereum.
• Functionality: Each SPL token type has its specific token account. If a user holds multiple types of SPL tokens, they will have a separate token account for each type.
• Each Token Account holds a specific type of SPL Token.
• Owned by a User Account.

example of Token Account

My Jupiter SPL Token Accounts

Stake Accounts:

• Purpose: Stake accounts are used for staking SOL tokens to validators on the Solana network.
• Functionality: These accounts track the staked SOL, delegate to validators, and manage staking rewards. They play a key role in the network’s Proof of Stake (PoS) consensus mechanism.
• Used for staking SOL tokens.
• Owned by a User Account and delegates SOL to validators.

example of Stake Account on Solana

My Stake Account on Solana

Program Derived Accounts (PDAs):

• Purpose: PDAs are special types of accounts generated by programs (smart contracts) on Solana. They do not have private keys.
• Functionality: PDAs are used by programs for various purposes, such as managing state, holding funds, or performing specific on-chain operations. They enable more sophisticated smart contract interactions and are essential for advanced dApp functionality.
• Generated by Program Accounts for various functions.
• Can be interacted with by User Accounts.

Associated Token Accounts:

• Purpose: These are a user-friendly feature that simplifies the management of SPL tokens.
• Functionality: An associated token account is automatically created for each type of SPL token a user owns, linked to their main wallet address. This simplifies the process of sending and receiving SPL tokens.
• A user-friendly way to manage SPL Tokens.
• Linked to User Accounts.

Ownership and Assignment to Programs

A created account is initialized to be owned by a built-in program called the System program and is called a system account aptly. An account itself have “owner” metadata. The owner is program id. The runtime grants the program write access to the account if its id matches the owner. For the case of the System program, the runtime allows clients to transfer lamports and importantly assign account ownership, meaning changing the owner to a different program id. So the diffrence that we can pointing out all of this is about the access to that account if the account is not owned by a program is only permitted to read its data and credit the account and if the account is owned by a program and it matches we have full access to that account.

Verifying validity of unmodified, reference-only accounts

For security purposes, it is recommended that programs check the validity of any account it reads, but does not modify.

This is because a malicious user could create accounts with arbitrary data and then pass these accounts to the program in place of valid accounts. The arbitrary data could be crafted in a way that leads to unexpected or harmful program behavior

The security model enforces that an account’s data can only be modified by the account’s Owner program. The runtime enforces this by rejecting any transaction containing a program that attempts to write to an account it does not own

If a program were to not check account validity, it might read an account it thinks it owns, but doesn’t. Anyone can issue instructions to a program, and the runtime does not know that those accounts are expected to be owned by the program

Rent

Keeping accounts alive on Solana incurs a storage cost called rent because the blockchain cluster must actively maintain the data to process any future transactions. This is different from Bitcoin and Ethereum, where storing accounts doesn’t incur any costs.

Rent exemption

An account is considered rent-exempt if it holds at least 2 years worth of rent. This is checked every time an account’s balance is reduced, and transactions that would reduce the balance to below the minimum amount will fail.

Program executable accounts are required by the runtime to be rent-exempt to avoid being purged.

Note: Use the getMinimumBalanceForRentExemption RPC endpoint to calculate the minimum balance for a particular account size. The following calculation is illustrative only.

For example, a program executable with the size of 15,000 bytes requires a balance of 105,290,880 lamports (=~ 0.105 SOL) to be rent-exempt:

105,290,880 = 19.055441478439427 (fee rate) * (128 + 15_000)(account size including metadata) * ((365.25/2) * 2)(epochs in 2 years)

References :

Solana Documentation | Solana