Added/changed post-review information

vkokosh · vkokosh · commit ad2b8338f2f1 · 2024-07-02T11:49:25.000+03:00
diff --git a/docs/develop/ethereum-to-ton/difference-of-blockchains.md b/docs/develop/ethereum-to-ton/difference-of-blockchains.md
@@ -39,11 +39,11 @@ In TON, everything is represented by smart contracts, which can also be called a
 - The contract optionally generates an outgoing message
 - The contract goes into standby mode until the following event occurs
 
-The result of scripts is always the creation of a transaction.  The transactions themselves are asynchronous, meaning that the system can continue processing other transactions while waiting for past transactions to complete. This provides more flexibility when processing complex transactions. Sometimes a single transaction may require multiple smart contract calls to be executed in a specific sequence. Because these calls are asynchronous, developers can more easily design and implement complex transaction flows that may involve multiple concurrent operations. A developer coming from Ethereum needs to realize that smart contracts in the TON blockchain can only communicate with each other by sending asynchronous messages, which means that if there is a need to request data from another contract and an immediate response is required, this will not be possible. Instead `get methods` must be called by clients outside the network, much like a wallet in Ethereum uses RPC nodes such as Infura to request smart contract states.
+The result of scripts is always the creation of a transaction.  The transactions themselves are asynchronous, meaning that the system can continue processing other transactions while waiting for past transactions to complete. This provides more flexibility when processing complex transactions. Sometimes a single transaction may require multiple smart contract calls to be executed in a specific sequence. Because these calls are asynchronous, developers can more easily design and implement complex transaction flows that may involve multiple concurrent operations. A developer coming from Ethereum needs to realize that smart contracts in the TON blockchain can only communicate with each other by sending asynchronous messages, which means that if there is a need to request data from another contract and an immediate response is required, this will not be possible. Instead `get methods` must be called by clients outside the network, much like a wallet in Ethereum uses RPC nodes such as Infura to request smart contract states. This is an important limitation for several reasons. For example, flash loans are transactions that must be executed within a single block, relying on the ability to borrow and repay in the same transaction. This is facilitated by the synchronous nature of Ethereum's EVM, but in TON, the asynchronous nature of all transactions makes executing a flash loan infeasible. Also Oracles, which provide smart contracts with external data, involve a more intricate design process in TON. What Oracles are and how to use them in TON can be found [here](/develop/oracles/about_blockchain_oracles).
 
 ## The difference of wallets
 
