adding a new section for network architecture (#842)

docs/networks/network-architecture/index.md

@@ -0,0 +1,68 @@
+---
+title: Flow's Network Architecture
+sidebar_position: 1
+---
+
+Flow has pioneered a new paradigm of multi-node architecture that solves the core problem of today’s blockchains.
+The result is a scalable, decentralized, and secure network which ensures user safety and long-term sustainability.
+
+To better understand the architecture, lets first understand the problems with the current blockchain. Then lets look at how Flow multi-node architecture solves these problems.
+
+# What are the biggest problems solved by Flow's Multi-node Architecture?
+
+## 1. The blockchain trilemma
+
+A blockchain should be fully decentralized, highly scalable and extremely secure. However a well-known problem with all blockchain is the blockchain trilemma - optimizing for any one edge comes at the cost of the other two.
+
+You can have a chain that is decentralized and secure but not scalable e.g. Bitcoin and Ethereum or you can have a chain that is scalable and secure but not as decentralized e.g. Solana, Aptos and Sui.
+While multi-chain systems like Cosmos, Layer 2 solutions (L2s) like Polygon, and cross-chain bridges offer innovative approaches to address these challenges, they divide the trust into separate and independent security zones and such zones with fewer validators can be more vulnerable to attacks and therefore less secure.
+
+![scenario_1](images/trilemma.png)
+
+## 2. Disadvantaging end-users
+Most blockchains, regardless of the number of participating nodes, inherently disadvantage individual end-users. This is because (colluding) nodes can censor user transactions or unfairly extract value from users in a phenomenon commonly known as Miner Extractable Value [MEV]. As a result, individual end users can end up paying an “invisible tax” or otherwise seeing their transactions fail due to MEV.
+
+
+## 3. Energy inefficient and unsustainable
+It is well established that Proof-of-Work chains like Bitcoin consume massive amounts of energy, require perpetual hardware upgrades for the miners to stay competitive, and are therefore extremely harmful to the environment. A Proof-of-Stake chain’s environmental impact is less severe, but as web3 applications achieve mainstream adoption, every node in these chains will have to provide more and more hardware resources to meet the increasing throughput demand and the ever growing on-chain state. Vertically scaling the nodes implies higher energy consumption and environmental footprint.
+
+## Multi-node Architecture on Flow
+
+![banner](./images/banner.png)
+
+In first-generation smart contract blockchains like Ethereum and Bitcoin, every node in the network performs all of the work associated with processing every transaction (including the entire network’s history, account balances, smart contract code, etc.). While highly secure, it’s also incredibly inefficient, and does not scale throughput (transaction per second, transaction latency) and capacity (on-chain data storage).
+
+Most second-generation blockchain networks focus on improving performance in one of two ways:
+
+1. They compromise decentralization by requiring that participating nodes run on powerful servers (e.g. Solana); or
+2. They dramatically increase smart developer complexity by breaking up the network through mechanisms such as sharding (e.g. L2s such as Polygon).
+
+The first approach is vulnerable to platform risk and cartel-like behavior. The second approach outsources the challenges of scaling the platform, effectively handing off the complexities of bridging the different strongly-federated ecosystems to application developers.
+
+Flow offers a new path: pipelining applied to blockchain networks.
+
+Pipelining is a well-established technique across various fields, from manufacturing to CPU design, for significantly increasing productivity.
+Flow leverages this concept by distributing the tasks typically handled by a full node in a monolithic blockchain architecture across four specialized roles: Collection, Consensus, Execution, and Verification.
+This division of labor between nodes occurs within the different validation stages for each transaction, rather than distributing transactions across different nodes as is done with sharding.
+In other words, every Flow node still participates in the validation of every transaction, but they do so only at one of the stages of validation.
+They can therefore specialize—and greatly increase the efficiency—for their particular stage of focus.
+
+![scenario_1](images/flow_node_types_1.gif)
+
+### Flow node types and what they do
+
+|                                          |   Node type    | Responsibility                                                                                                                              | What do the nodes of this type do?                                                                                                                              |
+|------------------------------------------|:--------------:|:--------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| ![collection](images/collection.png)     |   Collection   | Collection nodes act as a censorship-resistant data availability layer, which caches transactions for subsequent execution.                 | Collection nodes order transactions into batches known as collection.                                                                                           |
+| ![consensus](images/consensus.png)       |   Consensus    | The consensus committee serves as the security authority in the network and orchestrates Flow's transaction processing pipeline.            | Consensus nodes order collections into blocks and commit execution results after verification.                                                                  |
+| ![execution](images/execution.png)       |   Execution    | Execution nodes provide the computational resources for executing transactions and maintaining the state.                                   | Execution nodes execute the transaction and record state changes.                                                                                               |
+| ![verification](images/verification.png) |  Verification  | Verification nodes ensure that transactions are truthfully executed.                                                                        | Verification nodes verify the work of the execution nodes. They either approve or disagree with their results, reporting their findings to the consensus nodes. |
+| ![access](images/access.png)             |     Access     | Access Nodes route transactions into the network and replicate (parts of) the state and transaction results for external clients to query.  | Access node serve the API calls to send and read data from the chain.                                                                                           |
+
+### Further reading
+1. [Primer on multi-node architecture](https://flow.com/primer#primer-multinode)
+2. [Technical papers](https://flow.com/technical-paper)
+3. [Core protocol vision](https://flow.com/core-protocol-vision)
+4. [Medium article from Jan which deep dives into the Flow architecture](https://jan-bernatik.medium.com/introduction-to-flow-blockchain-7532977c8af8)
+
+In the next section, lets look at how Flow multi-node architecture solves those three big problems with blockchains.

docs/networks/network-architecture/solving-blockchain-trilemma.md

@@ -0,0 +1,51 @@
+---
+title: Solving the blockchain trilemma
+sidebar_label: Solving the blockchain trilemma
+sidebar_position: 2
+---
+
+# Solving the blockchain trilemma
+
+In a monolithic architecture, all nodes perform every task. As network usage grows, the transaction processing capacity of the individual nodes becomes a limiting factor, restricting the network’s throughput and latency. The amount of data that can be stored on-chain is limited since nodes have a finite storage capacity. The only way to scale monolithic blockchains is by increasing the capacity of each node by adding more CPU, memory, and storage (i.e. vertical scaling, an approach taken by Solana). However, this solution comes at the cost of decentralization. As nodes scale vertically, they become more expensive to run, and eventually, only a few operators can afford to run such high-performance, high-capacity nodes. Worse, energy consumption for every node in the network increases over time, making the chain environmentally unsustainable.
+
+Through its multi-node architecture, Flow implements a modular pipeline for processing transactions. This design allows the network to scale by tuning the level of decentralization at each specific step without sharding the state and fragmenting the network into smaller security zones.
+
+The modular pipeline is composed of Collection, Consensus, Execution and Verification Nodes.
+
+![pipeline](images/pipeline.png)
+
+
+## Separating Consensus from Compute
+
+At a high level, the pipeline essentially separates consensus from transaction computation. Non-deterministic (or “subjective”) processes such as determining the inclusion and order of transactions are decided by the broadly decentralized consensus committee. The deterministic (or “objective”) task of computing the result of those ordered transactions is done independently by a small number of specialized execution nodes.
+
+Collection and consensus are highly decentralized and achieve high levels of redundancy through a large number of lightweight, cost-effective nodes, numbering in the thousands, operated by several hundred different operators. These steps guarantee resilient transaction ordering (assuming that a malicious actor can only compromise a limited number of nodes).
+
+In comparison, transaction execution has low decentralization and redundancy (10 or less) with more powerful and expensive nodes. To accommodate for the anticipated growth of on-chain state without sharding, only the execution nodes have to be scaled vertically. All other node types can continue to run low-cost hardware. The execution nodes may eventually be scaled up to small data centers.
+
+![scaling_flow](images/scaling_flow.png)
+
+Low decentralization for transaction execution might appear to compromise decentralization of the whole network, as it is conceivable that a malicious actor might compromise a dominant fraction of nodes participating in execution. However, correctness of the transaction results is still guaranteed by the verification step, which also requires reasonably high redundancy, again with a large number of lighter and less expensive verification nodes to withstand compromisation attempts.
+
+Every node in Flow makes the protocol stronger, and the network can grow as needed to achieve different objectives:
+- More censorship resistance? Add more collection nodes
+- More decentralized block production? Add more consensus nodes
+- Need to accommodate higher transaction throughput and state storage? Scale up execution nodes
+- Do node operators want to reinforce network security with modest node hardware and low stake? Add more verification nodes.
+- Need access to chain data locally? Add access nodes.
+
+In contrast, when traditional Layer 1 blockchains add more nodes to increase decentralization, they do so without providing any additional benefits.
+
+![verying_redundancy](images/varying_redudancy.png)
+
+> Flow’s architectural goals are to provide a throughput of at least 1M TPS, ingest at least ½ GB of transaction data per second and store and serve a very large state of one Patebyte and beyond.
+
+Thus, Flow’s multi-node architecture solves the blockchain trilemma:
+
+1. **Scalability**: Scale to thousands of times higher throughput and on-chain storage capacity.
+
+2. **Decentralization**: Except for the execution nodes, all nodes are light weight and low cost, lowering the barrier to entry and ensuring participation from a diverse set of node operators—big and small
+
+3. **Security**: Maintain a shared non-sharded execution environment for all operations on the network and use a secure in-built platform to build on.
+
+![trilemma_solved](images/flow_trillema_solved.png)

docs/networks/network-architecture/sustainability.md

@@ -0,0 +1,20 @@
+---
+title: Sustainability
+sidebar_label: Sustainability
+sidebar_position: 3
+---
+
+# Sustainability with Flow
+
+It's no secret that Proof of Stake blockchains are better for the environment.
+As Web3 becomes more widely adopted, we engaged with Deloitte Canada to validate how much energy it uses.
+And the results are astounding: Flow uses just 0.18 GWh annually, based on 2021 usage – or in simpler terms, minting an NFT on Flow takes less energy than a Google search or Instagram post.
+
+
+In addition to operating on a Proof of Stake consensus system, Flow’s multi-role node architecture securely divides the processing between specialized node types, making the network significantly more efficient than other blockchain architectures.
+As network usage grows, vertical scaling is only needed for the execution nodes (as they execute transactions and persist all the chain state).
+Because the increase in energy and hardware consumption over time is restricted to a small subset of the nodes in the network, this drastically limits the environmental footprint of the chain.
+
+The overall energy use of the network won’t increase significantly even if the activity increases by 100x or more, making the per-transaction energy footprint decrease over time.
+
+Read more about it [here](https://flow.com/post/flow-blockchain-sustainability-energy-deloitte-report-nft).

docs/networks/network-architecture/user-safety.md

@@ -0,0 +1,20 @@
+---
+title: User safety
+sidebar_label: User safety
+sidebar_position: 4
+---
+
+# User Safety with Flow
+
+The monolithic node design of common L1s such as Bitcoin and Ethereum overly privileges operator control over block production.
+This makes the chain vulnerable to censorship and MEV attacks. This problem is exacerbated by L2s with centralized sequencers. ERC-4337 is also susceptible to MEV on the user operations via bundlers.
+
+![mev](images/mev_attack.png)
+
+Flow’s multi-node architecture provides censorship & MEV resistance by design:
+- Transactions are randomly assigned to collection nodes for inclusion in collections and eventually in blocks. Each collection node only sees a subset of transactions.
+
+
+- There is already a distinct separation between the proposers (represented by the collection nodes) and the builders (represented by the consensus nodes). This separation essentially provides an inherent implementation of "proposer-builder separation," a concept currently being explored by Ethereum. With this separation, even if the collection nodes were to reorder the transactions, there is no incentive for the consensus nodes to prefer one collection node’s proposal over another.
+
+![mev_protection](images/mev_protection_in_flow.png)

sidebars.js

@@ -17,9 +17,14 @@ const sidebars = {
   networks: [
     'networks/index',
     {
-      type: 'link',
+      type: 'category',
       label: 'Network Architecture',
-      href: 'https://jan-bernatik.medium.com/introduction-to-flow-blockchain-7532977c8af8',
+      link: { type: 'doc', id: 'networks/network-architecture/index' },
+      items: [
+        'networks/network-architecture/solving-blockchain-trilemma',
+        'networks/network-architecture/user-safety',
+        'networks/network-architecture/sustainability'
+      ],
     },
     {
       type: 'category',

src/ui/design-system/src/lib/Components/LinkGrid/index.tsx

@@ -95,7 +95,7 @@ const sections: LinkGridSection[] = [
       },
       {
         title: 'Network Architecture',
-        href: 'https://jan-bernatik.medium.com/introduction-to-flow-blockchain-7532977c8af8',
+        href: '/networks/network-architecture',
       },
     ],
     imageName: 'docs-the-stack',