Michael Sutton

The case for the uniqueness of fast pow tl;dr Finality has two moving parts: (i) fast inclusion (= high bps, how quickly a tx gets into a block), and (ii) fast confirmations (= how quickly that tx becomes irreversible). Any system with rapid block production can achieve the first. The second is where the tension shows: in pos, fast confirmations press directly against decentralization. In fast pow, the two properties are decoupled. prologue A few weeks ago I came across Solana’s founder claiming: “Solana is the fastest monetary system in the world”. Since Kaspa already runs at a faster block rate, I was curious to check Solana’s finality times. That curiosity quickly pointed me to a deeper issue: not raw speed, but how speed interacts with decentralization. —————— The tension is structural. In pos, finality means accumulating staked votes, and the more decentralized the stake distribution, the more time is required to reach finality. Here I’m not talking about hardware requirements or validator specs. The axis I’m discussing is centralization around the security mechanism itself: stake in pos vs. hardware in pow. To be secure, a block must be confirmed by a supermajority--typically >66.7% of the total economic stake. In a truly decentralized network, where n stakers with uniform share grows without bound, the time to coordinate this supermajority becomes a real bottleneck. Pow works differently. It samples the hardware space without requiring the protocol to explicitly collect evidence from a majority of miners. Each block is itself a statistical proof that the finder out-competed the full network’s hash power. This process--and its timing--remains independent of how many individual miners participate. Ethereum’s researchers understood this when moving to pos. Unlike Solana, which tolerates concentration to reach ~13-second finality, Ethereum’s designers could not accept that trade-off. Their solution was to introduce rotating committees. A rotating committee is a smaller subset of validators, randomly chosen from the full set, that votes on behalf of everyone else. But this comes with a different security model, known in the literature as exposure to a BFT adaptive attacker. The committee is selected first and then votes. That “select-then-work” sequence is theoretically exposed to adaptive attackers, since members are known in advance. Pow, by contrast, is “work-then-select”: the winner is only revealed after the work is done. Think of it this way: in pos, you know who the referees are before the game starts, which gives an attacker time to pressure them. In pow, you only learn who won after the work is already done, which removes that attack surface. So n confirmations provide consistent confidence regardless of miner granularity, and the system stays secure even under adaptive targeting. Beyond attack subtleties, the real issue is economic weight. When I send a billion-dollar transfer in a pos system, the question I care about is simple: how much stake is actually securing it? A committee vote provides strong statistical evidence, but only a true supermajority puts the full economic stake of the network behind my confirmation. In other words, a sampled committee may convince me that things are probably safe, but only the weight of the entire stake provides an overwhelming guarantee. And this is exactly where pow shines: each confirmation is not just a probability estimate, but a direct proof of work done against the full hash power of the network, no matter how many miners there are. closing remark I don’t claim to know every engineering detail of Ethereum or Solana. But I’m convinced the core principle holds. I’ll state it simply: fast pow uniquely enables fast finality without forcing a compromise on decentralization.

Imho, this *being able to verify* capability is a must for any serious content producer. For cs people: NP is an important human class as well

I saw this got exaggerated by several follow-up posts, so let me put it in perspective. This is mostly a boring correct choice in parts of the L1<>ZK interface where the same commitments need to be handled both by L1 nodes and by zk provers. You can think of these commitments as an L1 compression layer: L1 headers publish compact commitment data about which transactions were accepted by the DAG and in what order, and the prover later re-expands the relevant parts inside the zk guest using witnesses + public args. That is exactly why the hash here cannot be chosen from a purely “what is nicest for CPUs” or purely “what is nicest for circuits” perspective. It has to live on both sides. blake3 is not some unique Kaspa edge by itself. It is just one pragmatic point in the design space. In fact, it is not even uniformly ideal across zk stacks; it is much more natural for RISC-V oriented proving flows than for cairo-style ones. So yes, this matters. But mainly as another piece of careful systems design, not as a headline advantage on its own