Concepts proofread and rework 1 (ton-community#982)

* concepts_headers_and_links_styling

* update_pull_request_template

* Update introduction.mdx

rework_and_proofread

* Update introduction.mdx

proofread and active voice

* rework_blockchain_explorers

* explorers_style_update

* Update explorers-in-ton.mdx

proofread and active voice

* Update explorers-in-ton.mdx

proofread_check

* wallet_concepts_update

fixed style, updated information

* Update wallet-apps.mdx

proofread and style update

* fix_tlb_example_mistake

* Update wallet-apps.mdx

proofread and info update

* refactor_walletapps

* extend_tondevwallet_description

* Update wallet-apps.mdx

Proofread and formatting

* add_tonkey_to_dict

* update_nft_usecases

* Update nft.md

Active voice and proofread.

* style_reform

* Update blockchain-of-blockchains.md

proofread

* Update blockchain-of-blockchains.md

Proofread and active voice

* smart_contract_concept_refactor

Rework content

* Update smart-contract-addresses.md

Proofread and clarification.

* comparison_update

Author: reveloper

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,12 +1,13 @@
-<!--- Provide a general summary of your changes in the Title above -->
 
-## Why is it important?
+## Description
 
-<!--- Describe your changes in detail -->
+<--Brief description of the changes introduced in this pull request. Include any relevant issue numbers or links.-->
 
-## Related Issue
+Closes <--link to issue]-->.
 
