Merge pull request #846 from pixelplex/staging

Staging

Author: reveloper

cspell.json

@@ -4,9 +4,9 @@
   "language": "en",
   "files": [
     "**/*.md",
-    "**/*.mdx",
+    "**/*.mdx"
   ],
-  "dictionaries": ["tvm-instructions", "names", "commands"],
+  "dictionaries": ["tvm-instructions", "names", "commands", "examples"],
   "dictionaryDefinitions": [
     {
       "name":"tvm-instructions",
@@ -20,6 +20,10 @@
       "name":"commands",
       "path":"./src/grammar/commands-dictionary.txt"
     },
+    {
+      "name":"examples",
+      "path":"./src/grammar/examples-dictionary.txt"
+    },
   ],
   "words": [
     "ADNL",
@@ -103,6 +107,7 @@
     "Threadripper",
     "Threadripper-based",
     "Timeouted",
+    "Tolk",
     "Toncoin",
     "Toncoins",
     "Underload",
@@ -175,6 +180,7 @@
     "hmac",
     "howto",
     "HOWTO",
+    "idict",
     "inclusivity",
     "inplace",
     "int",
@@ -196,12 +202,14 @@
     "liteservers",
     "logname",
     "long",
+    "lowlevel",
     "masterchain",
     "mathrm",
     "mintless",
     "micropayment",
     "micropayments",
     "mintable",
+    "moddiv",
     "multichain",
     "multisignature",
     "mystore",
@@ -217,6 +225,7 @@
     "nonfinal",
     "penalising",
     "penalised",
+    "pfxdict",
     "precomplied",
     "preimage",
     "prer",
@@ -259,13 +268,15 @@
     "sunt",
     "superserver",
     "tick-tock",
+    "tilda",
     "timeouted",
     "tock",
     "tokenomics",
     "tvmbeta",
     "udict",
     "uint",
     "unbounceable",
+    "uncons",
     "underload",
     "underloaded",
     "unixtime",
@@ -300,6 +311,7 @@
   ],
   "flagWords": [],
   "ignorePaths": [
+    "scripts",
     "static",
     "node_modules",
     "package.json",
@@ -313,6 +325,6 @@
     "sidebars.js",
     "sidebars",
     "i18n",
-    ".husky",
+    ".husky"
   ]
 }

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

@@ -14,7 +14,7 @@ Ethereum, by inheriting and extending the foundational principles of Bitcoin, ha
 
 In response to these challenges, TON offers an alternative approach aimed at improving scalability and performance. Designed with the ambition to provide developers with maximum flexibility to create a variety of applications, TON uses the concept of shards and masterchain to optimize the block creation process. In each TON shardchain and masterchain, a new block is generated on average every 5 seconds, ensuring fast transaction execution. Unlike Ethereum, where state updates are synchronous, TON implements asynchronous messaging between smart contracts, allowing each transaction to be processed independently and in parallel, significantly speeding up transaction processing on the network. Sections and articles to familiarize yourself with:
 
-* [Shards](/v3/documentation/smart-contracts/shards)
+* [Shards](/v3/documentation/smart-contracts/shards/shards-intro)
 * [Comparison of Blockchains document](https://ton.org/comparison_of_blockchains.pdf)
 * [Comparison of Blockchains table (much less informative than the document, but more visual)](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-comparison)
 

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

@@ -208,7 +208,7 @@ 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.

docs/v3/concepts/dive-into-ton/ton-blockchain/sharding.md

@@ -21,5 +21,5 @@ In addition to the dynamic creation of shards, TON uses **Split Merge** function
 
 ## See Also
 
-* [Shards Dive In](/v3/documentation/smart-contracts/shards)
-* [# Infinity Sharding Paradigm](/v3/documentation/smart-contracts/infinity-sharding-paradigm)
+* [Shards Dive In](/v3/documentation/smart-contracts/shards/shards-intro)
+* [# Infinity Sharding Paradigm](/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm)

docs/v3/concepts/qa-outsource/auditors.mdx

@@ -14,6 +14,7 @@ Test your software with the following quality assurance providers.
 * [ton.tech](https://ton.tech/)
 * [trailofbits.com](https://www.trailofbits.com/)
 * [zellic.io](https://www.zellic.io/)
+* [tonbit.xyz](https://www.tonbit.xyz/)
 
 
 ## See Also

docs/v3/concepts/ton-blockchain/shards.md

@@ -21,5 +21,5 @@ In addition to the dynamic creation of shards, TON uses **Split Merge** function
 
 ## See Also
 
-* [Shards Dive In](/v3/documentation/smart-contracts/shards)
-* [# Infinity Sharding Paradigm](/v3/documentation/smart-contracts/infinity-sharding-paradigm)
+* [Shards Dive In](/v3/documentation/smart-contracts/shards/shards-intro)
+* [# Infinity Sharding Paradigm](/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm)

docs/v3/contribute/docs/schemes-guidelines.mdx

@@ -42,7 +42,7 @@ If the order of transactions doesn't matter, you can omit their labels. This sim
 
 
 
-Learn references directly from Visio [message-processing.vsdx](/static/schemes-visio/message-processing.vsdx).
+Learn references directly from Visio [message-processing.vsdx](/schemes-visio/message-processing.vsdx).
 
 
 ### Formats and Colors

docs/v3/documentation/dapps/oracles/red_stone.mdx

@@ -19,7 +19,7 @@ To learn more about RedStone oracles design go to the [RedStone docs](https://do
 ### price_manager.fc
 
 - Sample oracle contract that consumes RedStone oracles data [price_manager.fc](https://github.com/redstone-finance/redstone-oracles-monorepo/blob/main/packages/ton-connector/contracts/price_manager.fc) written in
-  FunC. It requires [TVM Upgrade 2023.07](v3/documentation/tvm/changelog/tvm-upgrade-2023-07).
+  FunC. It requires [TVM Upgrade 2023.07](/v3/documentation/tvm/changelog/tvm-upgrade-2023-07).
 
 #### initial data
 

docs/v3/documentation/data-formats/tlb/tl-b-language.mdx

@@ -5,7 +5,7 @@ import ThemedImage from '@theme/ThemedImage';
 TL-B (Type Language - Binary) serves to describe the type system, constructors and existing functions. For example, we
 can use TL-B schemes to build binary structures associated with TON Blockchain. Special TL-B parsers can read schemes to
 deserialize binary data into different objects. TL-B describes data schemes for `Cell` objects. If you not familiar
-with `Cells`, please read [Cell & Bag of Cells(BOC)](v3/documentation/data-formats/tlb/cell-boc#cell) article.
+with `Cells`, please read [Cell & Bag of Cells(BOC)](/v3/documentation/data-formats/tlb/cell-boc#cell) article.
 
 ## Overview
 
@@ -516,7 +516,7 @@ unary_succ$1 {n:#} x:(Unary ~n) = Unary ~(n + 1);
 _ u:(Unary Any) = UnaryChain;
 ```
 
-This is example has good explanation in [TL-B Types](v3/documentation/data-formats/tlb/tl-b-types#unary)
+This is example has good explanation in [TL-B Types](/v3/documentation/data-formats/tlb/tl-b-types#unary)
 article. The main idea here is that `UnaryChain` will recursively deserialize until reach of `unary_zero$0` (because we
 know last element of `Unary X` type by definition `unary_zero$0 = Unary ~0;` and `X` is calculated in runtime
 due `Unary ~(n + 1)` definition).