Among modern layer-one blockchains such as Bitcoin and Ethereum, honesty and legitimacy come at the cost of efficiency. On the Bitcoin blockchain, miners first compete in a guess-and-check race to compute a hash lower than a target value. Then, validator nodes confirm this hash and converge on the correct block ordering. This process, which implements a Proof-of-Work mechanism, is wildly inefficient. To allow miners enough time to complete their task, target hashes are set such that forming a block takes miners approximately 10 minutes on average. This is the issue that Solana and its elegant Proof-of-History (PoH) solves.

Proof-of-History establishes a trusted source of time, allowing validator nodes to order blocks solely based on timestamp. At any time, a leader is chosen based on a Proof-of-Stake election to be the generator of the PoH. This PoH relies on the one-way SHA-256 function to associate data with a verifiable timestamp. PoH is created by establishing a sequence of hashes, with each hash being the SHA-256 output of the previous hash:

Note that in this image, hash3 incorporates hash2, and hash2 incorporates hash1. Thus, we can reasonably conclude that hash3 may only exist if hash1 and hash2 already exist. We can liken this process to Jenny, an honest, hardworking student, summarizing chapters of Great Expectations in permanent marker. First, Jenny takes notes on chapter one. She then takes notes on chapter two, and so on. If Bob observes Jenny taking notes on chapter ten, Bob can conclude that Jenny already took notes on chapter nine and every prior chapter – this is because her notes for chapter ten incorporate context from prior chapters! In this analogy, taking notes is equivalent to creating the next hash in the sequence. We may also then say that the only way to generate notes on chapter ten is by reading chapters one through nine. Equivalently, because of the unpredictability of the SHA-256 function, the only way to compute the hash at index i is by recursively applying the SHA-256 function on indices [0,i-1]. Using this concept of time via recursive hashing, the leader can append data to hashes along this sequence to establish a chronological ordering:

In this image, the leader has embedded photograph1 within hash336 and photograph2 within hash600. Since hash600 is a subsequent product of hash336, we can conclude that photograph1 was taken before photograph2. Going back to our example, since Jenny is such a hardworking student, she copies any images in her book onto her notes. If photograph1 is an image in chapter one, and photograph2 is an image in chapter eight, any Bob, our observer, can conclude that Jenny copied photograph1 to her notes before she copied photograph2. It is key to note that Bob can conclude this without needing to reference a timestamp associated with each image; he can conclude this because of the chronological nature of Jenny’s notes. We can apply this concept of ordering to transactions by appending transaction data instead of photographs, thus giving a detailed history of transactional data.

Proof-of-History hash sequences are easily verifiable – validator nodes simply ensure that each output hash is the SHA-256 of the previous hash appended with any data that is inserted. Notably, this validation can occur in parallel: each core on a validator GPU validates a short subsequence of the total PoH and confirms that its final hash is the input to another core’s subsequence. If the general equation to produce a PoH sequence is:

then the equation for verifying a sequence is:

As you can see, as the number of cores on validator GPUs increases, the time needed to verify the sequence decreases (today, GPUs have thousands of cores). The key difference between Solana’s PoH and Bitcoin’s PoW is that SHA-256 validation is far quicker than SHA-256 generation.

In alternative blockchain technologies such as Bitcoin, wallclock timestamps denote ordering for submitted blocks; factors such as network latencies require approximately a one-hour buffer before these timestamps are valid for all nodes. In Solana, blocks consist of the PoH hashing sequence containing all embedded transactions, some metadata containing the number of transactions in the sequence, and a final state that serves as a timestamp. This final state is dependent only on the ordering of hashes – it is essentially wallclock-time-independent and instantly accurate for all nodes. When validator nodes receive blocks out of order, they can easily reorder the sequence by comparing the final states of each block. Once ordered, each validator node verifies each block by quickly computing its hashing sequence in parallel. If verified, the leader commits the block to the ledger.

The PoH algorithm establishes efficiency not only on a single sequence but across sequences. Instead of appending data to the current output hash, consider appending the current hash of another leaders’ PoH sequence. Then, we have synchronized the two PoH sequences and can compare hash indices of all data within both sequences to determine ordering:

Here, Generator B includes hash1a when creating hash3b. As a result, hash1a – and any data that it contains – comes before hash3b. To incorporate our running analogy, let us introduce Johnny, another hardworking student that is currently taking notes on chapter three of Oliver Twist. If Jenny were on chapter ten of Great Expectations, and she was to write “Johnny is on chapter three of Oliver Twist'' in her notes for chapter ten, Bob could then look at Jenny’s notes at any time and conclude that any of Johnny’s notes up to chapter three of Oliver Twist were taken before Jenny was on chapter ten of Great Expectations. Here, we create a chronological ordering of data across two sequences. This horizontal scaling is just another level of parallelism on the Solana network. Periodically synchronizing these sequences allows each to take on a portion of network traffic, thus lightening the load of each sequence leader. In practice, horizontal scaling is used to process extreme amounts of data in a given time frame.

