> The DataFinnovation post shows that the problem of implementing an Ethereum-like system whose performance in all cases is guaranteed to be faster than any single node in the network can be reduced to 3-SAT, which is a canonical problem in class NP.
All of that math to prove such an inconsequential point.
In practice, scalability limitations of blockchains don't come from the limitations of a single node's processing power, they come from the overhead of the current naive methods of maintaining consensus over contract state and execution. By lifting the execution overhead using optimistic fraud proofs or zero knowledge proofs, and lifting the state overhead using state sharding and state/history expiry, you end up with a protocol that can come to consensus on arbitrarily complex computations with little more overhead than the computation's resulting state change.
In simple terms, the quoted author misses the forest for the trees. They hold that blockchain protocols can't scale further than the processing power of a single node, but miss that when contract transaction execution verification requirements are reduced by proof schemes to mere state changes, one node could crank through as many transactions as their state changes could saturate a modern CPU/memory/disk pipeline, which it's safe to say is easily upwards of tens of thousands per second - plenty enough to satisfy global demand and enough to stand shoulder to shoulder with the traditional payment processors.