Overview

A new architecture for a high-performance blockchain.

Project stage

Only a whitepaper

Detailed description

The team is building a new blockchain protocol that’s based on encoding passage of time as data. It's called 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. The 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 the Proof of History (PoH) implementation and the 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 this 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.

Problem

Blockchain is an implementation of a fault tolerant replicated state machine. Current publicly available blockchains do not rely on time, or make a weak assumption about the participants abilities to keep time. Each node in the network usually relies on their own local clock without knowledge of any other participants clocks in the network. The lack of a trusted source of time means that when a message timestamp is used to accept or reject a message, there is no guarantee that every other participant in the network will make the exact same choice.

Solution

Solana is designed to create a ledger with verifiable passage of time, i.e. duration between events and message ordering. It is anticipated that every node in the network will be able to rely on the recorded passage of time in the ledger without trust.

Features

Proof of History: The Key to Speed
By weaving this standardized timestamp into the blockchain, nodes in the network can verify the time and order of events without witnessing them directly. This drastically reduces messaging overhead and is one example of the many optimization capabilities that become available through Solana’s Proof of History.

Sub-second finality that actually scales
Through Solana’s “Avalanche” network communication innovation, finality times reduce exponentially as the network grows. This means we can expect ~500ms finality up through 10s of thousands of nodes and beyond

Finally, scaling without sharding
Solana’s approach takes existing blockchain architecture and algorithms and improves on them instead of overlaying additional complexities such as sharding which can compromise security. We believe the right solution is a simple solution.

Scalable smart contracts in any language
With Solana, you can write smart contracts in almost any language. We leverage Berkeley Packet Filter, allowing any language that LLVM supports to be utilized.

Show details

Additional links

  • Token details

    • Token symbol ? Token symbol — a shorten token name. It is used during an ICO and after the coin listing at the cryptocurrency exchanges. : SOLANA
    • Fundrasing target ? Fundraising target — the maximum amount of funds to be raised during an ICO. When it is reached, the developers stop selling the tokens because they do not need to raise more money for the project development. : NA
    • Token type ? Token type — a platform for a startup launch that influences the stability of blockchain operation, the speed of transactions and the fees. :Own blockchain ()
    • Soft cap ? Soft cap — the minimum amount of funds to be raised for the project development. Sometimes when the soft cap has not been reached, the money is returned to the participants. : NA
    • Role of token ? Role of Token — type of token depending on the opportunities it offers to its owner. Utility tokens give their owners a right to use the project services, security tokens are aimed at bringing profit, and currency tokens are a money substitute. :NA
    • Total supply ? Total supply — a total amount of tokens that will be released by the developers. :NA
    • Escrow agent ? Escrow agent — a qualified agent who has the right of signature in a multisig wallet. An escrow agent participates in an ICO, monitors the financial operations of the developers and confirms their fairness. :No
    • Tokens for sale ? Tokens for sale — the number of tokens offered to the participants of an ICO. :NA
    • Whitelist ? Whitelist — a list of participants, who get an opportunity to buy tokens. To be whitelisted, you need to register on time because the number of participants and the registration period are usually limited. :Whitelist Open
    • Additional emission ? Additional emission — an additional release of tokens. It can be done once after the crowd sale or on an ongoing basis. In the projects with a limited emission there is no additional emission. :No
    • Exchange listing ? Exchange listing — an assumed date when the token will be listed at a cryptocurrency exchange. The developers usually indicate it in a roadmap and a white paper. :NA
    • Accepting currencies ? Accepting currencies — cryptocurrencies and fiat currencies that can be used for buying the project tokens. :BTC, ETH,
    • Can't participate ? Can't participate — the countries where it is prohibited to buy tokens. These can be countries where ICOs are prohibited altogether, or countries that have the requirements that a particular project does not meet. :No
    • Know Your Customer (KYC) ? Know Your Customer — a verification procedure for ICO participants, during which the developers can ask for personal data, a photo and a scanned copy of a passport of a potential investor. :No
    Get details
  • Token and Funds Distribution

    Token distribution date

    NA

    Unsold tokens

    NA

Sale schedule

Round Token Price Bonus Min / Max Purchase Soft Cap Hard Cap
Pre-Sale — Soon
Start Soon
NA No - Uncapped Uncapped
  • Team

    • Anatoly Yakovenko photo
      Anatoly Yakovenko
      CEO
    • Greg Fitzgerald photo
      Greg Fitzgerald
      CTO
    • Raj Gokal photo
      Raj Gokal
      COO
    • Eric Williams photo
      Eric Williams
      Data Science, Token Economics
    • Stephen Akridge photo
      Stephen Akridge
      Engineering
    • Alan Yu photo
      Alan Yu
      Partnerships, Biz Dev
    • Michael Vines photo
      Michael Vines
      Principal Engineer
    • Rob Walker photo
      Rob Walker
      Principal Engineer
    • Pankaj Garg photo
      Pankaj Garg
      Senior Staff Engineer
  • Advisors

Roadmap

  • Nov 2017
    Whitepaper published
  • Feb 2018
    Single node testnet
  • Jun 2018
    Multinode testnet
  • Jul 2018
    Public testnet
  • Sep 2018
    Smart Contracts SDK
  • Q4 2018
    Live mainnet
  • Q1 2019
    Token distribution

Activity