Solana scales to 65k transactions per second, while other popular blockchains do not scale as much. For example, the average Bitcoin network processes around 7 transactions per second, and the Ethereum network processes around 15 transactions per second.

The Ethereum network plans to switch to proof-of-stake and there are other layer 2 solutions that improve the throughput of the network. In the meantime Solana presents a much higher throughput than Ethereum.

Usually when blockchains increase throughput, they increase centralization. That’s known as the Scalability Trilemma, first defined by Vitalik here. It states that if you stick to "simple" techniques, you can only get two of those three. The three properties are:

• Scalability: the chain can process more transactions than a single regular node (think: a consumer laptop) can verify.
• Decentralization: the chain can run without any trust dependencies on a small group of large centralized actors. This is typically interpreted to mean that there should not be any trust (or even honest-majority assumption) of a set of nodes that you cannot join with just a consumer laptop.
• Security: the chain can resist a large percentage of participating nodes trying to attack it (ideally 50%; anything above 25% is fine, 5% is definitely not fine).

So given that Solana processes around 65k transactions per second, is it more centralized than other networks?

Nakamoto Coefficient

The first part of this is to analyze the Nakamoto Coefficient, which was introduced by @balajis:

If we look at Solana’s Nakamoto Coefficient, it is around 19. On the other end of the stick there is Ethereum, which only needs 3 miner pools to collide. Practically, Ethereum’s Nakamoto Coefficient is 3.

Now how does Solana achieve such a high throughput without compromising with centralization. It solves with a clever design. Let’s go through it

Solana’s design

Technically, proof-of-work and proof-of-stake are not consensus protocols by themselves, but they are often referred to as such for simplicity. They are actually Sybil resistance mechanisms and block author selectors; they are a way to decide who is the author of the latest block. It's this Sybil resistance mechanism combined with a chain selection rule that makes up a true consensus mechanism.

A chain selection rule is used to decide which chain is the "correct" chain. Ethereum and Bitcoin currently use the "longest chain" rule, which means that whichever blockchain is the longest will be the one the rest of the nodes accept as valid and work with. For proof-of-work chains, the longest chain is determined by the chain's total cumulative proof-of-work difficulty.

When transactions occur, they are timestamped according to their local system clock. Then, when other nodes verify the transactions, messages about their confirmation or rejection are also timestamped. The inherent discrepancies between local system clocks (even those from nodes acting in good faith) ultimately pave a path for attacks where bad actors can try to take over a cryptocurrency network using fake transaction broadcasts that closely approximate real timestamps — for example, “fake stake” (or “resource exhaustion”) attacks in the case of PoS, and Denial-of-Service (DoS) attacks in the case of PoW. To ensure that transactions have not been manipulated and that funds are spent only once, a lot of time and processing power needs to be dedicated to verifying timestamp accuracy in a PoW or PoS system.

For Solana, this problem is solved by the creation of Proof of History. In this way, nodes can guarantee that there was an amount of time that has passed by using a verifiable delay function. And using it, Solana guarantees that there are clocks that are “synchronized”.

When all the respective clocks across the decentralized network are synchronized, transactions take much less time to verify because individual nodes do not have to dedicate so much processing power toward verifying various timestamps. This synchronization allows the network to optimize for speed, and as a result, the Solana blockchain is inherently fast and engineered for native scalability — enabling higher energy efficiency and higher security through the low processing power and the tamper-resistant nature of its synchronized timestamps. Solana’s efforts to boost transaction speed rely on a semi-centralized structure in which a node leader is elected and all nodes agree to adopt one universal source of time.

Solana is fast because it uses a pre-determined leader schedule that all validators calculate the same way without having to communicate with each other since the schedule is a function of data already on the blockchain.

Solana’s built-in mechanism for synchronizing time across nodes helps the network support a theoretical peak capacity of 65,000 transactions per second, currently

Blocks are only accepted if they follow that leader schedule. In this way, random validators cannot insert themselves into the schedule.

To prevent validators from 'skipping' the validator that comes before them, Proof of History is used to force all validators to spend a minimum amount of time before they could even submit their block. Thus if validator B follows validator A, B cannot try to skip A by chaining off its previous block, because B has to run the Proof of History algorithm at least as long as A does, so A will get a fair chance of submitting their block.