fix conflict

Author: kmurphypolygon

docs/cdk/architecture/cdk-validium.md

@@ -1,6 +1,8 @@
+<!--
 ---
 comments: true
 ---
+-->
 
 The Polygon CDK validium is one of two configuration options of the Polygon CDK, the other being the Polygon zkEVM rollup.
 

docs/cdk/architecture/cdk-zkevm.md

@@ -1,6 +1,8 @@
+<!--
 ---
 comments: true
 ---
+-->
 
 Polygon zkEVM is a zero-knowledge rollup (or zk-rollup) designed to emulate the Ethereum Virtual Machine.
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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.
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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.
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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.
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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. 
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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).
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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.
 

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

@@ -1,6 +1,8 @@
+<!--
 ---
 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. 
 

docs/cdk/architecture/type-1-prover/testing-and-proving-costs.md

@@ -1,6 +1,8 @@
+<!--
 ---
 comments: true
 ---
+-->
 
 ## Testing the prover