update: zkNode & minor edits (#77)

Co-authored-by: Ashutosh Tripathi <[email protected]>

docs/protocol/admin-role.md

@@ -12,7 +12,7 @@ keywords:
   - timelock controller
 ---
 
-Polygon zkEVM's _Admin_ consists of three (3) developers of the Polygon team, who oversee any upgrades of the zk-Rollup software.
+Polygon zkEVM's _Admin_ consists of three (3) developers of the Polygon team, who oversee any upgrades of the zk-rollup software.
 
 Whenever there are bug fixes or updates to be made, the Admin uses a special _Admin Multisig Contract_ to approve the changes.
 
@@ -22,9 +22,9 @@ However, there's a minimum 10-day waiting period before the changes get executed
 
 The 10-day delay allows users to carefully assess the proposed changes and decide whether to exit or not.
 
-Another smart contract called the _Timelock Contract_ is responsible for enabling the 10-day delay.
+Another smart contract called _Timelock Contract_ is responsible for enabling the 10-day delay.
 
-An outline of the _upgrade process_ is outlined [here](/protocol/zkevm-upgrades-process.md#process-overview).
+An outline of the _upgrade process_ is outlined [here](/protocol/zkevm-upgrades-process.md).
 
 ## Admin Contract In Detail
 

docs/protocol/upgradability.md

@@ -22,7 +22,7 @@ In tandem, Polygon intends to move its governance of upgrades from the currently
 
 These gradual _changes in governance_ will follow Polygon Improvement Proposals (PIPs), as already outlined in Polygon's [Three Pillars of Governance](https://forum.polygon.technology/t/the-three-pillars-of-polygon-governance-call-for-proposals/11847).
 
-Presently, centralization is seen in the form of the _Admin Multisig Contract_ and the [_Security Council Multisig_](/docs/protocol/security-council.md#security-council.md).
+Presently, centralization is seen in the form of the _Admin Multisig Contract_ and the [_Security Council Multisig_](/docs/protocol/security-council.md).
 
 ## Deploying Battle-tested Contracts
 

docs/zknode/overview.md

@@ -12,55 +12,25 @@ keywords:
   - RPC
 ---
 
-A 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 (Sequencers or Aggregators). Polygon zkEVM participants will choose how they participate:
+zkNode is the software needed to run a zkEVM node. It is a client that network users require to synchronize and know the state of the Polygon zkEVM.
 
-- As a node to know the state of the network, or
-- As a participant in the process of batch production in any of the two roles: **Sequencer** or **Aggregator**
+The main actors influencing the L2 State and its finality are the _trusted Sequencer_ and _trusted Aggregator_.
 
-The zkNode architecture is modular in nature. You can check out the below diagram for more clarity.
+The zkNode architecture is modular in nature. See the below diagram for more clarity.
 
 ![zkNode Diagram](figures/fig3-zkNode-arch.png)
 
-## Sequencers
+Most important to understand, is the primary path taken by transactions; from when users submit the transactions to the zkEVM network up until they are finalized and incorporated in the L1 State.
 
-A **Sequencer** receives L2 transactions from the users, preprocesses them as a new L2 batch, and then proposes the batch to the PoE smart contract as a valid L2 transaction. The **Sequencer** receives **transactions from users** and will **receive all fees** from all published transactions. Sequencer is therefore economically incentivized to post valid transactions in order to profit the most from them. A **Transaction Pool** with a sorting algorithm to choose the most profitable transactions is often used to solve this.
+Polygon zkEVM achieves this by utilizing several actors. Here is a list of the most prominent zkEVM components;
 
-While publishing a series of transactions, the **Sequencer** must pay a **fee in MATIC** tokens. This sum will change depending on the pending batches that need to be validated. If a sequencer shows malicious behavior by **posting invalid transactions** or **creating batches with just one transaction**, the protocol ensures that it will be very expensive to break the chain. This ensures that publishing invalid transactions will result in a loss for the sequencer.
+- The **Users**, who connect to the zkEVM network by means of an **RPC** node (e.g., MetaMask), submit their transactions to a database called 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 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. By doing so, the sequenced batches should be included in the L1 State.
+- The **Synchronizer** is the component that updates the State DB by fetching data from Ethereum through Etherman.
+- The **Etherman** is a low-level component that implements methods for all interactions with the L1 network and smart contracts.
+- The **State DB** is a database for permanently storing state data (but not the Merkle trees).
+- The **Aggregator** is another node whose role is to produce proofs attesting to the integrity of the Sequencer's proposed state change. These proofs are zero-knowledge proofs (or ZK-proofs) and the Aggregator employs a cryptographic component called the Prover for this purpose.
+- The **Prover** is a complex cryptographic tool capable of producing ZK-proofs of hundreds of batches, and aggregating these into a single ZK-proof which is published as the validity proof.
 
-Sequencers can be either **Trusted** or **Permissionless**:
-
-### Trusted
-
-**Trusted sequencers** are added to the network in order to achieve **fast finality**. The trusted sequencers predict what the state will look like before it’s actually virtualized on L1.
-
-### Permissionless
-
-To improve decentralization of the Polygon zkEVM, we allow permissionless sequencers to run on the network. Anyone with required hardware setup can initialize their own zkNode and participate as an independent, censor-resistant, **permissionless sequencer** in the network.
-
-## Aggregators
-
-An **Aggregator** receives all the transaction information from the Sequencer and sends it to the **Prover** (or zkProver) which provides a byte-sized zk-Proof after complex polynomial computations. The Smart Contract validates this proof. This way, an **Aggregator** collects the data, sends it to the **Prover**, receives its output and finally, sends the information to the smart contract to verify that the **Validity Proof** from the **Prover** is correct.
-
-The **MATIC** fee paid by the sequencers will be given to the aggregators. If the chain is overloaded with batches, the **MATIC cost will increase**, which will better incentivize the aggregators to generate verifiable proofs. The total cost of running aggregators is calculated by two factors: L1 transaction cost, and Server costs (to be defined).
-
-## Synchronizer
-
-Other than sequencing and validating processes, the zkNode also enables synchronisation of batches and their validity proofs, which happens only after these have been added to L1. This is accomplished using a subcomponent called the **Synchronizer**.
-
-A **Synchronizer** is responsible for getting all the data from Smart Contracts, which includes the data posted by the **sequencers** (transactions) and the data posted by the **aggregators** (validity proofs). All this data is stored in a huge database and served to third parties through a service called **JSON-RPC**.
-
-The Synchronizer is responsible for reading the events from the Ethereum blockchain, including new batches to keep the state fully synced. The information read from these events must be stored in the database. The Synchronizer also handles possible reorgs, which will be detected by checking if the last `ethBlockNum` and the last `ethBlockHash` are synced.
-
-## RPC
-
-RPC (Remote Procedure Call) is a JSON-RPC interface compatible with Ethereum. For a software application to interact with the Ethereum blockchain (by reading blockchain data and / or sending transactions to the network), it must connect to an Ethereum node. RPC enables integration of the zkEVM with existing tools, such as Metamask, Etherscan, and Infura. It adds transactions to the **Pool** and interacts with the **State** using read-only methods. 
-
-## State
-
-This subcomponent implements the Merkle Tree and connects to the DB backend. It checks integrity at the block level (information related to gas and block size, among others) and some transaction-related information (signatures, sufficient balance). It also stores the Smart Contract code into the Merkle tree and processes transactions using EVM.
-
-## [zkProver](/zkProver/overview.md)
-
-All the rules for a transaction to be valid are implemented and enforced in the zkProver. A zkProver performs complex mathematical computations in the form of polynomials and assembly language. These are later verified on a Smart Contract.
-
-These rules could be seen as constraints that a transaction must satisfy in order to be able to modify the state tree or the exit tree. The zkProver is the most complex module which required development of two new programming languages to implement the needed elements. Its detailed architecture is outlined [here](/zkProver/overview.md).
+Users can set up their own _local zkNode_ by following this guide [here](/setup-local-node.md), or a production zkNode as detailed [here](/docs/setup-production-node.md).