-<!--- This project accepts pull requests related to open issues, if possible -->
-<!--- If suggesting a new feature or change, please discuss it in an issue first -->
-<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
-<!--- Please link to the issue here, if possible: -->
+## Checklist
+
+- [ ] I have created an issue.
+- [ ] I am working on content that aligns with the [Style guide](https://docs.ton.org/v3/contribute/style-guide/).
+- [ ] I have reviewed and formatted the content according to [Content standardization](https://docs.ton.org/v3/contribute/content-standardization/).
+- [ ] I have reviewed and formatted the text in the article according to [Typography](https://docs.ton.org/v3/contribute/typography/).

cspell.json

@@ -116,6 +116,9 @@
     "Tolk",
     "Toncoin",
     "Toncoins",
+    "Tonhub",
+    "Tonkeeper",
+    "Tonkey",
     "Underload",
     "Uninit",
     "WAGMI",

docs/v3/concepts/dive-into-ton/go-from-ethereum/blockchain-services.md

@@ -1,10 +1,10 @@
-# Blockchain Services
+# Blockchain services
 
-## Domain Name Systems
+## Domain name systems
 
-In Ethereum, users use the Ethereum Name Service (ENS), which is a decentralized naming system built on top of the Ethereum blockchain.
+In Ethereum, users use the **Ethereum Name Service (ENS)**, which is a decentralized naming system built on top of the Ethereum blockchain.
 
-The TON blockchain includes an embedded domain name system known as the TON DNS. It is a decentralized service that allows users to register human-readable domain names for their smart contracts, websites, or any other online content. Such a device facilitates interaction with decentralized applications (dApps) and other resources on the TON blockchain. The DNS system in TON functions similarly to traditional Internet DNS systems, but its decentralized nature eliminates the need for a centralized authority to control and manage domain names, thereby reducing the risks of censorship, fraud, and domain name hijacking.
+The TON blockchain includes an embedded domain name system known as the TON DNS. It's a decentralized service that allows users to register human-readable domain names for their smart contracts, websites, or any other online content. Such a device facilitates interaction with decentralized applications (dApps) and other resources on the TON blockchain. The DNS system in TON functions similarly to traditional Internet DNS systems, but its decentralized nature eliminates the need for a centralized authority to control and manage domain names, thereby reducing the risks of censorship, fraud, and domain name hijacking.
 
 ## WWW
 

docs/v3/concepts/dive-into-ton/go-from-ethereum/difference-of-blockchains.md

@@ -1,4 +1,4 @@
-# The Difference of Blockchains
+# The difference of blockchains
 
 In this chapter, we will examine the key differences between the Ethereum blockchain compared to the TON blockchain. The analysis will include an overview of the network architectures, highlight their unique features, and evaluate the advantages and disadvantages of each.
 
@@ -46,7 +46,7 @@ The result of scripts is always the creation of a transaction.  The transactions
 
 We have already discussed that in Ethereum, a user's wallet is generated based on their address, which is in a 1-to-1 relationship with their public key. But in TON, all wallets are smart contracts that must be deployed by the user himself. Since smart contracts can be configured in different ways and have different features, there are several versions of wallets, which you can read about [here](/v3/documentation/smart-contracts/contracts-specs/wallet-contracts). Due to the fact that wallets are smart contracts, a user can have multiple wallets with different addresses and initial parameters. To send a transaction, the user must sign the message with his private key and send it to his wallet contract, which in turn forwards it to the smart contract of a particular DApp application. This approach greatly increases flexibility in wallet design and developers can add new versions of the wallet in the future. In Ethereum at the moment developers are actively using multi-sig wallets (smart contracts) like gnosis and are just starting to introduce so-called `account-abstractions' like ERC-4337, where wallets will be filled with such functionality as sending transactions without a native token, account recovery, after its loss, etc., but it's worth noting, wallet accounts are much more expensive to use in terms of gas fees compared to EOA in Ethereum.
 
-## Messages and Transactions
+## Messages and transactions
 
 What happens between two contracts is called a message - a small number of tokens and arbitrary data are sent to a specified address. When the message arrives at the contract, it is processed by the contract code, the contract updates its state and optionally sends a new message. All these actions on the contract are recorded as transactions. Let's imagine an example, we have a chain of messages, from contract `A` to contract `B`, from contract `B`, to contract `C`, then we will have two messages and three transactions. But initially, to change the state of the blockchain, you need an outside signal. To invoke a smart contract, you need to send an external message that goes to the validators and they apply it to the smart contract. And we already discussed in the last subsection that a wallet is a smart contract, so this external message usually first goes to the wallet's smart contract, which records them as the first transaction and that first transaction usually contains an embedded message for the actual destination contract. When the wallet smart contract receives the message, it processes it and delivers it to the destination contract (in our example, contract `A` could be a wallet and when it receives the external message, it will have the first transaction). The sequence of transactions forms a chain. So you can see that each smart contract has its own transactions, which means that each contract has its own `little blockchain` (you can read more about it [here](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains)), so the network can process the transactions due to this completely independent of each other
 

docs/v3/concepts/dive-into-ton/go-from-ethereum/solidity-vs-func.md

@@ -37,9 +37,9 @@ In case of FunC, the main data types are:
 
 Currently, FunC has no support for defining custom types.
 
-### See Also
+### See also
 
-- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
+- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)
 
 ## Declaring and using variables
 
@@ -58,9 +58,9 @@ FunC is a more abstract and function-oriented language, it supports dynamic typi
 var z = x + y; // Dynamic variable declaration 
 ```
 
-### See Also
+### See also
 
-- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
+- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)
 
 ## Loops
 
@@ -88,9 +88,9 @@ repeat(10) {
 ;; x = 1024
 ```
 
-### See Also
+### See also
 
-- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
+- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)
 
 ## Functions
 
@@ -114,33 +114,33 @@ Transitioning to FunC, FunC program is essentially a list of function declaratio
 }
 ```
 
-### See Also 
+### See also 
 
-- [Functions](/v3/documentation/smart-contracts/func/docs/functions)
+- [Functions](/v3/documentation/smart-contracts/func/docs/functions/)
 
 ## Flow control structures
 
 Most of the control structures known from curly-braces languages are available in Solidity, including: `if`, `else`, `while`, `do`, `for`, `break`, `continue`, `return`, with the usual semantics known from C or JavaScript.
 
 FunC supports classic `if-else` statements, as well as `ifnot`, `repeat`, `while` and `do/until` loops.  Also since v0.4.0 `try-catch` statements are supported.
 
-### See Also
+### See also
 
-- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
+- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)
 
 ## Dictionaries
 
 Dictionary (hashmap/mapping) data structure is very important for Solidity and FunC contract development because it allows developers to efficiently store and retrieve data in smart contracts, specifically data related to a specific key, such as a user’s balance or ownership of an asset.
 
 Mapping is a hash table in Solidity that stores data as key-value pairs, where the key can be any of the built-in data types, excluding reference types, and the value of the data type can be any type. Mappings are most typically used in Solidity and the Ethereum blockchain to connect a unique Ethereum address to a corresponding value type. In any other programming language, a mapping is equivalent to a dictionary.
 
-In Solidity, mappings do not have a length, nor do they have the concept of setting a key or a value. Mappings are only applicable to state variables that serve as store reference types. When mappings are initialised, they include every possible key, and are mapped to values whose byte-representations are all zeros.
+In Solidity, mappings don't have a length, nor do they have the concept of setting a key or a value. Mappings are only applicable to state variables that serve as store reference types. When mappings are initialised, they include every possible key, and are mapped to values whose byte-representations are all zeros.
 
 An analogy of mappings in FunC are dictionaries, or TON hashmaps. In the context of TON, a hashmap is a data structure represented by a tree of cells. Hashmap maps keys to values ​​of arbitrary type so that quick lookup and modification are possible. The abstract representation of a hashmap in TVM is a Patricia tree, or a compact binary trie. Working with potentially large cell trees can create several problems. Each update operation builds an appreciable number of cells (each cell built costs 500 gas), which means that these operations can run out of resource if used carelessly. To avoid exceeding the gas limit, limit the number of dictionary updates in a single transaction. Also, a binary tree for `N` key-value pairs contains `N-1` forks, which means a total of at least `2N-1` cells. The storage of a smart contract is limited to `65536` unique cells, so the maximum number of entries in the dictionary is `32768`, or slightly more if there are repeating cells.
 
-### See Also 
+### See also 
 
-- [Dictionaries in TON](/v3/documentation/smart-contracts/func/docs/dictionaries)
+- [Dictionaries in TON](/v3/documentation/smart-contracts/func/docs/dictionaries/)
 
 ## Smart-contract communication
 
@@ -208,15 +208,15 @@ var msg = begin_cell()
 send_raw_message(msg, mode);
 ```
 Let's discuss in more detail what it looks like for our smart contract to send a message to our recipient:
