Text corrections

lkhg · Jan 16, 2024 · c4f1dbd · c4f1dbd
1 parent 3e19c44
commit c4f1dbd
Show file tree

Hide file tree

Showing 7 changed files with 10 additions and 10 deletions.
diff --git a/docs/miden/vm/architecture/introduction.md b/docs/miden/vm/architecture/introduction.md
@@ -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.
 

diff --git a/docs/miden/vm/architecture/stack/field-ops.md b/docs/miden/vm/architecture/stack/field-ops.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)
 

diff --git a/docs/miden/vm/tools/debugger.md b/docs/miden/vm/tools/debugger.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. |

diff --git a/docs/pos/architecture/index.md b/docs/pos/architecture/index.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
 

diff --git a/docs/pos/concepts/transactions/index.md b/docs/pos/concepts/transactions/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`.
 

diff --git a/docs/zkEVM/how-to/index.md b/docs/zkEVM/how-to/index.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.
diff --git a/docs/zkEVM/spec/index.md b/docs/zkEVM/spec/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.