fix: typos in documentation files

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

@@ -12,7 +12,7 @@ However, there are input and output values shared among the tables. These values
 
 ## How CTLs work
 
-The CTL protocol is based on the [logUP argment](https://eprint.iacr.org/2022/1530.pdf), which works similar to how range-checks work. Range-checks are discussed in a subsequent document to this one.
+The CTL protocol is based on the [logUP argument](https://eprint.iacr.org/2022/1530.pdf), which works similar to how range-checks work. Range-checks are discussed in a subsequent document to this one.
 
 ### Example (CTL)
 
@@ -116,4 +116,4 @@ On the other side, and for the same STARK table $S$, the verifier:
 
 - Computes the sum $Z = \sum_j Z_{j}^l$.
 - Checks equality, $Z =?\ Z_0^S$.
-- Checks whether each of the running sums $Z_{j}^l$ and $Z^S$ were correctly constructed. 
+- Checks whether each of the running sums $Z_{j}^l$ and $Z^S$ were correctly constructed. 

docs/cdk/how-to/integrate-da.md

@@ -33,7 +33,7 @@ This section shows you how to create a custom CDK validium DAC contract.
         - Use the Polygon DAC implementation contract: [PolygonDataCommittee.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v8.0.0-rc.3-fork.12/contracts/v2/consensus/validium/PolygonDataCommittee.sol) as a guide.
         - The contract supports custom smart contract implementation and, through this, DACs can add their custom on-chain verification logic.
 
-6. You can leave the `verifyMessage` function empty but make sure the `getProcotolName` function returns a unique name (such as Avail, Celestia, etc). The following example code comes from the [PolygonDataCommitee.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v8.0.0-rc.3-fork.12/contracts/v2/consensus/validium/PolygonDataCommittee.sol) implementation.
+6. You can leave the `verifyMessage` function empty but make sure the `getProtocolName` function returns a unique name (such as Avail, Celestia, etc). The following example code comes from the [PolygonDataCommitee.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v8.0.0-rc.3-fork.12/contracts/v2/consensus/validium/PolygonDataCommittee.sol) implementation.
 
     ```solidity
     // Name of the data availability protocol
@@ -44,7 +44,7 @@ This section shows you how to create a custom CDK validium DAC contract.
     /**
      * @notice Return the protocol name
      */
-    function getProcotolName() external pure override returns (string memory) {
+    function getProtocolName() external pure override returns (string memory) {
         return _PROTOCOL_NAME;
     }
     ```

docs/cdk/how-to/migrate/forkid-9-12.md

@@ -172,7 +172,7 @@ go run ./zk/debug_tools/datastream-host \
 4. Start CDK-Erigon Sequencer
     - On a fork upgrade, once the upgrade Tx is finalized you can start the sequencer. Once started, check logs and ensure new blocks are generated with new forkid.
         - You would expect to see starting block #5796790 as forkid 12. If you see the starting block 5796790 as fork id 9 there is a problem.
-        If the new block is on the old fork id 9, you need to resync sequencer from scratch or get one of the rpc datadirs (that were synced till the halt and are currenctly stopped) and replace it to become the new sequencer.
+        If the new block is on the old fork id 9, you need to resync sequencer from scratch or get one of the rpc datadirs (that were synced till the halt and are currently stopped) and replace it to become the new sequencer.
 6. Verify in the sequencer’s logs that new blocks are being generated with fork ID 12.
 7. Start the Pool Manager (if used/needed).
 8. Start CDK-Erigon RPCs (if used/needed).