One of the most popular layer-one blockchain protocols in operation is Solana. The protocol offers a suite of DeFi applications, a vibrant NFT ecosystem, gaming, and more. 

With a current market cap of $11.5 billion, Solana utilizes a novel consensus mechanism called “proof of history”. However, very few people understand this mechanism. This article will provide an overview of proof-of-history and the background of how blockchain consensus mechanisms evolved to this point.

The Byzantine Generals Problem

Trustless. That’s the significant advantage that decentralized systems have over their centralized counterparts. If you store your wealth in fiat, you trust that a certain number of centralized third parties (your bank, your government) will operate with honesty and competence. But, given (1) these third parties are humans, and (2) history, it is not unreasonable to conclude that sooner or later, this trust will be broken.

Decentralization removes the burden of trusting a centralized third party and outsources that responsibility to the network. However, decentralization creates a new problem. And it’s one that has plagued decentralized systems for decades. If there is no trusted third party, how are decentralized entities (who are often adversarially opposed) ever able to achieve consensus (i.e. agreement, truth, objectivity)?

The Byzantine Generals Problem captures this conundrum. Imagine that several generals have surrounded the City of Byzantine. The generals know that if they attack the city in unison, they will successfully sack it. However, if even one general fails to act accordingly, the attackers will be crushed for lack of manpower. So, the generals need a secure communication system to achieve consensus (agreement on when all are to attack). But the generals doubt the reliability of their messages between each other from fear that Byzantium defenders might have captured at least one courier and altered the message(s). What are the generals to do?

Satoshi’s Solution: Proof of Work

Satoshi Nakamoto used a consensus mechanism called “proof of work” to solve the Byzantine Generals Problem for bitcoin. 

Proof-of-work means that network participants trust the blockchain ledger that contains the most computation work (i.e., applied computational energy). The very core of bitcoin is a mathematical algorithm called “SHA-256”. We will circle back to this later, but for now just understand that a SHA-256 algorithm is a math puzzle that takes computing power to solve. Fundamentally, bitcoin miners use computing power in a race against each other to see who can solve SHA-256 first. The bitcoin protocol requires this algorithm to be solved every 10 minutes so that new transactions can be continually updated on the ledger. 

The high-level take away is that proof-of-work solves the Byzantine Generals Problem because miners are economically disincentivized to lie. Miners must expend energy (computational power + electricity = money) to solve SHA-256. If a particular miner lies (falsifies the transaction data), the other miners will collectively recognize the lie and reject the block (the new addition to that blockchain that contains a specific period of transaction data). Thus, the liar will have expended energy (spent money) but will not receive an economic reward.

There is likely no network more secure than bitcoin. This security results from clever game-theory concepts, cryptography, and high energy expenditure. But the high energy expenditure led to the development of “Proof of Stake”.

Vitalik’s Energy Solution: Proof of Stake

Vitalik Buterin is on a crusade to transition the second-largest crypto network, Ethereum, from proof-of-work to proof of stake. The purpose of this transaction is to reduce the energy expenditure of the Ethereum network. 

Proof-of-stake is an alternative consensus mechanism whereby a decentralized network chooses a “validator” randomly to propose the next block. Once the chosen validator proposes the next block, it is verified by the other validators, and the chosen validator receives a block reward.

Entities become validators by staking (locking up) a certain amount of applicable cryptocurrency onto the network. This very concept is what illuminates the economic incentive that keeps the validators’ honest. A validator is economically incentivized to propose the new block honestly, because successfully doing otherwise would irreparably harm the network, thereby destroying the validator’s own investment (the staked cryptocurrency). 

One particular problem with traditional proof-of-stake networks is that sometimes validators submit blocks at the same time. Therefore, the entire network must slow down to internally communicate with itself as the proper ordering of the blocks are established. This communication traffic jam leads us to the development of “Proof of History”.

Anatoly’s Speed Solution: Proof of History

In 2017, Anatoly Yakavenko proposed a novel proof of stake blockchain called Solana meant to dramatically improve the transaction output over traditional proof of stake networks.

