What Is Solana (SOL) and How Does It Work?

What Is Solana (SOL)?

Solana is a public blockchain where developers can build and run onchain programs. Those programs are similar to smart contracts: pieces of code that run on the blockchain and automatically carry out certain agreements or actions.

SOL is Solana's native token. You use SOL, among other things, to pay transaction fees on the network. Solana has its own mainnet, the production environment where the network normally runs. There are also Devnet and Testnet, which are used for development and testing by validators. Solana Mainnet Beta went live in March 2020. That name is still used for the production network.

Key Takeaways

• Solana is a public blockchain for onchain programs.
• SOL is the native token and is used for transaction fees.
• Validators process transactions and vote on blocks through proof of stake.
• Proof of History helps place events in a verifiable order.
• Parallel processing can help, but it does not work for all transactions at the same time.

How Does Solana Work?

Solana uses proof of stake. In that system, validators help keep the network running. A validator is a computer that processes transactions, votes on blocks, and helps verify which data ends up in the digital ledger.

A validator's influence depends on the stake delegated to that validator. Here, stake means SOL that is linked to a validator to support that validator's participation in the network. The validator does not get ownership or control over that delegated SOL.

Validators take turns in different roles. The validator that is leader at that moment produces blocks and adds new entries to the ledger during a slot. A slot is, simply put, a period during which that validator has this task.

For consensus, Solana uses Tower BFT, a consensus method. Consensus means the network participants decide together which version of the ledger is valid. Tower BFT uses Proof of History as a time reference. Once a block has received votes from a supermajority of the network, it is considered confirmed.

A transaction goes through several steps. First it comes in, then the signature is checked. Next, the network checks, among other things, the payer and the accounts involved. After that, the instructions are executed. If everything is correct, the changes are recorded. If execution fails, the changes are rolled back, except for any applicable fees.

Solana (SOL) Overview

What Is Proof of History on Solana?

Proof of History, often shortened to PoH, is a way to record the order of events and the passage of time between them in a verifiable way. You can think of it as a cryptographic timeline for the network.

Technically, PoH works with a sequential hash chain. A hash is a digital result of a calculation. In this chain, each new hash is created using the result of the previous hash as input. That creates a fixed order that cannot just be changed later without recalculating the rest.

Transactions, or hashes of transactions, can also be included in this sequence. That makes it possible to verify where a transaction belongs in the order. Segments of the sequence can be recalculated in parallel to perform this check.

Proof of History is not a replacement for proof of stake or validator votes. So it does not independently decide which blocks are finally approved. The stake-weighted votes of validators are still needed for consensus. Tower BFT uses PoH's time reference, among other things, to determine timeouts in the consensus process.

How Does Solana Process Transactions in Parallel?

Solana tries to execute transactions at the same time when they do not get in each other's way. It does this with Sealevel. The main idea is simple: a transaction says in advance which accounts it wants to read and which accounts it is allowed to change.

When two transactions do not have overlapping account access, Sealevel can schedule and execute them in parallel. That means they can be processed side by side instead of strictly one after the other.

Say two transactions both work with completely different accounts. Then they can run independently. If two transactions want to change the same account, there is a conflict. Those transactions cannot be executed independently in parallel and have to be processed in a safe order.

Transaction signatures are also checked in parallel in batches. Within a single transaction, instructions are still executed one after another. If something goes wrong along the way, the network rolls back the changes from that transaction, except for any applicable fees.

So parallel processing does not mean that all transactions in a block always run at the same time. Shared writable accounts limit how much parallelism is possible.

Who Founded Solana?

Anatoly Yakovenko and Raj Gokal are the co-founders of Solana. Yakovenko developed the original Proof of History concept and published the first technical description of it in 2017.

Raj Gokal joined the early project in December 2017. Greg Fitzgerald and Stephen Akridge were early technical contributors. They helped turn the technical ideas into a prototype and a network implementation.

Solana Labs was founded in 2018 around the development of the network.

What Are the Benefits of Solana?

Solana combines stake-weighted consensus with a verifiable time reference through Proof of History. Because of that, validators do not need to constantly coordinate with each other about the order of events.

Sealevel makes parallel execution possible for transactions that do not share account access. That design can help process independent work side by side. How much parallelism is possible in practice does depend on the transactions themselves and the accounts used.

Solana programs can call other programs within the same transaction. That allows onchain applications to work together and use each other's building blocks.

Transaction fees are paid in SOL. Every transaction has a base fee and can also include an optional priority fee. With such a priority fee, a user can pay a leader extra to get a transaction scheduled faster.

SOL holders can delegate their stake to one or more validators. In doing so, they keep ownership and control over their delegated tokens.

What Are the Downsides of Solana?

Solana has had historical periods when the mainnet did not confirm new blocks and validators needed a coordinated restart. On September 14, 2021, the network was down for 17 hours after a transaction flood caused memory issues and validator crashes.

On September 30, 2022, block production stopped again. A bug in the consensus implementation prevented fork recovery at that time, after which block production resumed following a coordinated restart. These are historical incidents and do not prove that the network does not work now, but they do show that availability problems have happened.

Running a validator requires relatively powerful hardware. For a validator, the current recommendation is at least 12 CPU cores, 256 GB of RAM, NVMe storage, and a symmetric internet connection of at least 1 Gbit/s. Requirements like these can make it harder for parties without those resources to participate as validators. The recommendations can also change with future software versions.

Because votes are stake-weighted, validators with more delegated stake have more influence on the consensus outcome. In addition, slashing is not currently implemented as an in-protocol mechanism. Slashing is a system where stake can be reduced if a validator does not follow certain rules.

Costs and rewards are not fixed either. Transaction fees can vary, among other things, based on the chosen priority and network usage. Staking rewards depend, among other things, on validator commission, uptime, and the total amount of delegated stake. Validator and delegator rewards are funded in part by protocol issuance and transaction fees.

Conclusion

Solana is a public blockchain for onchain programs, with SOL as the native token used for things like transaction fees. Validators process transactions and reach consensus on blocks through Proof of Stake and Tower BFT.

Proof of History provides a verifiable time reference. Sealevel can execute transactions in parallel when they do not have conflicting access to accounts. That does not mean every transaction can automatically be processed at the same time.

Important tradeoffs include historical network outages, the relatively heavy hardware requirements for validators, and the fact that influence within consensus is tied to delegated stake. If you want to understand Solana, the main thing to remember is how validators, Proof of History, and parallel processing come together in the same network.