feat: add cross-linking with to tblkch whitepaper #1379
+237
−221
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
Author
|
Category: Should we simplify the sentence so the links sit on the naturally related word (i underlined the word). This would mean that we might have to rewrite the sentence sligtly in some cases |
Contributor
Author
|
Category: I used chapter number reference cause they were too long(below is how long the descriptive links were) 
|
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -198,7 +198,7 @@ The account state itself approximately consists of the following data: | |||
| - Its *storage usage statistics*, including the number of cells and bytes kept in the persistent storage of the smart contract (i.e., inside the blockchain state) and the last time a storage usage payment was exacted from this account. | |||
| - An optional *formal interface description* (intended for smart contracts) and/or *user public information* (intended mostly for human users and organizations). | |||
|
|
|||
| Notice that there is no distinction between "smart contract" and "account" in the TON Blockchain. Instead, "simple" or "wallet" accounts, typically employed by human users and their cryptocurrency wallet applications for simple cryptocurrency transfers, are just simple smart contracts with standard (shared) code and with persistent data consisting of the public key of the wallet (or several public keys in the case of a multi-signature wallet; cf. [1.7.6](#1-7-6-example%3A-creating-a-cryptocurrency-wallet-smart-contract) for more detail). | |||
| Notice that there is no distinction between "smart contract" and "account" in the TON Blockchain. Instead, "simple" or "wallet" accounts, typically employed by human users and their cryptocurrency wallet applications for simple cryptocurrency transfers, are just simple smart contracts with standard (shared) code and with persistent data consisting of the public key of the wallet (or several public keys in the case of a multi-signature wallet; [Example: creating a cryptocurrency wallet smart contract](#1-7-6-example%3A-creating-a-cryptocurrency-wallet-smart-contract) for more detail). | |||
Collaborator
There was a problem hiding this comment.
Shouldn't there be a link on a "wallet" instead?
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -214,7 +214,7 @@ In addition to shardchain blocks and their states, the TON Blockchain contains * | |||
|
|
|||
| ## 1.3 Consistency conditions | |||
|
|
|||
| In addition to the data structures contained in the block and in the blockchain state, which are serialized into bags of cells according to certain TL-B schemes explained in detail later (cf. Chapters [3](#3-messages%2C-message-descriptors%2C-and-queues)—[5](#5-block-layout)), an important component of the blockchain layout is the *consistency conditions* between data kept inside one or in different blocks (as mentioned in [1.2.3](#1-2-3-interaction-with-other-blocks-and-the-outside-world-global-and-local-consistency-conditions)). This section describes in detail the function of consistency conditions in the blockchain. | |||
| In addition to the data structures contained in the block and in the blockchain state, which are serialized into bags of cells according to certain TL-B schemes explained in detail later (Chapters [3](#3-messages%2C-message-descriptors%2C-and-queues)—[5](#5-block-layout)), an important component of the blockchain layout is the *consistency conditions* between data kept inside one or in different blocks (as mentioned in [Interaction with other blocks and the outside world. Global and local consistency conditions](#1-2-3-interaction-with-other-blocks-and-the-outside-world-global-and-local-consistency-conditions)). This section describes in detail the function of consistency conditions in the blockchain. | |||
Collaborator
There was a problem hiding this comment.
The *consistency conditions* should be a non-italic link instead. (as mentioned in ...) should be removed.
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -273,11 +273,11 @@ Of course, the "witness" value $f(x):Y$ may be included inside the (modified) da | |||
|
|
|||
| ### 1.3.8. Example: consistency condition for *InMsgDescr* | |||
|
|
|||
| For instance, the consistency condition between $X:=\textit{InMsgDescr}$, the list of all inbound messages processed in a block, and $Y:=\textit{Transactions}$, the list of all transactions present in a block, is of the above sort: "For any input message $x$ present in *InMsgDescr*, a transaction $y$ must be present in the block such that $y$ processes $x$".<sup>[8](#fn8)</sup> The procedure of $\exists$-elimination described in [1.3.7](#1-3-7-constructive-elimination-of-existence-quantifiers) leads us to introduce an additional field in the inbound message descriptors of *InMsgDescr*, containing a reference to the transaction in which the message is actually processed. | |||
| For instance, the consistency condition between $X:=\textit{InMsgDescr}$, the list of all inbound messages processed in a block, and $Y:=\textit{Transactions}$, the list of all transactions present in a block, is of the above sort: "For any input message $x$ present in *InMsgDescr*, a transaction $y$ must be present in the block such that $y$ processes $x$".<a id="ref-fn8"></a><sup>[8](#fn8)</sup> The procedure of $\exists$-elimination described in [Constructive elimination of existence quantifiers](#1-3-7-constructive-elimination-of-existence-quantifiers) leads us to introduce an additional field in the inbound message descriptors of *InMsgDescr*, containing a reference to the transaction in which the message is actually processed. | |||
Collaborator
There was a problem hiding this comment.
$\exists$-elimination should be a link here.
Contributor
Author
|
@verytactical I have clarified this new approach with Alexy, as I had some questions around it (based on the screenshots I shared above). I'll adjust the sentences especially those with described in, explained in, etc and place the links on the natural occuring text. |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: verytactical <[email protected]>
Co-authored-by: verytactical <[email protected]>
Co-authored-by: verytactical <[email protected]>
Co-authored-by: verytactical <[email protected]>
reveloper
requested changes
Dec 1, 2025
foundations/whitepapers/tblkch.mdx
Outdated
|
|
||
| <span id="ref-4">**[4]**</span> N. Durov, *Telegram Open Network Virtual Machine*, 2018. | ||
| [4] N. Durov, *Telegram Open Network Virtual Machine*, 2018. | ||
|
|
||
|
|
||
| ## Footnotes |
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -59,7 +59,7 @@ where $[A]$ equals one when condition $A$ is true, and zero otherwise. | |||
|
|
|||
| - Next, $\lceil l/8\rceil$ data bytes follow. This means that the $l$ data bits of the cell are split into groups of eight, and each group is interpreted as a big-endian 8-bit integer and stored into a byte. If $l$ is not divisible by eight, a single binary one and a suitable number of binary zeroes (up to six) are appended to the data bits, and the completion tag (the least significant bit of the descriptor byte $d_2$) is set. | |||
|
|
|||
| - Finally, $r$ references to other cells follow. Each reference is normally represented by 32 bytes containing the SHA-256 hash of the referenced cell, computed as explained below in [1.1.4](#1-1-4-the-sha256-hash-of-a-cell). | |||
| - Finally, $r$ references to other cells follow. Each reference is normally represented by 32 bytes containing the [SHA-256 hash of the referenced cell](#1-1-4-the-sha256-hash-of-a-cell) computed. | |||
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -102,7 +102,7 @@ Signatures are an excellent example of the application of representation hashes. | |||
|
|
|||
| ### 1.1.10. Higher hashes of a cell | |||
|
|
|||
| In addition to the transparent and representation hashes of a cell $c$, a sequence of *higher hashes* $\text{Hash}_i(c)$, $i=1,2,\dots$ may be defined, which eventually stabilizes at $\text{Hash}_\infty(c)$. (More detail may be found in [[4](#ref-4), 3.1].) | |||
| In addition to the transparent and representation hashes of a cell $c$, a sequence of [*higher hashes*](/foundations/whitepapers/tvm#3-1-generalities-on-cells) $\text{Hash}_i(c)$, $i=1,2,\dots$ may be defined, which eventually stabilizes at $\text{Hash}_\infty(c)$. | |||
Collaborator
There was a problem hiding this comment.
I didn't see why the original higher hash link leads to 3.1 of TVM; the reader may also be confused. As for me, 3.1.5 or 3.1.6 TVM works better as a reference for explanation.
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -163,15 +163,15 @@ Originally, each outbound message is included into *OutMsgQueue*; it is removed | |||
|
|
|||
| ### 1.2.8. Layout of *InMsgDescr*, *OutMsgDescr* and *OutMsgQueue* | |||
|
|
|||
| All of the most important non-split shardchain data structures related to messages are organized as *hashmaps* or *dictionaries* (implemented by means of Patricia trees serialized into a tree of cells as described in [[4](#ref-4), 3.3]), with the following keys: | |||
| All of the most important non-split shardchain data structures related to messages are organized as *hashmaps* or *dictionaries* (implemented by means of [Patricia trees](/foundations/whitepapers/tvm#3-3-hashmaps,-or-dictionaries) serialized into a tree of cells), with the following keys: | |||
Collaborator
There was a problem hiding this comment.
3.3.2 of TVM seems better as an accurate reference for [Patricia trees].
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -198,7 +198,7 @@ The account state itself approximately consists of the following data: | |||
| - Its *storage usage statistics*, including the number of cells and bytes kept in the persistent storage of the smart contract (i.e., inside the blockchain state) and the last time a storage usage payment was exacted from this account. | |||
| - An optional *formal interface description* (intended for smart contracts) and/or *user public information* (intended mostly for human users and organizations). | |||
|
|
|||
| Notice that there is no distinction between "smart contract" and "account" in the TON Blockchain. Instead, "simple" or "wallet" accounts, typically employed by human users and their cryptocurrency wallet applications for simple cryptocurrency transfers, are just simple smart contracts with standard (shared) code and with persistent data consisting of the public key of the wallet (or several public keys in the case of a multi-signature wallet; cf. [1.7.6](#1-7-6-example%3A-creating-a-cryptocurrency-wallet-smart-contract) for more detail). | |||
| Notice that there is no distinction between "smart contract" and "account" in the TON Blockchain. Instead, "simple" or "wallet" accounts, typically employed by human users and their cryptocurrency wallet applications for simple cryptocurrency transfers, are just simple smart contracts with standard (shared) code and with persistent data consisting of the public key of the wallet (or several public keys in the case of a [multi-signature wallet](#1-7-6-example%3A-creating-a-cryptocurrency-wallet-smart-contract)). | |||
Collaborator
There was a problem hiding this comment.
The link should be set on the regular "wallet", since the example is a regular wallet
| @@ -273,11 +273,11 @@ Of course, the "witness" value $f(x):Y$ may be included inside the (modified) da | |||
|
|
|||
| ### 1.3.8. Example: consistency condition for *InMsgDescr* | |||
|
|
|||
| For instance, the consistency condition between $X:=\textit{InMsgDescr}$, the list of all inbound messages processed in a block, and $Y:=\textit{Transactions}$, the list of all transactions present in a block, is of the above sort: "For any input message $x$ present in *InMsgDescr*, a transaction $y$ must be present in the block such that $y$ processes $x$".<sup>[8](#fn8)</sup> The procedure of $\exists$-elimination described in [1.3.7](#1-3-7-constructive-elimination-of-existence-quantifiers) leads us to introduce an additional field in the inbound message descriptors of *InMsgDescr*, containing a reference to the transaction in which the message is actually processed. | |||
| For instance, the consistency condition between $X:=\textit{InMsgDescr}$, the list of all inbound messages processed in a block, and $Y:=\textit{Transactions}$, the list of all transactions present in a block, is of the above sort: "For any input message $x$ present in *InMsgDescr*, a transaction $y$ must be present in the block such that $y$ processes $x$".<a id="ref-fn8"></a><sup>[8](#fn8)</sup> The procedure of [$\exists$-elimination](#1-3-7-constructive-elimination-of-existence-quantifiers) leads us to introduce an additional field in the inbound message descriptors of *InMsgDescr*, containing a reference to the transaction in which the message is actually processed. | |||
Collaborator
There was a problem hiding this comment.
Broken link in the section 1.3.7, whether ommit this or fix this:
foundations/whitepapers/tblkch.mdx
Outdated
|
|
||
| In most cases when we need to assign logical time intervals, we use the minimal logical time intervals just described. | ||
|
|
||
| ### 1.4.6. Logical time in the TON Blockchain | ||
|
|
||
| The TON Blockchain assigns logical time and logical time intervals to several of its components. | ||
|
|
||
| For instance, each outbound message created in a transaction is assigned its *logical creation time*; for this purpose, the creation of an outbound message is considered an atomic event, logically dependent on the previous message created by the same transaction, as well as on the previous transaction of the same account, on the inbound message processed by the same transaction, and on all events contained in the blocks referred to by hashes contained in the block with the same transaction. As a consequence, *outbound messages created by the same smart contract have strictly increasing logical creation times*. The transaction itself is considered a collection of atomic events, and is assigned a logical time interval (cf. [4.2.1](#4-2-1-logical-time-of-a-transaction) for a more precise description). | ||
| For instance, each outbound message created in a transaction is assigned its *logical creation time*; for this purpose, the creation of an outbound message is considered an atomic event, logically dependent on the previous message created by the same transaction, as well as on the previous transaction of the same account, on the inbound message processed by the same transaction, and on all events contained in the blocks referred to by hashes contained in the block with the same transaction. As a consequence, *outbound messages created by the same smart contract have strictly increasing logical creation times*. The transaction itself is considered a collection of atomic events, and is assigned a [logical time](#4-2-1-logical-time-of-a-transaction) interval. |
Collaborator
There was a problem hiding this comment.
Link text should be a [logical time interval]. Link should lead to the logical time interval (1.4.3. Logical time intervals)
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -446,7 +446,7 @@ In particular, when we say that a block *must* import in its *InMsgDescr* the me | |||
|
|
|||
| ## 1.6 Configurable parameters and smart contracts | |||
|
|
|||
| Recall that the TON Blockchain has several so-called "configurable parameters" (cf. [[3](#ref-3)]), which are either certain values or certain smart contracts residing in the masterchain. This section discusses the storage of and access to these configurable parameters. | |||
| Recall that the TON Blockchain has several so-called ["configurable parameters"](/foundations/whitepapers/ton), which are either certain values or certain smart contracts residing in the masterchain. This section discusses the storage of and access to these configurable parameters. | |||
Collaborator
There was a problem hiding this comment.
Can we provide a more specific link or delete this? It seems just as extra confusion, redirecting to the entire whitepaper under the "configurable parameters" link text.
foundations/whitepapers/tblkch.mdx
Outdated
| @@ -964,13 +966,13 @@ nanograms$_ amount:(VarUInteger 16) = Grams; | |||
|
|
|||
| If one wants to represent $x$ nanograms, one selects an integer $\ell<16$ such that $x<2^{8\ell}$, and serializes first $\ell$ as an unsigned 4-bit integer, then $x$ itself as an unsigned $8\ell$-bit integer. Notice that four zero bits represent a zero amount of Grams. | |||
|
|
|||
| Recall (cf. [[3, A](#ref-3)]) that the original total supply of Grams is fixed at five billion (i.e., $5\cdot10^{18}<2^{63}$ nanograms), and is expected to grow very slowly. Therefore, all the amounts of Grams encountered in practice will fit in unsigned or even signed 64-bit integers. The validators may use the 64-bit integer representation of Grams in their internal computations; however, the serialization of these values the blockchain is another matter. | |||
| Recall that the original total supply of [Grams](/foundations/whitepapers/ton#a-the-ton-coin-or-the-gram) is fixed at five billion (i.e., $5\cdot10^{18}<2^{63}$ nanograms), and is expected to grow very slowly. Therefore, all the amounts of Grams encountered in practice will fit in unsigned or even signed 64-bit integers. The validators may use the 64-bit integer representation of Grams in their internal computations; however, the serialization of these values the blockchain is another matter. | |||
…on-org/docs into crosslinking-tblkch-whitepaper
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #559