Pomegra Wiki

Flow

Flow is a blockchain designed to scale transaction throughput by partitioning validator work across specialised node types—execution nodes that process transactions, verification nodes that check correctness, and consensus nodes that order transactions—rather than fragmenting state across shards. Built to support media and gaming applications, Flow demonstrates that you can increase capacity without asking every validator to maintain every account.

Why the traditional blockchain bottleneck exists

Every blockchain faces a fundamental tension: consensus requires that a supermajority of validators agree on the next block, which demands communication among them. The more validators you add for security, the more messages they must exchange. At the same time, every validator typically maintains a copy of the entire blockchain state—all accounts, balances, contracts. This redundancy is the source of security, but it also sets a hard ceiling on throughput. If you want to process 100,000 transactions per second, each validator would need hardware capable of executing 100,000 transactions per second locally. That bar climbs faster than hardware improves.

Most scaling solutions bite the bullet and shard state: split the blockchain into multiple independent chains that execute transactions in parallel. Ethereum, Bitcoin, and others have explored or adopted sharding. But sharding introduces its own costs—cross-shard communication is expensive, and security becomes fragmented across shards.

Flow’s answer: role separation

Flow takes a different path. Instead of asking all validators to do all work, it splits validator responsibilities into three roles.

Execution nodes receive transactions, execute them against their current state copy, and produce a cryptographic proof (technically, a collection-state commitment). They do the hardest computational work but do not participate in consensus ordering. Hundreds of execution nodes can run in parallel.

Verification nodes check that execution nodes performed their work correctly. They do not re-execute every transaction; instead, they sample transactions and verify the proofs submitted by execution nodes. This sampling is probabilistic but statistically sound: if even a small fraction of verification nodes are honest, they will catch any misdeclared proof.

Consensus nodes form a tight committee that orders transactions and produces the canonical blockchain history. They communicate using Practical Byzantine Fault Tolerance, a protocol that tolerates up to one-third malicious nodes. A dedicated consensus layer is fast because there are fewer of them and they only order transactions, not execute them.

In addition, collection nodes act as gateways, accepting user transactions and routing them to the network.

This separation allows execution and verification to scale independently of consensus. Flow can add more execution nodes to handle more transactions without slowing down the consensus layer or requiring every validator to store every state change.

The trade-offs

Flow’s design is elegant but comes with costs. First, it requires more infrastructure. A full validator on Flow runs multiple node types, and smaller participants may only run one type. This creates a spectrum of involvement rather than the homogeneous validator set that Bitcoin or early Ethereum aspired to.

Second, the role separation introduces latency. Execution and verification add steps between transaction submission and finality. A transaction must be executed, then verified, then consensus must order it. Chains like Bitcoin with a single unified validator role can achieve finality in a single round of consensus (modulo Nakamoto finality); Flow adds extra layers.

Third, the correctness of the entire system depends on the statistical honesty of verification nodes. If the sampling probability is set too low, a coordinated set of execution nodes might slip false state past them. Flow’s parameters try to make this infeasible, but the threat model is more complex than a simple majority-of-stake requirement.

Implementation and adoption

Flow was built by Dapper Labs (now rebranded as Dapper), the team behind CryptoKitties, the early blockchain game that made Ethereum’s scalability limits visible. That pedigree shows: Flow is engineered to feel smooth for non-technical users. It supports flow wallets that work with phone numbers, offers low transaction fees, and has attracted games, NFT marketplaces, and media companies.

The network uses Proof of Stake and offers staking rewards in FLOW tokens. As of recent checks, the network remains active but has smaller total value locked than Ethereum or Solana, reflecting both its smaller developer base and its narrower use case (media and gaming rather than general finance).

Flow demonstrates a real architectural choice: rather than chase the highest possible throughput via sharding or rollups, you can achieve meaningful scale by reconceptualising what a validator does. By letting execution be stateless and distributed, and consensus be narrow and fast, Flow sidesteps the need to fragment state. For applications that fit its design—particularly those that can tolerate the additional latency—it offers a cleaner scalability story than sharded systems.

See also

Wider context

  • Cryptocurrency Exchange — where FLOW tokens are traded
  • Bitcoin — the original blockchain with simpler validator roles
  • Internet Computer — alternative L1 with different execution model
  • Celo — another L1 focused on specific user needs
  • Scroll — L2 scaling solution using different technique