Merge pull request #1787 from 0xPolygon/cdk/consistent-wording

CDK: Update pool manager wording

docs/cdk/architecture/cdk-validium.md

@@ -19,7 +19,7 @@ The validium configuration has one major advantage over the zkEVM rollup option:
 In relation to storing transaction data off-chain, the CDK validium comes with the requirement to manage the data.
 
 - First of all, the transaction data is not published to the L1 but only the hash of the data.
-- Secondly, a trusted-sequencer collects transactions from the pool DB, puts them into batches and computes the hash of the transaction data. 
+- Secondly, a trusted-sequencer collects transactions from the transaction pool manager, puts them into batches and computes the hash of the transaction data. 
 
 It is due to the above two points that the Polygon CDK validium has to have a set of _trusted actors_, who can monitor and even authenticate the hash values that the sequencer proposes to be published on the L1. 
 

docs/cdk/architecture/cdk-zkevm.md

@@ -18,9 +18,9 @@ Polygon zkEVM achieves this by utilizing several actors. The diagram below depic
 
 Here is an outline of the most prominent rollup components:
 
-- The **users**, who connect to the zkEVM network by means of an RPC node (e.g., Infura or Alchemy), submit their transactions to a database called the pool DB.
-- The **pool DB** is the storage for transactions submitted by users. These are kept in the pool waiting to be put in a batch by the sequencer.
-- The **sequencer** is a node responsible for fetching transactions from the pool DB, checking if the transactions are valid, then putting valid ones into a batch. The sequencer submits all batches to the L1 and then sequences the batches. This process proposes the sequence of batches to be included in the L1 state.
+- The **users**, who connect to the zkEVM network by means of an RPC node (e.g., Infura or Alchemy), submit their transactions to a database called the pool DB which is managed by the [transaction pool manager](https://github.com/0xPolygon/zkevm-pool-manager).
+- The **pool DB** is the storage for transactions submitted by users. The transaction pool manager selects the transactions to send to the sequencer.
+- The **sequencer** is a node responsible for receiving transactions, checking if the transactions are valid, then putting valid ones into a batch. The sequencer submits all batches to the L1 and then sequences the batches. This process proposes the sequence of batches to be included in the L1 state.
 - The **state DB** is a database for permanently storing state data (but not the Merkle trees).
 - The **synchronizer** is the component that updates the state DB by fetching data from Ethereum through the Etherman.
 - The **Etherman** is a low-level component that implements methods for all interactions with the L1 network and smart contracts.

docs/cdk/concepts/rollup-vs-validium.md

@@ -57,7 +57,7 @@ Below is a breakdown of the technical differences between a zkEVM rollup and val
 | **Gas fees**          | High, because all transaction data is stored on Ethereum.                                                                                                                                                | Low, because only the hash of the transaction data is stored on Ethereum.                                                                                                                                                                                  |
 | **Proof generation**  | Uses Prover to generate proofs of batched transactions for validation.                                                                                                                                   | Uses Prover to generate proofs of batched transactions for validation.                                                                                                                                                                                     |
 | **Final settlement**  | Transaction batches and their corresponding proofs are added to the Ethereum state.                                                                                                                      | The hash of transaction data and its proof are added to the Ethereum state, referred to as the consolidated state.                                                                                                                                         |
-<sub><sup>\*</sup>JSON RPC, Pool DB, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub>
+<sub><sup>\*</sup>JSON RPC, Tx pool manager, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub>
 
 ## Further reading
 

docs/zkEVM/architecture/effective-gas/user-tx-flow/sequencer-flow-egp.md

@@ -1,6 +1,6 @@
 In this phase of the end-to-end transaction flow, transactions go through different stages, depending on the user's $\texttt{GasPriceSigned}$:
 
-1. Sequencing transactions from the pool.
+1. Sequencing transactions coming from the transaction pool manager.
 2. Estimating the effective gas price (EEGP) using the current $\texttt{L1GasPrice}$ and RPC's estimated $\texttt{GasUsedRPC}$.
 
     $$
@@ -27,7 +27,7 @@ In this phase of the end-to-end transaction flow, transactions go through differ
     - Transactions with these two opcodes get executed with the $\texttt{GasPriceSigned}$.
     - Otherwise, they are executed with the $\texttt{NEGP}$.
 
-   Since the sequencer is obliged to execute all transactions in the pool, each transaction is executed during a particular stage of the flow described above.
+   Since the sequencer is obliged to execute all transactions in the transaction pool manager, each transaction is executed during a particular stage of the flow described above.
 
    The entire sequencer flow is summarized in the figure below.
 

docs/zkEVM/architecture/effective-gas/zkevm-egp-strat.md

@@ -27,14 +27,14 @@ This document presents an outline of Polygon zkEVM's strategy for executing tran
 
     (a) Estimation of each transaction's possible consumption of L2 resources. That is, determining an approximate gas cost.
 
-    (b) Checking user’s signed gas price against the expected $\texttt{MinL2GasPrice}$. Store the transaction in the pool if $\texttt{SignedGasPrice} < \texttt{MinL2GasPrice}$​. Otherwise discard it.
+    (b) Checking user’s signed gas price against the expected $\texttt{MinL2GasPrice}$. Store the transaction in the transaction pool manager if $\texttt{SignedGasPrice} < \texttt{MinL2GasPrice}$​. Otherwise discard it.
 
-    (c\) The pool here refers to a collection of transactions waiting to be selected for execution by the sequencer.
+    (c\) The transaction pool manager here refers to a collection of transactions waiting to be selected for execution by the sequencer.
 
 
-- **Put in place a criterion for determining which transactions to store in the pool**
+- **Put in place a criterion for determining which transactions to store in the transaction pool manager**
 
-    Only the transactions that satisfy the criterion are stored on the pool.
+    Only the transactions that satisfy the criterion are stored on the transaction pool manager.
 
     The user's signed gas price is checked against either the breakeven factor, or the gas price suggested to the user.