The parallelization of the block validation process, elimination of nodal consensus on ordering and time, and horizontal scaling between sequences allows for Solana to achieve transaction speeds unmatched by any other blockchain. Specifically, the Solana network has a maximum throughput of 50,000 transactions per second. In comparison, Ethereum can compute 25 transactions per second, and Bitcoin only 7. On tests that have been run by the Solana community, users have reported bandwidths of up to 100 mbps, and block times of 0.5 seconds.

Solana’s multithreading capabilities allow for parallel processing of smart contracts, while Ethereum can only process one smart contract at a time. In terms of computing, Solana blows the competition out of the water while still maintaining the trust that blockchain technology promises. Why doesn’t everyone use Solana?

As previously mentioned, Bitcoin and Ethereum emphasize security and decentralization at the cost of efficiency – this is due to the famous Blockchain Trilemma. The Trilemma asserts that blockchain technology can not excel in all three of scalability, security, and decentralization; one of these aspects must be sacrificed. In Solana’s case, scalability is prioritized in exchange for a less secure network. By relying on validators that have access to powerful GPUs to maximize throughput, Solana lacks the decentralization, and thus security, of Ethereum and Bitcoin. The cost of high-end GPUs serves as an economic restriction on the number of validator nodes on the Solana network. Currently, the Solana network has around 2,000 validators compared to 10,000 full validator nodes on Bitcoin and 500,000 validators on Ethereum. This small number of validators on the Solana network increases the chance of validator collusion and centralization. As a result, Solana’s security may be compromised if a certain entity achieves a large portion of the validator pool. The use of a Proof of Stake mechanism for validation indicates that a collusion of 33% of the network could compromise consensus and 66% could attack the ledger. Currently, the top 20 stakers on the Solana network make up more than 33% of the network; theoretically, these validators could collude and halt the network at any moment.

In recent times, there have been multiple full-fledged outages of the Solana network, bringing into question the actual decentralized nature of the platform. Just in 2022, there have been 11 major outages (some lasting up to 20 hours) which have frightened Solana developers and users. Due to the unpredictability of these outages, those using the Solana network must always assume that there is no guarantee that a transaction will execute at a given time. As a result, it is agreed within the blockchain space that the security of Solana is questionable.

Brent Friedman (Blockchain at Berkeley Education Department).

Yakovenko, Anatoly. Solana: A New Architecture for a High Performance Blockchain. https://solana.com/solana-whitepaper.pdf.

Among modern layer-one blockchains such as Bitcoin and Ethereum, honesty and legitimacy come at the cost of efficiency. On the Bitcoin blockchain, miners first compete in a guess-and-check race to compute a hash lower than a target value. Then, validator nodes confirm this hash and converge on the correct block ordering. This process, which implements a Proof-of-Work mechanism, is wildly inefficient. To allow miners enough time to complete their task, target hashes are set such that forming a block takes miners approximately 10 minutes on average. This is the issue that Solana and its elegant Proof-of-History (PoH) solves.

Proof-of-History establishes a trusted source of time, allowing validator nodes to order blocks solely based on timestamp. At any time, a leader is chosen based on a Proof-of-Stake election to be the generator of the PoH. This PoH relies on the one-way SHA-256 function to associate data with a verifiable timestamp. PoH is created by establishing a sequence of hashes, with each hash being the SHA-256 output of the previous hash:

Note that in this image, hash3 incorporates hash2, and hash2 incorporates hash1. Thus, we can reasonably conclude that hash3 may only exist if hash1 and hash2 already exist. We can liken this process to Jenny, an honest, hardworking student, summarizing chapters of Great Expectations in permanent marker. First, Jenny takes notes on chapter one. She then takes notes on chapter two, and so on. If Bob observes Jenny taking notes on chapter ten, Bob can conclude that Jenny already took notes on chapter nine and every prior chapter – this is because her notes for chapter ten incorporate context from prior chapters! In this analogy, taking notes is equivalent to creating the next hash in the sequence. We may also then say that the only way to generate notes on chapter ten is by reading chapters one through nine. Equivalently, because of the unpredictability of the SHA-256 function, the only way to compute the hash at index i is by recursively applying the SHA-256 function on indices [0,i-1]. Using this concept of time via recursive hashing, the leader can append data to hashes along this sequence to establish a chronological ordering:

In this image, the leader has embedded photograph1 within hash336 and photograph2 within hash600. Since hash600 is a subsequent product of hash336, we can conclude that photograph1 was taken before photograph2. Going back to our example, since Jenny is such a hardworking student, she copies any images in her book onto her notes. If photograph1 is an image in chapter one, and photograph2 is an image in chapter eight, any Bob, our observer, can conclude that Jenny copied photograph1 to her notes before she copied photograph2. It is key to note that Bob can conclude this without needing to reference a timestamp associated with each image; he can conclude this because of the chronological nature of Jenny’s notes. We can apply this concept of ordering to transactions by appending transaction data instead of photographs, thus giving a detailed history of transactional data.

