In the rapidly evolving world of Web3, scalability is key to creating a truly decentralized and accessible internet. Among the many blockchain platforms competing for dominance, Flow stands out due to its innovative modular design which is decentralized, secure, and efficient, making Flow an ideal platform for consumer applications and institutional entrants to Web3.

In this document, we will explore how Flow's architecture allows it to scale effectively while maintaining security and decentralization. We will also compare Flow with other prominent blockchains like Solana and Base to highlight what makes Flow unique.

Introduction

Flow was originally designed after scalability issues on Ethereum came to a head with the wild popularity of Cryptokitties. The Cryptokitty app designers realized drastic changes must take place before Web3 can support consumer-grade adoption. To better deliver a decentralized, secure, and rapidly scalable Web3 network model, they conceived Flow. The core of Flow is multifaceted—rather than using monolithic nodes where each node implements all stages of the transaction processing pipeline, on Flow each of five transaction processing steps runs on a specialized node type. In unison, the various components of the five node types deliver a highly efficient computation platform that overcomes many of the drawbacks other networks struggle with.

Modular Design On Flow

Flow addresses the fundamental challenges in blockchain technology—the blockchain trilemma, which posits that a blockchain must make trade-offs between scalability, decentralization, and security. Traditional blockchains cannot fully achieve all three properties simultaneously, but Flow's modular design provides an elegant solution that maximizes each aspect.

Solving the Blockchain Trilemma

In traditional monolithic blockchains, every node does all of the work. In a nutshell, the blockchain’s entire functionality is provided by a single node. For decentralization, instead of one node, n independent node copies (replicas) are used, which make the resulting network resilient against failures. However, the limitation of all the functionality needing to fit into one node (server) remains, while the energy and hardware costs increase by a factor of n. In comparison, Flow consists of specialized node types:

• Collector Nodes are responsible for data availability, minimizing the data per block to less than 1MB, even if the network is processing millions of transactions per second. Ethereum is exploring conceptually similar directions with ‘data availability shards’ and ‘danksharding’.
• Consensus Nodes are optimized for decentralized decision-making. Without the burden of needing to inspect transactions, transaction execution, and state storage, they can very quickly agree on what transactions to schedule for execution and their order. Transaction execution and verification of execution results are offloaded to Execution and Verification Nodes, respectively. To compare, L2s have a similar effect in the Ethereum ecosystem: offloading mundane transaction execution and state storage of the L1’s consensus participants for scalability.
• Execution Nodes handle the computationally intensive task of executing transactions and storing the state. Execution Nodes could be best compared with L2 sequencers.
• Verifier Nodes re-execute transactions to guarantee that only correct transaction results are committed. In particular, Verifier Nodes don’t store the state but receive cryptographic witnesses from Execution Nodes proving honest transaction execution. Ethereum is researching comparable approaches to stateless verification.

With its unique architecture, Flow has the potential to scale beyond 1 million transactions per second at maturity and to store petabytes of state data—requiring only one-tenth of the hardware and energy of traditional monolithic chains. 

‍

Solana and Base provide prominent archetypes for a tangible comparison of the pipelined architecture of Flow versus traditional monolithic chain or L2 implementations.

Flow vs L1 (e.g. Solana) vs L2 (e.g. Base)

Solana is decentralized now because the network’s computation load and state size are easily manageable by an average personal computer. However, this is going to change if usage grows, because all node operators would have to vertically scale their nodes. So, for example, if the Solana state grew to 1PB and 50 CPUs were required to process the incoming transactions, every node would need the corresponding hardware to keep up.

As Vitalik Buterin explains, skyrocketing hardware costs are a major driver for centralization. So in the future, Solana (and all other monolithic L1s) will either compromise decentralization or admit that use-cases are viable on their platform, but only if the total worldwide computing load is comfortably satisfied by a single home server!

‍

Ethereum operates with native computing capacity that must fit within a home server and uses L2s, such as Base or Optimism, for scaling. L2s are highly centralized by design, with weak resilience, lacking mechanisms to guarantee correctness and censorship concerns. While Base has committed to implementing fault proofs eventually, Optimism is already working on it and Arbitrum already has them on mainnet, a core decentralization problem remains. An L2 has generally only a single sequencer, which maintains the entire state and decides which transactions to include and their order. An auditable trail of work is created as the L2 sequencer and the underlying L1 produce blocks, allowing staked validator nodes (Arbitrum) or arbitrary community members (out of the goodness of their hearts in case of Optimism) to repeat the computation and confirm correctness. Nevertheless, whoever controls the sole sequencer decides what transactions are accepted and in what order, bypassing the expensive and slow L1. So in terms of objective properties, L2s are largely centralized with only decentralized verification.

In terms of computational resources, L2s are an effective way of scaling a blockchain, because doubling the number of L2s means that the combined system can theoretically process twice as many transactions. We have talked about the centralization, resilience, and censorship challenges introduced by L2s, but there is one additional, potentially even bigger problem.

Let’s resort to a thought experiment: You ask your friend for advice because your old laptop is too slow by now and you are running into its limitations all the time. Your friend recommends buying a second old laptop, to double your computational power. The challenges with that proposal are obvious and equally apply to L2s: the onus is on you to run program A on laptop 1 and program B on laptop 2, to remember what data is stored on which laptop, and copy data and computation results. You need to make sure neither computer has security vulnerabilities and check compatibility with your other hardware such as printer and NAS, etc. If you are a software developer, the problem is even more severe: some parts of your software are executed on laptop 1 and other components must concurrently run on laptop 2, so they must exchange data over a slow network connection, and your software should be correct despite running on this concurrent distributed hardware platform. 

‍

The ideal solution is clear: let’s get a new laptop that has twice as many resources, but it is one device. In blockchain terms: an integrated platform that scales like many L2 under the hood, but behaves like an L1. Flow’s vision is exactly that: developers get the convenient atomic state updates and direct calls of other smart contracts without asynchronous bridging but without scaling limitations. This frees the developer to focus on higher-level work, catalyzes creativity, and reduces the cost and probability of security risks, which in turn benefits users and fosters innovation. 

Blockdaemon and Flow

Blockdaemon takes the concept of implementing the evolved network model of Flow a step further, nullifying management-related concerns for institutional clients. As a white glove service, Blockdaemon makes the entire spectrum of opportunities on the Flow network highly accessible to clientele ready to deploy resources yet in need of specialized guidance to properly navigate the digital asset ecosystem.

Blockdaemon has been operating Flow nodes since network genesis and has expertise in running all five types of nodes. Currently, it runs three consensus nodes and one verification node. It offers fully managed Flow nodes to institutional investors, custodian providers, dApp developers, and anyone who wants to run a staked node or the RPC node.

Conclusion

Flow naturally overcomes the latent drawback of capacity-constrained L1s and centralized L2 networks. The modular Flow protocol efficiently ascribes duties to five node types that operate in unison to deliver a horizontally scalable computation platform. Flow has been architected to scale beyond 1 million transactions per second at maturity while storing petabytes of data at a tenth of the hardware and energy use that monolithic architectures would require. This potential and current level of utility positions Flow as the premier network to host the next generation of decentralized applications for consumers.