fix merge conflicts

Author: kmurphypolygon

.github/assets/nginx.conf

@@ -6,6 +6,6 @@ server {
     error_page 404 /404.html;
 
     location / {
-        try_files $uri.html $uri $uri/ /index.html;
+        try_files $uri.html $uri $uri/ =404;
     }
 }

docs/cdk/architecture/cdk-validium.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 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 of validium](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.

docs/cdk/architecture/cdk-zkevm.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 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. 

docs/cdk/architecture/staking-the-bridge.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 The LxLy bridge is the native bridging infrastructure for all CDK chains. The way it works is each individual CDK chain deploys an instance of the LxLy bridge that connects to an L1 (Ethereum by default) by deploying contracts that carry out deposit and withdrawal of assets, along with escrow management. These contracts are managed by node operators corresponding to the respective CDK chains.
 
 This changes as the AggLayer v1 goes online, and introduces an upgrade to the existing LxLy architecture in the form of a _unified instance_ of the LxLy bridge that multiple chains can connect to.

docs/cdk/architecture/type-1-prover/intro-t1-prover.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 The Polygon type 1 prover is a ZK-EVM proving component capable of generating proofs for Ethereum blocks. It has been developed in collaboration with the Toposware team.
 
 !!! info

docs/cdk/architecture/type-1-prover/t1-architecture.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 The Polygon type 1 prover is designed for efficient implementation of STARK proofs and verification of Ethereum transactions. It achieves efficiency by restricting the Algebraic Intermediate Representation (AIR) to constraints of degree 3.
 
 The execution trace needed to generate a STARK proof can be assimilated to a large matrix, where columns are registers and each row represents a view of the registers at a given time.

docs/cdk/architecture/type-1-prover/t1-cpu-component.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 The CPU is the central component of the Polygon type 1 prover. Like any central processing unit, it reads instructions, executes them, and modifies the state (registers and the memory) accordingly. 
 
 Other complex instructions, such as Keccak hashing, are delegated to specialized STARK tables. 

docs/cdk/architecture/type-1-prover/t1-ctl-protocol.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 Since each STARK module is like a small state machine where its state transition can be uniquely captured in the form of a table, called the `execution trace`, the STARK modules are henceforth also referred to as _STARK tables_. See the repo for further details of each table [here](https://github.com/0xPolygonZero/plonky2/tree/main/evm/spec/tables).
 
 For each STARK table, ordinary STARK proof and verification are used to check if all state transitions occurring in the module satisfies stipulated constraints.

docs/cdk/architecture/type-1-prover/t1-design-challenge.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 The EVM wasn't designed with zero-knowledge proving and verification in mind, and this makes the design of an efficient type 1 prover extremely challenging.
 
 Some of the challenges stem from the way the EVM is implemented. Here are some of the discrepancies that occur when deploying the most common zero-knowledge primitives to the EVM.

docs/cdk/architecture/type-1-prover/t1-rangechecks.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 Tables often deal with 256-bit words which are split into 16-bit limbs. This helps to avoid field overflows. Range-checks are used for examining integrity of values in these 16-bit limbs. 
 
 ### What to range-check?