From 0add546c15cc090f086cc2122f7bc48d68fa7522 Mon Sep 17 00:00:00 2001 From: Yash Jagtap Date: Sun, 12 Jan 2025 19:10:45 +0530 Subject: [PATCH] fix: typos --- .../archive-migration-prerequisites.mdx | 2 +- docs/berkeley-upgrade/archive-migration/index.mdx | 2 +- .../mainnet-database-maintenance.mdx | 2 +- docs/exchange-operators/faq.mdx | 2 +- docs/exchange-operators/index.mdx | 2 +- .../rosetta/samples/scan-blocks.mdx | 2 +- .../rosetta/samples/send-transactions.mdx | 4 ++-- docs/glossary.mdx | 2 +- docs/mina-protocol/scan-state.mdx | 2 +- docs/mina-protocol/time-locked-accounts.mdx | 2 +- docs/mina-protocol/whats-in-a-block.mdx | 2 +- docs/node-developers/sandbox-node.mdx | 2 +- .../connecting-to-the-network.mdx | 2 +- docs/node-operators/index.mdx | 2 +- docs/node-operators/seed-peers/docker-compose.mdx | 2 +- docs/node-operators/troubleshooting.mdx | 4 ++-- docs/using-mina/how-to-send-and-receive.mdx | 2 +- docs/zkapps/o1js-reference/classes/DynamicProof.mdx | 2 +- .../namespaces/Experimental/classes/BatchReducer.mdx | 12 ++++++------ .../Experimental/functions/IndexedMerkleMap.mdx | 2 +- .../namespaces/Mina/functions/LocalBlockchain.mdx | 2 +- .../Mina/type-aliases/NetworkConstants.mdx | 2 +- docs/zkapps/o1js-reference/type-aliases/Provable.mdx | 2 +- docs/zkapps/o1js/custom-tokens.mdx | 2 +- docs/zkapps/o1js/keccak.mdx | 2 +- docs/zkapps/o1js/sha256.mdx | 2 +- .../feature-overview/custom-tokens.mdx | 6 +++--- .../writing-a-zkapp/feature-overview/permissions.mdx | 2 +- .../introduction-to-zkapps/interact-with-mina.md | 2 +- .../introduction-to-zkapps/secure-zkapps.mdx | 2 +- .../introduction-to-zkapps/smart-contracts.mdx | 2 +- .../testing-zkapps-lightnet.mdx | 6 +++--- .../testing-zkapps-locally.mdx | 4 ++-- docs/zkapps/zkapp-development-frameworks.mdx | 2 +- 34 files changed, 46 insertions(+), 46 deletions(-) diff --git a/docs/berkeley-upgrade/archive-migration/archive-migration-prerequisites.mdx b/docs/berkeley-upgrade/archive-migration/archive-migration-prerequisites.mdx index 82c4cd68b..7e9b70698 100644 --- a/docs/berkeley-upgrade/archive-migration/archive-migration-prerequisites.mdx +++ b/docs/berkeley-upgrade/archive-migration/archive-migration-prerequisites.mdx @@ -31,7 +31,7 @@ You can use any gsutil-compatible alternative to Google Cloud or a gsutil wrappe ## (Optional) Google Cloud bucket with Devnet/Mainnet precomputed blocks -Precomputed blocks are the JSON files that a correctly configured node updloads to the Google Cloud bucket. +Precomputed blocks are the JSON files that a correctly configured node uploads to the Google Cloud bucket. The Devnet/Mainnet to Berkeley archive data migration requires access to precomputed blocks that are uploaded by daemons that are connected to the Devnet or Mainnet networks. The **berkeley-migration** app uses the gsutil app to download blocks. If you didn't store precomputed blocks during the first phase of migration, you can use the precomputed blocks provided by Mina Foundation. diff --git a/docs/berkeley-upgrade/archive-migration/index.mdx b/docs/berkeley-upgrade/archive-migration/index.mdx index e43dcf017..e19526e61 100644 --- a/docs/berkeley-upgrade/archive-migration/index.mdx +++ b/docs/berkeley-upgrade/archive-migration/index.mdx @@ -37,7 +37,7 @@ Finally, see the shell script example that is compatible with a stock Debian 11 After the migration, you will have two databases: -- The original Devnet/Mainnet database with small data adjustments (all pending blocks from last canoncial block until the fork block are converted to canoncial blocks) +- The original Devnet/Mainnet database with small data adjustments (all pending blocks from last canonical block until the fork block are converted to canoncial blocks) - A new Berkeley database based on Devnet/Mainnet data, but: - Without Devnet/Mainnet orphaned blocks - Without pending blocks that are not in the canonical chain diff --git a/docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx b/docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx index 8bc94be80..c9256e6da 100644 --- a/docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx +++ b/docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx @@ -24,7 +24,7 @@ preserving some aspect of the database that is lost during the migration process Two databases exist after the successful migration: - The original Devnet/Mainnet database with small data adjustments: - - All pending blocks from last canoncial block until the fork block are converted to canonical blocks + - All pending blocks from last canonical block until the fork block are converted to canonical blocks - A new Berkeley database based on Devnet/Mainnet data with these differences: - Without Devnet/Mainnet orphaned blocks diff --git a/docs/exchange-operators/faq.mdx b/docs/exchange-operators/faq.mdx index 689cdb85a..5f6dd8083 100644 --- a/docs/exchange-operators/faq.mdx +++ b/docs/exchange-operators/faq.mdx @@ -162,7 +162,7 @@ No, there are no official broadcast nodes at this time. However, you can broadc ### Should I be staking my funds? -Since Mina is a Proof of Stake (PoS) consensus network without lockup for staked tokens, it is recommended to stak these funds to support the quality of the Mina network. Additionally, by not staking, you are missing out on staking rewards that you can otherwise be receiving from the Mina blockchain. +Since Mina is a Proof of Stake (PoS) consensus network without lockup for staked tokens, it is recommended to stake these funds to support the quality of the Mina network. Additionally, by not staking, you are missing out on staking rewards that you can otherwise be receiving from the Mina blockchain. You can look into staking this wallet, either by running your own block production node or just by delegating your funds to a staking pool on the network. Delegating to a staking pool is simpler to set up. diff --git a/docs/exchange-operators/index.mdx b/docs/exchange-operators/index.mdx index 4a8f85cc8..b269fd708 100644 --- a/docs/exchange-operators/index.mdx +++ b/docs/exchange-operators/index.mdx @@ -29,7 +29,7 @@ Use Rosetta API if you are: - Integrating the Mina blockchain with your exchange - Building blockchain applications, such as explorers and wallets -Using Rosetta for building your application is preferrable, as it's API is more appropriate for applications and far more stable than GraphQL. +Using Rosetta for building your application is preferable, as it's API is more appropriate for applications and far more stable than GraphQL. - [Running with Docker](/exchange-operators/rosetta/run-with-docker) - How to install Rosetta from Docker image diff --git a/docs/exchange-operators/rosetta/samples/scan-blocks.mdx b/docs/exchange-operators/rosetta/samples/scan-blocks.mdx index 210902935..109ef99c0 100644 --- a/docs/exchange-operators/rosetta/samples/scan-blocks.mdx +++ b/docs/exchange-operators/rosetta/samples/scan-blocks.mdx @@ -32,7 +32,7 @@ async function waitForBlock(blockHeight: number) { def wait_for_block(block_index): """ Checks if block with given index exist - Once the /block response is succesful - returns the response + Once the /block response is successful - returns the response Otherwise, retries fetching it with 10 seconds delay """ diff --git a/docs/exchange-operators/rosetta/samples/send-transactions.mdx b/docs/exchange-operators/rosetta/samples/send-transactions.mdx index 2ddda5448..1e4ef580b 100644 --- a/docs/exchange-operators/rosetta/samples/send-transactions.mdx +++ b/docs/exchange-operators/rosetta/samples/send-transactions.mdx @@ -11,14 +11,14 @@ This flow is also described in the [Construction API Overview](https://docs.clou ::: The steps needed to send payment in MINA token are following: -1. Given a key pair, derive the account indentifier using `/construction/derive` endpoint +1. Given a key pair, derive the account identifier using `/construction/derive` endpoint 1. Call `/construction/preprocess` and `/construction/metadata` to construct parameters for `/construction/payloads` request 1. Create an unsigned transaction blob using `construction/payloads` endpoint 1. Call `construction/parse` (optional) to check if the unsigned transaction does what you expect 1. Use detached signer to sign the transaction 1. Call `construction/combine` to generate signed blob to be sent via `/construction/submit` endpoint 1. Call `construction/parse` again (optional) to confirm correctness of the signed transaction -1. Get a future transaction hash using `/construction/hash` enpoint +1. Get a future transaction hash using `/construction/hash` endpoint 1. Submit the signed transaction blob via `/construction/submit` endpoint For ease of readability, this sample implementation skips the sanity checks (steps 4 and 7) and combines steps 2 and 3 in a single `tx_payloads` function call. diff --git a/docs/glossary.mdx b/docs/glossary.mdx index 515bef481..d82f7adbe 100644 --- a/docs/glossary.mdx +++ b/docs/glossary.mdx @@ -123,7 +123,7 @@ A digital asset or currency that uses cryptographic primitives to secure financi ### daemon -The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subcribe model. +The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subscribe model. ### DAO diff --git a/docs/mina-protocol/scan-state.mdx b/docs/mina-protocol/scan-state.mdx index 1b87683c8..72b42f250 100644 --- a/docs/mina-protocol/scan-state.mdx +++ b/docs/mina-protocol/scan-state.mdx @@ -4,7 +4,7 @@ hide_title: true description: A data structure that allows decoupling the production of transaction SNARKs from block producers to snark workers. keywords: - data structure - - blockchian + - blockchain - full binary tree - snark - snarked ledger diff --git a/docs/mina-protocol/time-locked-accounts.mdx b/docs/mina-protocol/time-locked-accounts.mdx index f639e67e2..a81957611 100644 --- a/docs/mina-protocol/time-locked-accounts.mdx +++ b/docs/mina-protocol/time-locked-accounts.mdx @@ -26,7 +26,7 @@ A time-lock consists of the following fields `initial_minimum_balance`, `cliff` You can still use an account if it has a time-lock, as long as the account holds enough funds. The amount of funds that are time-locked starts off as `initial_minimum_balance` at the beginning of the network. Once the network reaches a block height equal to the `cliff`, the time-locked amount begins to decrease by the `vesting_increment` amount every `vesting_period`. -For a more technical explanaition of this process, please see [RFC-0025](https://github.com/MinaProtocol/mina/blob/master/rfcs/0025-time-locked-accounts.md) which has a more in-depth overview. +For a more technical explanation of this process, please see [RFC-0025](https://github.com/MinaProtocol/mina/blob/master/rfcs/0025-time-locked-accounts.md) which has a more in-depth overview. ### Liquid Balance Details: diff --git a/docs/mina-protocol/whats-in-a-block.mdx b/docs/mina-protocol/whats-in-a-block.mdx index 5fde2d438..772aeb26d 100644 --- a/docs/mina-protocol/whats-in-a-block.mdx +++ b/docs/mina-protocol/whats-in-a-block.mdx @@ -91,7 +91,7 @@ The consensus state is comprised of: * Block stake winner * Block creator * Coinbase receiver -* Superchage coinbase +* Supercharge coinbase #### Consensus Constants diff --git a/docs/node-developers/sandbox-node.mdx b/docs/node-developers/sandbox-node.mdx index 50b50e4e6..067777d91 100644 --- a/docs/node-developers/sandbox-node.mdx +++ b/docs/node-developers/sandbox-node.mdx @@ -30,7 +30,7 @@ docker run \ ``` -This command starts a daemon inside the docker container and exposes the GraphQL port (3085) to your computer. This port is used for communication with the client. This daemon automatical runs in the background with a block producer and SNARK worker. +This command starts a daemon inside the docker container and exposes the GraphQL port (3085) to your computer. This port is used for communication with the client. This daemon automatically runs in the background with a block producer and SNARK worker. You can view logs by executing. diff --git a/docs/node-operators/block-producer-node/connecting-to-the-network.mdx b/docs/node-operators/block-producer-node/connecting-to-the-network.mdx index 86b9e0ccb..a35fd5eb2 100644 --- a/docs/node-operators/block-producer-node/connecting-to-the-network.mdx +++ b/docs/node-operators/block-producer-node/connecting-to-the-network.mdx @@ -238,7 +238,7 @@ The expected response includes these fields: - When sync status reaches `Synced` and the node is connected to 1 or more peers, the node is successfully connected to the network. A corresponding daemon log shows the sync status: `[Info] Mina daemon is now synced`. -- An issue with your port configuration can causethe `Bootstrap` state to persist for more than an hour. +- An issue with your port configuration can cause the `Bootstrap` state to persist for more than an hour. ## Step up your game diff --git a/docs/node-operators/index.mdx b/docs/node-operators/index.mdx index 66d2e9fc9..bf436c79f 100644 --- a/docs/node-operators/index.mdx +++ b/docs/node-operators/index.mdx @@ -44,7 +44,7 @@ This section describes operations on Mina and how node operators can run Mina no - [Archive Nodes](/node-operators/archive-node) - Running an Archive Node - [Seed Peers](/node-operators/seed-peers) - Running a Seed Peer - [Data and History](/node-operators/data-and-history) - A look at retrieving historic data. -- [Delegation Program](/node-operators/delegation-program) - The Mina Foundation Delegation Prgram for Block Producers +- [Delegation Program](/node-operators/delegation-program) - The Mina Foundation Delegation Program for Block Producers - [Staking Service Guidelines](/node-operators/staking-service-guidelines) - [Mina Signer](/node-operators/mina-signer) - [Mina CLI Reference](/node-operators/mina-cli-reference) - Guide to CLI interactions with Mina networks diff --git a/docs/node-operators/seed-peers/docker-compose.mdx b/docs/node-operators/seed-peers/docker-compose.mdx index 95911771d..71505ec29 100644 --- a/docs/node-operators/seed-peers/docker-compose.mdx +++ b/docs/node-operators/seed-peers/docker-compose.mdx @@ -54,7 +54,7 @@ services: To retrieve the status of the Mina Node, run `docker compose exec mina_node mina client status` -In the client status, you should also see the _Adresses and ports_ section. +In the client status, you should also see the _Addresses and ports_ section. ```shell Addresses and ports: diff --git a/docs/node-operators/troubleshooting.mdx b/docs/node-operators/troubleshooting.mdx index 2422947d4..ea71a4a00 100644 --- a/docs/node-operators/troubleshooting.mdx +++ b/docs/node-operators/troubleshooting.mdx @@ -1,7 +1,7 @@ --- title: Troubleshooting hide_title: true -description: Answers to comon problems when setting up a Mina daemon +description: Answers to common problems when setting up a Mina daemon keywords: - syncing a node - networking @@ -161,7 +161,7 @@ There is some behavior with our p2p networking module that triggers this warning Here is an example of this using the [ufw](https://help.ubuntu.com/community/UFW#UFW_-_Uncomplicated_Firewall) firewall tool. Thanks Ducca for sharing these rules and confirming they fix the issues on Hetzner. -Allow SSH, HTTP, HTTPS porst: +Allow SSH, HTTP, HTTPS ports: ``` ufw allow 22 diff --git a/docs/using-mina/how-to-send-and-receive.mdx b/docs/using-mina/how-to-send-and-receive.mdx index 7c2fd6739..e6b829761 100644 --- a/docs/using-mina/how-to-send-and-receive.mdx +++ b/docs/using-mina/how-to-send-and-receive.mdx @@ -96,7 +96,7 @@ When sending transactions on a blockchain, such as Mina, senders must include a ::: -### Viewing your transction on a blockchain explorer +### Viewing your transaction on a blockchain explorer You can view your transactions using one of the community-run blockchain explorers: diff --git a/docs/zkapps/o1js-reference/classes/DynamicProof.mdx b/docs/zkapps/o1js-reference/classes/DynamicProof.mdx index 054b1c956..6fc6e4afe 100644 --- a/docs/zkapps/o1js-reference/classes/DynamicProof.mdx +++ b/docs/zkapps/o1js-reference/classes/DynamicProof.mdx @@ -1,4 +1,4 @@ -The `DynamicProof` class enables circuits to verify proofs using in-ciruit verfication keys. +The `DynamicProof` class enables circuits to verify proofs using in-circuit verification keys. This is opposed to the baked-in verification keys of the `Proof` class. In order to use this, a subclass of DynamicProof that specifies the public input and output types along with the maxProofsVerified number has to be created. diff --git a/docs/zkapps/o1js-reference/namespaces/Experimental/classes/BatchReducer.mdx b/docs/zkapps/o1js-reference/namespaces/Experimental/classes/BatchReducer.mdx index 25009f00c..5832727e4 100644 --- a/docs/zkapps/o1js-reference/namespaces/Experimental/classes/BatchReducer.mdx +++ b/docs/zkapps/o1js-reference/namespaces/Experimental/classes/BatchReducer.mdx @@ -836,7 +836,7 @@ the element of type `T` to put assertions on. A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. **Param** an array of [Field](../../../classes/Field.mdx) elements describing the provable data of the new `T` element. @@ -969,7 +969,7 @@ the element of type `T` to put assertions on. A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. **Param** an array of [Field](../../../classes/Field.mdx) elements describing the provable data of the new `T` element. @@ -1056,7 +1056,7 @@ the element of type `T` to put assertions on. A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. **Param** an array of [Field](../../../classes/Field.mdx) elements describing the provable data of the new `T` element. @@ -2104,7 +2104,7 @@ fromFields: {}; A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. ###### Param @@ -2353,7 +2353,7 @@ fromFields: {}; A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. ###### Param @@ -2509,7 +2509,7 @@ fromFields: {}; A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. ###### Param diff --git a/docs/zkapps/o1js-reference/namespaces/Experimental/functions/IndexedMerkleMap.mdx b/docs/zkapps/o1js-reference/namespaces/Experimental/functions/IndexedMerkleMap.mdx index 1a98404bb..9cd017d52 100644 --- a/docs/zkapps/o1js-reference/namespaces/Experimental/functions/IndexedMerkleMap.mdx +++ b/docs/zkapps/o1js-reference/namespaces/Experimental/functions/IndexedMerkleMap.mdx @@ -37,7 +37,7 @@ ZkProgram({ Initially, every `IndexedMerkleMap` is populated by a single key-value pair: `(0, 0)`. The value for key `0` can be updated like any other. When keys and values are hash outputs, `(0, 0)` can serve as a convenient way to represent a dummy update to the tree, since 0 is not -effciently computable as a hash image, and this update doesn't affect the Merkle root. +efficiently computable as a hash image, and this update doesn't affect the Merkle root. ## Parameters diff --git a/docs/zkapps/o1js-reference/namespaces/Mina/functions/LocalBlockchain.mdx b/docs/zkapps/o1js-reference/namespaces/Mina/functions/LocalBlockchain.mdx index 66952eba9..a8c52e5a7 100644 --- a/docs/zkapps/o1js-reference/namespaces/Mina/functions/LocalBlockchain.mdx +++ b/docs/zkapps/o1js-reference/namespaces/Mina/functions/LocalBlockchain.mdx @@ -225,7 +225,7 @@ A mock Mina blockchain running locally and useful for testing. > slotTime: UInt64; > ``` > -> Duration of 1 slot in millisecondw +> Duration of 1 slot in milliseconds > > ### getNetworkState() > diff --git a/docs/zkapps/o1js-reference/namespaces/Mina/type-aliases/NetworkConstants.mdx b/docs/zkapps/o1js-reference/namespaces/Mina/type-aliases/NetworkConstants.mdx index 433b553e6..5135f4b5f 100644 --- a/docs/zkapps/o1js-reference/namespaces/Mina/type-aliases/NetworkConstants.mdx +++ b/docs/zkapps/o1js-reference/namespaces/Mina/type-aliases/NetworkConstants.mdx @@ -26,7 +26,7 @@ genesisTimestamp: UInt64; slotTime: UInt64; ``` -Duration of 1 slot in millisecondw +Duration of 1 slot in milliseconds ## Source diff --git a/docs/zkapps/o1js-reference/type-aliases/Provable.mdx b/docs/zkapps/o1js-reference/type-aliases/Provable.mdx index ababb2dea..f448b3073 100644 --- a/docs/zkapps/o1js-reference/type-aliases/Provable.mdx +++ b/docs/zkapps/o1js-reference/type-aliases/Provable.mdx @@ -59,7 +59,7 @@ fromFields: (fields: Field[], aux: any[]) => T; A function that returns an element of type `T` from the given provable and "auxiliary" data. -This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`. +This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`. #### Parameters diff --git a/docs/zkapps/o1js/custom-tokens.mdx b/docs/zkapps/o1js/custom-tokens.mdx index 04049ce6f..0eb3feafd 100644 --- a/docs/zkapps/o1js/custom-tokens.mdx +++ b/docs/zkapps/o1js/custom-tokens.mdx @@ -121,7 +121,7 @@ class TokenContract extends SmartContract { amount: UInt64, callback: Experimental.Callback ) { - // approves the callback which deductes the amount of tokens from the sender + // approves the callback which deducts the amount of tokens from the sender let senderAccountUpdate = this.approve(callback); // Create constraints for the sender account update and amount diff --git a/docs/zkapps/o1js/keccak.mdx b/docs/zkapps/o1js/keccak.mdx index f42790ace..f9a56cdd3 100644 --- a/docs/zkapps/o1js/keccak.mdx +++ b/docs/zkapps/o1js/keccak.mdx @@ -25,7 +25,7 @@ Because of the common usage of Keccak in Ethereum, it is a key component of o1js ## Keccak and Poseidon -As an o1js developer, you are likely familar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js. +As an o1js developer, you are likely familiar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js. In contrast, Keccak is a hash function that requires binary arithmetic. It operates over binary data and is not native to most zero knowledge proofs. For this reason, Keccak is not as efficient as Poseidon, but it is still very useful for verifying Ethereum transactions and blocks. So, when you choose what hash function to use, important considerations include the use case and the data that needs to be hashed. diff --git a/docs/zkapps/o1js/sha256.mdx b/docs/zkapps/o1js/sha256.mdx index d07557559..493805a1f 100644 --- a/docs/zkapps/o1js/sha256.mdx +++ b/docs/zkapps/o1js/sha256.mdx @@ -25,7 +25,7 @@ widely used for traditional Web2 applications and protocols and blockchain techn ## SHA-256 and Poseidon -As an o1js developer, you are likely familar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js. +As an o1js developer, you are likely familiar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js. In contrast, SHA-2 is a hash function that requires binary arithmetic. It operates over binary data and is not native to most zero knowledge proofs. For this reason, SHA-256 is not as efficient as Poseidon. However, it is still very useful for verifying Ethereum transactions and blocks. So, when you choose what hash function to use, important considerations include the use case and the data that needs to be hashed. diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/custom-tokens.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/custom-tokens.mdx index eee17f0e2..2d0c6eba4 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/custom-tokens.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/custom-tokens.mdx @@ -30,7 +30,7 @@ If you want to create a fungible token you can use the Blockchain applications have various use cases for custom tokens, including a real-world financial asset, stake in an on-chain protocol, or even skill points in a game. Most blockchains, like Ethereum, do not natively support custom tokens. You implement custom tokens as smart contracts on top of the execution layer of the underlying protocol. -Token standards ensure the interoperability of applications on Etherum, these standardisations are agree upon in ERCs, Ethereum Request for customElements, such as the fungible token standard [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/). +Token standards ensure the interoperability of applications on Ethereum, these standardisations are agree upon in ERCs, Ethereum Request for customElements, such as the fungible token standard [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/). The Ethereum community has created and agreed upon other reference implementations and standardisation that are audited and easy to configure, such as [ERC-721](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/) for NFTs. Mina supports custom token functionality at a low level in the tech stack. Mina treats custom tokens almost the same way as the native MINA token. This approach offers the following benefits: @@ -107,7 +107,7 @@ Each subclass token contract that inherits the default `TokenContract` must impl approveBase(forest: AccountUpdateForest): void; ``` -The `TokenContract` also containts helper methods that make it easy to iterate through and approve a forest of child account updates. +The `TokenContract` also contains helper methods that make it easy to iterate through and approve a forest of child account updates. The usual implementation is as easy as this: @@ -174,7 +174,7 @@ abstract class TokenContract extends SmartContract { } ``` -Which utlizses the `Approvable` API to send token from an account to another one. +Which utilizes the `Approvable` API to send token from an account to another one. ## Custom Token Terminology diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx index f175f0e29..0807a2d4f 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx @@ -274,7 +274,7 @@ setVerificationKey: { ``` The first property, `auth`, is one of the previously introduced authentication types - `none`, `impossible`, `proof`, `signature` or `signatureOrProof`. -The `txnVersion` property on the other hand is the newly introduce transction version, which specifies the version of a transaction that was supported by the protocol when the zkApp verification key was last changed. +The `txnVersion` property on the other hand is the newly introduce transaction version, which specifies the version of a transaction that was supported by the protocol when the zkApp verification key was last changed. o1js exposes a function `TransactionVersion.current()` which returns the current transaction version of the protocol. diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.md b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.md index 78b6b1247..934058d53 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.md +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.md @@ -305,7 +305,7 @@ To unpack what happens here, the first line of the method creates a new, empty a let senderUpdate = AccountUpdate.create(this.sender); ``` -- `AccountUpdate` is the class in o1js that represents account udpates. +- `AccountUpdate` is the class in o1js that represents account updates. - `AccountUpdate.create()` instantiates this class and attaches the update to the current transaction at the same level where `create` is called. If it is called inside an `@method`, the `AccountUpdate` is created as a child (public input) of the zkApp update. diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps.mdx index d9f17653a..30b661419 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps.mdx @@ -319,7 +319,7 @@ There is a more complicated version of this problem when interacting with accoun To have a concrete example, consider a token airdrop. As the token contract developer, you precompute a [Merkle map](/zkapps/o1js/merkle-tree) containing eligible accounts and their airdrop amounts, and store the Merkle root onchain. _Claiming_ an airdrop has to involve updating the tree and onchain root, because otherwise the same account could claim the airdrop multiple times. -To scale payouts to multiple concurrent users per block, you approach the problem with [actions and reducer](/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer). To claim, a user dipatches a "claim" action that contains their address and airdrop amount. +To scale payouts to multiple concurrent users per block, you approach the problem with [actions and reducer](/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer). To claim, a user dispatches a "claim" action that contains their address and airdrop amount. On top of that, every block, you run a reducer method which contains the following logic: diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx index 1a7ab479e..3ed8172ef 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx @@ -26,7 +26,7 @@ You write smart contracts by extending the base class `SmartContract`: class HelloWorld extends SmartContract {} ``` -The `constructor` of a `SmartContract` is inherited from the base class and cannot be overriden. +The `constructor` of a `SmartContract` is inherited from the base class and cannot be overridden. The zkApp account address (a public key) is its only argument: diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-lightnet.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-lightnet.mdx index 2972a829e..ef0db1f55 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-lightnet.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-lightnet.mdx @@ -131,7 +131,7 @@ You can configure different network properties as appropriate to your testing re ### Start the network without the archive data tools -By default, the Lightnet blockchian network starting up also launches the archive data tools such as the `Mina archive process`, the `PostgreSQL RDBMS` and the `Archive-Node-API` application. +By default, the Lightnet blockchain network starting up also launches the archive data tools such as the `Mina archive process`, the `PostgreSQL RDBMS` and the `Archive-Node-API` application. To use fewer resources when your testing does not require the archive data tools, you can start the network without them. @@ -258,7 +258,7 @@ To get the network status use the following command: $ zk lightnet status ``` -The network status is returned, including HTTP endpoints, network propertis and state, code snippet of a zkApp using o1js API, and more. +The network status is returned, including HTTP endpoints, network properties and state, code snippet of a zkApp using o1js API, and more. ## Blockchain accounts @@ -314,7 +314,7 @@ Use HTTP endpoints to manage accounts: ### Lightnet o1js API namespace The `acquireKeyPair()`, `releaseKeyPair()`, and `listAcquiredKeyPairs()` methods in the `Lightnet` o1js API namespace handle the communication with the running Mina accounts manager helper tool. -For details, see the source code comments of the correspointing [namespace](https://github.com/o1-labs/o1js/blob/23cdfa3e17a8e8132b70895d34aab711cebd676f/src/lib/mina/fetch.ts#L804) methods. +For details, see the source code comments of the corresponding [namespace](https://github.com/o1-labs/o1js/blob/23cdfa3e17a8e8132b70895d34aab711cebd676f/src/lib/mina/fetch.ts#L804) methods. For the real-world example of using Lightnet and o1js API, see [run-live.ts](https://github.com/o1-labs/o1js/blob/main/src/examples/zkapps/hello-world/run-live.ts) example file. diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-locally.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-locally.mdx index 3b6d47c0a..aeb236f5b 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-locally.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/testing-zkapps-locally.mdx @@ -158,12 +158,12 @@ describe('Add smart contract integration test', () => { await txn.sign([feePayerKey, zkAppPrivateKey]).send(); }); - it('sets intitial state of num to 1', async () => { + it('sets initial state of num to 1', async () => { currentState = zkAppInstance.num.get(); expect(currentState).toEqual(Field(1)); }); - it('correctly updates num from intial state to 3', async () => { + it('correctly updates num from initial state to 3', async () => { txn = await Mina.transaction(feePayer, async () => { await zkApp.update(); }); diff --git a/docs/zkapps/zkapp-development-frameworks.mdx b/docs/zkapps/zkapp-development-frameworks.mdx index 86cfa86c2..b7a28efc3 100644 --- a/docs/zkapps/zkapp-development-frameworks.mdx +++ b/docs/zkapps/zkapp-development-frameworks.mdx @@ -78,5 +78,5 @@ Start here: |**Censorship resistance**|Decentralized and censorship resistant.|Censorship resistance via hybrid sequencing model.| |**Support for multi-user apps**|Many multi-user use cases require sophisticated architecture and are limited by L1 throughput.|Capable of handling higher throughput and multiple concurrent users, thanks to Protokit's modular sequencer.| |**Execution environment**|Proving off-chain, verification on-chain, transaction ordering possible on-chain.|Hybrid execution model, both on-chain (sequencer) and off-chain thanks to recursive zk-proofs, verification on-chain (MINA L1).| -|**DX**|New programming model, distinct from traditional web3.0 development.|Module oriented app-chain development, similiar to Substrate Pallets, Cosmos SDK Modules or EVM smart contracts.| +|**DX**|New programming model, distinct from traditional web3.0 development.|Module oriented app-chain development, similar to Substrate Pallets, Cosmos SDK Modules or EVM smart contracts.| |**Composability**|Fully composable. Contracts can call other contracts directly within a single transaction.|Protokit supports bi-directional L2 ↔ L1 messaging out of the box.|