-1. Initially, we need to build our message. The full structure of the send can be found [here](/v3/documentation/smart-contracts/message-management/sending-messages). We won't go into detail on how to assemble it here, you can read about that at the link.
+1. Initially, we need to build our message. The full structure of the send can be found [here](/v3/documentation/smart-contracts/message-management/sending-messages/). We won't go into detail on how to assemble it here, you can read about that at the link.
 2. The body of the message represents a cell. In `msg_body_cell` we do: `begin_cell()` - creates `Builder` for the future cell, first `store_uint` - stores the first uint into `Builder` (1 - this is our `op`), second `store_uint` - stores the second uint into `Builder` (num - this is our number that we will manipulate in the receiving contract), `end_cell()` - creates the cell.
 3. To attach the body that will come in `recv_internal` in the message,  we reference the collected cell in the message itself with `store_ref`.
 4. Sending a message.
 
 This example presented how smart contracts can communicate with each other. 
 
-### See Also 
+### See also 
 
-- [Internal Messages](/v3/documentation/smart-contracts/message-management/internal-messages)
-- [Sending Messages](/v3/documentation/smart-contracts/message-management/sending-messages)
-- [Non-bouncable messages](/v3/documentation/smart-contracts/message-management/non-bounceable-messages)
+- [Internal Messages](/v3/documentation/smart-contracts/message-management/internal-messages/)
+- [Sending Messages](/v3/documentation/smart-contracts/message-management/sending-messages/)
+- [Non-bouncable messages](/v3/documentation/smart-contracts/message-management/non-bounceable-messages/)

docs/v3/concepts/dive-into-ton/go-from-ethereum/tvm-vs-evm.md

@@ -1,10 +1,10 @@
 # TVM vs EVM
 
-Ethereum Virtual Machine (EVM) and TON Virtual Machine (TVM) are both stack-based virtual machines developed for running smart contract code. Although they have common features, there are notable distinctions between them.
+**Ethereum Virtual Machine (EVM)** and **TON Virtual Machine (TVM)** are both stack-based virtual machines developed for running smart contract code. Although they have common features, there are notable distinctions between them.
 
 ## Data presentation
 
-### Ethereum Virtual Machine (EVM)
+### EVM
 1. Fundamental Data Units
  - The EVM operates primarily on 256-bit integers, reflecting its design around Ethereum's cryptographic functions (e.g.,   Keccak-256 hashing and elliptic curve operations).
  - Data types are limited mainly to integers, bytes, and occasionally arrays of these types, but all must conform to 256-bit processing rules.
@@ -15,7 +15,7 @@ Ethereum Virtual Machine (EVM) and TON Virtual Machine (TVM) are both stack-base
 - The simplification to 256-bit word constraints means that the EVM is not inherently designed to handle complex or custom data structures directly.
 - Developers often need to implement additional logic within smart contracts to simulate more complex data structures, which can lead to increased gas costs and complexity.
 
