Merge pull request #387 from SsNiPeR1/main

Update tvm-overview.md

docs/learn/tvm-instructions/tvm-overview.md

@@ -15,11 +15,11 @@ This document provides a bird's-eye view of how TVM executes transactions.
 When some event happens on the account in one of the TON chains, it causes a **transaction**. The most common event is the "arrival of some message", but generally speaking there could be `tick-tock`, `merge`, `split` and other events.
 
 Each transaction consists of up to 5 phases:
-1. **Storage phase** - in this phase, storage fees accrued by the contract due to the occupation of some space in the chain state are calculated. Read more in [Storage Fees](/develop/smart-contracts/fees#storage-fee).
-2. **Credit phase** - in this phase, the balance of the contract with respect to a (possible) incoming message value and collected storage fee are calculated
-3. **Compute phase** - in this phase, TVM is executed (see below), the result of the TVM execution is an aggregation of `exit_code`, `actions` (serialized list of actions), `gas_details`, `new_storage` and some others.
-4. **Action phase** - if the compute phase was successful, in this phase, `actions` from the compute phase are processed. In particular, actions may include sending messages, updating the smart contract code, updating the libraries etc. Note that some actions may fail during processing (for instance, if we try to send message with more TON than the contract has), in that case the whole transaction may revert or this action may be skipped (it depends on the mode of the actions, in other words, the contract may send a `send-or-revert` or  `try-send-if-no-ignore` type of message).
-5. **Bounce phase** - if the compute phase failed (it returned `exit_code >= 2`), in this phase, _bounce message_ is formed for transactions initiated by an incoming message.
+1. **Storage phase** - in this phase, storage fees accumulated by the contract due to the occupation of some space in the chain state are calculated. Read more in [Storage Fees](/develop/smart-contracts/fees#storage-fee).
+2. **Credit phase** - in this phase, the balance of the contract with respect to a (possible) incoming message value and collected storage fee are calculated.
+3. **Compute phase** - in this phase, TVM is executing the contract (see below) and the result of the contract execution is an aggregation of `exit_code`, `actions` (serialized list of actions), `gas_details`, `new_storage` and some others.
+4. **Action phase** - if the compute phase was successful, in this phase, `actions` from the compute phase are processed. In particular, actions may include sending messages, updating the smart contract code, updating the libraries, etc. Note that some actions may fail during processing (for instance, if we try to send message with more TON than the contract has), in that case the whole transaction may revert or this action may be skipped (it depends on the mode of the actions, in other words, the contract may send a `send-or-revert` or  `try-send-if-no-ignore` type of message).
+5. **Bounce phase** - if the compute phase failed (it returned `exit_code >= 2`), in this phase, the _bounce message_ is formed for the transactions initiated by an incoming message.
 
 ## Compute phase
 In this phase, the TVM execution occurs.
@@ -29,7 +29,7 @@ At any given moment, the TVM state is fully determined by 6 properties:
 * Stack (see below)
 * Control registers - (see below) to put it simply, this means up to 16 variables which may be directly set and read during execution
 * Current continuation - object which describes a currently executed sequence of instructions
-* Current codepage - to put it simply, this means the version of TVM which is currently running
+* Current codepage - in simple terms, this means the version of TVM which is currently running
 * Gas limits - a set of 4 integer values; the current gas limit g<sub>l</sub>, the maximal gas limit g<sub>m</sub>, the remaining gas g<sub>r</sub> and the gas credit g<sub>c</sub>
 * Library context - the hashmap of libraries which can be called by TVM 
 
@@ -41,9 +41,9 @@ TVM is a last-input-first-output stack machine. In total, there are 7 types of v
 
 And four distinct flavours of cells:
 * Cell - basic (possibly nested) opaque structure used by TON Blockchain for storing all data
-* Slice - special object which allows you to read from a cell
-* Builder - special object which allows you to create new cells
-* Continuation - special object which allows you to use a cell as source of TVM instructions
+* Slice - a special object which allows you to read from a cell
+* Builder - a special object which allows you to create new cells
+* Continuation - a special object which allows you to use a cell as source of TVM instructions
 
 ### Control registers
 * `c0` — Contains the next continuation or return continuation (similar to the subroutine return address in conventional designs). This value must be a Continuation.
@@ -71,4 +71,4 @@ Besides exit_code and consumed gas data, TVM indirectly outputs the following da
 
 All other register values will be neglected.
 
-Note, that since there is a limitation on max cell-depth `<1024`, and particularly a limitation on c4 and c5 depth `<=512`, there will be a limitation on the number of output actions in one tx `<=255`. If a contract need to send more than that, it may send a message with the request `continue_sending` to itself and send all necessary messages in subsequent transactions.
+Note, that since there is a limit on max cell-depth `<1024`, and particularly the limit on c4 and c5 depth `<=512`, there will be a limit on the number of output actions in one tx `<=255`. If a contract needs to send more than that, it may send a message with the request `continue_sending` to itself and send all necessary messages in subsequent transactions.

docs/participate/nodes/node-types.md

@@ -28,11 +28,11 @@ Such nodes are indispensable for creating blockchain explorers or other tools th
 
 ### Liteserver Node
 
-When an endpoint is activated in a full node, the node assumes the role of a **Liteserver**. This node type can field and respond to requests from Lite Clients, allowing for seamless interaction with the TON Blockchain.
+When an endpoint is activated on a full node, the node assumes the role of a **Liteserver**. This node type can field and respond to requests from Lite Clients, allowing to seamlessly interract with the TON Blockchain.
 
 #### Interaction with Lite Clients
 
-Liteservers enable swift communication with Lite Clients, facilitating tasks like balance checks or transaction submissions without necessitating the full block history.
+Liteservers enable swift communication with Lite Clients, facilitating tasks like retrieving balance or submitting transactions without necessitating the full block history.
 
 #### Public Liteservers
 

docs/participate/ton-storage/storage-faq.md

@@ -17,7 +17,7 @@
 
 ## How to host static TON site in TON Storage
 
-1. [Create](/participate/ton-storage/storage-daemon#creating-a-bag-of-files) the Bag from folder with website files, upload it to the network and get the Bag ID. Folder must contain `index.html` file.
+1. [Create](/participate/ton-storage/storage-daemon#creating-a-bag-of-files) the Bag from folder with website files, upload it to the network and get the Bag ID. The folder must contain `index.html` file.
 
 2. Open the Google Chrome browser on your computer.
 
@@ -32,7 +32,7 @@
 
 ## How to migrate TON NFT content to TON Storage
 
-If you used a [standard NFT smart contract](https://github.com/ton-blockchain/token-contract/blob/main/nft/nft-collection-editable.fc) for your collection, you need to send a [message](https://github.com/ton-blockchain/token-contract/blob/2d411595a4f25fba43997a2e140a203c140c728a/nft/nft-collection-editable.fc#L132) to the collection smart contract from the collection owner's wallet with a new url prefix.
+If you used a [standard NFT smart contract](https://github.com/ton-blockchain/token-contract/blob/main/nft/nft-collection-editable.fc) for your collection, you need to send a [message](https://github.com/ton-blockchain/token-contract/blob/2d411595a4f25fba43997a2e140a203c140c728a/nft/nft-collection-editable.fc#L132) to the collection smart contract from the collection owner's wallet with a new URL prefix.
 
 As an example, if the url prefix used to be `https://mysite/my_collection/`, the new prefix will be `tonstorage://my_bag_id/`.
 
@@ -46,7 +46,7 @@ dns_storage_address#7473 bag_id:uint256 = DNSRecord;
 
 ## How to host static TON site in TON Storage (Low Level)
 
-[Create](/participate/ton-storage/storage-daemon#creating-a-bag-of-files) the Bag from folder with website files, upload it to the network and get the Bag ID. Folder must contain `index.html` file.
+[Create](/participate/ton-storage/storage-daemon#creating-a-bag-of-files) the Bag from folder with website files, upload it to the network and get the Bag ID. The folder must contain `index.html` file.
 
 You need to assign the following value to the sha256("site") DNS Record of your TON domain: