Highlighted Articles

Frequently Asked Questions

We are building a new blockchain protocol that’s based on encoding passage of time as data. We call this Proof of History (PoH). Solana is creating a trustless, distributed, cryptographic protocol to create a reliable ordering of events, which solves for many of the existing scalability problems that other blockchain protocols face. Our solution is built to make transaction processing independent of consensus. Additionally, this is 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.
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. Because of our Proof of History (PoH) implementation and our Avalanche communication design, Solana blockchain’s time to finality scales with the logarithm of the number of nodes. What does this mean? A high throughput network, with tens of thousands of nodes, that retains sub-second finality 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.

Indeed, Solana was previously known as Loom Protocol. Due to other projects having similar names, the project team decided to change its name to Solana.

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.

Solana uses Proof of Stake (PoS) as its consensus mechanism. Solana does innovate on the consensus layer--our approach to better scalability is adding a sense of time to a permissionless network. Read about our PoH protocol here.
Solana is a permissionless network.
Given the high transaction throughput of Solana, which is comparable to the amount of transactions that NASDAQ completes per second, we believe Solana will be capable of powering the next generation of decentralised exchanges, prediction markets, payment platforms, etc. However, that’s not to say that other dApps won’t be suitable for Solana. The aim of the project is to be a dApp platform that can support a broad range of use cases beyond those mentioned above.
Solana will be built with a LLVM front end, which will mean that any language supported by LLVM will be available to developers. The full suite of supported languages will be rolled out progressively, starting with Solidity and Javascript.

Our development is in full swing, our whitepaper has been validated by multiple parties, and feedback is always welcome. Join our Telegram or contact us for the latest.

As of early May, Solana is at single node testnet v0.5.0. We achieved 250,000 transactions per second. This is a 700% increase over the previous version, which was at 35,000 transactions per second. During this version of the testnet we peaked at 400,000 transactions. These results were achievable partly because of Stephen Akridge’s GPU implementation, which enables 870,000 signature verifications per second.

The next milestone for the project is to set up a multinode testnet. We expect to share an update in June.

If you’d like to stay up to date on the team’s progress feel free to review our Github under the releases section. Or feel free to join us on Telegram 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 whitepaper and checking out our github? Check out our Careers page or get in touch via Telegram or email.
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.
PoRep is replicating the ledger, not the state (this is the Spool). You still need to pay message fees so you can’t DoS everything, but you can create many accounts with little value in each. We might end up pushing things to disk if they are stale or small.

The smallest packet size as outlined within the whitepaper is made up of the following elements:

  • 20 byte (160 bit) last valid hash counter (ripemd of the sha)
  • 8 byte counter
  • 2 byte flags and payload size
  • 20 byte to address (ripemd(sha256(public key)))
  • 8 byte amount
  • 8 byte fee
  • 32 byte public key used to sign
  • 64 byte signature

The sum of all of that is: 20 + 8 + 2 + 20 + 8 + 8 + 32 + 64 = 162 bytes.

In theory, the packet size could be reduced even further by keeping the amounts dynamically sized based on flags and dropping the counters. However, the gains are minimal, and would only serve to increase the format complexity.

For more on Proof of History, check out our articles on Medium.