<\/a><\/noindex><\/p>\nBasic Concepts<\/h3>\n <\/p>\n
Account<\/strong> (account<\/em>). A set of data identified by a 256-bit number account_id<\/em> (most often this is the public key of the account owner). In the basic case (see below, the zero blockchain<\/em>), this data refers to the user's balance. Anyone can 'borrow' a specific account_id<\/em> amount, but its value can only be changed according to certain rules.<\/p>\n<\/p>\n
Smart Contract<\/strong> (smart contract<\/em>). Essentially, it's a specific instance of an account, enhanced with the smart contract code and storage for its variables. In the case of a 'wallet,' money can be credited and debited from it according to relatively simple and predefined rules, while in the case of a smart contract, these rules are written in the form of its code (in some Turing-complete programming language).<\/p>\n<\/p>\n
The state of the blockchain<\/strong> (state of blockchain<\/em>). A collection of states of all accounts\/smart contracts (in an abstract sense \u2014 a hash table where the keys are account identifiers, and the values are the data stored in the accounts).<\/p>\n<\/p>\n
Message<\/strong> (message<\/em>). I used the phrase 'credit and debit money' \u2014 this is a specific example of a message ('transfer N grams<\/em> from account account_1<\/em> to account account_2<\/em>'). Obviously, only the node that possesses the private key of the account account_1<\/em> \u2014 and can confirm this with a signature \u2014 can send such a message. The result of delivering such messages to a regular account is an increase in its balance, and for the smart contract, it is the execution of its code (which will process the receipt of the message). Of course, other messages are also possible (transferring not money, but arbitrary data between smart contracts).<\/p>\n<\/p>\n
Transaction<\/strong> (transaction<\/em>The delivery of a message is called a transaction. Transactions alter the state of the blockchain. It is from transactions (records of message delivery) that blocks in the blockchain are formed. In this regard, one can think of the blockchain state as an incremental database \u2014 all blocks are 'diffs' that need to be applied sequentially to attain the current database state. The specifics of packaging these 'diffs' (and restoring the full state from them) will be discussed in the next article.<\/p>\n<\/p>\n
Blockchain in TON: What is it and why is it needed?<\/h3>\n <\/p>\n
As mentioned in the previous article, a blockchain is a data structure where elements (blocks) are ordered in a 'chain', and each subsequent block in the chain contains the hash of the previous one.<\/em>In the comments, a question was raised: why is such a data structure necessary when we already have DHT \u2014 a distributed hash table? It's clear that some data can be stored in a DHT, but this is only suitable for non-'sensitive' information. Cryptocurrency balances cannot be stored in a DHT \u2014 primarily due to the lack of checks on integrity.<\/em>In fact, the entire complexity of the blockchain structure arises to prevent tampering with the data stored in it.<\/p>\n<\/p>\n
However, the blockchain in TON appears even more complex than in most other distributed systems \u2014 and there are two reasons for this. The first is the desire to minimize the need for forks.<\/em>In traditional cryptocurrencies, all parameters are set at the initial stage, and any attempt to change them effectively creates an 'alternative universe' of cryptocurrency. The second reason is the support for fragmentation (sharding<\/em>, ) of the blockchain. A blockchain is a structure that cannot grow smaller over time; typically, each node responsible for the network's functionality must store it completely. In traditional (centralized) systems, sharding is employed to address such issues: part of the records in the database resides on one server, part on another, and so on. In the case of cryptocurrencies, this functionality is still quite rare \u2014 particularly because it is challenging to add sharding to a system that was not originally designed for it.<\/em>So how does TON plan to solve both of the problems described above?<\/p>\n<\/p>\n
?<\/p>\n
<\/p>\n
Blockchain Content. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
First of all, let's talk about what will be stored in the blockchain. It will hold the states of accounts (wallets in the basic case) and smart contracts (for simplicity, we will consider them the same as accounts). Essentially, this will be a regular hash table \u2014 the keys will be identifiers account_id<\/strong>, and the values will be data structures containing things like:<\/p>\n<\/p>\n
\nbalance;<\/li>\n smart contract code (only for smart contracts);<\/li>\n smart contract data storage (only for smart contracts);<\/li>\n statistics;<\/li>\n (optionally<\/em>) public key for transfers from the account, by default account_id;<\/li>\nqueue of outgoing messages (they are recorded here for forwarding to the recipient);<\/li>\n list of the most recently delivered messages to this account.<\/li>\n<\/ul>\n<\/p>\n
As mentioned above, the blocks consist of transactions \u2014 messages delivered to various account_ids. However, in addition to account_id, messages also contain a 32-bit field workchain_id<\/em> \u2014 the identifier of the so-called workchain<\/strong> (workchain<\/em>, working blockchain<\/em>). This allows having several independent blockchains with different configurations. Meanwhile, workchain_id = 0 is considered a special case, the zero workchain<\/strong> \u2014 it is the balances in it that will correspond to the cryptocurrency TON (Grams). Most likely, in the beginning, there will be no other workchains at all.<\/p>\n<\/p>\n
Shardchains. Infinite Sharding Paradigm.<\/h3>\n <\/p>\n
But the growth of the number of blockchains does not stop there. Let's delve into sharding. Imagine that each account (account_id) is allocated its own blockchain \u2014 it contains all incoming messages \u2014 and the states of all such blockchains are stored on separate nodes.<\/p>\n
<\/p>\n
Of course, this is quite wasteful: probably, transactions will occur very rarely in each of these shardchains<\/strong> (shardchain<\/em>, shard blockchain<\/em>) and a lot of powerful nodes will be needed (to give a hint, we are talking not just about clients on mobile phones \u2014 but serious servers).<\/p>\n<\/p>\n
Therefore, shardchains consolidate accounts based on binary prefixes of their identifiers: if a shardchain has the prefix 0110, it will include transactions of all account_ids that start with those digits. This shard_prefix<\/em> can have a length from 0 to 60 bits \u2014 and importantly, it can change dynamically.<\/p>\n<\/p>\n
<\/p>\n
When one of the shard chains starts receiving an excessive amount of transactions, the nodes working on it \"split\" it into two child chains according to pre-defined rules \u2014 their prefixes will be one bit longer (one of them will have this bit equal to 0, and the other will have it equal to 1). For example, shard_prefix<\/em> = 0110<\/u>b will split into 0110<\/u>0b and 0110<\/u>1b. Conversely, if two \"neighboring\" shard chains start to feel sufficiently relaxed (for a certain period), they will merge back together.<\/p>\n <\/p>\n
Thus, sharding is done \"bottom-up\" \u2014 we assume that each account has its own shard, but they are temporarily \"glued\" together by prefixes. This is what is meant by the Infinite Sharding Paradigm<\/strong> (paradigm of infinite sharding.<\/em>).<\/p>\n<\/p>\n
It is important to emphasize that work chains exist only virtually \u2014 in fact, workchain_id<\/em> it is part of the identifier of a specific shard chain. To put it formally, each shard chain is defined by a pair of numbers (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Error correction. Vertical blockchains.<\/h3>\n <\/p>\n
It is traditionally believed that any transaction in a blockchain is \"carved in stone.\" However, in the case of TON, the possibility to \"rewrite history\" is provided \u2014 if someone (i.e., a \"fishing\" node<\/em>) proves that one of the blocks was signed incorrectly. In this case, a special correction block is added to the respective shard chain, containing the hash of the block being corrected (and not the last block in the shard chain). Presenting the shard chain as a horizontally laid chain of blocks, it can be said that the correction block attaches itself to the erroneous block not to the right, but on top \u2014 therefore, it is considered that it becomes part of a small \"vertical blockchain.\" Thus, it can be said that shard chains are two-dimensional blockchains.<\/em>.<\/p>\n<\/p>\n
<\/p>\n
If subsequent blocks refer to the erroneous changes made to the affected block (i.e., if new transactions are based on invalid data), corrective transactions are added on top of these blocks as well. If the blocks do not involve the 'affected' information, these 'corrective waves' do not apply to them. For example, in the illustration above, the transaction in the first block that increases account C's balance was deemed incorrect\u2014therefore, the transaction that decreases this account's balance in the third block must also be annulled, and a corrective block should be committed on top of that block.<\/p>\n
<\/p>\n
It should be noted that although corrective blocks are displayed as being 'above' the originals, they will actually be appended to the end of the corresponding blockchain (where they belong chronologically). The two-dimensional arrangement simply indicates which point in the blockchain they will be 'attached' to (via the hash of the original block contained within them).<\/p>\n
<\/p>\n
One could philosophize separately about how good the solution of 'changing the past' really is. It seems that if we allow for the possibility of an incorrect block appearing in the shardchain, we must also allow the possibility of an erroneous corrective block. Here, as far as I can judge, the difference lies in the number of nodes that must reach consensus on new blocks\u2014relative to each shardchain, a relatively small 'working group<\/em>of nodes (frequently changing composition) will be working, whereas the introduction of corrective blocks will require the consensus of all validator nodes<\/em>. I will discuss validators, working groups, and other roles of nodes in the next article.<\/p>\n<\/p>\n
One blockchain to govern them all<\/h3>\n <\/p>\n
Above, a lot of information about different types of blockchains has been listed, which also needs to be stored somewhere. Specifically, this refers to the following information:<\/p>\n
<\/p>\n
\nthe number and configurations of workchains;<\/li>\n the number of shardchains and their prefixes;<\/li>\n which nodes are currently responsible for which shardchains;<\/li>\n hashes of the last added blocks in all shardchains.<\/li>\n<\/ul>\n<\/p>\n
As you might have guessed, all these things are recorded in yet another storage blockchain\u2014 masterchain<\/strong> (masterchain<\/em>, master blockchain<\/em>). Thanks to the presence of hashes from the blocks of all shard chains in its blocks, it creates a highly interconnected system. This means that the generation of a new block in the master chain will happen immediately after the generation of blocks in the shard chains \u2014 it is expected that blocks in the shard chains will appear almost simultaneously about every 5 seconds, while the next block in the master chain will come a second after that.<\/p>\n<\/p>\n
But who will be responsible for carrying out all this titanic work \u2014 for forwarding messages, executing smart contracts, forming blocks in the shard chains and the master chain, as well as checking blocks for errors? Will millions of users' phones quietly handle all of this with the Telegram client installed on them? Or perhaps, the Durov team will abandon decentralization ideas and their servers will do this the old-fashioned way?<\/p>\n
<\/p>\n
In reality, neither of these answers is correct. However, this article is quickly running out of space, so the discussion about the various roles of nodes (you may have already noticed mentions of some of them), as well as their operational mechanics will continue in the next part.<\/p>\n
Source: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u0430\u043d\u043d\u044b\u0439 \u0442\u0435\u043a\u0441\u0442 \u2014 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0442\u0435\u0439, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 (\u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e) \u0433\u043e\u0442\u043e\u0432\u044f\u0449\u0435\u0439\u0441\u044f \u043a \u0432\u044b\u0445\u043e\u0434\u0443 \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 Telegram Open Network (TON). \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0447\u0430\u0441\u0442\u0438 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0435\u0451 \u0441\u0430\u043c\u044b\u0439 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u2014 \u0441\u043f\u043e\u0441\u043e\u0431 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0443\u0437\u043b\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u043e\u043c\u043d\u044e, \u0447\u0442\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u044f \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u043d\u0435 \u0438\u043c\u0435\u044e \u0438 \u0432\u0435\u0441\u044c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"TON:](\"\/wp-content\/uploads\/2019\/05\/e2a24aa1dda6a435e60da257af662853.png\")
<\/p>\n