Merge pull request 0xPolygon#261 from 0xPolygon/empieichO-docs-review

Update CDK - rollup and validium architectures

Author: EmpieichO

docs/cdk/architecture/cdk-validium-option.md

@@ -0,0 +1,48 @@
+The Polygon CDK validium is one of two configuration options of the Polygon CDK, the other being the Polygon zkEVM rollup.
+
+As per [the definition](https://ethereum.org/developers/docs/scaling/validium), the Polygon CDK validium uses validity proofs to enforce integrity of state transitions, but it does not store transaction data on the Ethereum network.
+
+The Polygon CDK validium is in fact a _zero-knowledge validium_ (zkValidium) because it utilises the Polygon zkEVM's off-chain prover to produce zero-knowledge proofs, which are published as _validity proofs_.
+
+The use of the above-mentioned prover, to a certain extent, adds trustlessness to the Polygon CDK validium.
+
+The validium mode inherits, not just the prover, but all the Polygon zkEVM's components and their functionalities, except that it does not publish transaction data on L1.
+
+The validium configuration has one major advantage over the zkEVM rollup option: And that is, reduced gas fees due to the off-chain storage of transaction data, where only a hash of the transaction data gets stored on the Ethereum network.
+
+## Data availability committee (DAC)
+
+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. 
+
+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. 
+
+The hash values need to be verified as true _footprints_ of the transaction data corresponding to all transactions in the sequenced batches.
+
+These _trusted actors_ are collectively called the Data Availability Committee (DAC). 
+
+After verifying the proposed hash values individually, each DAC member signs them and sends the signature to the sequencer.
+
+The sequencer uses a _multi-sig_, which is a custom-specified _m-out-of-n multi-party protocol_, to attach the required _m_ signatures to the hash of the transaction data. The _multi-sig_ contract lives on the L1 network. 
+
+Architecturally speaking, the Polygon CDK validium is therefore nothing but a zkEVM with a DAC. That is, **Polygon CDK validium =  Polygon zkEVM + DAC**.
+
+## Validium data flow
+
+The DAC works together with the sequencer to control the flow of data and state changes. 
+
+The diagram below depicts a simplified outline of the Polygon CDK validium architecture. It particularly shows how the DAC and the sequencer relate in the overall data flow.
+
+![CDK validium data availability dataflow](../../img/cdk/cdk-val-dac-02.png)
+
+The entire process can be broken down as follows:
+
+1. **Batch formation**: The sequencer collects user transactions, adds them to blocks, and puts the blocks in batches while recursively computing their hash values.
+2. **Batch authentication**: Once the batches are assembled, and their hash values computed, they need to be authenticated by the DAC. The sequencer therefore forwards the batch data, and their corresponding hash values to the DAC, as a way to request for signatures.
+3. **Data validation and storage**: The DAC nodes independently validate the batch data against the hash values received from the sequencer. Once validated, each hash value is stored in each DAC node's local database for future reference.
+4. **Signature generation**: Each DAC node generates a signature for each batch hash. This serves as an endorsement of the batch's integrity and authenticity.
+5. **Communication with Ethereum**: The sequencer collects the DAC members' signatures and the original batch hash, and submits them to the Ethereum network for verification.
+6. **Verification on Ethereum**: A designated _multi-sig_ smart contract on Ethereum verifies the submitted signatures against each DAC member's known signatures, and confirms that sufficient approval has been provided for the batch hash.
+7. **Final settlement with zero-knowledge proof**: The aggregator prepares a proof for the batch via the prover and submits it to the Ethereum network. This proof confirms the validity of the transactions in the batch without revealing transaction details. The chain's state gets updated on Ethereum.

docs/cdk/architecture/cdk-zkevm-option.md

@@ -0,0 +1,24 @@
+Polygon zkEVM is a zero-knowledge rollup (or zk-rollup) designed to emulate the Ethereum Virtual Machine.
+
+It is a scaling-solution to Ethereum as it rolls up many transactions into one batch. 
+
+These batches are submitted to the L1, where their integrity is proved and verified before being included in the L1 state.
+
+Proving, verification of batches, and state changes are all controlled by smart contracts.
+
+Most important to understand is the primary path taken by transactions from when users submit these transactions to the zkEVM network up until they are finalized and incorporated in the L1 State. 
+
+Polygon zkEVM achieves this by utilizing several actors. The diagram below depicts the various actors and how they interact.
+
+![zkEVM option architecture](../../img/cdk/cdk-zkevm-arch-overview.png)
+
+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 **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.
+- 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.

docs/img/cdk/cdk-zkevm-arch-overview.png

@@ -86,7 +86,8 @@ nav:
         - Quickly test a running stack: cdk/how-to/quick-test-stack.md
         - Manage allowlists with policies: cdk/how-to/manage-policies.md
       - Architecture:
-        - DAC: cdk/architecture/dac.md
+        - CDK rollup option: cdk/architecture/cdk-zkevm-option.md
+        - CDK validium option: cdk/architecture/cdk-validium-option.md
       - Specification:
         - Validium vs rollup: cdk/spec/validium-vs-rollup.md
       - Concepts: