Feedback common(draft)

Author: Alexey-Ostrovsky

docs/v3/guidelines/quick-start/developing-smart-contracts/blueprint-sdk-overview.mdx

@@ -30,7 +30,7 @@ Example/
 ```
 </TabItem>
 <TabItem value="Tolk" label="Tolk">
-```
+```ls title="Project structure"
 Example/
 ├── contracts/           # Folder containing smart contracts code
 │   └── hello_world.tolk # Main contract file
@@ -52,11 +52,11 @@ This folder contains your smart contract source code written in one of the avail
 
 ### `/wrappers`
 
-While `@ton/ton SDK` provides us interfaces of serializing and sending messages for standard smart-contracts such as `wallets`, if we develop our own smart-contract that will deserialize received messages by its own custom protocol we need to provide some wrapper object that will serialize messages sent to smart-contract, deserialize responses from `get method`s and serialize contract itself for deployment.
+To interact with your smart-contract off-chain you need to serialize and desirialize messages sended to it. `Wrapper` classes developed to mirror your smart-contract implementation making it simple to use it's functionality.
 
 ### `/tests`
 
-This directory contains test files for your smart contracts. Testing contracts directly in TON network is not the best option because it requires some amount of time and may lead to losing funds. This testing playground tool allow you to execute multiple smart-contracts and even send messages between them in your "local network". Tests are crucial for ensuring your smart contracts behave as expected before deployment to the network.
+This directory contains test files for your smart contracts. Testing contracts directly in TON network is not the best option because it requires some amount of time and may lead to losing funds. This testing playground tool allow you to execute multiple smart-contracts and even send messages between them in your **"local network"**. Tests are crucial for ensuring your smart contracts behave as expected before deployment to the network.
 
 ### `/scripts`
 

docs/v3/guidelines/quick-start/developing-smart-contracts/deploying-to-network.mdx

@@ -6,17 +6,17 @@ In this part of the guide we will proceed to deployment of previously developed
 
 ## Address and initial state
 
-We already know that [address](/v3/documentation/smart-contracts/addresses/) is unique identifier of `smart-contract`, i.e `actor`, `account` in network which is used to send transactions and verify their sender upon receive but we still didn't discussed how it's created. The common formula of smart-contract address looks like that:
+We already know that [address](/v3/documentation/smart-contracts/addresses/) is unique identifier of `smart-contract` in network which is used to send transactions and verify their sender upon receive, but we still didn't discussed how it's created. The common formula of smart-contract address looks like that:
 
 ***address=hash(state_init(code, data))***
 
 Address of smart-contract is a hash of aggregated initial code and data of smart-contracts upon deployment. This simple mechanism have few important consequences:
 
 ### You already know the address
 
-In TON any address that didn't accept any transaction and, as a consequnce, dont have any data is considered in `nonexzist` state, nethertheless when we created a wallet using wallet app in [Getting started](/v3/guidelines/quick-start/getting-started) section we still was able to get address of our **future** wallet smart-contract from wallet app before it's deployment and examine it in explorer. 
+In TON any address that don't have any data is considered in `nonexistent` state, nevertheless when we created a wallet using wallet app in [Getting started](/v3/guidelines/quick-start/getting-started) section we still was able to get address of our **future** wallet smart-contract from wallet app before it's deployment and examine it in explorer. 
 
-The reason behind that is because creating your private and public key pair through **mnemonic phrase**, where second key is part of initial data of smart-contract makes `state_init` of our contract fully determent:
+The reason behind that is because creating your **private** and **public** key pair through **mnemonic phrase**, where second key is part of initial data of smart-contract makes `state_init` of our contract fully determent:
  - **code** is one of the standard wallet implementation, like `v5r1`.
  - **data** is `public_key` with other default initialized fields.
 
@@ -40,7 +40,7 @@ init(id: Int, owner: Address) {
 }
 ```
 
-If we remove `id` field from its initial storage we can ensure that **only one** `CounterInternal` smart-cotnract could exzist for a particular owner, moreover, if we consider owner as wallet smart-contract, by knowing its public_key and version we could calculate wallet address and, as a consequnce, address of its `CounterInternal` contract.
+If we remove `id` field from its initial storage we can ensure that **only one** `CounterInternal` smart-cotnract could exzist for a particular owner.
 
 :::info Tokens
 This mechanism plays cruicial role in [Jetton Processing](v3/guidelines/dapps/asset-processing/jettons), each non-native(jetton) token requires it's own `Jetton Wallet` for a particular owner and therefore provides a calculatable address from it, creating a **star scheme** with basic wallet in center.
@@ -50,23 +50,19 @@ This mechanism plays cruicial role in [Jetton Processing](v3/guidelines/dapps/as
 
 Now, when our smart-contracts is fully tested, we are ready to deploy them into the TON. In `Blueprint SDK` this process is the same for both `mainnet` and `testnet` and any of the presented languages in guide: `FunC`, `Tact`, `Tolk`. Deploy scripts relays on the same wrappers that you have used in testing scripts:
 
-```typescript
+```typescript title="/scripts/deployHelloWorld"
 import { toNano } from '@ton/core';
 import { HelloWorld } from '../wrappers/HelloWorld';
 import { CounterInternal } from '../wrappers/CounterInternal';
 import { compile, NetworkProvider } from '@ton/blueprint';
-import { mnemonicToWalletKey } from '@ton/crypto';
 
 export async function run(provider: NetworkProvider) {
-    const mnemonic = "".split(' '); // Insert your mnemonic
-    const { publicKey, secretKey } = await mnemonicToWalletKey(mnemonic);
-
     const helloWorld = provider.open(
         HelloWorld.createFromConfig(
             {
                 id: Math.floor(Math.random() * 10000),
-                seqno: 0,
-                publicKey: publicKey
+                ctxCounter: 0,
+                ctxCounterExt: 0n,
             },
             await compile('HelloWorld')
         )
@@ -99,6 +95,7 @@ export async function run(provider: NetworkProvider) {
     console.log('ID', await helloWorld.getID());
     console.log('ID', (await counterInternal.getId()).toString());
 }
+
 ```
 
 You can run those scripts by entering following command:

docs/v3/guidelines/quick-start/developing-smart-contracts/processing-messages.mdx

@@ -5,7 +5,7 @@ import TabItem from '@theme/TabItem';
 
 > **Summary:** In previous steps we modified our smart-contract interaction with `storage, `get methods` and learned basic smart-contract development flow.
 
-Now that we have learned basic examples of modifying smart-contract code and using development tools, we are ready to move on to the main functionality of smart contracts - sending and receiving messages. In TON messages not only used for sending currency, but also as data-exchange mechanism between smart-contracts.
+Now we are ready to move on to the main functionality of smart contracts - **sending and receiving messages**. In TON messages not only used for sending currency, but also as data-exchange mechanism between smart-contracts.
 
 
 :::tip
@@ -18,81 +18,14 @@ If you are stuck on some of the examples you can find original template project
 
 Before we proceed to implementation let's briefly describe main ways and patterns that we can use to process internal messages.
 
-### Operations
-
-Common pattern in TON contracts is to include a **32-bit operation code** in message bodies which tells your contract what action to perform:
-
-<Tabs groupId="language">
-<TabItem value="FunC" label="FunC">
-```func
-;; This is NOT a part of the project, just an example!
-const int op::increment = 1;
-const int op::decrement = 2;
-
-() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {
-    ;; Step 1: Check if the message is empty
-    if (in_msg_body.slice_empty?()) {
-        return; ;; Nothing to do with empty messages
-    }
-
-    ;; Step 2: Extract the operation code
-    int op = in_msg_body~load_uint(32);
-
-    ;; Step 3-7: Handle the requested operation
-    if (op == op::increment) {
-        increment();   ;;call to specific operation handler
-        return;
-    } else if (op == op::decrement) {
-        decrement();
-        ;; Just accept the money
-        return;
-    }
-
-    ;; Unknown operation
-    throw(0xffff);
-}
-```
-</TabItem>
-<TabItem value="Tolk" label="Tolk">
-```tolk
-//This is NOT a part of the project, just an example!
-const op::increment : int = 1;
-const op::decrement : int = 2;
-
-fun onInternalMessage(myBalance: int, msgValue: int, msgFull: cell, msgBody: slice) {
-    // Step 1: Check if the message is empty
-    if (slice.isEndOfSlice()) {
-        return; // Nothing to do with empty messages
-    }
-
-    // Step 2: Extract the operation code
-    var op = in_msg_body~load_uint(32);
-
-    // Step 3-7: Handle the requested operation
-    if (op == op::increment) {
-        increment();   //call to specific operation handler
-        return;
-    } else if (op == op::decrement) {
-        decrement();
-        // Just accept the money
-        return;
-    }
-
-    // Unknown operation
-    throw(0xffff);
-}
-```
-</TabItem>
-</Tabs>
-
 ### Actors and roles
 
 Since TON implements [actor](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains/#single-actor) model it's natural to think about smart-contracts relations in terms of `roles`, determining who can access smart-contract functionality or not. The most common examples of roles are:
 
  - `anyone`: any contract that don't have distinct role.
  - `owner`: contract that has exclusive access to some crucial parts of functionality.
 
-Let's examine `recv_internal` function signature to understdand how we could use that:
+Let's examine `recv_internal` function signature to understand how we could use that:
 
 <Tabs groupId="language">
 <TabItem value="FunC" label="FunC">
@@ -175,6 +108,75 @@ fun onInternalMessage(myBalance: int, msgValue: int, msgFull: cell, msgBody: sli
 </TabItem>
 </Tabs>
 
+
+### Operations
+
+Common pattern in TON contracts is to include a **32-bit operation code** in message bodies which tells your contract what action to perform:
+
+<Tabs groupId="language">
+<TabItem value="FunC" label="FunC">
+```func
+;; This is NOT a part of the project, just an example!
+const int op::increment = 1;
+const int op::decrement = 2;
+
+() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {
+    ;; Step 1: Check if the message is empty
+    if (in_msg_body.slice_empty?()) {
+        return; ;; Nothing to do with empty messages
+    }
+
+    ;; Step 2: Extract the operation code
+    int op = in_msg_body~load_uint(32);
+
+    ;; Step 3-7: Handle the requested operation
+    if (op == op::increment) {
+        increment();   ;;call to specific operation handler
+        return;
+    } else if (op == op::decrement) {
+        decrement();
+        ;; Just accept the money
+        return;
+    }
+
+    ;; Unknown operation
+    throw(0xffff);
+}
+```
+</TabItem>
+<TabItem value="Tolk" label="Tolk">
+```tolk
+//This is NOT a part of the project, just an example!
+const op::increment : int = 1;
+const op::decrement : int = 2;
+
+fun onInternalMessage(myBalance: int, msgValue: int, msgFull: cell, msgBody: slice) {
+    // Step 1: Check if the message is empty
+    if (slice.isEndOfSlice()) {
+        return; // Nothing to do with empty messages
+    }
+
+    // Step 2: Extract the operation code
+    var op = in_msg_body~load_uint(32);
+
+    // Step 3-7: Handle the requested operation
+    if (op == op::increment) {
+        increment();   //call to specific operation handler
+        return;
+    } else if (op == op::decrement) {
+        decrement();
+        // Just accept the money
+        return;
+    }
+
+    // Unknown operation
+    throw(0xffff);
+}
+```
+</TabItem>
+</Tabs>
+
+
 By combining both of these patterns you can achieve a comprehensive description of your smart-contract's systems ensuring secure interaction between them and unleash full potential of TON actors model.
 
 ## Implementation in Tact
@@ -244,7 +246,7 @@ Example/
 
 At the top of the generated contract file: `counter_internal.tact`, you may see a [message](https://docs.tact-lang.org/book/structs-and-messages/) definition:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 message Add {
     queryId: Int as uint64;
     amount: Int as uint32;
@@ -253,7 +255,7 @@ message Add {
 
 A message is a basic structure for communication between contracts. Tact automatically serializes and deserializes messages into cells. To ensure that opcodes will be the same during message structure changes, it may be added like below:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 message(0x7e8764ef) Add {
     queryId: Int as uint64;
     amount: Int as uint32;
@@ -293,7 +295,7 @@ counter: Int as uint32;
 
 To ensure that only the contract owner can interact with specific functions, add an `owner` field:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 id: Int as uint32;
 counter: Int as uint32;
 owner: Address;
@@ -305,7 +307,7 @@ These fields are serialized similarly to structures and stored in the contract's
 
 If you compile the contract at this stage, you will encounter the error: `Field "owner" is not set`. This is because the contract needs to initialize its fields upon deployment. Define an [`init()`](https://docs.tact-lang.org/book/contracts/#init-function) function to do this:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 init(id: Int, owner: Address) {
     self.id = id;
     self.counter = 0;
@@ -317,7 +319,7 @@ init(id: Int, owner: Address) {
 
 To accept messages from other contracts, use a [receiver](https://docs.tact-lang.org/book/functions/#receiver-functions) function. Receiver functions automatically match the message's opcode and invoke the corresponding function:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 receive(msg: Add) {
     self.counter += msg.amount;
     self.notify("Cashback".asComment());
@@ -328,7 +330,7 @@ receive(msg: Add) {
 
 To ensure that only the contract owner can send messages, use the `require` function:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 receive(msg: Add) {
     // `sender()` function is used to retrieve message sender address
     require(sender() == self.owner, "Not owner!");
@@ -343,7 +345,7 @@ receive(msg: Add) {
 
 Tact also provides handy ways to share same logic through [traits](https://docs.tact-lang.org/book/types/#traits). Use the `Ownable` trait, which provides built-in ownership checks:
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 // Import library to use trait
 import "@stdlib/ownable";
 
@@ -370,7 +372,7 @@ Tact supports [getter functions](https://docs.tact-lang.org/book/functions/#gett
 Get function cannot be called from another contract.
 :::
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 get fun counter(): Int {
     return self.counter;
 }
@@ -380,7 +382,7 @@ Note, that the `owner` getter is automatically defined via the `Ownable` trait.
 
 #### Complete contract
 
-```tact title="counter_internal.tact"
+```tact title="/contracts/counter_internal.tact"
 import "@stdlib/deploy";
 import "@stdlib/ownable";
 
@@ -436,15 +438,15 @@ npm blueprint build
 
 [Wrappers](https://docs.tact-lang.org/book/compile/#wrap-ts) facilitate contract interaction from TypeScript. Unlike in FunC or Tolk, they are generated automatically during the build process:
 
-```typescript ./wrappers/CounterInternal.ts
+```typescript title="/wrappers/CounterInternal.ts"
 export * from '../build/CounterInternal/tact_CounterInternal';
 ```
 
 ### Step 3: Updating tests
 
 Now let's ensure that our smart-contract failes if non-owner tries to increment smart-contract by adding this test:
 
-```typescript title="tests/CounterInternal.spec.ts"
+```typescript title="/tests/CounterInternal.spec.ts"
 import { Blockchain, SandboxContract, TreasuryContract} from '@ton/sandbox';
 import { Cell, toNano } from '@ton/core';
 import { CounterInternal } from '../wrappers/CounterInternal';
@@ -540,7 +542,7 @@ Let's modify our smart-contract to recieve external messages and send increase c
 
 Add `recv_external` function to `HelloWorld` smart-contract:
 
-```func title="HelloWorld.fc"
+```func title="/contracts/HelloWorld.fc"
 () recv_external(slice in_msg) impure {
     accept_message();
 
@@ -578,7 +580,7 @@ npm blueprint build
 
 And add wrapper method to call it through our wrapper class for sending external message:
 
-```typescript
+```typescript title="/wrappers/HelloWorld.ts"
 async sendExternalIncrease(
     provider: ContractProvider,
     opts: {
@@ -603,7 +605,7 @@ async sendExternalIncrease(
 
 Update test to esnure that `HelloWorld` contract recieved internal message, sended internal message to `CounterInternal` contract and both updated their counters:
 
-```typescript title="HelloWorld.spec.ts"
+```typescript title="/tests/HelloWorld.spec.ts"
 import { Blockchain, SandboxContract, TreasuryContract } from '@ton/sandbox';
 import { Cell, toNano} from '@ton/core';
 import { HelloWorld } from '../wrappers/HelloWorld';
@@ -693,4 +695,3 @@ Verify that all examples is correct by running test script:
 npm blueprint test
 ```
 
-Congratulations! You have successfully created a **multi-contract** system and learned how to handle **internal** and **external** messages. This example illustrates the typical flow of any message chain: sending an `external message`, triggering the `internal messages` flow based on your system model, and so on. Now that our contracts have been fully tested, we are ready to deploy them and interact with them on-chain.