Solana is a proof of stake blockchain plus a few upgrades. Similar to Ethereum, Solana validators (those who have staked a requisite amount of currency onto the network) are randomly selected to propose the next block onto the blockchain. But to avoid a situation where the network is slowed due to two validators submitting blocks simultaneously, the Solana network posts a validator schedule into the future for all to see for a given period of time.

This scheduling dramatically speeds up the processing of the network because the network no longer needs to communicate with itself to figure out the proper ordering. And this is the fundamental reason why Solana processes 65,000 transactions per second compared to Ethereum’s 30 transactions per second.

However, this scheduling concept introduces a new problem! What happens if a dishonest validator tries to jump ahead of another in the line? To put it another way, how can the Solana network verify that the validators followed the outlined schedule?

Proof of History: A SHA-256 Cryptographic Clock

Proof-of-history is a method for verifying that this schedule was followed. A proof of history provides cryptographic proof that a certain event (B) occurred after another event (A), but before a third event (C). Proof of history offers hard proof that A then B then C sequentially occurred, in that specific order. 

To do this, Solana implements a distributed cryptographic clock that runs separately with every validator in the network. From a high level, imagine Solana as a proof of stake system, but underpinning the entire network are separate cryptographic clocks running in unison with each validator. So exactly how does this work?

Enter again the SHA-256 algorithm. In the Solana network, every validator must contribute one, and only one, CPU to run the SHA-256 algorithm. Technically speaking, it is known to a level of extreme precision exactly how long it takes to execute one revolution of the SHA-256 algorithm with just one CPU. These SHA-256 repetitions are called “ticks”. Because a Solana validator must contribute only one CPU to run the SHA-256 algorithm continually, and any single CPU individually processes the SHA-256 algorithm in the same amount of time as any other CPU, then Solana validators can verify that a proposed block was properly submitted, because validators can read each other’s cryptographic clocks to see how many ticks occurred before the block was submitted.

Understanding how blocks and the SHA-256 output data come together is key to understanding the Solana network. As a validator submits his block to be verified, the validator includes his updated SHA-256 sequence into that block. This addition is proof to the rest of the network that the validator has been properly processing his ticks, and never skipped a beat! To put it another way, as a validator is submitting his block to the network, the validator merges the block information (all the transactions within a given period of time) with the ticks from his cryptographic clock (the updated data output of his running SHA-256 algorithm). This merging of data produces one fresh line of code that the other validators can quickly verify.

Then this process is repeated. The next validator takes the summary code from the previous block (again, that summary code is the transaction data + the ticks), the validator adds the new transaction data and his tick data, a new block (and summary code) is produced. And the process is repeated again and again.

Difference Uses of SHA-256 in Proof of Work and Proof of History

At this point, you might be asking yourself what is the exact difference between the use of the SHA-256 algorithm in a proof-of-work protocol like bitcoin, as compared to its use in a proof of stake / proof of history protocol like Solana. Here’s the difference: 

With proof of work, miners race against each other to see who can solve SHA-256 first. Thus, miners are economically incentivized to deploy as much computing power as possible to have an advantage at receiving the block reward. All the energy within the entire network is colliding into this algorithm. SHA-256 is the beating heart of a protocol like bitcoin. This is by design, and it’s what makes it so secure.

With proof-of-history, each validator only contributes one CPU each to run SHA-256. This contribution is solely for keeping a distributed, unified, cryptographic clock between all the validators. The data from these cryptographic clocks do get stamped into each block, but the energy usage to run SHA-256 in Solana is infinitesimally smaller than bitcoin. The algorithm is not the protocol’s core, but more like a sidebar tool that helps keep time.

Conclusion

Proof of work was the first major consensus mechanism to solve the Byzantine Generals Problem. But some believed proof-of-work was energy inefficient and developed proof of stake. Proof-of-stake processing can be sped up if the network is able to execute an orderly schedule of block validators. And that’s why proof of history was developed. Solana achieves blazing fast processing output by implementing a schedule, and then verifying that the schedule was followed with proof-of-history.