docs: remove mkdocs automation (0xPolygon#196)

* remove platform * chore: add docs * chore: merge the two docs folder * chore: rename docs folder --------- Co-authored-by: Dr K Murphy <[email protected]>
LAIR3 · Jul 25, 2024 · 51c7983 · 51c7983
1 parent 5de0e14
commit 51c7983
Show file tree

Hide file tree

Showing 59 changed files with 436 additions and 220 deletions.
diff --git a/DOCS.md b/DOCS.md
diff --git a/doc-drafts/architecture.excalidraw → docs/architecture.excalidraw b/doc-drafts/architecture.excalidraw → docs/architecture.excalidraw
diff --git a/doc-drafts/cdk-ops.org → docs/cdk-ops.org b/doc-drafts/cdk-ops.org → docs/cdk-ops.org
diff --git a/doc-drafts/cdk-policies.md → docs/cdk-policies.md b/doc-drafts/cdk-policies.md → docs/cdk-policies.md
diff --git a/docs/connect-testnet.md b/docs/connect-testnet.md
diff --git a/doc-drafts/da-mode.md → docs/da-mode.md b/doc-drafts/da-mode.md → docs/da-mode.md
diff --git a/doc-drafts/deploy-sepolia-l1.md → docs/deploy-sepolia-l1.md b/doc-drafts/deploy-sepolia-l1.md → docs/deploy-sepolia-l1.md
diff --git a/docs/img/architecture.png b/docs/img/architecture.png
diff --git a/docs/img/how-to/account.png b/docs/img/how-to/account.png
diff --git a/docs/img/how-to/manual-network-entry.png b/docs/img/how-to/manual-network-entry.png
diff --git a/docs/img/how-to/tx-success.png b/docs/img/how-to/tx-success.png
diff --git a/docs/integrate-da.md b/docs/integrate-da.md
@@ -1,7 +1,3 @@
----
-comments: true
----
-
 This document shows you how to integrate a third-party data availability (DAC) solution into your CDK stack.
 
 ## Prerequisites
@@ -19,7 +15,7 @@ This section shows you how to create a custom CDK validium DAC contract.
 
 3. Run `npm install` from the root.
 
-4. `cd` to the `contracts/v2/consensus/validium` directory. 
+4. `cd` to the `contracts/v2/consensus/validium` directory.
 
     !!! tip
         - Until further notice, these contracts run on the [etrog release](https://polygon.technology/blog/polygon-zkevm-the-etrog-upgrade-is-live-on-mainnet).
@@ -35,9 +31,7 @@ This section shows you how to create a custom CDK validium DAC contract.
     ```solidity
     // Name of the data availability protocol
     string internal constant _PROTOCOL_NAME = "<MY_PROTOCOL_NAME>";
-
     ...
-
     /**
      * @notice Return the protocol name
      */
@@ -52,7 +46,7 @@ This section shows you how to create a custom CDK validium DAC contract.
     const supporteDataAvailabilityProtocols = ["<CONTRACT_NAME>"];
     ```
 
-8. Make your contract deployable by copying, editing for your custom implementation, and pasting back in, the `if` statement from the [/deployment/v2/4_createRollup.ts#L251](https://github.com/0xPolygonHermez/zkevm-contracts/blob/54f58c8b64806429bc4d5c52248f29cf80ba401c/deployment/v2/4_createRollup.ts#L260) node creation script. 
+8. Make your contract deployable by copying, editing for your custom implementation, and pasting back in, the `if` statement from the [/deployment/v2/4_createRollup.ts#L251](https://github.com/0xPolygonHermez/zkevm-contracts/blob/54f58c8b64806429bc4d5c52248f29cf80ba401c/deployment/v2/4_createRollup.ts#L260) node creation script.
 
 !!! info "`PolygonValidiumEtrog.sol` solution"
 
@@ -113,7 +107,7 @@ This section shows you how to deploy the Docker image containing your custom DAC
 4. Edit [docker/scripts/v2/deploy-docker.sh](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v6.0.0-rc.1-fork.9/docker/scripts/v2/deploy-docker.sh) to add the following line:
 
     ```sh
-    sudo chmod -R go+rxw docker/gethData before docker build -t hermeznetwork/geth-zkevm-contracts -f docker/Dockerfile .  
+    sudo chmod -R go+rxw docker/gethData before docker build -t hermeznetwork/geth-zkevm-contracts -f docker/Dockerfile .
     ```
 
 5. In the [deployment/v2/4_createRollup.ts](https://github.com/0xPolygonHermez/zkevm-contracts/blob/54f58c8b64806429bc4d5c52248f29cf80ba401c/deployment/v2/4_createRollup.ts#L290) file, uncomment the 290-291, and add a `console.log` output that grabs the address of the DAC:
@@ -131,7 +125,7 @@ This section shows you how to deploy the Docker image containing your custom DAC
     sudo npm run docker:contracts
     ```
 
-7. Tag the image with the following command, where `XXXX` is custom: 
+7. Tag the image with the following command, where `XXXX` is custom:
 
     ```sh
     docker image tag hermeznetwork/geth-zkevm-contracts hermeznetwork/geth-cdk-validium-contracts:XXXX
@@ -141,7 +135,7 @@ This section shows you how to deploy the Docker image containing your custom DAC
 
 This section shows you how to set up your CDK node that sends and receives data from the DAC.
 
-1. Create a package that implements the [`DABackender`](https://github.com/0xPolygon/cdk-validium-node/blob/b6ee6cb087099c2e97f3e596f84672fc021b517a/dataavailability/interfaces.go#L14) interface and place it under the [`cdk-validium-node/tree/develop/dataavailability`](https://github.com/0xPolygon/cdk-validium-node/tree/develop/dataavailability) directory. 
+1. Create a package that implements the [`DABackender`](https://github.com/0xPolygon/cdk-validium-node/blob/b6ee6cb087099c2e97f3e596f84672fc021b517a/dataavailability/interfaces.go#L14) interface and place it under the [`cdk-validium-node/tree/develop/dataavailability`](https://github.com/0xPolygon/cdk-validium-node/tree/develop/dataavailability) directory.
 
 2. Add a new constant to the [/dataavailability/config.go](https://github.com/0xPolygon/cdk-validium-node/blob/b6ee6cb087099c2e97f3e596f84672fc021b517a/dataavailability/config.go) file that represents the DAC.
 
@@ -161,7 +155,7 @@ This section shows you how to set up your CDK node that sends and receives data
 ## Test the integration
 
 !!! tip
-    - By default, all E2E tests run using the DAC. 
+    - By default, all E2E tests run using the DAC.
     - It is possible to run the E2E tests using other DAC backends by amending the `test.node.config.toml` file.
 
 To test your DAC integration, follow the steps below.
@@ -195,4 +189,3 @@ To test your DAC integration, follow the steps below.
 4. Update the contracts Docker image tag with the custom tag you created at the [deploy Docker image](#deploy-docker-image) section, step 7, by amending the node's [Docker compose file](https://github.com/0xPolygon/cdk-validium-node/blob/develop/test/docker-compose.yml).
 
 5. Modify the Makefile so it can run your test. Use the [Polygon DAC Makefile](https://github.com/0xPolygon/cdk-validium-node/blob/develop/test/Makefile) as an example.
-
diff --git a/docs/manage-policies.md b/docs/manage-policies.md
@@ -1,7 +1,3 @@
----
-comments: true
----
-
 # Manage allowlists, and more, with policies
 
 !!! important

diff --git a/docs/migrate/forkid-7-to-9.md b/docs/migrate/forkid-7-to-9.md
@@ -1,7 +1,3 @@
----
-comments: true
----
-
 This document shows you how to migrate from fork 7 to fork 9 using the Kurtosis package.
 
 !!! tip

diff --git a/docs/migrate/fork.md → docs/migrate/upgrade.md b/docs/migrate/fork.md → docs/migrate/upgrade.md
@@ -1,5 +1,3 @@
-This document shows Polygon partners how to migrate an isolated CDK stack.
-
 ## Process to upgrade forks for isolated CDK chains
 
 In order to avoid reorgs and other undesirable scenarios, all L2 transactions must be verified before upgrading a fork. Verification means that all batches are closed, sequenced, and verified on L1.
@@ -9,10 +7,10 @@ Follow the steps to verify all batches for upgrading.
 1. Stop the sequencer.
 2. Enforce the sequencer to stop at a specific `batch_num`.
 
-    1. In the statedb, get WIP batch number: 
-        
-        `SELECT batch_num, wip FROM state.batch WHERE wip IS true;` 
-        
+    1. In the statedb, get WIP batch number:
+
+        `SELECT batch_num, wip FROM state.batch WHERE wip IS true;`
+
         Result = X (write down X for later)
 
     2. Edit node config:
@@ -26,7 +24,7 @@ Follow the steps to verify all batches for upgrading.
 
     4. Check sequencer halted when reaching batch `X+1` (this is obvious in the logs).
 
-    5. Wait until all pending batches are virtualized (X): 
+    5. Wait until all pending batches are virtualized (X):
 
         `SELECT batch_num FROM state.virtual_batch ORDER BY batch_num DESC LIMIT 1;` → X
 
@@ -36,11 +34,11 @@ Follow the steps to verify all batches for upgrading.
 
         2. `SELECT batch_num, batch_num_final FROM state.proof WHERE NOT generating AND batch_num = Y AND batch_num_final = X` wait until this query returns a row, remove `WHERE` conditions to get a sense of progress.
 
-    7. Edit node config to force the aggregator into sending the already aggregated proof ASAP: 
+    7. Edit node config to force the aggregator into sending the already aggregated proof ASAP:
 
         `Aggregator.VerifyProofInterval = "5m”`. Then restart aggregator.
 
-    8. Wait until the proof is settled on-chain: 
+    8. Wait until the proof is settled on-chain:
 
         `SELECT batch_num FROM state.verified_batch ORDER BY batch_num DESC LIMIT 1;` → X
 
@@ -68,5 +66,5 @@ Follow the steps to verify all batches for upgrading.
     2. `Sequencer.BatchMaxDeltaTimestamp = “1800s”`
     3. `SequenceSender.WaitPeriodSendSequence = "60s”` # restore previous value
     4. `SequenceSender.LastBatchVirtualizationTimeMaxWaitPeriod = “600s”` # restore previous value
-    
+
 7. Restart sequencer, sequence-sender, and aggregator.
diff --git a/doc-drafts/policies-img/01_policies.png → docs/policies-img/01_policies.png b/doc-drafts/policies-img/01_policies.png → docs/policies-img/01_policies.png
diff --git a/doc-drafts/policies-img/02_policies.png → docs/policies-img/02_policies.png b/doc-drafts/policies-img/02_policies.png → docs/policies-img/02_policies.png
diff --git a/doc-drafts/policies-img/03_policies.png → docs/policies-img/03_policies.png b/doc-drafts/policies-img/03_policies.png → docs/policies-img/03_policies.png
diff --git a/doc-drafts/policies-img/04_policies.png → docs/policies-img/04_policies.png b/doc-drafts/policies-img/04_policies.png → docs/policies-img/04_policies.png
diff --git a/docs/quickstart/breakdown-deployment.md b/docs/quickstart/breakdown-deployment.md
@@ -0,0 +1,121 @@
+---
+comments: true
+---
+
+Rather than executing the deployment process as a monolithic operation, you can break it down into stages and run each stage separately.
+
+### Enable or disable stages
+
+You can enable a stage by setting the boolean value to `true` and disable it by setting it to `false`, in the [`params.yml`](https://github.com/0xPolygon/kurtosis-cdk/blob/main/params.yml) file.
+
+!!! important
+    - By default, all stages are executed.
+
+## Deployment stages
+
+Currently, the deployment process includes the following stages:
+
+  1. Deploy Local L1.
+  2. Deploy zkEVM contracts on L1.
+  3. Deploy zkEVM node and CDK peripheral databases.
+  4. Deploy CDK central/trusted environment.
+  5. Deploy CDK/bridge infrastructure.
+  6. Deploy permissionless node.
+
+## Specifying stages
+
+The example scripts below show you how to deploy the stack to enable various stage permutations.
+
+!!! tip
+    To run the scripts, you need to have [yq](https://pypi.org/project/yq/) installed.
+
+### Disable all deployment steps
+
+```sh
+yq -Y --in-place 'with_entries(if .value | type == "boolean" then .value = false else . end)' params.yml
+```
+
+### Deploy L1
+
+```sh
+yq -Y --in-place '.deploy_l1 = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_l1 = false' params.yml # reset
+# Perform additional tasks...
+```
+
+### Deploy zkEVM contracts on L1
+
+```sh
+yq -Y --in-place '.deploy_zkevm_contracts_on_l1 = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml --image-download always .
+yq -Y --in-place '.deploy_zkevm_contracts_on_l1 = false' params.yml # reset
+# Perform additional tasks...
+```
+
+### Deploy zkEVM node and CDK peripheral databases
+
+```sh
+yq -Y --in-place '.deploy_databases = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_databases = false' params.yml # reset
+# Perform additional tasks...
+```
+
+### Deploy CDK central environment
+
+```sh
+yq -Y --in-place '.deploy_cdk_central_environment = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_cdk_central_environment = false' params.yml # reset
+# Perform additional tasks...
+```
+
+### Deploy CDK bridge infrastructure
+
+```sh
+yq -Y --in-place '.deploy_cdk_bridge_infra = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_cdk_bridge_infra = false' params.yml # reset
+# Perform additional tasks...
+```
+
+### Deploy zkEVM permissionless node
+
+```sh
+yq -Y --in-place '.deploy_zkevm_permissionless_node = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_zkevm_permissionless_node = false' params.yml # reset
+```
+
+### Deploy observability stack
+
+```sh
+yq -Y --in-place '.deploy_observability = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_observability = false' params.yml # reset
+```
+
+### Deploy Blockscout stack
+
+```sh
+yq -Y --in-place '.deploy_l2_blockscout = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_l2_blockscout = false' params.yml # reset
+```
+
+### Deploy ETH load balancer
+
+```sh
+yq -Y --in-place '.deploy_blutgang = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.deploy_blutgang = false' params.yml # reset
+```
+
+### Apply workload
+
+```sh
+yq -Y --in-place '.apply_workload = true' params.yml
+kurtosis run --enclave cdk-v1 --args-file params.yml .
+yq -Y --in-place '.apply_workload = false' params.yml # reset
+```