Referring to the fundamental report published earlier this year, there is an excellent explanation of the difference between other blockchains and Solana that can be illustrated by using a relay race analogy. Firstly, let us look at the relay race analogy to understand most existing blockchains.

Yakovenko writes that “Most blockchains rely on sequential validation of blocks which requires validators to talk to each other to reach a consensus on the passage of time when a transaction occurs. This slows down the network because the previous block of transactions must be confirmed by every validator node on the network before the next block can begin. Picture a relay race with three runners, and the racetrack as a snapshot of time. The sum of the distance each runner has covered signifies the total work done, but the second runner cannot begin running until the baton is passed to them by the first runner.”

Let us apply the same analogy to the Solana blockchain and compare.

“With the Solana blockchain, all three runners can run simultaneously without needing to wait for a baton to be passed. Collectively, they are doing the same amount of work as other teams, but in terms of time, they only use one third of it to complete the race.  When compared to the sequential method used by the other team; Solana’s runners are three times more efficient. Solana allows its team to complete three times the work in one full lap of the track, and it does it in the same amount of time.”, Yakovenko says.

Expanding the relay race analogy to the Solana network validators, each validator can effectively be thought of as a runner. What makes Solana unique and allows for near instant finality is the implementation of a leader and verifier system. The flow chart below taken from the whitepaper  illustrates this:

The diagram is quite complicated so let us explain everything step by step. All Solana validators have the same computational power. The network will randomly select one validator and make them the leader. All the other validators become verifiers.

The leaders’ job is to order all the transactions. With the high-spec computers used as validators, such an operation is easy and quick to do. Once the leader has ordered the transactions, they broadcast the order of transactions to all the verifiers. The leader then carries out the transactions. Next, the verifiers  confirm all the transactions carried out by the leader in the next block.

To help us understand how the transactions and their order are processed and verified, it is important that we understand the basic functionality of the cryptographic function used by Solana. Solana uses SHA-256.

The first key feature of SHA-256, is that its output is always the same length regardless of the input. The length of the output refers to the number of characters that make up the output. There are always 64 characters in the output of a SHA-256 hash. The input can be anything, a word, a sentence, a data structure, a transaction or even this entire report. Let us illustrate this with an example.

Input: cryptonary

Hash with SHA-256

601be2a1b9e0e830d88eb54beb8b973faa4b2e8ebcb1b4bbdfdaa694faf79026

Input: This article covers proof of history with an interactive example.

Hash with SHA-256

5a7c2a03b5778518ac22ec283c8117f9322baf4b0fae8aa4b72e5cf4d88d3edb

As can be seen from the examples above, in the first case, only one word was provided to the SHA-256 function. In the second case, a whole sentence was provided to the SHA-256 function. Despite the difference in the length of the inputs, the output is always 64 characters long. 

Interacting with the above example and this report:

The SHA-256 hash function does not require a lot of computing power. There are many websites which allow users to try out these cryptographic functions. This report is written to work with most online hashing websites; it works best with https://md5hashing.net/hash due to their decode function, and simple user interface.

All the examples presented in this report will work with this website. Make sure to scroll down after hashing any input and select the SHA-256 function. This is shown by the red box below:

The second key feature of the SHA-256 protocol is that each input and output are a unique pair. Let us use a couple of examples to visualise this.

Input: cryptonary

Hash with SHA-256

601be2a1b9e0e830d88eb54beb8b973faa4b2e8ebcb1b4bbdfdaa694faf79026

Input: Cryptonary

Hash with SHA-256

ecc5c00c8ddc74c2edf8ba18e140ad2dcfa96ec74a578c43f76a1783a35b1b5e

As can be seen despite the only difference in the input being the capitalisation of ‘c’, a different output was generated. Let us look at a more relevant example to show how Solana functions. As mentioned previously, the leader orders transactions. The order of transactions is important and is very similar to a phrase. In the diagram above three transactions are ordered by the leader, and their order transmitted. Let us compare each transaction to a word.

Transaction 1	cryptonary
Transaction 2	solana
Transaction 3	podcast

When the transactions are in the correct order (1->2->3) they make sense, just like words in a phrase. Using the (1->2->3) order from above, we would end up with the phrase: cryptonary solana podcast. If the order is changed (2->1->3), the resulting phrase would be: solana cryptonary podcast.

The order of transactions is important for a blockchain or any financial ledger, just like the order of words is important in a phrase.

As shown previously, each input into SHA-256 has a unique output. The output is order sensitive. Let us use the two phrases from above to illustrate this:

cryptonary solana podcast	solana cryptonary podcast
(1->2->3)	(2->1->3)
Hash with SHA - 256	Hash with SHA - 256
213330553f1a6d846b13b1bc28acced932c46e82e7b4e6580635a0e38e1115ef	c53ec92760bc96e7f419e7a4ad02e8847ed259afb426d3def300474bf4696051

If you followed along with the above example, you were playing the role of a ‘verifier’. The author of this report is the ‘leader’. The phrase ‘cryptonary solana podcast’ has been broadcast by the author, just like transactions are broadcast by the leader. The author has then carried out the transactions by using SHA-256 to hash ‘cryptonary solana podcast’ and then broadcasting the resulting hash to the network. The reader has then hashed the phrase, just like the verifier hashes the transactions. The hash which the reader has generated can be compared against the hash published in this report. For the hashes to match, the inputs must be identical. Once enough verifiers confirm the hash is correct, the transactions are verified, and the network has reached a new ‘state’. Each ‘state’ is equivalent to its hash and thus unique.

What happens if the leader wants to add more transactions, or the author more words to the phrase? In this case the agreed upon state which is represented as a hash, is used as an input into the SHA-256 function along with any new transactions appended to it. Let us add some more transactions.

Transaction 4	free
Transaction 5	alpha

Our current phrase/state is ‘cryptonary solana podcast’, represented by:

213330553f1a6d846b13b1bc28acced932c46e82e7b4e6580635a0e38e1115ef

We want to add ‘free alpha’ onto the phrase, similarly to how new transactions would be ordered, broadcast, carried out and verified. To do this, we take the current state and append the new transactions and phrases as shown below:

Input: 213330553f1a6d846b13b1bc28acced932c46e82e7b4e6580635a0e38e1115ef free alpha

Hash with SHA-256

7da087187afd6e94aab3893245c7be1c869daa0ee6f165bf7cced879209a264a

The current phrase/state in its hash form is shown in bold in the above example. The appended words are shown in italic in the input.

The output as mentioned before is truly unique to the input. Thus, it can only be obtained if the previous state has been acquired by hashing with SHA-256, hence proof of history. It is also proof that time has passed. To arrive to a new state, it is necessary that hashing with SHA-256 has been done. This requires time spent by a computer to do this. This means we can trust that real time has passed between the states.

You will also notice that this time we only added two transactions and words, not three as was the case in the first operation. This is an important factor. It allows Solana transactions to occur at the speed that the leader and validators can carry out the SHA-256 function to update the ‘state’. Just like the previous example, the author broadcasts the order of the new words to be added to the phrase, and the resulting state to the readers. This process is similar to the leader broadcasting the order of new transactions and resultant state to the verifiers. Once the new state is confirmed by enough verifiers the loop begins again. The process is continually repeated, adding more transactions each time and building up the history. After two more loops, the leader would be changed in the Solana network. The current leader would become a verifier, and one of the current verifiers would be randomly selected to become the leader.