-### TON Virtual Machine (TVM)
+### TVM
 1. Cell-Based Architecture
 - TVM uses a unique "bag of cells" model to represent data. Each cell can contain up to 128 data bytes and can have up to 4 references to other cells.
 - This structure allows the TVM to natively support arbitrary algebraic data types and more complex constructions such as trees or directed acyclic graphs (DAGs) directly within its storage model.
@@ -28,12 +28,12 @@ Ethereum Virtual Machine (EVM) and TON Virtual Machine (TVM) are both stack-base
 
 ## Stack machine
 
-### Ethereum Virtual Machine (EVM)
+### EVM
 
 - The EVM operates as a traditional stack-based machine, where it uses a last-in, first-out (LIFO) stack to manage computation.
 - It processes operations by pushing and popping 256-bit integers, which are the standard size for all elements in the stack.
 
-### TON Virtual Machine (TVM)
+### TVM
 
 - TVM also functions as a stack-based machine but with a key distinction: it supports both 257-bit integers and references to cells.
 - This allows TVM to push and pop these two distinct types of data onto/from the stack, providing enhanced flexibility in direct data manipulation.
@@ -75,41 +75,41 @@ It’s essential to note that the EVM supports complex data structures by levera
 
 ## Arithmetic operations
 
-### Ethereum Virtual Machine (EVM)
+### EVM
 
 - The Ethereum Virtual Machine (EVM) handles arithmetic using 256-bit integers, meaning operations such as addition, subtraction, multiplication, and division are tailored to this data size. 
 
-### TON Virtual Machine (TVM)
+### TVM
 
 - The TON Virtual Machine (TVM) supports a more diverse range of arithmetic operations, including 64-bit, 128-bit, and 256-bit integers, both unsigned and signed, as well as modulo operations. TVM further enhances its arithmetic capabilities with operations like multiply-then-shift and shift-then-divide, which are particularly useful for implementing fixed-point arithmetic. This variety allows developers to select the most efficient arithmetic operations based on the specific requirements of their smart contracts, offering potential optimizations based on data size and type.
 
 ## Overflow checks
 
-### Ethereum Virtual Machine (EVM)
+### EVM
 
 - In the EVM, overflow checks are not inherently performed by the virtual machine itself. With the introduction of Solidity 0.8.0, automatic overflow and underflow checks were integrated into the language to enhance security. These checks help prevent common vulnerabilities related to arithmetic operations but require newer versions of Solidity, as earlier versions necessitate manual implementation of these safeguards. 
 
-### TON Virtual Machine (TVM)
+### TVM
 
 - In contrast, TVM automatically performs overflow checks on all arithmetic operations, a feature built directly into the virtual machine. This design choice simplifies the development of smart contracts by inherently reducing the risk of errors and enhancing the overall reliability and security of the code.
 
 ## Cryptography and hash functions
 
-### Ethereum Virtual Machine (EVM)
+### EVM
 
 - EVM has support for the Ethereum-specific cryptography scheme, such as the secp256k1 elliptic curve and the keccak256 hash function. Also, EVM does not have built-in support for Merkle proofs, which are cryptographic proofs used to verify the membership of an element in a set.
 
-### TON Virtual Machine (TVM)
+### TVM
 
 - TVM offers support for 256-bit Elliptic Curve Cryptography (ECC) for predefined curves, like Curve25519. It also supports Weil pairings on some elliptic curves, which are useful for fast implementation of zk-SNARKs (zero-knowledge proofs). Popular hash functions like sha256 are also supported, providing more options for cryptographic operations. In addition, TVM can work with Merkle proofs, providing additional cryptographic features that can be beneficial for certain use cases, such as verifying the inclusion of a transaction in a block.
 
 ## High-level languages
 
-### Ethereum Virtual Machine (EVM)
+### EVM
 
 - EVM primarily uses Solidity as its high-level language, which is an object-oriented, statically-typed language similar to JavaScript and C++. Also, there are other languages for writing Ethereum smart-contracts such as Vyper, Yul, etc.
 
-### TON Virtual Machine (TVM)
+### TVM
 
 - TVM uses FunC as a high-level language designed for writing TON smart contracts. It is a procedural language with static types and support for algebraic data types. FunC compiles to Fift, which in turn compiles to TVM bytecode.