Merge branch 'main' of https://github.com/0xPolygon/polygon-docs into di/agglayer

Author: kmurphypolygon

docs/img/zkEVM/l2state-executor-hashdb-exec-trace.png

@@ -0,0 +1,79 @@
+This document explains how the zkEVM proving system manages changes in the L2 state tree.
+
+The main components of the zkEVM proving system are, the ROM, the prover HashDB, and the storage state machine's executor.
+
+In the zkEVM context, as in Ethereum, it is crucial to ensure the accuracy of state changes resulting from the execution of transactions.
+
+## zkEVM ROM
+
+The zkEVM ROM, written in zero-knowledge assembly (zkASM), is a program designed to prove computations related to correct L2 state transitions resulting from L2 transactions in a given batch.
+
+Often, multiple zkASM instructions are used to implement a single zkEVM opcode.
+
+The L2 state is captured in the form of a Merkle tree, and its Merkle root, referred to as the _state root_, uniquely represents the summary of the current state data.
+
+The zkEVM ROM must, therefore, have the capability to correctly execute the `CREATE`, `READ`, `UPDATE`, and `DELETE` (CRUD) operations on the Merkle tree.
+
+## The storage state machine
+
+The zkEVM implements a secondary state machine, known as the _storage state machine_, specifically for generating an _execution trace_. 
+
+The execution trace provides evidence for any creation, reading, updating, or deletion of L2 state data.
+
+Any operation applied to the Merkle tree must be evidenced with proof, attesting that the tree modification was executed correctly.
+
+Such a proof consists of the sibling node and other relevant hash nodes sufficient for verification purposes. This is called a Merkle proof.
+
+An example of a Merkle proof can be found in the [Concepts section](../../concepts/sparse-merkle-trees/sparse-merkle-tree.md).
+
+Verifying a Merkle proof involves using the given information to compute the Merkle root and checking if it matches the actual Merkle root.
+
+After processing the last L2 transaction in a batch, the resulting root becomes the _new state root_.
+
+### Example. (Proving `READ` and `UPDATE` operations)
+
+We provide illustrative examples showcasing two CRUD operations on the L2 state: _read_ and _update_ operations.
+
+The storage state machine is responsible for providing validity proofs of these operations.
+
+![Figure: State change](../../../img/zkEVM/l2state-read-proof-eg.png)
+
+Consider the figure above, where the objective is to read the information stored in the fourth leaf ($l_4$). 
+
+Suppose a user carries out a transaction and $l_4$ represents the balance of the account that initiates the transaction.
+
+In the process of reading this leaf, it is crucial to verify its inclusion in the current state at the specified position.
+
+This is deterministically computed from some unique properties of the stored data, such as the account address or the data type.
+
+In the figure above, the blue boxes represent data that must be supplied to the storage state machine for generating the execution trace.
+
+As typically required when verifying a Merkle proof, the data stored in the blue boxes enables the storage state machine to validate that the computed root matches the state root of the Merkle tree.
+
+![Figure: _](../../../img/zkEVM/l2state-update-proof-eg.png)
+
+Consider the figure above, which depicts a scenario where a leaf is updated.
+
+A leaf update means changing the leaf's value, which consequently modifies the state root.
+
+Consequently, the yellow boxes in the figure represent all affected nodes, as they incorporate information from the updated leaf $l_2$. 
+
+The storage state machine is used once again to generate an execution trace, ensuring the accuracy of all tree modifications.
+
+Following the same procedure as in the _read_ case, the consistency of the state root is verified to confirm that the changes have been accurately executed.
+
+## The storage state machine's executor and HashDB
+
+All essential hashes required for computing execution traces are stored in the HashDB. 
+
+During the execution of the L2 state’s related zkEVM opcodes, such as `SSTORE` or `SLOAD`, the storage state machine’s executor consistently retrieves values from the HashDB and uses them to construct the corresponding execution traces.
+
+The HashDB contains all the hashes, which are all the nodes of the Merkle tree of the L2 state.
+
+The figure below depicts an interaction of the executor with the HashDB, when proving the state transition from $S^{L2_x}_i$ to $S^{L2_x}_{i+1}$. 
+
+The executor takes as inputs, the current state $S^{L2_x}_i$ and a batch of transactions, retrieves Merkle proofs from the HashDB, and produces the execution trace representing all changes to the state tree.
+
+![Figure: _ ](../../../img/zkEVM/l2state-executor-hashdb-exec-trace.png)
+
+It is important to note that the Merkle tree used in the Polygon zkEVM is a binary sparse Merkle tree (SMT), distinguishing itself from the Merkle tree used in the L1 EVM.

docs/img/zkEVM/l2state-read-proof-eg.png

@@ -0,0 +1,48 @@
+Generating a proof for the valid processing of a single batch requires multiple inputs.
+
+In addition to the data from each transaction in the processed batch, other inputs are necessary to ensure the network's overall security.
+
+For example, some inputs need to be sent to the smart contract.
+
+Central to generation of proofs and their verification are the verifier smart contract and the prover, as well as their interaction.
+
+This document, therefore, explores what the prover transmits to the verifier smart contract and why.
+
+In the zkEVM context, the focus is on generating _succinct_[^1] proofs rather than privacy concerns. 
+
+Consequently, L2 transactions and L2 state data are public. 
+
+We therefore delve into the initial design of the proving system, which operates without private inputs.
+
+## Public inputs
+
+Recall that the prover generates a proof, and sends the proof and an array of public inputs, denoted by $\texttt{[publics]}$ to the smart contract. The figure below depicts this.
+
+![Figure: _ ](../../../img/zkEVM/psi-prover-sends-to-verif-sc.png)
+
+The public inputs consist of the following data:
+
+- `batchData` which is the data of all the L2 transactions in the batch being proved.
+
+- `currentStateRoot` referring to the current L2 state root.
+
+- `proverAccount` which is the prover's account due to receive rewards. This account is attached to the proof so as to avoid successful plagiariasm of the proof.
+
+- `timestamp` specifies the time at which the proof was generated.
+
+- `forkId` is the current version of the L2 EVM being used.
+
+- `chainId` is the identifier of the chain for which the proof is being generated. The protocol is designed with the capability to host multiple layer 2 networks.
+
+The public output of this process is a new L2 state root, denoted by `newStateRoot`.
+
+The prover does not send all these public inputs to the L1 smart contract. Some inputs are already stored in the contract. These include: `currentStateRoot`, `forkId`, and `chainId`.
+
+The rest of the inputs need to be included in the `calldata` of the transaction sent to the L1’s smart contract. That is, `batchData`, `timestamp`, `newStateRoot`.
+
+Since the `proverAccount` is included in the L1 transaction’s signature, it need not be explicitly provided.
+
+Finally, the prover also sends the proof of correct execution of all L2 transactions within the batch.
+
+
+[^1]: The term [_succinct_](https://www.di.ens.fr/~nitulesc/files/Survey-SNARKs.pdf) refers to the size of the proof being very small compared to the size of the statement or the witness (i.e., the size of the computation itself).