Merge branch 'main' of https://github.com/0xPolygon/polygon-docs into km/cdk-qs-rollup

Author: kmurphypolygon

docs/img/zkEVM/lxly-bridge-diagram.png

@@ -14,7 +14,7 @@ $$
 x' - (x + y) = 0 \text{ | degree} = 1
 $$
 
-In the above, the constraint equation is followed by the implied algebraic degree of the constraint. This degree is determined by the number of multiplications between trace columns. If a constraint does not involve any multiplications between columns, its degree is $1$. If a constraint involves multiplication between two columns, its degree is $2$. If we need to multiply three columns together, the degree is $3$ ect.
+In the above, the constraint equation is followed by the implied algebraic degree of the constraint. This degree is determined by the number of multiplications between trace columns. If a constraint does not involve any multiplications between columns, its degree is $1$. If a constraint involves multiplication between two columns, its degree is $2$. If we need to multiply three columns together, the degree is $3$ etc.
 
 The maximum allowed constraint degree in Miden VM is $9$. If a constraint degree grows beyond that, we frequently need to introduce additional columns to reduce the degree.
 

docs/miden/vm/architecture/introduction.md

@@ -232,7 +232,7 @@ The effect on the rest of the stack is:
 
 ## `EXT2MUL`
 
-The `EXT2MUL` operation pops top $4$ values from the top of the stack, performs mulitplication between the two extension field elements, and pushes the resulting $4$ values onto the stack. The diagram below illustrates this graphically.
+The `EXT2MUL` operation pops top $4$ values from the top of the stack, performs multiplication between the two extension field elements, and pushes the resulting $4$ values onto the stack. The diagram below illustrates this graphically.
 
 ![ext2mul](../../../../img/miden/vm/design/stack/field-operations/EXT2MUL.png)
 

docs/miden/vm/architecture/stack/field-ops.md

@@ -4,13 +4,13 @@ The Miden debugger supports the following commands:
 
 | Command | Shortcut | Arguments | Description |
 | --- | --- | --- | --- |
-| next | n | count? | Steps `count` clock cycles. Will step `1` cycle of `count` is ommitted. |
+| next | n | count? | Steps `count` clock cycles. Will step `1` cycle of `count` is omitted. |
 | continue | c | - | Executes the program until completion, failure or a breakpoint. |
-| back | b | count? | Backward step `count` clock cycles. Will back-step `1` cycle of `count` is ommitted. |
+| back | b | count? | Backward step `count` clock cycles. Will back-step `1` cycle of `count` is omitted. |
 | rewind | r | - | Executes the program backwards until the beginning, failure or a breakpoint. |
 | print | p | - | Displays the complete state of the virtual machine. |
-| print mem | p m | address? | Displays the memory value at `address`. If `address` is ommitted, didisplays all the memory values. |
-| print stack | p s | index? | Displays the stack value at `index`. If `index` is ommitted, displays all the stack values. |
+| print mem | p m | address? | Displays the memory value at `address`. If `address` is omitted, didisplays all the memory values. |
+| print stack | p s | index? | Displays the stack value at `index`. If `index` is omitted, displays all the stack values. |
 | clock | c | - | Displays the current clock cycle. |
 | quit | q | - | Quits the debugger. |
 | help | h | - | Displays the help message. |

docs/miden/vm/tools/debugger.md

@@ -18,7 +18,7 @@ The Polygon Network is broadly divided into three layers:
 * **Heimdall layer** — a set of proof-of-stake Heimdall nodes running in parallel to the Ethereum mainnet, monitoring the set of staking contracts deployed on the Ethereum mainnet, and committing the Polygon Network checkpoints to the Ethereum mainnet. Heimdall is based on Tendermint.
 * **Bor layer** — a set of block-producing Bor nodes shuffled by Heimdall nodes. Bor is based on Go Ethereum.
 
-![Figure: Ethereum, Bor and Heimdall archictecture](../../img/pos/architecture.png)
+![Figure: Ethereum, Bor and Heimdall architecture](../../img/pos/architecture.png)
 
 ## Staking smart contracts on Ethereum
 

docs/pos/architecture/index.md

@@ -1,6 +1,6 @@
 
 
-The Transactions subsection provides information about the EIP-1559 as it applies to how gas estimations and costing of transations work on Polygon PoS. Further on, are discussions on new and old types of transaction formats and how they are processed in Polygon PoS.
+The Transactions subsection provides information about the EIP-1559 as it applies to how gas estimations and costs of transactions work on Polygon PoS. Further on, are discussions on new and old types of transaction formats and how they are processed in Polygon PoS.
 
 Regarding account abstraction, the subsection contains a simplified overview of the different components of ERC-4337 and how these components work together. These are altogether; `UserOperation`, `Bundler`, `EntryPoint`, and `Contract Account`. Optional ERC-4337 components are `Paymasters` and `Aggregators`.
 

docs/pos/concepts/transactions/index.md

@@ -10,6 +10,8 @@ We have listed three faucet tools you can use to receive MATIC testnet tokens, a
 - [Polygon faucet](https://faucet.polygon.technology/)
 - [Alchemy MATIC faucet](https://mumbaifaucet.com/)
 - [QuickNode multi-chain faucet](https://faucet.quicknode.com/drip)
+- [LearnWeb3 Mumbai MATIC Faucet](https://learnweb3.io/faucets/polygon_mumbai)
+- [LearnWeb3 zkEVM MATIC Faucet](https://learnweb3.io/faucets/polygon_zkevm)
 
 In addition, Polygon faucet also provides Polygon zkEVM testnet ETH tokens.
 
@@ -76,3 +78,11 @@ In order to receive MATIC Mumbai tokens using QuickNode faucet,
    ![img](../../img/tools/gas/quicknode-faucet3.png)
 
 - You can also view your transaction details on [Polygonscan](https://mumbai.polygonscan.com/) by clicking on the TxHash.
+
+## LearnWeb3 Faucets
+
+In order to receive MATIC tokens on Mumbai or zkEVM using the LearnWeb3 Faucet:
+
+- Head over to the [Mumbai Faucet](https://learnweb3.io/faucets/polygon_mumbai) or the [zkEVM Faucet](https://learnweb3.io/faucets/polygon_zkevm).
+- Sign in to LearnWeb3 by clicking **Sign In** in the top-right. Connect your GitHub if you haven't already done so to gain access to the faucet.
+- Enter your wallet address and request MATIC tokens

docs/tools/gas/matic-faucet.md

@@ -82,7 +82,7 @@ Once sequenced batches have been verified, the _Global Exit Tree_ gets updated,
 
 The Rollup Manager manages the following lists of availability;
 
-- Rollup consensus mechanisms. The list may consists of Consensus contracts such as PolygonZkEVM.sol or zkValidium.sol.
+- Rollup consensus mechanisms. The list may consist of Consensus contracts such as PolygonZkEVM.sol or zkValidium.sol.
 - Verifier contracts. For example, the PolygonZkEVM.sol uses the _Verifier.sol_ SC for verification of batches.
 
 Governance SC oversees Consensus mechanisms and Verifiers that can be added to the respective lists.
@@ -104,7 +104,7 @@ The [Rollup Manager SC](https://github.com/0xPolygonHermez/zkevm-contracts/blob/
 
   - The developer selects the Consensus and Verifier for the required rollup amongst those available in the Rollup Manager's lists,
   - Requests creation of a rollup with the selected specifications,
-  - Governance SC invokes the Rollup Manager's `AddNewRollupType()` function,
+  - Governance SC invokes the Rollup Manager's `addNewRollupType()` function,
   - Once, a rollup is created, the transfer of assets can be processed in the usual manner.
 
 ### Overall flow of events
@@ -118,11 +118,11 @@ The below diagram captures the following flow of events, most of which are handl
 - Verification of batches,
 - Updating the Global Exit Root.
 
-![Figure 3: Events flow related to RollupManager.sol](../../../img/zkEVM/lxly-3-flow-rollupmanager.png)
+![Figure 3: Events flow related to RollupManager.sol](../../../img/zkEVM/lxly-bridge-diagram.png)
 
 ## Conclusion
 
-Although the LXLY Bridge is still a work in progress, it is designed to be Polygon's talisman for accomplishing multi-chain interoperability.
+Although the LXLY Bridge is still in development, it is a central component to Polygon's aggregaton layer which offers multi-chain interoperability.
 
 The LXLY Bridge currently works with the Polygon zkEVM as the L2 and the Ethereum network as L1.
 

docs/zkEVM/architecture/protocol/lxly-bridge.md

@@ -1,3 +1,3 @@
-The aim with this section is to demostrate that existing smart contracts, developer toolings and wallets work seamlessly in Polygon zkEVM as in Ethereum.
+The aim with this section is to demonstrate that existing smart contracts, developer toolings and wallets work seamlessly in Polygon zkEVM as in Ethereum.
 
 Herein are guides to; writing a smart contract using the OpenZeppelin Wizard, deploying an NFT using Foundry, deploying an ERC-20 token using Hardhat, and verifying a smart contract either manually on the Explorer or using Remix.

docs/zkEVM/how-to/index.md

@@ -1,5 +1,5 @@
 This section contains specifications of other zkEVM features not covered in the Architecture section of this documentation.
 
-First are the two novel languages: The zero-knowledge Assembly (zkASM) language which interpretes the firmware of microprocessor-type state machines, and the Polynomial Identity Language (PIL) which is instrumental in enabling verification of state transitions.
+First are the two novel languages: The zero-knowledge Assembly (zkASM) language which interprets the firmware of microprocessor-type state machines, and the Polynomial Identity Language (PIL) which is instrumental in enabling verification of state transitions.
 
 Second are some of the differences between Polygon zkEVM and the EVM. These are differences in terms of opcodes, supported precompiled contracts, newly added features and other variances.