Frequently Asked Questions

Solana is a company that is creating a trustless, distributed, cryptographic protocol built on the back of a verifiable delay function. What does this mean? We’re building a new blockchain with a data structure that encodes the passage of time as data. We call this Proof of History (PoH).

PoH gives us a sense of trustless time and message ordering before consensus. This drastically reduces messaging overhead between nodes in the network and solves many of the existing scalability problems that other blockchain protocols face.

Additionally, it allows us to build a high-throughput blockchain that doesn’t rely on shards, partitions, side chains, multi chains, etc. As a result of this new system architecture, Solana’s new PoH blockchain will allow up to 710,000 transactions per second on a 1 gigabit network.

The goal of the Solana architecture is to demonstrate there exists a set of software algorithms that when used in combination to implement a blockchain, removes software as a performance bottleneck, allowing transaction throughput to scale proportionally with network bandwidth. The architecture goes on to satisfy all three desirable properties of a proper blockchain: it is scalable, secure and decentralized.

The architecture describes a theoretical upper bound of 710 thousand transactions per second (tps) on a standard gigabit network and 28.4 million tps on 40 gigabit. Furthermore, the architecture supports safe, concurrent execution of programs authored in general purpose programming languages such as C or Rust.

Ultimately, our goal is to provide the the ideal toolkit for developers to build the next generation of blockchain applications without limitations.

In short: communication overhead. Since Proof of History (PoH) provides a trustless sense of time and ordering of messages, network nodes can trust the relative message times that they receive in the PoH broadcast without having to communicate with all the other nodes in the network. For many distributed networks, the time to finality (the guarantee that past transactions on a digital ledger are legitimate and will not change) scales as the square or even the cube of the number of nodes in the system due to the necessity to confer with other network participants on message ordering.

Because of our Proof of History implementation and our Avalanche communication design, Solana blockchain’s time to finality scales with the logarithm of the number of nodes. This translates into a high throughput network that can support tens of thousands of nodes, while retaining sub-second confirmation times.

Proof of Replication (PoRep) is a proof of storage protocol. And in our blockchain, it’s used for increasing availability, making it unnecessary for all nodes in the entire network to store the full ledger. It achieves this by ensuring that each bit of data has been replicated to it’s own uniquely dedicated physical storage node(s).

In practical terms, it essentially allows the network to prove that a node you don’t trust is using its resources to store a segment of the ledger. This generates a torrent like network, where no single node is holding the full ledger, but a copy is always available on demand.

Avalanche is a method of organising the network data flow. The generator (leader) is at the top of the pyramid, with validators at each level below it. And for every additional level below the generator, the number of validators doubles.

This enables Solana to scale their finality times logarithmically or log(n), where ‘n’ is the number of nodes. Typically, finality times on traditional gossip protocols scale at n squared, which means the finality times suffer exponentially as nodes increase on the network. However with Avalanche, the opposite occurs on Solana, thus supporting greater decentralization of nodes, while maintaining sub-second finality times.

The name Solana is inspired by a beach town in Northern San Diego county where the CEO and the Co-Founders lived and surfed for 5 years.

For a deeper dive on how Proof of History (PoH) works make sure to read our detailed article on the concept, and also our analogy of how our PoH method is like a water clock.

Solana uses Proof of Stake (PoS) as its consensus mechanism. PoH allows Solana nodes to process the ledger optimistically, i.e. in terms of the CAP theorem Solana is an availability preferring system, and by leveraging validator vote lockouts that increase exponentially in time, Solana’s economic finality grows probabilistically with ledger depth.

More information is available within the technical section of this FAQ, or you can also refer to our online book on Solana, which takes a technical deep dive on what’s been implemented and what’s to come.

Solana is open source, freely forkable and thus can be run as either a permissioned or permissionless network.

The positive consequence of high performance is low cost. We estimate that the cost per transaction will be around $0.0001 USD per transaction.

At Solana, our dream is to enable developers to build applications without needing to worry about performance. We intend to do this by building the world’s fastest blockchain without compromising on security or decentralization.

Therefore any decentralized application that demands high throughput, like for instance, the hundreds of thousands of transactions completed on NASDAQ each second, would benefit from utilizing Solana as their underlying blockchain.

