fix: comment differences ton.pdf and current implementation

ton/ton.mdx

@@ -50,9 +50,9 @@
 
 • TON DNS (cf. [4.3.1](#3-2-ton-dht%3A-kademlia-like-distributed-hash-table)), a service for assigning human-readable names to accounts, smart contracts, services and network nodes.
 
-• TON Payments (cf. [Chapter 5](#5-ton-payments)), a platform for micropayments, micropayment channels and a micropayment channel network. It can be used for fast off-chain value transfers, and for paying for services powered by TON Services.
+• TON Payments (cf. [Chapter 5](#5-ton-payments)), a platform for micropayments, micropayment channels and a micropayment channel network. It can be used for fast off-chain value transfers, and for paying for services powered by TON Services. **[NOT IMPLEMENTED]**
 
-• TON will allow easy integration with third-party messaging and social networking applications, thus making blockchain technologies and distributed services finally available and accessible to ordinary users (cf. [4.3.23](#4-3-23-ton-www)), rather than just to a handful of early cryptocurrency adopters.
+• TON will allow easy integration with third-party messaging and social networking applications, thus making blockchain technologies and distributed services finally available and accessible to ordinary users (cf. [4.3.23](#4-3-23-ton-www)), rather than just to a handful of early cryptocurrency adopters. **[NOT IMPLEMENTED]**
 
 While the TON Blockchain is the core of the TON project, and the other components might be considered as playing a supportive role for the blockchain, they turn out to have useful and interesting functionality by themselves. Combined, they allow the platform to host more versatile applications than it would be possible by just using the TON Blockchain (cf. [2.9.13](#2-9-13-is-it-possible-to-upload-facebook-into-a-blockchain%3F) and [4.1](#4-1-ton-service-implementation-strategies)).
 
@@ -115,7 +115,7 @@
 
 Each workchain is identified by its number or **workchain identifier** (`workchain_id : uint32`), which is simply an unsigned 32-bit integer. Workchains are created by special transactions in the masterchain, defining the (previously unused) `workchain_id` and the formal description of the workchain, sufficient at least for the interaction of this workchain with other workchains and for superficial verification of this workchain's blocks.
 
-### 2.1.7. Creation and activation of new workchains
+### 2.1.7. Creation and activation of new workchains **[NOT IMPLEMENTED - only Workchain Zero exists]**
 
 The creation of a new workchain may be initiated by essentially any member of the community, ready to pay the (high) masterchain transaction fees required to publish the formal specification of a new workchain.
 
@@ -203,7 +203,7 @@
 
 The same mechanism can be used to fix non-fatal mistakes in the masterchain blocks as well.
 
-### 2.1.17. Correcting invalid shardchain blocks
+### 2.1.17. Correcting invalid shardchain blocks **[POSSIBLY NOT FULLY IMPLEMENTED]**
 
 Normally, only valid shardchain blocks will be committed, because validators assigned to the shardchain must reach a two-thirds Byzantine consensus before a new block can be committed. However, the system must allow for detection of previously committed invalid blocks and their correction.
 
@@ -227,7 +227,7 @@
 
 The masterchain state implicitly defines a map transforming the hash of the first block of each "vertical" blockchain into the hash of its latest version. This enables a client to identify and locate any vertical blockchain by the hash of its very first (and usually the only) block.
 
-### 2.1.18. TON coins and multi-currency workchains
+### 2.1.18. TON coins and multi-currency workchains **[PARTIALLY IMPLEMENTED - only TON coin exists]**
 
 The TON Blockchain supports up to $2^{32}$ different "cryptocurrencies", "coins", or "tokens", distinguished by a 32-bit `currency_id`. New cryptocurrencies can be added by special transactions in the masterchain. Each workchain has a basic cryptocurrency, and can have several additional cryptocurrencies.
 
@@ -285,9 +285,9 @@
 
 • A **Java-like imperative language**, with each smart contract resembling a separate class.
 
-• A **lazy functional language** (think of Haskell).
+• A **lazy functional language** (think of Haskell). 
 
-• An **eager functional language** (think of ML).
+• An **eager functional language** (think of ML). 
 
 ### 2.1.21. Configurable parameters
 
@@ -355,7 +355,7 @@
 
 The description of a previous version of TL, suitable for serializing arbitrary objects into sequences of 32-bit integers, is available at https://core.telegram.org/mtproto/TL.
 
-A new version of TL, called **TL-B**, is being developed for the purpose of describing the serialization of objects used by the TON Project. This new version can serialize objects into streams of bytes and even bits (not just 32-bit integers), and offers support for serialization into a tree of TVM cells (cf. [2.3.14](#2-3-14-tvm-cells)). A description of TL-B will be a part of the formal specification of the TON Blockchain.
+A new version of TL, called **TL-B**, is being developed for the purpose of describing the serialization of objects used by the TON Project. This new version can serialize objects into streams of bytes and even bits (not just 32-bit integers), and offers support for serialization into a tree of TVM cells (cf. [2.3.14](#2-3-14-tvm-cells)). A description of TL-B will be a part of the formal specification of the TON Blockchain. **[TL-B SPECIFICATION STATUS UNKNOWN]**
 
 ### 2.2.6. Blocks and transactions as state transformation operators
 
@@ -779,7 +779,7 @@
 
 Notice that hypercube routing introduces some additional delays and expenses, because of the necessity to forward messages through several intermediate shardchains. However, the number of these intermediate shardchains grows very slowly, as the logarithm $\log N$ (more precisely, $\lceil\log_{16} N\rceil - 1$) of the total number of shardchains $N$. For example, if $N \approx 250$, there will be at most one intermediate hop; and for $N \approx 4000$ shardchains, at most two. With four intermediate hops, we can support up to one million shardchains. We think this is a very small price to pay for the essentially unlimited scalability of the system. In fact, it is not necessary to pay even this price:
 
-### 2.4.20. Instant Hypercube Routing: fast path for messages
+### 2.4.20. Instant Hypercube Routing: fast path for messages **[POSSIBLY NOT FULLY IMPLEMENTED]**
 
 A novel feature of the TON Blockchain is that it introduces a fast path for forwarding messages from one shardchain to any other, allowing in most cases to bypass the slow hypercube routing of [2.4.19](#2-4-19-hypercube-routing-slow-path-for-messages-with-assured-delivery) altogether and deliver the message into the very next block of the final destination shardchain.
 
@@ -966,13 +966,13 @@
 
 On the other hand, this nominating or lending system enables one to become a validator without investing a large amount of money into TON coins first. In other words, it prevents those keeping large amounts of TON coins from monopolizing the supply of validators.
 
-### 2.6.4. Fishermen: obtaining money by pointing out others' mistakes
+### 2.6.4. Fishermen: obtaining money by pointing out others' mistakes **[POSSIBLY NOT FULLY IMPLEMENTED]**
 
 Another way to obtain some rewards without being a validator is by becoming a fisherman. Essentially, any node can become a fisherman by making a small deposit in the masterchain. Then it can use special masterchain transactions to publish (Merkle) invalidity proofs of some (usually shardchain) blocks previously signed and published by validators. If other validators agree with this invalidity proof, the offending validators are punished (by losing part of their stake), and the fisherman obtains some reward (a fraction of coins confiscated from the offending validators). Afterwards, the invalid (shardchain) block must be corrected as outlined in [2.1.17](#2-1-17-correcting-invalid-shardchain-blocks). Correcting invalid masterchain blocks may involve creating vertical blocks on top of previously committed masterchain blocks (cf. [2.1.17](#2-1-17-correcting-invalid-shardchain-blocks)); there is no need to create a fork of the masterchain.
 
 Normally, a fisherman would need to become a full node for at least some shardchains, and spend some computing resources by running the code of at least some smart contracts. While a fisherman does not need to have as much computing power as a validator, we think that a natural candidate to become a fisherman is a would-be validator that is ready to process new blocks, but has not yet been elected as a validator (e.g., because of a failure to deposit a sufficiently large stake).
 
-### 2.6.5. Collators: obtaining money by suggesting new blocks to validators
+### 2.6.5. Collators: obtaining money by suggesting new blocks to validators **[NOT IMPLEMENTED AS SEPARATE ROLE]**
 
 Yet another way to obtain some rewards without being a validator is by becoming a collator. This is a node that prepares and suggests to a validator new shardchain block candidates, complemented (collated) with data taken from the state of this shardchain and from other (usually neighboring) shardchains, along with suitable Merkle proofs. (This is necessary, for example, when some messages need to be forwarded from neighboring shardchains.) Then a validator can easily check the proposed block candidate for validity, without having to download the complete state of this or other shardchains.
 
@@ -1204,7 +1204,7 @@
 
 ### 2.7.9. Performing merge operations
 
 After that, when the validators from the union of the two original task groups are ready to become validators for the merged shardchain (this might involve a state transfer from the sibling shardchain and a state merge operation), they commit a merge commit flag in the headers of blocks of their shardchain (this event is propagated to the next masterchain blocks), and stop creating new blocks in separate shardchains (once the merge commit ag appears, creating blocks in separate shardchains is forbidden). Instead, a merged shardchain block is created (by the union of the two original task groups), referring to both of its preceding blocks in its header. This is reflected in the next masterchain block, which will contain the hash of the newly created block of the merged shardchain. After that, the merged task group continues creating blocks in the merged shardchain.
 
 ---
 
@@ -1405,7 +1405,7 @@
 | EOS       | 2016, (2018)| 4| DPoS      | yes| m   | ht.  | no   | L    |
 | PolkaDot  | 2016, (2019)| 4| PoS BFT   | yes| m   | ht.  | no   | L    |
 | Cosmos    | 2017, ?   | 4  | PoS BFT   | yes| m   | ht.  | no   | L    |
 | **TON**   | 2017, (2018)| 5| PoS BFT   | yes| m   | mix  | dyn. | T    |
 
 **Table Legend**: Project – project name; Year – year announced and year deployed; G. – generation (cf. [2.8.15](#2-8-15-simplified-classification-generations-of-blockchain-projects)); Cons. – consensus algorithm (cf. [2.8.3](#2-8-3-creating-and-validating-blocks%3A-proof-of-work-vs-proof-of-stake) and [2.8.4](#2-8-4-variants-of-proof-of-stake-dpos-vs-bft)); Sm. – support for arbitrary code (smart contracts; cf. [2.8.6](#2-8-6-support-for-turing-complete-code-in-transactions%2C-i-e-%2C-essentially-arbitrary-smart-contracts)); Ch. – single/multiple blockchain system (cf. [2.8.2](#2-8-2-single-blockchain-vs-multi-blockchain-projects)); R. – heterogeneous/homogeneous multichain systems (cf. [2.8.8](#2-8-8-blockchain-types%3A-homogeneous-and-heterogeneous-systems)); Sh. – sharding support (cf. [2.8.12](#2-8-12-sharding-support)); Int. – interaction between blockchains, (L)oose or (T)ight (cf. [2.8.14](#2-8-14-interaction-between-blockchains%3A-loosely-coupled-and-tightly-coupled-systems)).
 
@@ -1443,7 +1443,7 @@
 
 ### 2.9.7. EOS [5]; https://eos.io
 
 EOS (2018 or later) is a proposed heterogeneous multi-blockchain DPoS system with smart contract support and with some minimal support for messaging (still loosely-coupled in the sense described in [2.8.14](#2-8-14-interaction-between-blockchains%3A-loosely-coupled-and-tightly-coupled-systems)). It is an attempt by the same team that has previously successfully created the BitShares and SteemIt projects, demonstrating the strong points of the DPoS consensus algorithm. Scalability will be achieved by creating specialized workchains for projects that need it (e.g., a distributed exchange might use a workchain supporting a special set of optimized transactions, similarly to what BitShares did) and by creating multiple workchains with the same rules (confederations in the sense described in [2.8.10](#2-8-10-heterogeneous-systems-with-several-workchains-having-the-same-rules%2C-or-confederations)). The drawbacks and limitations of this approach to scalability have been discussed in _loc._, _cit._ Cf. also [2.8.5](#2-8-5-comparison-of-dpos-and-bft-pos), [2.8.12](#2-8-12-sharding-support), and [2.8.14](#2-8-14-interaction-between-blockchains%3A-loosely-coupled-and-tightly-coupled-systems) for a more detailed discussion of DPoS, sharding, interaction between workchains and their implications for the scalability of a blockchain system.
 
 At the same time, even if one will not be able to create a Facebook inside a blockchain (cf. [2.9.13](#2-9-13-is-it-possible-to-upload-facebook-into-a-blockchain%3F)), EOS or otherwise, we think that EOS might become a convenient platform for some highly-specialized weakly interacting distributed applications, similar to BitShares (decentralized exchange) and SteemIt (decentralized blog platform).
 
@@ -1851,17 +1851,17 @@
 
 An even simpler form of storing files is completely off-chain: one might essentially create a torrent for a new file, and use TON DHT as a distributed torrent tracker for this torrent ([cf. 3.2.10](#3-2-10-distributed-torrent-trackers-and-network-interest-groups-in-ton-dht)). This might actually work pretty well for popular files. However, one does not get any availability guarantees. For example, a hypothetical blockchain Facebook ([cf. 2.9.13](#2-9-13-is-it-possible-to-upload-facebook-into-a-blockchain%3F)), which would opt to keep the profile photographs of its users completely off-chain in such torrents, might risk losing photographs of ordinary (not especially popular) users, or at least risk being unable to present these photographs for prolonged periods. The TON Storage technology, which is mostly off-chain, but uses an on-chain smart contract to enforce availability of the stored files, might be a better match for this task.
 
-### 4.1.8. Decentralized mixed services, or fog services
+### 4.1.8. Decentralized mixed services, or fog services  **[NOT IMPLEMENTED]**
 
 So far, we have discussed centralized mixed services and applications. While their on-chain component is processed in a decentralized and distributed fashion, being located in the blockchain, their off-chain component relies on some servers controlled by the service provider in the usual centralized fashion. Instead of using some dedicated servers, computing power might be rented from a cloud computing service offered by one of the large companies. However, this would not lead to decentralization of the off-chain component of the service.
 
 A decentralized approach to implementing the off-chain component of a service consists in creating a market, where anybody possessing the required hardware and willing to rent their computing power or disk space would offer their services to those needing them. For example, there might exist a registry (which might also be called a market or an exchange) where all nodes interested in keeping files of other users publish their contact information, along with their available storage capacity, availability policy, and prices. Those needing these services might look them up there, and, if the other party agrees, create smart contracts in the blockchain and upload files for off-chain storage. In this way a service like TON Storage becomes truly decentralized, because it does not need to rely on any centralized cluster of servers for storing files.
 
-### 4.1.9. Example: fog computing platforms as decentralized mixed services
+### 4.1.9. Example: fog computing platforms as decentralized mixed services **[NOT IMPLEMENTED]**
 
 Another example of such a decentralized mixed application arises when one wants to perform some specific computations (e.g., 3D rendering or training neural networks), often requiring specific and expensive hardware. Then those having such equipment might offer their services through a similar exchange, and those needing such services would rent them, with the obligations of the sides registered by means of smart contracts. This is similar to what fog computing platforms, such as Golem (https://golem.network/) or SONM (https://sonm.io/), promise to deliver.
 
-### 4.1.10. Example: TON Proxy is a fog service
+### 4.1.10. Example: TON Proxy is a fog service **[NOT IMPLEMENTED]**
 
 TON Proxy provides yet another example of a fog service, where nodes wishing to offer their services (with or without compensation) as tunnels for ADNL network traffic might register, and those needing them might choose one of these nodes depending on the price, latency and bandwidth offered. Afterwards, one might use payment channels provided by TON Payments for processing micropayments for the services of those proxies, with payments collected, for instance, for every 128 KiB transferred.
 
@@ -2021,24 +2021,24 @@
 
 A ton-site may embed into the HTML pages it returns some usual-looking POST forms, with POST actions referring either to ton-sites, ton-services or smart contracts by means of suitable (TON) URLs. In that case, once the user fills and submits that custom form, the corresponding action is taken, either immediately or after an explicit confirmation.
 
-### 4.3.23. TON WWW
+### 4.3.23. TON WWW **[NOT IMPLEMENTED]**
 
 All of the above will lead to the creation of a whole web of cross-referencing entities, residing in the TON Network, which would be accessible to the end user through
 
-### 4.3.24. Advantages of TON WWW
+### 4.3.24. Advantages of TON WWW **[NOT IMPLEMENTED]**
 This TON WWW of on-chain and off-chain services has some advantages over its conventional counterpart. For example, payments are inherently integrated in the system. User identity can be always presented to the services (by means of automatically generated signatures on the transactions and RPC requests generated), or hidden at will. Services would not need to check and re-check user credentials; these credentials can be published in the blockchain once and for all. User network anonymity can be easily preserved by means of TON Proxy, and all services will be effectively unblockable. Micropayments are also possible and easy, because ton-browsers can be integrated with the TON Payments system.
 
 ---
 
-# 5. TON Payments
+# 5. TON Payments **[NOT IMPLEMENTED]**
 
 The last component of the TON Project we will briefly discuss in this text is TON Payments, the platform for (micro)payment channels and lightning network value transfers. It would enable instant payments, without the need to commit all transactions into the blockchain, pay the associated transaction fees (e.g., for the gas consumed), and wait five seconds until the block containing the transactions in question is confirmed.
 
 The overall overhead of such instant payments is so small that one can use them for micropayments. For example, a TON file-storing service might charge the user for every 128 KiB of downloaded data, or a paid TON Proxy might require some tiny micropayment for every 128 KiB of traffic relayed.
 
 While TON Payments is likely to be released later than the core components of the TON Project, some considerations need to be made at the very beginning. For example, the TON Virtual Machine (TON VM; [cf. 2.1.20](#2-1-20-ton-virtual-machine)), used to execute the code of TON Blockchain smart contracts, must support some special operations with Merkle proofs. If such support is not present in the original design, adding it at a later stage might become problematic ([cf. 2.8.16](#2-8-16-complications-of-changing-the-genome-of-a-blockchain-project)). We will see, however, that the TON VM comes with natural support for smart payment channels ([cf. 5.1.9](#5-1-9-ton-vm-support-for-smart-payment-channels)) out of the box.
 
-## 5.1 Payment Channels
+## 5.1 Payment Channels **[NOT IMPLEMENTED]**
 
 We start with a discussion of point-to-point payment channels, and how they can be implemented in the TON Blockchain.
 
@@ -2134,7 +2134,7 @@
 
 We expect the internal payment channel to be extremely simple (e.g., the simple synchronous payment channel discussed in [5.1.3](#5-1-3-simple-bidirectional-synchronous-trustless-payment-channel)), to minimize the size of Merkle proofs to be submitted. The external payment channel will have to be smart in the sense described in [5.1.7](#5-1-7-more-sophisticated-payment-channels.-promises).
 
-## 5.2 Payment Channel Network, or Lightning Network
+## 5.2 Payment Channel Network, or Lightning Network **[NOT IMPLEMENTED]**
 
 Now we are ready to discuss the lightning network of TON Payments that enables instant money transfers between any two participating nodes.