Part 1: Solana Fundamentals

Understanding the Solana fundamentals is a bit mind-twisting for the Ethereum community. Solana is one of the most popular chains out there… but why does it still feel like an enigma?

This article explains some of its core mechanisms and it’s a perfect starting point for Solana newbies.

Why is Solana better than others?

Solana is a Layer-1 solution for the terrible scalability issue that some blockchains face. Its fundamental optimisations proved so robust that their network speed competes with Visa’s confirmation times.

Solana is still a blockchain for distributed computing (like the good old Ethereum). Although, it does not rely on the traditional Proof of Work consensus algorithm. It relies on Proof of Stake which brings quite a significant speed increase of validation. Most importantly, it uses Proof of History, which is an optimization method of the consensus algorithm. 


The content of this series is separated into two parts:

  • PART 1:
    • Proof of History: Time-tracking extension of the usual consensus algorithm
    • Accounts and Programs: Data storage and modification
  • PART 2:
    • Transaction: What does a transaction mean
    • Token Creation: A real-life example of how to use Solana

You can find another very useful article about Solana (other than their docs) here. It gives an overview of the network’s technicalities, but it’s a bit eye-straining so it will take a lot of focus to go through it.

Proof of History

Proof Of History is the main pillar of the Solana fundamentals.

This system makes validators aware of the global time of the Solana blockchain. It allows consensus over transactions order. Without this, other blockchains face big time latencies due to back and forth debate on the truthful timestamps of transactions.

Proof of History eliminates the burden of sorting transactions. 

The chain of events is already decided and this helps validators check hashes in parallel.

How it works

There is a chain of hashes. Periodically, validators compute a new hash from the previous one. They add it to the chain alongside the number of iterations required to obtain it. 

Hashes are computed using the Verifiable Delay Function, such that each hash takes time to calculate. Therefore, we know that between each entry in the chain, some time passed.

Solana Fundamentals: Hashes Sequence

This chain represents the passage of time. Using it, we can now form a time relationship between transactions.

To do so, we place a transaction ‘in between’ hashes (call them timestamps).

Let’s say transaction T happened between timestamps A and B. We have to signal that T happened after A and before B:

  • After A: within the T’s metadata, we add the hash of A (latest computed timestamp)
  • Before B: add T to the A’s entry in the time chain. Therefore, the hash for B will be dependent on T. 
Solana Fundamentals: Transaction

This way, we obtain a global and trustless ordering of transactions. Thus, we eliminate the lag of time consensus which allows quicker validation. Because order doesn’t matter, separate hash sequences can be verified by different CPUs in parallel.

Accounts and Programs

Solana differs a lot from Ethereum when it comes to the way data is stored and modified.

A smart contract in Ethereum consists of methods and global variables which store state data. Solana separates these two, placing state data and executable code at different addresses.

Solana programs refer to approximately the same concept as Ethereum smart contracts.

Let’s categorize the type of Solana accounts (addresses):

  1. Data accounts: These store state. They can be of two types:
    • System owned accounts: They have a public and private key pair. Using this pair, you can sign a transaction that calls an executable program to modify the data in this account. For example, your SOL account is part of this category.
    • Program Derived Accounts: They don’t have a private and public key pair. An executable program creates and maintains these accounts. No external user can sign for PDA addresses as they are completely controlled by the programs. They allow programs’ intercommunication (any program can sign for a PDA once given the authority) and don’t require unnecessary storage of the key pair when attempting to modify them.
  2. Program accounts: Do not store state, but executable code. They are immutable once deployed. 
  3. Native accounts: They are special program accounts that sit at the core of the Solana networks. The most relevant ones are:
    • System Program: in charge of creating accounts and ruling account ownership.
    • BPF Loader: in charge of programs’ deployments and execution of instructions.

There are a few more fundamental concepts to mention when it comes to accounts.

Ownership of accounts

In Solana, every account is owned by a program. When a program owns an account, it means it has read/write access to it. All the other programs only have read-only access.

  • The owner of an account is an executable program that can modify the state of the account
  • Every account is by default owned by the Solana System Program
  • Having the private key of an account makes you the ‘holder’. You can not directly modify the account, but you can call an instruction of its owner to amend it


To store data on the Solana network, we need to pay rent for the accounts, every epoch (approximately every 2 days). If the account doesn’t have enough assets to pay rent, it will be permanently deleted from the network. Although, there is a ‘rent-exception’. If the account holds at least 2 years worth of rent, you are exempt from paying at all.

Program accounts must qualify for the rent exception to ensure permanence.

The rent amount per epoch is directly proportional to the size of the account:  (fee rate) * (account size + metadata). The above multiplied by (365.25/2) * 2 represents how much an account would need to hold to be rent exempt. 

Another essential concept, part of Solana fundamentals, is the SLP.

Solana Program Library

This is a collection of general-use programs supported by the Solana team (similar to Openzeppeline). They are deployed on the Solana blockchain and can be used by any of us. They offer functionalities such as creating, swapping, lending tokens as well as stake pools or name services. Most commonly, SPL is considered a token standard for Solana.


Apart from being a blockchain for distributed computing, the Solana fundamentals are very different from what we know on Ethereum. So I hope this gave you a high-level understanding of some of the core concepts of this network. There is more to come!

Part 2 of this article will give you a true feel of how the network behaves. We will talk about transactions and see a practical example of how to create a Solana token.

Leave a Reply