Below we’ve highlighted some of the key features of Solana, and some example use-cases and stakeholders that would benefit from each feature:

  1. Solana’s network architecture automatically orders transactions as they enter the network, rather than by block. This is especially useful in decentralized exchanges and marketplaces in order to have fair ordering of transactions for users.
  2. Our quick settlement times (sub-second confirmations) are especially useful for payments, marketplaces, decentralized exchanges, gaming, etc. This is a broad feature which would be desirable for any decentralized application since it translates into fast response times and contributes to a better end-user experience.
  3. Our low transaction costs (estimated at $0.0001/tx USD) is especially useful for decentralized applications where cost efficiency is essential. Any application that requires guarantees on consistently low transaction costs for themselves and their end-users would benefit from this feature. Particularly where micropayments are expected to frequently occur, being able to ensure that transaction fees remain as an insignificant fraction of the overall value being transacted is essential.
  4. All LLVM compatible languages are supported for smart contracts development on Solana, which means developers can build in various languages within their application.
  5. Solana is the sustainable scalability solution that scales with traditional hardware and bandwidth improvements. Any project that chooses our platform will be assured that their business can scale and grow over time without having to migrate to alternative blockchains due to to network constraints.
  6. Solana is creating high-level APIs and RPCs that will be highly compatible with existing UIs written specifically for Ethereum applications to reduce friction for adoption. Existing Ethereum developers that require higher throughput on their network can easily migrate to Solana with minimal pain.

Solana will be built with a LLVM front end, which means that any language supported by LLVM will be available to developers. The full suite of supported languages will be rolled out progressively, starting with C and C++.

Our development is in full swing and we’re racing towards a mainnet launch. Feedback is always welcome, so please join our Discord community or contact us for the latest.

As of early January, Solana is at multinode testnet v0.11.0 and we’ve achieved 186,000 transactions per second with over 50 nodes. During this version of the testnet we peaked at 350,000 transactions per second.

The next major milestones will be to start on-boarding validators onto the network, implement fork selection, and rollback into the consensus algorithm so that we can achieve a fully featured testnet.

The section above is updated periodically. To stay up to date on the team’s progress feel free to review our Github releases. Or feel free to join us on Discord to speak directly with the team.

Yes. Do you know Cuda or Rust? Or are you familiar with wallet integrations? Or is there something else you’re excited about helping with after reading our book and checking out some issues on github? Join us on Discord to speak directly with the team.

We use Cuda, Rust. The primary reason for this is because there is no garbage collector. And the compiler manages memory for you. This is critical because to interface with the GPU we need to access the memory directly without overhead. All the other garbage collection languages typically have high overheads.
Messages that talk through the blockchain require a fee. PoRep or Storage Replicators are not processing transactions, but are simply providing a replication of as much storage as they choose. They are not really in the path of a DDoS attack.

In Solana, the traditional definition of a block doesn’t apply. Instead messages are constantly streamed to the downstream validators and are validated periodically through voting rounds.

For Solana a block is a period of time measured in PoH hashes that a leader can use to transmit data. The leaders, selected on a stake-weighted round-robin schedule, will attempt to transmit as much data as possible during their assigned block. Their block will be measured in time, and time is measured in hashes. If they transmit too much during their block then validators will simply not be able to keep up and consider that transmission a failure.

In our current design, a block allows a leader node approximately 1 second to transmit in each slot, regardless of whether they convince the network of their block within that duration or not. The next leader is rotated in automatically without waiting.

In Solana’s Proof of Stake implementation, we introduce the concept of vote lockouts and the stacking of consensus votes into our consensus algorithm.

The purpose of the lockout is to force a voter to commit opportunity cost to a specific fork. Voters that violate the lockouts and vote for a diverging fork within the lockout should be punished. Slashing or simply freezing the voter from rewards for a long period of time can be used as punishment.

Voters should be rewarded for selecting the fork that the rest of the network selected as often as possible. This is well-aligned with generating a reward when the vote stack is full and the oldest vote needs to be dequeued. Thus a reward should be generated for each successful dequeue.

Currently a vote stack is considered full when 5 votes (a maximum vote lockout of 32) on the same fork is achieved, at which point the oldest vote can be dequeued. The parameters for a successful dequeue and vote lockouts are adjustable.