-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](/participate/wallets/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 just starting to implement so-called `account abstractions`, where wallets will be smart contracts, while in TON this approach exists from the very beginning.
+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](/participate/wallets/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
 
@@ -52,5 +52,6 @@ What happens between two contracts is called a message - a small number of token
 ## The difference of Gas system 
 
 In Ethereum, the cost of a transaction is measured in `gas`, which reflects the amount of computing resources required for the transaction. The `gas` cost is divided into a `base fee` set by the protocol and a `priority fee` that the user adds to speed up transaction processing by validators. The `total fee` will be = `units of gas used` * (`base fee` + `priority fee`).
+Additionally, storage in Ethereum is essentially free, meaning that once data is stored on the blockchain, there is no ongoing cost for keeping it there.
 
 In TON, the calculation of transaction fees is complex and includes several types of fees: for storing smart contracts in the blockchain, for importing messages into the blockchain, for executing code on a virtual machine, for processing actions after code execution, and for sending messages outside the TON blockchain. The price of gas and some other parameters can be changed by voting on the main network. Unlike Ethereum, TON users cannot set the gas price themselves. Also, the developer needs to return the remaining gas funds to the owner manually, otherwise they will remain locked. The use of smart contract storage also affects the price: if a wallet's smart contract has not been used for a long time, the next transaction will cost more.
diff --git a/docs/develop/ethereum-to-ton/solidity-vs-func.md b/docs/develop/ethereum-to-ton/solidity-vs-func.md
@@ -35,7 +35,11 @@ In case of FunC, the main data types are:
 - Tuples – is an ordered collection of up to 255 components, having arbitrary value types, possibly distinct.
 - Tensors – is an ordered collection ready for mass assigning like: (int, int) a = (2, 4). A special case of tensor type is the unit type (). It represents that a function doesn’t return any value, or has no arguments.
 
-Currently, FunC has no support for defining custom types,
+Currently, FunC has no support for defining custom types.
+
+### See Also
+
+- [Statements](/develop/func/statements)
 
 ## Declaring and using variables
 
@@ -54,20 +58,76 @@ FunC is a more abstract and function-oriented language, it supports dynamic typi
 var z = x + y; // Dynamic variable declaration 
 ```
 
-FunC's type flexibility and function-orientation provide convenience and security when developing smart contracts. It offers flexible type management through automatic inference and controls data access through feature visibility.
+### See Also
+
+- [Statements](/develop/func/statements)
+
+## Loops
+
+Solidity supports `for`, `while`, and `do { ... } while` loops.
+
+If you want to do something 10 times, you can do it this way:
+
+```js
+uint x = 1;
+
+for (uint i; i < 10; i++) {
+    x *= 2;
+}
+
+// x = 1024
+```
+
+FunC in turn supports `repeat`, `while`, and `do { ... } until` loops. The for loop is not supported. If you want to execute the same code as in the example above on Func, you can use `repeat`
+
+```func
+int x = 1;
+repeat(10) {
+  x *= 2;
+}
+;; x = 1024
+```
+
+### See Also
+
+- [Statements](/develop/func/statements)
 
 ## Functions
 
-Solidity approaches function declarations with a blend of clarity and control. In this programming language, each function is initiated with the keyword "function," followed by the name of the function and its parameters. The body of the function is enclosed within curly braces, clearly defining the operational scope. Additionally, return values are indicated using the "returns" keyword. What sets Solidity apart is its categorization of function visibility—functions can be designated as `public`, `private`, `internal`, or `external`, dictating the conditions under which they can be accessed and called by other parts of the contract or by external entities.
+Solidity approaches function declarations with a blend of clarity and control. In this programming language, each function is initiated with the keyword "function," followed by the name of the function and its parameters. The body of the function is enclosed within curly braces, clearly defining the operational scope. Additionally, return values are indicated using the "returns" keyword. What sets Solidity apart is its categorization of function visibility—functions can be designated as `public`, `private`, `internal`, or `external`, dictating the conditions under which they can be accessed and called by other parts of the contract or by external entities. Below is an example in which we set the global variable `num` in the Solidity language: 
+
+```js
+function set(uint256 _num) public returns (bool) {
+    num = _num;
+    return true;
+}
+```
+
+Transitioning to FunC, FunC program is essentially a list of function declarations/definitions and global variable declarations. A FunC function declaration typically starts with an optional declarator, followed by the return type and the function name. Parameters are listed next, and the declaration ends with a selection of specifiers—such as `impure`, `inline/inline_ref`, and `method_id`. These specifiers adjust the function's visibility, its ability to modify contract storage, and its inlining behavior. Below is an example in which we stores storage variable as a cell into persistent storage in the Func language: 
+
+```func
+() save_data(int num) impure inline {
+  set_data(begin_cell()
+            .store_uint(num, 32)
+           .end_cell()
+          );
+}
+```
+
+### See Also 
 
-Transitioning to FunC, FunC program is essentially a list of function declarations/definitions and global variable declarations. A FunC function declaration typically starts with an optional declarator, followed by the return type and the function name. Parameters are listed next, and the declaration ends with a selection of specifiers—such as `impure`, `inline/inline_ref`, and `method_id`. These specifiers adjust the function's visibility, its ability to modify contract storage, and its inlining behavior.
+- [Functions](/develop/func/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
+
+- [Statements](/develop/func/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.
@@ -76,4 +136,87 @@ Mapping is a hash table in Solidity that stores data as key-value pairs, where t
 
 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.
 
-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.
+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 
+
+- [Dictionaries in TON](/develop/func/dictionaries)
+
+## Smart-contract communication
+
+Solidity and FunC provide different approaches to interacting with smart contracts. The main difference lies in the mechanisms of invocation and interaction between contracts.
+
+Solidity uses an object-oriented approach where contracts interact with each other through method calls. This is similar to method calls in traditional object-oriented programming languages.
+
+```js
+// External contract interface
+interface IReceiver {
+    function receiveData(uint x) external;
+}
+
+contract Sender {
+    function sendData(address receiverAddress, uint x) public {
+        IReceiver receiver = IReceiver(receiverAddress);
+        receiver.receiveData(x);  // Direct call of the contract function
+    }
+}
+```
+
+FunC, used in the TON blockchain ecosystem, operates on messages to invoke and interact between smart-contracts. Instead of calling methods directly, contracts send messages to each other, which can contain data and code for execution. 
+
+Consider an example where a smart contract sender must send a message with a number, and a smart contract receiver must receive that number and perform some manipulation on it. 
+
+Initially, the smart contract recipient must describe how it will receive messages.
+
+```func
+() recv_internal(int my_balance, int msg_value, cell in_msg, slice in_msg_body) impure {
+    int op = in_msg_body~load_uint(32);
+    
+    if (op == 1) {
+        int num = in_msg_body~load_uint(32);
+        ;; do some manipulations
+        return ();
+    }
+
+    if (op == 2) {
+        ;;...
+    }
+}
+```
+
+Let's discuss in more detail what receiving a message looks like in our destination contract:
+1. `recv_internal()` - this function is executed when a contract is accessed directly within the blockchain. For example, when a contract accesses our contract.
+2. The function accepts amount of the contract balance, the amount of the incoming message, the cell with the original message and the `in_msg_body` slice, which stores only the body of the received message. 
+3. Our message body will store two integer numbers. The first number is a 32-bit unsigned integer `op`, identifying the `operation` to be performed, or the `method` of the smart contract to be invoked. You can draw some analogy with Solidity and think of `op` as a function signature. The second number is the number we need to perform some manipulations with.
+4. To read from the resulting slice `op` and `our number`, we use `load_uint()`.
+5. Next, we manipulate the number (we omitted this functionality in this example).
+
+Next, the sender's smart contract is to send the message correctly. This is accomplished with`send_raw_message`, which expects a serialized message as an argument.
+
+```func
+int num = 10;
+cell msg_body_cell = begin_cell().store_uint(1,32).store_uint(num,32).end_cell();
+
+var msg = begin_cell()
+            .store_uint(0x18, 6)
+            .store_slice("EQBIhPuWmjT7fP-VomuTWseE8JNWv2q7QYfsVQ1IZwnMk8wL"a) ;; in the example, we just hardcode the recipient's address
+            .store_coins(0)
+            .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1)
+            .store_ref(msg_body_cell)
+        .end_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](develop/smart-contracts/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 
+
+- [Internal Messages](/develop/smart-contracts/guidelines/internal-messages)
+- [Sending Messages](/develop/smart-contracts/messages)
+- [Non-bouncable messages](develop/smart-contracts/guidelines/non-bouncable-messages)
diff --git a/docs/develop/ethereum-to-ton/tvm-vs-evm.md b/docs/develop/ethereum-to-ton/tvm-vs-evm.md
