Main Features — Tech Overview
A deep dive into Solana’s proposed solution raises questions such as, how Proof of History is being implemented on the blockchain, and exactly how does Solana work and what tools are they using?
First we need to understand how the network was designed, and what it consists of. This is summarized in the diagram below, a visual demonstration of Solana´s network design, from the top-down.
The Proof of History is a high frequency Verifiable Delay Function. It means that it will require a determined number of correlative steps to be evaluated. But on the other hand, those steps will produce in the end a unique output , easy to verify.
In the solution section, we talked about how Solana would increase the number of txn/s and how it would reduce the necessary resources used to run them. The explanation of how this is possible goes hand in hand with the explanation of the hash function.
The Hash Function operates as a way to compress data, so that larger amounts of data can end up being compressed in little sets of bits, which encourages a lighter tx weight and therefore a more effective and faster sequence.
As summarized above, the Proof of History sequence is designed to work with a cryptographic hash function.
What is especially relevant about cryptographic hash functions, is that it is impossible to predict what you will have in the end (the output) without executing the whole function from the beginning, using the original input. Consequently, having the input and trying to predict the output is impossible, you will be required to run the function to achieve a result.
Taking that into consideration, imagine this hash function running from some random starting point (initial Input) and once that process is complete you obtain your first Output (hash 1). Here is where it gets interesting, feed the inputs with the obtained output you got from running the function before, into the input of the next hash as in the diagram below:
Now if we were to repeat this process… 300 times for example. You can begin to see that we have created a single threaded process where the final output (hash 300) is a completely unguessable except for those who execute the whole thread.
This cycle of feeding outputs to the inputs of the next function along with the data that is generated, is then represented as time passing and history being created, in Solana’s words, ticks. Each output carries detailed information and cannot be predicted without running the function. Like the films in the Marvel Saga in our above example, each Output represents a tick of time that is exactly in its place within the thread of sequential time
Therefore, instead of using unreliable time, Solana proposes to use these sequentially ordered and unpredictable Outputs to determine a specific moment in time, a specific moment in that threaded process which we may call history.
Avalanche : Solana’s solution for Congestion
Solana’s high transaction output at 1 GB network is done through an architecture Solana developed called Avalanche. Similar to a torrent network, a full copy of the ledger isn’t necessarily available at any particular node, but a full copy is always available and can be passed around by collecting each piece and reconstructing it.
In the image above, you may observe that the assigned leader node’s block data is split into two. It makes it’s initial hop onto the 2nd level then proceeds to hop a second time to its peers. After the 3rd hop, the block makes a fourth hop back to the leader node to report it’s vote. With the ⅔ + 1 majority vote, the block reaches finality and moves on to the next block.
By only having to share half of the block data amongst peers, it greatly reduces bandwidth and data usage in the network
The Honest Approach
In order for Solana to keep nodes and verifiers honest, the Proof of History generator will intentionally send an invalid hash at random intervals. Due to the incentives the nodes have of verifying any hash they receive, Solana ensures that any verifiers validating an invalid hash will get slashed.
Proof of Stake
Solana uses proof of stake (POS) for consensus so and it has many of the same characteristics of other POS based coins. As a refresher here are some of the main characteristics of a POS coin:
- Proof of Stake coins make use of Validators
- Proof of stake can be proven by
- Locking coins in a wallet
- Locking coins in a Masternode and contributing to the stability of the chain
- Payout order is determined by the “age” of the staked coins or masternode
- Each staked wallet or masternode receives minted or newly forged coins
- A wallet or masternode that is offline for too long is no longer “payable” and may be removed from the network
- POS serves to prevent bad actors from introducing invalid transactions to the network by making it not worthwhile to undermine the security of the network
- Penalty for “bad actors” can be the loss of staked coins and rewards
- Trust is ensured as long as the rewards of proof of stake are greater than the opportunity for gains made by fraud
Solana has very similar construct but has implemented their proof of stake in a slightly different fashion.
- Solana chooses a Validator from those nodes that have been bonded (i.e. have staked a coin)
- The voting and selection of the validator is then determined by the node that has been up the longest or most bonded node
- Solana relies on quick confirmations; if a node doesn’t respond within a specified time it is marked as stale and removed from voting , if that node was the validator at the time, a new election is held to select a new validator
- If a super-majority (2/3rds of nodes) votes within that timeout then the branch is considered valid
- Slashing, which is the act of making a bond invalid, prevents a validator from committing fraud or trying to validate multiple nodes as the bonded coins will be lost
- A major difference is the concept of a secondary elected node. Once selected the secondary node can take over the primary role in the case of a network outage or other failure.