Proof-of-History hash sequences are easily verifiable – validator nodes simply ensure that each output hash is the SHA-256 of the previous hash appended with any data that is inserted. Notably, this validation can occur in parallel: each core on a validator GPU validates a short subsequence of the total PoH and confirms that its final hash is the input to another core’s subsequence. If the general equation to produce a PoH sequence is:

then the equation for verifying a sequence is:

As you can see, as the number of cores on validator GPUs increases, the time needed to verify the sequence decreases (today, GPUs have thousands of cores). The key difference between Solana’s PoH and Bitcoin’s PoW is that SHA-256 validation is far quicker than SHA-256 generation.

In alternative blockchain technologies such as Bitcoin, wallclock timestamps denote ordering for submitted blocks; factors such as network latencies require approximately a one-hour buffer before these timestamps are valid for all nodes. In Solana, blocks consist of the PoH hashing sequence containing all embedded transactions, some metadata containing the number of transactions in the sequence, and a final state that serves as a timestamp. This final state is dependent only on the ordering of hashes – it is essentially wallclock-time-independent and instantly accurate for all nodes. When validator nodes receive blocks out of order, they can easily reorder the sequence by comparing the final states of each block. Once ordered, each validator node verifies each block by quickly computing its hashing sequence in parallel. If verified, the leader commits the block to the ledger.

The PoH algorithm establishes efficiency not only on a single sequence but across sequences. Instead of appending data to the current output hash, consider appending the current hash of another leaders’ PoH sequence. Then, we have synchronized the two PoH sequences and can compare hash indices of all data within both sequences to determine ordering:

Here, Generator B includes hash1a when creating hash3b. As a result, hash1a – and any data that it contains – comes before hash3b. To incorporate our running analogy, let us introduce Johnny, another hardworking student that is currently taking notes on chapter three of Oliver Twist. If Jenny were on chapter ten of Great Expectations, and she was to write “Johnny is on chapter three of Oliver Twist'' in her notes for chapter ten, Bob could then look at Jenny’s notes at any time and conclude that any of Johnny’s notes up to chapter three of Oliver Twist were taken before Jenny was on chapter ten of Great Expectations. Here, we create a chronological ordering of data across two sequences. This horizontal scaling is just another level of parallelism on the Solana network. Periodically synchronizing these sequences allows each to take on a portion of network traffic, thus lightening the load of each sequence leader. In practice, horizontal scaling is used to process extreme amounts of data in a given time frame.

The parallelization of the block validation process, elimination of nodal consensus on ordering and time, and horizontal scaling between sequences allows for Solana to achieve transaction speeds unmatched by any other blockchain. Specifically, the Solana network has a maximum throughput of 50,000 transactions per second. In comparison, Ethereum can compute 25 transactions per second, and Bitcoin only 7. On tests that have been run by the Solana community, users have reported bandwidths of up to 100 mbps, and block times of 0.5 seconds.

Solana’s multithreading capabilities allow for parallel processing of smart contracts, while Ethereum can only process one smart contract at a time. In terms of computing, Solana blows the competition out of the water while still maintaining the trust that blockchain technology promises. Why doesn’t everyone use Solana?

As previously mentioned, Bitcoin and Ethereum emphasize security and decentralization at the cost of efficiency – this is due to the famous Blockchain Trilemma. The Trilemma asserts that blockchain technology can not excel in all three of scalability, security, and decentralization; one of these aspects must be sacrificed. In Solana’s case, scalability is prioritized in exchange for a less secure network. By relying on validators that have access to powerful GPUs to maximize throughput, Solana lacks the decentralization, and thus security, of Ethereum and Bitcoin. The cost of high-end GPUs serves as an economic restriction on the number of validator nodes on the Solana network. Currently, the Solana network has around 2,000 validators compared to 10,000 full validator nodes on Bitcoin and 500,000 validators on Ethereum. This small number of validators on the Solana network increases the chance of validator collusion and centralization. As a result, Solana’s security may be compromised if a certain entity achieves a large portion of the validator pool. The use of a Proof of Stake mechanism for validation indicates that a collusion of 33% of the network could compromise consensus and 66% could attack the ledger. Currently, the top 20 stakers on the Solana network make up more than 33% of the network; theoretically, these validators could collude and halt the network at any moment.

In recent times, there have been multiple full-fledged outages of the Solana network, bringing into question the actual decentralized nature of the platform. Just in 2022, there have been 11 major outages (some lasting up to 20 hours) which have frightened Solana developers and users. Due to the unpredictability of these outages, those using the Solana network must always assume that there is no guarantee that a transaction will execute at a given time. As a result, it is agreed within the blockchain space that the security of Solana is questionable.

Brent Friedman (Blockchain at Berkeley Education Department).

Yakovenko, Anatoly. Solana: A New Architecture for a High Performance Blockchain. https://solana.com/solana-whitepaper.pdf.