Apply suggestions from code review

Co-authored-by: hsutaiyu <51791408+hsutaiyu@users.noreply.github.com>

Author: EmpieichO

docs/zkEVM/architecture/index.md

@@ -1,8 +1,8 @@
-Polygon zkEVM, as an L2 scaling-solution to Ethereum, processes and rolls up many transactions into batches. 
+As an Ethereum Layer 2 scaling solution, Polygon zkEVM gathers transactions into batches after executing them.
 
-The batches are sent to Ethereum, sequenced, proved to be valid, as well as being verified. All these steps are carried out under the control of smart contracts.
+Aggregated batches are then dispatched to Ethereum for verification and validation, all managed through smart contracts.
 
-The aim with this document is to provide a broader sense of the protocol design while stating the currently implemented configuration.
+This document aims to offer a comprehensive understanding of the protocol design while delineating the currently implemented configuration.
 
 The major components of Polygon zkEVM are:
 
@@ -30,15 +30,14 @@ The earlier version, Polygon Hermez 1.0, was based on the Proof of Donation (PoD
 
 PoD was basically a decentralized auction conducted automatically, with participants (coordinators) bidding a certain number of tokens in order to be selected for creating batches.
 
-It was based on a decentralized auction model to get the right to produce batches in a specific timeframe.
 
-The latest Consensus Contract (PolygonZkEVM.sol) is designed to leverage the experience of the PoD in v1.0 and adds support for the permissionless participation of multiple coordinators to produce batches in L2.
+The updated consensus contract (PolygonZkEVM.sol) is designed to build upon the insights gained from PoD in v1.0 and adds support for permissionless participation of multiple coordinators in producing L2 batches.
 
-In the PoD mechanism, the economic incentives were set up so the validators need to be very efficient in order to be competitive.
+In the PoD mechanism, economic incentives were structured to _require_ validators to operate with high efficiency to remain competitive.
 
-The latest version of the zkEVM Consensus Contract (deployed on Layer 1) is modelled after the [Proof of Efficiency](https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/11988).
+The latest version of the zkEVM consensus contract (deployed on Layer 1) is modeled after the [Proof of Efficiency](https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/11988).
 
-Although designed to support for permissionless participation of multiple coordinators to produce batches in L2, for security sake and due to the protocol being in its early development stages, only one coordinator (called the Sequencer) is currently brought to service.
+While the protocol design is intended to support permissionless participation of multiple coordinators to generate L2 batches, for security reasons and given the protocol's early development stage, only one coordinator (referred to as the Sequencer) is currently operational.
 ​
 ### Implementation model
 ​
@@ -61,35 +60,35 @@ The strategic implementation of the contract-based consensus ensures that the ne
 ​
 A full zk-rollup schema requires on-chain publication of both the transaction data (which users need to reconstruct the full state) and the validity proofs (zero-knowledge proofs).
 
-However, given the Ethereum configuration, publishing data on-chain incurs gas prices, making the choice between a full zk-rollup and a hybrid configurations challenging.
+However, given Ethereum's current framework, publishing callback data to L1 incurs high gas fees, complicating the decision between opting for a full zk-rollup or a hybrid configuration.
 
 Under a Hybrid schema, either of the following is possible:
 
 - Validium: Data is stored off-chain and only the validity proofs are published on-chain.
-- Volition: For some transactions, both the data and the validity proofs remain on-chain while for the remaining ones, only proofs go on-chain.
+- Volition: For some transactions, both the data and the validity proofs are published on-chain, while in others, only the proofs are stored on-chain.
 
-Unless, among other things, the proving module can be highly accelerated to mitigate costs for the validators, a Hybrid schema remains viable.
+Unless, among other considerations, the proving module can be significantly accelerated to alleviate high costs for validators, a hybrid schema remains a viable option.
 ​
 ### `PolygonZkEVM.sol`
 ​
 The underlying protocol in zkEVM ensures that the state transitions are correct by employing a validity proof.
 
-In order to ensure that a set of pre-determined rules have been followed when allowing state transitions, the consensus contract (`PolygonZkEVM.sol`, deployed on L1) is utilized.
+In order to ensure adherence to a set of pre-determined rules for state transitions, the consensus contract (`PolygonZkEVM.sol`, deployed on L1) is utilized.
 ​
 !!!info
-    The consensus contract is currently deployed on both [Ethereum Mainnet](https://etherscan.io/address/0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2) and [Cardona Testnet](https://sepolia.etherscan.io/address/0xa997cfD539E703921fD1e3Cf25b4c241a27a4c7A).
+    The consensus contract is currently deployed on both [Ethereum mainnet](https://etherscan.io/address/0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2) and [Cardona testnet](https://sepolia.etherscan.io/address/0xa997cfD539E703921fD1e3Cf25b4c241a27a4c7A).
 ​
 A smart contract verifies the validity proofs to ensure that each transition is completed correctly. 
 
-The verification is accomplished by employing zk-SNARK circuits. 
+State transition verification is carried out by employing zk-SNARK circuits. 
 
-A system of this type requires two processes: transaction batching and transaction validation.
+A system of this type necessitates two processes: transaction batching and transaction validation.
 
-Polygon zkEVM employs two types of participants in order to carry out the two procedures: A sequencer and an aggregator.
+Polygon zkEVM implements two participant network roles in order to carry out its procedures: A sequencer and an aggregator.
 
 Under this two-layer model:
 
-- The sequencer proposes transaction batches to the network for execution. That is, they roll-up transaction requests into batches and add them to the Consensus Contract.
+- The sequencer proposes transaction batches to the network upon executing them. That is, it rolls up transactions into batches and adds them to the consensus contract.
 ​
 - The aggregator checks the validity of the transaction batches and provides validity proofs.
 
@@ -102,41 +101,41 @@ The smart contract, therefore, makes two calls:
 
 !!!info
 
-    Although the current protocol design allows for several sequencers and aggregators, for the sake of security and due to the protocol being in its early development stages, only one sequencer and one aggregator are currently put into service.
+    Although the current protocol design allows for several sequencers and aggregators, to prioritize security and given the early stage of protocol development, only one sequencer and one aggregator are currently operational.
 
-    These are henceforth referred to as _trusted sequencer_ and _trusted aggregator_. 
+    These are henceforth referred to as the _trusted sequencer_ and the _trusted aggregator_. 
 
 ### Tokenomics
 
-The consensus smart contract imposes the following requirements on the trusted sequencer and the trusted aggregator:
+The consensus smart contract imposes the following requirements on the trusted sequencer and the trusted aggregator.
 ​
 #### Sequencer
 
 - The trusted sequencer must run the software necessary for a full zkEVM node.
 
 - The trusted sequencer should pay a fee in the form of POL tokens for the right to create and process batches.
 
-- The trusted sequencer is incentivized for proposing valid batches (which consist of valid transactions,) with the fees paid by the users of the network who sent the transactions.
+- The trusted sequencer is incentivized to propose valid batches (consisting of valid transactions) with the fees paid by the network users who initiated the transactions.
 
 #### Aggregator
 
-An trusted aggregator receives all the transaction information from the trusted sequencer and sends it to the prover, which in turn provides a zk-proof after performing some complex computations. 
+A trusted aggregator receives all the transaction information from the trusted sequencer and sends it to the prover, which in turn provides a zk-proof after performing some complex computations. 
 
 A special _verfier_ smart contract validates the validity proof.
 
 The trusted aggregator's task is to therefore:
 
 - Provide validity proofs for the L2 transactions proposed by the trusted sequencer.
 
-- Run zkEVM's zkNode software and the zkProver for creating the zero-knowledge validity proofs.
+- Run zkEVM's zkNode software and the zkProver for generating zero-knowledge validity proofs.
 
 - For a given batch, the trusted aggregator earns the POL fees (paid by the trusted sequencer) for providing a validity proof.
 
-- In a decentralized setting, an trusted aggregator needs to indicate their intention to validate transactions. And subsequently competes to produce validity proofs based on their own strategy.
+- In a decentralized setting, each trusted aggregator needs to declare its intention to validate transactions, and subsequently compete to produce validity proofs based on its own strategy.
 
 ## zkNode
 
-zkNode is the software needed to run a zkEVM node. It is a client that the network requires to implement the synchronization and govern the roles of the participants (trusted sequencer or trusted aggregator).
+zkNode is the essential software for running a zkEVM node. It is a client that the network requires to implement the synchronization and govern the roles of the participants, including the trusted sequencer and the trusted aggregator.
 
 Other than the trusted sequencer and the trusted aggregator, participants in the Polygon zkEVM network can take part as nodes that seek to know the state of the network.
 
@@ -170,7 +169,7 @@ Below is a summary of the fee structure for the trusted sequencer and the truste
 
 ## zkProver
 
-zkEVM employs zero-knowledge technology to create validity proofs.
+zkEVM employs zero-knowledge technology to generate validity proofs.
 
 It uses a zero-knowledge prover (zkProver), which is intended to run on a server and is being engineered to be compatible with most consumer hardware.
 
@@ -198,7 +197,7 @@ It is a combination of two smart contracts, one deployed on one chain and the se
 
 The L1 and L2 contracts in zkEVM are identical except for where each is deployed.
 
-Bridge L1 contract is on the Ethereum mainnet in order to manage asset transfers between rollups, while bridge L2 contract is on a specific rollup and it is responsible for asset transfers between mainnet and the rollup (or rollups).
+Bridge L1 contract is on the Ethereum mainnet in order to manage asset transfers between rollups, while bridge L2 contract operates in a designated rollup, managing asset transfers between mainnet and the rollup(s).
 
 Layer 2 interoperability allows a native mechanism to migrate assets between different L2 networks. This solution is embedded in the bridge smart contract.
 
@@ -208,15 +207,15 @@ Verifier is a smart contract which is able to verify any zk-SNARK cryptographic
 
 The SNARK verifier proves the validity of every transaction in the batch.
 
-It is the key entity in any zk-rollup architecture as it verifies the correctness of each proof, and thus ensuring integrity in state transitions.
+It is the core entity in any zk-rollup architecture as it verifies the correctness of each proof, thus ensuring the integrity of state transitions.
 
 The verifier contract is currently deployed on the [Ethereum mainnet](https://etherscan.io/address/0x4F9A0e7FD2Bf6067db6994CF12E4495Df938E6e9) and [Cardona testnet](https://sepolia.etherscan.io/address/0x8EdA1d8c254a77a57A6A7A1C0262e9A44A7C6D6d).
 
 ## Transaction life cycle
 
-Before getting transactions in the L2 flow, users need some funds to perform any L2 transaction.
+Users need funds on L2 to be able to send transactions to the L2 network.
 
-To do so, users need to transfer some ether from L1 to L2 through the zkEVM bridge dApp.
+To do so, users need to deposit Ether to L2 through the [Polygon Portal](https://portal.polygon.technology/bridge).
 
 - Bridge
 
@@ -226,15 +225,15 @@ To do so, users need to transfer some ether from L1 to L2 through the zkEVM brid
 
 - L2 transactions
 
-    - User initiates a transation in a wallet (e.g. MetaMask) and sends it to a trusted sequencer.
+    - User initiates a transaction using their wallet (e.g. MetaMask) and sends it to a trusted sequencer.
 
     - The transaction gets finalized on L2 once the trusted sequencer commits to adding the transaction to a batch. This is known as the trusted state.
 
     - Sequencer sends the batch data to L1 smart contract, enabling any L2 node to synchronize from L1 in a trustless way. This is also known as the virtual state.
 
-    - Aggregator will take pending transactions, and build a proof.
+    - Aggregator takes the pending transactions, and builds a proof.
 
-    - Once the proof is verified, user's transactions attain L1 finality (important for withdrawal purposes). This is called the consolidated state.
+    - Once the proof is verified, the transactions attain L1 finality (important for withdrawal of funds from L2). This is called the consolidated state.
 
 The above process is a summarized version of how transactions are processed in Polygon zkEVM. 
 
@@ -256,7 +255,7 @@ Smart contracts are deployed to ensure that everyone who executes state changes
 
 ## Efficiency and overall strategy
 
-Efficiency is key to network performance. Polygon zkEVM applies several implementation strategies to guarantee efficiency. A few of them are listed below:
+Efficiency is key to network performance. Polygon zkEVM uses several implementation strategies to maximize efficiency. A few are listed below:
 
 1. The first strategy is to deploy the consensus contract, which incentivizes the aggregator to participate in the proof generation process.