Peer review edits

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/starknet_architecture_overview.adoc

@@ -3,7 +3,8 @@
 = Starknet architecture: Overview
 
 :description: An overview of the different components of Starknet, including sequencers, provers, and nodes. Explains the roles of each component and how they interact to create a highly scalable, efficient, and secure network. Debunks common misconceptions about the relationship between sequencers and provers. Discusses the different methods for nodes to keep track of the network's state.
-:keywords: Starknet, Starknet architecture, Sequencers, Provers, Nodes, Starknet roles, Starknet components, Starknet architecture overview, Starknet architecture introduction, Starknet architecture details, Starknet architecture explanation, Starknet architecture guide, Starknet architecture tutorial, Starknet architecture documentation, Starknet architecture manual, Starknet architecture reference, Starknet architecture handbook, Starknet architecture how-to, Starknet architecture introduction, Starknet architecture overview, Starknet architecture introduction, Starknet architecture details, Starknet architecture explanation, Starknet architecture guide, Starknet architecture tutorial, Starknet architecture documentation, Starknet architecture manual, Starknet architecture reference, Starknet architecture handbook, Starknet architecture how-to
+:keywords: Starknet, Starknet architecture, [.x .x-first .x-last]#sequencers#, Provers, Nodes, Starknet roles, Starknet components, Starknet architecture overview, Starknet architecture introduction, Starknet architecture details, Starknet architecture explanation, Starknet architecture guide, Starknet architecture tutorial, Starknet architecture documentation, Starknet architecture manual, Starknet architecture reference, Starknet architecture handbook, Starknet architecture how-to
+
 
 Starknet is a coordinated system, with each component—sequencers,
 provers, and nodes—playing a specific yet interconnected role. Although
@@ -21,7 +22,7 @@ tags it as `ACCEPTED_ON_L2`. The final step involves the prover, which
 executes the operating system on the new block, calculates its proof,
 and submits it to Layer 1 (L1) for verification.
 
-For more information on the transaction flow, see xref:Network_Architecture/transaction_life_cycle.adoc[].
+For more information on the transaction flow, see xref:Network_Architecture/transaction-life-cycle.adoc[].
 
 image::transaction-flow.png[]
 
@@ -209,14 +210,14 @@ Starknet.
 Each type of node setup comes with its own set of hardware requirements
 and trust assumptions.
 
-=== Nodes That Replay Transactions
+=== Nodes that replay transactions
 
 Nodes that replay transactions require powerful machines to track and
 execute all transactions. These nodes don’t have trust assumptions; they
 rely solely on the transactions they execute, guaranteeing that the
 state at any given point is valid.
 
-=== Nodes That Rely on L2 Consensus
+=== Nodes that rely on L2 consensus
 
 Nodes that rely on L2 consensus require less computational power. They
 need sufficient storage to keep the state but don’t need to process a
@@ -227,7 +228,7 @@ mechanism and leader election amongst sequencers are in place, these
 nodes will only need to trust that a sequencer who staked their stake to
 produce a block is not willing to lose it.
 
-=== Nodes That Check Proof Validation on L1
+=== Nodes that check proof validation on L1
 
 Nodes that only update their state based on proof validation on L1
 require the least hardware. They have the same requirements as an