There is a saying that "Engineering is finding the best compromises". You know about the Crypto Trilemma: Secure (S), Fast (F), Decentralized (D).
Think of it as you have 15 eggs (I show them with 0) and 3 baskets. For Bitcoin/ETH, it may look something like this:
S: 00000
F: 00000
D: 00000
When we say Fast, think of it as "fast for the transaction fee you spend". So a cheaper network is somewhat considered a faster one too. Bitcoin Cash was not happy with the speed of BTC, so they went with:
S: 00000
F: 0000000
D: 000
But not all these 3 are "perceived" equally. Usually people only see speed, so for a new blockchain to "look" impressive, it can do something like:
S: 0
F: 0000000000000
D: 0
EOS and XRP are examples of this approach. Basically, AWS with extra steps (not very decentralized). For EOS, everyone votes for iirc 12 nodes to do all the transaction processing until the next election.
Let's look at Solana's claim on "Proof Of History". Wondering why other networks did not do an update if it's a great idea. Looking at their dev docs, they introduce this concept of "Cluster", initiated by "Leaders" where "Validators" join them and and "Clients" send transactions to.
> [clusters] simply ignore the existence of the other. Transactions sent to the wrong one are quietly rejected.
So they are breaking down the blockchain into small Validator groups. You have to know which Cluster you want to contact. That's... a compromise. It's not even comparable with ETH or the internet where you have this massive pool of validators that all participate over the same network.
But ok, let's go with the compromise. Then the issues start to emerge. When there are clusters, what happens to the network hash rate? is it divided up? then someone can easily come in and 51% the clusters one by one? Well, they have to work around that. Let's see.
> Additional validators then register with any registered member of the cluster.
Ok, so, if I have a cluster where I know all the Validators, I can collude with them to just ignore any new Validators from coming in?
> A validator receives all entries from the leader and submits votes confirming those entries are valid... Clients send transactions to any validator's Transaction Processing Unit (TPU) port. If the node is in the validator role, it forwards the transaction to the designated leader.
If I'm the leader, can I censor a transaction coming from a Validator? Or perhaps I see a transaction that will move the market, can I sneak in a transaction in my own benefit before broadcasting that one to my validators?
This just kind of a bank.
On a more humane note, I listened to Solana's podcast and I am annoyed that they were dunking on ETH and acted so egotistically "we are new like electric car... people say we are so smart". The blockchain speed/scale limitations are just hard to solve the right way, it's disingenuous to discredit truly brilliant people for your own tech. So maybe I'm dismissive of something that's lying underneath. For what it's worth, Vitalik recently has talked about many of these limitations.
Still, good on Solana for providing legible documentation.