Time is an important element in Solana's consensus algorith
What is Solana
Originally called Loom Protocol (not to be confused with Loom Network), Solana is a blockchain protocol that states on their website they can achieve up to 710k transactions/second on a 1gb network, on modern computing hardware, without data partitioning. We've heard bold claims of high TPS so let's get the eye-rolling out of the way and taper our expectations. With that said, let's dig in to see how they will achieve their claims.
The team
Anatoly Yakovenko, CEO, 12+ years experience at Qualcomm and a brief stint at Dropbox. Impressive experience at Qualcomm.
Raj Gokal, COO, serial entrepreneur in the health tech space. No big name exits as far as I see.
Eric Williams, Data Science, his LinkedIn handle is "science the data". I like that. B.S. Physics from UC Berkeley and Ph.D. Particle Physics from Columbia University. Worked at Omada with Raj Gokal.
Alan Yu, Strategy/BD/Sales, 10 years experience selling ad products at Google (my former employer so here's a nod to you sir)
Stephen Akridge, Engineering, ~10 years experience at Qualcomm
The team has criss-crossed paths during their university days at University of Illinois, working at Qualcomm, and working at health startups such as Omada.
Token Metrics and Roadmap
Token Metrics:
Currently unavailable. Will update when available.
Testnet
Testnet currently performing at 250k TPS, peaking at 400k TPS.
Roadmap
June - Testnet 2.0 and public demo
September - Public testnet
Q4 2018 - Mainnet launch
Q1 2019 - Token Generation Event (TGE)
Consensus Algorithm
Let's start with the consensus algorithm. This section will be longer than the rest because we view it as one of the most critical differentiators for Solana.
Remember in every blockchain, transactions are grouped together in a "block". The miner or group that validates the block becomes the leader - they have the authority to create the next block on the blockchain. The leader broadcasts the latest copy of the blockchain and selects the next leader. In Bitcoin, the leader is chosen by competition. First miner to solve Bitcoin's Proof-of-Work algorithm claims the role of leader. In other protocols, such as Dfinity the Leader is chosen by a lottery. In Ethereum, the Leader is chosen by a lottery with increased chances of winning based on how much coin a validator owns. Consensus algorithms come in a variety of flavors.
Solana proposes a blockchain architecture based on its consensus algorithm named "Proof of History (PoH)". At first glance, this sounds a lot like "Proof-of-Elapsed Time" (PoET) used by HyperLedger Sawtooth. PoET is theoretically a more energy saving algorithm because it does not force all validators to simultaneously solve a cryptographic puzzle as Bitcoin does. Instead, the Leader generates a wait time in which all eligible validators must wait that amount of time.
PoH aims to solve one the trickiest problems in distributed networks, consensus on time. How do nodes trust messages that have timestamps encoded in it? What is the node that sent the message uses its local time or if the timer is out of sync. What is the time in the message was tampered with? Nodes simply cannot trust an external source of time. Instead of fixating on the timestamp, what is the nodes could trust that an event happened "before" or "after" an event. Solana's PoH is a Verifiable Delay Function. VDFs are slow and difficult to compute, even using a large amount of parallelism. But the result can be verified quickly. PoH adds in a cryptographic hash function to each event, allowing validators to prove the sequence of events. The algorithm is run continuously with the previous result to be used as the next output. PoH will keep track of how many times the function is run.
PoH also supports horizontal scaling as multiple generators can synchronize by mixing their state into each others sequences. Utilized in conjunction with either PoW or PoS, PoH will result in fast time to finality (TTF). The trick is to reduce the overhead messaging that bogs down Byzantine Fault Tolerance (BFT) replicated state machines. In plain English, replicated state machines is simply using multiple servers (or nodes) to achieve Byzantine Fault Tolerance.
Not only is Solana utilizing its PoH algorithm, but also proposing two additional time-based algorithms. The first is an "agnostic partition size" PoS algorithm, and the other is called Proof-of-Replication (PoRep). Remember, all of these algorithms are meant for validators to reach consensus on the final state of the distributed ledger. PoRep and PoH working together should provide a defense of both space and time against a forged ledger.
In plain English... if a malicious actor were to tamper with the data and timestamp of previous transactions, the output would change unpredictably. Validators would quickly prove this is an alternate history and reject the faked output. PoH will speed performance through reduced overhead and horizontal scaling. It will increase security through time validation. More speed. More security.
CAP Theorem
For the non-technical readers it would be helpful to read up on the CAP theorem. There is a similar framework called the Scalability Trilemma (coined by Kyle Samani of Multicoin Capital) but first proposed by Trent XYZ of Ocean Protocol. A similar essay titled Blockchain: A Game of Tradeoffs is featured here on our Education Series here at Quantalysus. CAP stands for Consistency, Availability and Partition tolerance. The theory states that distributed networks can only achieve two. One has to give.
Consistency: all participants on the network have the most updated information.
Availability: network participants (nodes) are always on and listening
Partition Tolerance: when one node goes down, the show goes on. The more nodes that are missing, the higher the partition.
Solana asserts that in a non-partitioned state there is one Leader (node that sends the transactions to other validators/verifiers) in the network. The other Verifiers that have the same hardware specs as the Leader can be elected as a Leader. The election process of selecting a leader is performed through a Proof-of-Stake based process. When nodes fail (partition tolerance is tested), networks have to choose between Consistency or Availability. Solana will select Consistency over Availability due to PoH serving as an objective measure of time. Over the long run, Solana's approach will select Availability. In the event of a major partition, control of the network will be tested. Solana plans to utilize Horizontal Scaling in the event of a large partition. Let's dig into specifics of Availability in Solana.
Availability and Staking
To deal with partitions (node failures) with reasonable human timeframes, we propose a dynamic approach to unstake unavailable verifiers. When the number of verifiers is high and above 2 3 , the unstaking process can be fast. The number of hashes that must be generated into the ledger is low before the unavailable verifiers stake is fully unstaked and they are no longer counted for consensus. When the number of verifiers is below 2 3 rds but above 1 2 , the unstaking timer is slower, requiring a larger number of hashes to be generated before the missing verifiers are unstaked. In a large partition, like a partition that is missing 1 2 or more of the verifiers, the unstaking process is very very slow. Transactions can still be entered into the stream, and verifiers can still vote, but full 2 3 rds consensus will not be achieved until a very large amount of hashes have been generated and the unavailable verifiers have been unstaked. The difference in time for a network to regain liveness allows us as customers of the network human timeframes to pick a partition that we want to continue using.
Horizontal Scaling
Solana's PoH algorithm is configurable to allow for Horizontal Scaling. In the world of databases (remember, a blockchain is a database that's distributed), scale is achieved horizontally or vertically. In Vertical Scaling, the computers are upgraded through better processors and more storage. In Horizontal Scaling, more nodes are added. Horizontal Scaling in Solana will be achieved through each node mixing the sequence state between each generator. This is different from sharding, as sharding is a subset of Horizontal Scaling approaches. Horizontal Sharding uses one instance of the data across different nodes or Solana's case mixing sequence events. In databases, sharding is basically the same, but allow multiple instances of the same data to be spread across nodes.
Elections
To select the next Leader, an Election is held when a failure is detected. In the event of a tie, the largest Solana node with tokens staked (highest voting power) will be chosen to select a new PoH generator. This is one potential weak spot as it may be likely that the tiebreaker node will be the same node each time there is a failure. In the event of a Black Swan failure should we really trust the same validator over and over.
Solana runs a Proof-of-Stake Election process. It is meant to be fast and effective in slashing bad actors. Each node participating in the election puts up an amount of collateral with Solana token(s) in an escrow account, this collateral is called a Bond. Queue a bad bail bond joke! 1, 2, 3, go! The election will last a short amount of time in order to allow all validators the ability to receive the same information. The vote must take place quickly. Consensus is reached once a super majority of 2/3 of bonds are reached. Like other Proof-of-Stake systems, Solana runs the risk of major token holder collusion. Please see the whitepaper to understand how Solana will deal with last minute vote switching and secondary fall back elections.
Keeping Nodes Honest
Verifiers have economic incentives to automatically validate any hash the Generator sends it. To avoid this, Solana throws in something interesting. I think of it as a Trojan Horse (not to be confused with a computer virus). Basically, the PoH Generator will intentionally send an invalid hash to the verifiers in random intervals. Any Verifier validating an invalid hash will get slashed. Additionally, every verifier is required to respond within 500 milliseconds or risk losing their spot in the current validation cycle. The fast time frame also serves as a deterrent to malicious nodes intercepting and spying on what other nodes are validating.
Smart Contract
Solana will feature smart contracts. The likely supported languages will be Solidity and JS. Eventually more established and safer languages will be supported.
Verdict
Solana looks like a strong project on paper. Its testnet TPS claims are far higher than anything I have seen aside from closed permissioned-based networks. The team has the relevant backgrounds and their whitepaper is extremely well written. If you dig into the GitHub you'll see it has been active since February of this year. Solana has a proprietary time based consensus algorithm that will presumably pair well with PoW and PoS. Ultimately, Solana is a Proof-of-Stake based network. Therefore it inherits its advantages and disadvantages.
I'm going to set up a test node to see what happens. I've seen projects with far less material, far less experience, and far less well written material do well in this crazy cryptocurrency market. With my expectations sufficiently lowered, I can honestly give this project high praise. I will update my verdict as I uncover more.
