zk style checking

Author: kmurphypolygon

docs/zkEVM/architecture/index.md

@@ -1,6 +1,6 @@
-Various Layer 2 solutions aimed at improving the scalability of the Ethereum network, primarily transaction throughput, have been developed over the past years. The ultimate and intended benefit for Ethereum network users is a reduction in gas fees, while maintaining decentralisation and security.
+Various layer 2 solutions aimed at improving the scalability of the Ethereum network, primarily transaction throughput, have been developed over the past years. The ultimate and intended benefit for Ethereum network users is a reduction in gas fees, while maintaining decentralisation and security.
 
-Polygon zkEVM is a Layer 2 Rollup solution that combines data availability and execution verification in Layer 1 of the Ethereum blockchain to ensure L2 state transition security and reliability.
+Polygon zkEVM is a layer 2 rollup solution that combines data availability and execution verification in layer 1 of the Ethereum blockchain to ensure L2 state transition security and reliability.
 
 This section will describe the infrastructure that Polygon designed and implemented for its zkEVM, with a focus on providing an overview of the components used in the development of the zkEVM Protocol.
 
@@ -10,59 +10,59 @@ This section describes the components used in the Polygon zkEVM to enable transa
 
 The three main components of zkEVM protocol are:
 
-- Trusted sequencer
-- Trusted aggregator, and
-- Consensus Contract (PolygonZkEVM.sol, deployed on L1)
+- Trusted sequencer.
+- Trusted aggregator.
+- Consensus contract (PolygonZkEVM.sol, deployed on L1).
 
 ### Trusted sequencer
 
-The Trusted sequencer component is in charge of receiving L2 transactions from users, ordering them, generating batches, and submitting them to the Consensus contract's storage slots in the form of sequences.
+The trusted sequencer component is in charge of receiving L2 transactions from users, ordering them, generating batches, and submitting them to the consensus contract's storage slots in the form of sequences.
 
 The sequencer executes and broadcasts batches of transactions to L2 network nodes in order to achieve fast finality and reduce costs associated with high network usage. That's before even submitting them to L1.
 
-The Trusted sequencer must run a zkEVM node in sequencer mode and be in control of a Consensus Contract-enforced Ethereum account.
+The Trusted sequencer must run a zkEVM node in sequencer mode and be in control of a consensus contract-enforced Ethereum account.
 
 ### Trusted aggregator
 
-The Trusted aggregator component can compute the L2 State based on batches of L2 transactions executed by the Trusted sequencer.
+The trusted aggregator component can compute the L2 State based on batches of L2 transactions executed by the trusted sequencer.
 
-The main role of the Trusted aggregator, on the other hand, is to take the L2 batches committed by the Trusted sequencer and generate Zero-Knowledge proofs attesting to the batches' computational integrity. These ZK proofs are generated by the aggregator using a special off-chain EVM interpreter.
+The main role of the trusted aggregator, on the other hand, is to take the L2 batches committed by the trusted sequencer and generate zero-Knowledge proofs attesting to the batches' computational integrity. These ZK proofs are generated by the aggregator using a special off-chain EVM interpreter.
 
-The Consensus Contract's logic validates the Zero-Knowledge proofs, resulting in the zkEVM inheriting the L1 security. Verification is required before committing new L2 State roots to the Consensus Contract. A verified proof is an irrefutable evidence that a given sequence of batches led to a specific L2 State.
+The consensus contract's logic validates the zero-Knowledge proofs, resulting in the zkEVM inheriting the L1 security. Verification is required before committing new L2 state roots to the consensus contract. A verified proof is an irrefutable evidence that a given sequence of batches led to a specific L2 state.
 
 !!!info
-     L2 State Root
+     L2 state root
 
-     An L2 State root is a concise cryptographic digest of the L2 State. In case you want to read more about State roots, please check out [this article](https://ethereum.org/en/developers/docs/scaling/zk-rollups/#state-commitments).
+     An L2 state root is a concise cryptographic digest of the L2 state. In case you want to read more about state roots, please check out [this article](https://ethereum.org/en/developers/docs/scaling/zk-rollups/#state-commitments).
 
-The Trusted aggregator should run a zkEVM node in aggregator mode and must control a specific Ethereum account enforced in a Consensus Contract.
+The trusted aggregator should run a zkEVM node in aggregator mode and must control a specific Ethereum account enforced in a consensus contract.
 
 ### Consensus contract
 
-The Consensus Contract used by both the Trusted sequencer and the Trusted aggregator in their interactions with L1 is the PolygonZkEVM.sol contract.
+The consensus contract used by both the trusted sequencer and the trusted aggregator in their interactions with L1 is the `PolygonZkEVM.sol` contract.
 
-The Trusted sequencer can commit batch sequences to L1 and store them in the `PolygonZkEVM.sol` contract, creating a historical repository of sequences.
+The trusted sequencer can commit batch sequences to L1 and store them in the `PolygonZkEVM.sol` contract, creating a historical repository of sequences.
 
-The `PolygonZkEVM.sol` Contract also enables the aggregator to publicly verify transitions from one L2 State root to the next. The Consensus Contract accomplishes this by validating the aggregator's ZK-proofs, which attest to the proper execution of transaction batches.
+The `PolygonZkEVM.sol` contract also enables the aggregator to publicly verify transitions from one L2 state root to the next. The consensus contract accomplishes this by validating the aggregator's zk-proofs, which attest to the proper execution of transaction batches.
 
 ## zkEVM node execution modes
 
 zkEVM node is a software package containing all components needed to run zkEVM network. It can be run in three different modes; as a sequencer, an aggregator, or RPC.
 
 ### Sequencer mode
 
-In the sequencer mode, the node holds an instance of L2 State, manages batch broadcasting to other L2 network nodes, and has a built-in API to handle L2 user interactions (transaction requests and L2 State queries).
+In the sequencer mode, the node holds an instance of L2 state, manages batch broadcasting to other L2 network nodes, and has a built-in API to handle L2 user interactions (transaction requests and L2 State queries).
 
-There is also a database to temporarily store transactions that have not yet been ordered and executed (pending transactions pool), as well as all the components required to interact with L1 in order to sequence transaction batches and keep its local L2 State up to date.
+There is also a database to temporarily store transactions that have not yet been ordered and executed (pending transactions pool), as well as all the components required to interact with L1 in order to sequence transaction batches and keep its local L2 state up to date.
 
 ### Aggregator mode
 
-In the aggregator mode, the node has all the components needed to execute transaction batches, compute the resulting L2 State and generate the Zero-Knowledge proofs of computational integrity.
+In the aggregator mode, the node has all the components needed to execute transaction batches, compute the resulting L2 state and generate the zero-knowledge proofs of computational integrity.
 
-Also, has all the components needed to fetch transaction batches committed in L1 by the Trusted sequencer and call the functions to publicly verify the L2 State transitions on L1.
+Also, has all the components needed to fetch transaction batches committed in L1 by the trusted sequencer and call the functions to publicly verify the L2 state transitions on L1.
 
 ### RPC mode
 
-In the RPC mode, the zKEVM node has a limited functionality. It primarily maintains an up-to-date instance of L2 State, initially with respect to batches broadcast by the Trusted sequencer, and later with sequences of batches fetched from the Consensus Contract.
+In the RPC mode, the zKEVM node has a limited functionality. It primarily maintains an up-to-date instance of L2 state, initially with respect to batches broadcast by the trusted sequencer, and later with sequences of batches fetched from the consensus contract.
 
-The node continuously interacts with L1 in order to keep the local L2 State up to date, as well as to check the synchronization of L2 State roots. The default syncing rate for the synchroniser is every 2 seconds, unless stipulated otherwise in the configuration.
+The node continuously interacts with L1 in order to keep the local L2 state up to date, as well as to check the synchronization of L2 state roots. The default syncing rate for the synchronizer is every 2 seconds, unless stipulated otherwise in the configuration.

docs/zkEVM/architecture/protocol/index.md

@@ -1,12 +1,12 @@
-This document aims to explain how the Polygon zkEVM Protocol manages the L2 Rollup's states while providing state transition verifiability and security.
+This document aims to explain how the Polygon zkEVM protocol manages the L2 rollup's states while providing state transition verifiability and security.
 
 ## Trustless L2 state management
 
-The Trusted sequencer generates batches, but in order to achieve fast finality of L2 transactions and avoid the need to wait for the next L1 block, they are shared with L2 network nodes via a broadcasting channel. Each node will run the batches to compute the resulting L2 state locally.
+The trusted sequencer generates batches, but in order to achieve fast finality of L2 transactions and avoid the need to wait for the next L1 block, they are shared with L2 network nodes via a broadcasting channel. Each node will run the batches to compute the resulting L2 state locally.
 
-Once the Trusted sequencer has committed the sequences of batches fetched directly from L1, L2 network nodes will execute them again, and they will no longer have to trust it.
+Once the trusted sequencer has committed the sequences of batches fetched directly from L1, L2 network nodes will execute them again, and they will no longer have to trust it.
 
-The off-chain execution of the batches will eventually be verified on-chain via a Zero-Knowledge proof, and the resulting L2 state root will be committed. As the zkEVM protocol progresses, new L2 state roots will be synchronized directly from L1 by L2 network nodes.
+The off-chain execution of the batches will eventually be verified on-chain via a zero-knowledge proof, and the resulting L2 state root will be committed. As the zkEVM protocol progresses, new L2 state roots will be synchronized directly from L1 by L2 network nodes.
 
 !!!info
     Both data availability and verification of transaction execution rely only on L1 security assumptions and at the final stage of the protocol, the nodes will only rely on data present in L1 to stay synchronized with each L2 state transition.
@@ -15,21 +15,21 @@ The off-chain execution of the batches will eventually be verified on-chain via
 
 As shown in the above figure, L2 nodes can receive batch data in three different ways:
 
-1. Directly from the Trusted Sequencer before the batches are committed to L1, or
-2. Straight from L1 after the batches have been sequenced, or
-3. Only after correctness of execution has been proved by the Aggregator and verified by the `PolygonZkEVM.sol` contract.
+1. Directly from the trusted sequencer before the batches are committed to L1.
+2. Straight from L1 after the batches have been sequenced.
+3. Only after correctness of execution has been proved by the aggregator and verified by the `PolygonZkEVM.sol` contract.
 
 It is worth noting that the three batch data formats are received by L2 nodes in the chronological order listed above.
 
 ## Three L2 states
 
 There are three stages of the L2 state, each corresponding to the three different ways in which L2 nodes can update their state. All three cases depend on the format of batch data used to update the L2 state.
 
-In the first instance, the update is informed solely by the information (i.e., Batches consisting of ordered transactions) coming directly from the Trusted Sequencer, before any data availability on L1. The resulting L2 state is called the Trusted state.
+In the first instance, the update is informed solely by the information (i.e., Batches consisting of ordered transactions) coming directly from the trusted sequencer, before any data availability on L1. The resulting L2 state is called the trusted state.
 
-In the second case, the update is based on information retrieved from the L1 network by L2 nodes. That is, after the batches have been sequenced and data has been made available on L1. The L2 state is referred to as the Virtual state at this point.
+In the second case, the update is based on information retrieved from the L1 network by L2 nodes. That is, after the batches have been sequenced and data has been made available on L1. The L2 state is referred to as the virtual state at this point.
 
-The information used to update the L2 state in the last case includes verified zero-knowledge proofs of computational integrity. That is, after the Zero-Knowledge proof has been successfully verified in L1, L2 nodes synchronise their local L2 state root with the one committed in L1 by the Trusted Aggregator. As a result, such an L2 state is known as the Consolidated state.
+The information used to update the L2 state in the last case includes verified zero-knowledge proofs of computational integrity. That is, after the zero-knowledge proof has been successfully verified in L1, L2 nodes synchronize their local L2 state root with the one committed in L1 by the trusted aggregator. As a result, such an L2 state is known as the consolidated state.
 
 The figure below depicts the timeline of L2 State stages from a batch perspective, as well as the actions that trigger progression from one stage to the next.