You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/develop/blockchain/sharding-lifecycle.mdx
+15-8Lines changed: 15 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -14,15 +14,20 @@ ISP underpins the TON Blockchain's design, treating each account as part of its
14
14
15
15
Each shardchain, or more precisely, each shardchain block, is identified by a combination of `workchain_id` and a binary prefix `s` of the account_id.
16
16
17
+
## Messages and Instant Hypercube Routing (Instant Hypercube Routing)
18
+
19
+
In the infinite sharding paradigm, each account (or smart-contract) is treated as if it were itself in a separate shardchain.
20
+
Interaction between accounts occurs solely through the sending of messages, which is part of the actor model where accounts act as actors. An efficient messaging system between shardchains is critical to the operation of the TON blockchain.
21
+
A feature of TON is Instant Hypercube Routing, which enables fast delivery and processing of messages between shardchains, ensuring that messages created in a block of one shardchain are processed in the next block of the target shardchain, regardless of their number in the system.
- Shards of a workchain are divided by time and denoted in black dashed line.
25
-
- Blocks 101, 102, 103, and 80 relate to the masterchain block with seqno=29. Here, 101, 102, and 103 are in one shard, while 80 is in another.
29
+
- Shards of a workchain are divided by time and denoted in dashed line.
30
+
- Blocks 222, 223, and 224 relate to the masterchain block with seqno=102. Here, 222 is in one shard, while 223 and 224 are in another.
26
31
- If a split or merge event happens, the affected shards pause until the next masterchain block.
27
32
28
33
In summary, Split Merge in TON Blockchain is a complex yet efficient mechanism that enhances scalability and interaction within the blockchain network. It exemplifies TON's approach to resolving common blockchain challenges, emphasizing efficiency and global consistency.
@@ -49,16 +54,18 @@ The non-split parts are crucial for ensuring global consistency, reduced to inte
49
54
50
55
Key components of the non-split part of a shardchain block include:
51
56
52
-
-**InMsgDescr**: Descriptions of all messages imported into the block.
53
-
-**OutMsgDescr**: Descriptions of all messages exported or generated by the block.
57
+
-**InMsgDescr**: Descriptions of all messages imported into the block (i.e., either processed by the transaction included in the block or forwarded to the output queue, in the case of a transient message traveling along a path dictated by `Hypercube Routing`).
58
+
-**OutMsgDescr**: Descriptions of all messages exported or generated by the block (i.e. either messages generated by a transaction included in the block, or transit messages with a destination not belonging to the current shardchain, forwarded from `InMsgDescr`).
54
59
55
60
#### Block Header and Validator Signatures
56
61
57
-
The block header, another non-split component, contains essential information like workchain_id, binary prefix of account_ids, and various hashes (e.g., of the immediate predecessor). Validator signatures are appended to the unsigned block, forming the signed block.
62
+
The block header, another non-split component, contains essential information like `workchain_id`, binary prefix of `account_ids`, block sequence number (defined as the smallest non-negative integer greater than the sequence numbers of its predecessors), logical time, and unixtime generation. It also contains a hash of the immediate predecessor of the block (or its two immediate predecessors in the case of a preceding
63
+
shardchain merge event), hashes of its initial and final states (i.e., the states of the shardchain immediately before and immediately after the current block is processed), and a hash of the most recent masterchain block known at the time the shardchain block was generated. Validator signatures are appended to the unsigned block, forming the signed block.
58
64
59
65
#### Outbound Message Queue
60
66
61
-
OutMsgQueue in the shardchain state is a critical non-split part. It holds undelivered messages from OutMsgDescr until they are processed or delivered to their destination.
67
+
`OutMsgQueue` in the shardchain state is a critical non-split part. It contains undelivered messages included in `OutMsgDescr`, either by the last shardchain block leading to this state or by one of its predecessors.
68
+
Initially, each outgoing message is included in the `OutMsgQueue` and stored there, until they are processed or delivered to their destination.
Copy file name to clipboardExpand all lines: docs/develop/blockchain/shards.mdx
+50-6Lines changed: 50 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -4,19 +4,55 @@
4
4
Page is under development
5
5
:::
6
6
7
-
Sharding is a mechanism in TON blockchain which allows to process a large number of transactions. The main idea of sharding in TON is that when account A sends a message to account B and account C sends a message to account D both of these operations can be performed asynchronously.
7
+
Sharding is a mature concept originating in [database design](https://en.wikipedia.org/wiki/Shard_(database_architecture)). It involves splitting and distributing one logical data set across multiple databases that share nothing and can be deployed across multiple servers.
8
+
Simply put, sharding allows horizontal scalability - splitting data to distinct, independent pieces that can be processed in parallel. This is a key concept in the world's transition from data to [big data](https://en.wikipedia.org/wiki/Big_data).
9
+
When data sets are becoming too big to be handled by traditional means, there's no other way to scale other than to break them down into smaller pieces.
10
+
11
+
The Sharding mechanism in the TON blockchain, allows a large number of transactions to be processed.
12
+
The TON Blockchain consists of one masterchain and up to 2<sup>32</sup> workchains. Each workchain is a separate chain with its rules. Each workchain can further split into 2<sup>60</sup> shardchains, or sub-shards, containing a fraction of the workchain's state. Currently, only one workchain is operating on TON - Basechain.
13
+
The main idea of sharding in TON is that when account A sends a message to account B and account C sends a message to account D both of these operations can be performed asynchronously.
8
14
9
15
By default in the Basechain (`workchain=0`) there is only one shard with a shard number `0x8000000000000000` (or `1000000000000000000000000000000000000000000000000000000000000000` in binary representation). The masterchain (`workchain=-1`) always has one and only one shard.
10
16
17
+
## Masterchain
18
+
19
+
The Masterchain is the primary chain that stores the network configuration and the final state of all workchains. You can understand this as the masterchain being the core directory, a single source of truth for all the shards in the ecosystem.
20
+
21
+
It carries fundamental protocol information, including current settings, a list of active validators and their stakes, active workchains, and associated shardchains. Most importantly, it maintains a record of the latest block hashes for all workchains and shardchains, enforcing consensus across the network.
22
+
23
+
## Workchain
24
+
25
+
The Masterchain splits into individual chains called Workchains. Workchains are customized blockchains tailored to certain transactions or use cases, running parallel within the TON network.
26
+
27
+
## Uniqueness
28
+
29
+
In designing the TON blockchain, two key decisions were made that make it unique among other blockchains that utilize sharding.
30
+
31
+
First, TON provides for dynamic segmentation of the blockchain depending on the network load. When the number of transactions increases to a critical level, the blockchain is automatically split into two separate shardchains.
32
+
If the load on one of the parts continues to grow, it is split in half again, and this process continues as needed. If the number of transactions decreases, the shards can merge again.
33
+
This adaptive model allows for the creation of as many shards as needed at a given time.
34
+
35
+
The second solution that distinguishes TON is the principle of a non-fixed number of shards. Unlike systems like Ethereum 2.0, which supports a fixed number of shards (64 shards), TON allows adding more and more shards depending on the needs of the network, with a theoretical limit of 2<sup>60</sup> shards per worker chain.
36
+
This number is so large as to be virtually limitless, and allows over 100 million shards to be provided to every person on Earth and still have a supply left over. This approach is the only way to meet dynamic scaling requirements that are difficult to predict in advance.
37
+
38
+
39
+
11
40
## Splitting
12
41
13
-
Each shard is responsible for some subset of accounts with some common binary prefix. This prefix appears in shard id which presented by a 64-bit integer and has the following structure: `<binary prefix>100000...`. For example, shard with id `1011100000...` contains all accounts started with prefix `1011`.
42
+
In TON Blockchain, a sequence of transactions of a single account (e.g. `Tx1 -> Tx2 -> Tx3 -> ...`) is called an account transaction chain or <b>AccountChain</b>. This emphasizes that it is a sequence of transactions associated with a single account.
43
+
Several such <b>AccountChains</b> combined within a single shard form a <b>ShardChain</b>. The <b>ShardChain</b> (hereinafter referred to as the shard) is responsible for storing and processing all transactions within a shard, where each transaction chain is defined by a specific account group.
44
+
45
+
These groups of accounts are denoted by a common binary prefix, which serves as a criterion for clustering them in the same shard.
46
+
This prefix appears in shard id which presented by a 64-bit integer and has the following structure: `<binary prefix>100000...`. For example, shard with id `1011100000...` contains all accounts started with prefix `1011`.
14
47
15
48
When number of transactions in some shard grows, this shard splits into two shards. New shards obtain the following ids: `<parent prefix>01000...` and `<parent prefix>11000...` and become responsible for accounts starting with `<parent prefix>0` and `<parent prefix>1` correspondingly. The seqnos of blocks in shards go continuously starting from the parent last seqno plus 1. After split, shards go independently and may have different seqnos.
16
49
17
-
Masterchain block contains information about shards in their headers. After the block of shard appears in masterchain header it may be considered as finished (it cannot be rolled back).
Masterchain block contains information about shards in its header. After the block of shard appears in masterchain header it may be considered as finished (it cannot be rolled back).
54
+
55
+
An actual example:
20
56
* Masterchain block `seqno=34607821` has 2 shards: `(0,4000000000000000,40485798)` and `(0,c000000000000000,40485843)` (https://toncenter.com/api/v2/shards?seqno=34607821).
21
57
* Shard `shard=4000000000000000` was splitted into `shard=2000000000000000` and `shard=6000000000000000`, and the masterchain block `seqno=34607822` obtains 3 shards: `(0,2000000000000000,40485799)` and `(0,6000000000000000,40485799)`. Note that both new shards have the same seqnos but different shard IDs (https://toncenter.com/api/v2/shards?seqno=34607822).
22
58
* New shards go independently and after 100 masterchain blocks (in masterchain block `seqno=34607921`) one shard has the last block `(0,2000000000000000,40485901)` and another one has `(0,6000000000000000,40485897)` (https://toncenter.com/api/v2/shards?seqno=34607921).
@@ -25,5 +61,13 @@ Example:
25
61
If the load on shards goes down they can merge back:
26
62
* Two shards can merge if they have a common parent and, therefore, their shard ids are `<parent prefix>010...` and `<parent prefix110...`. Merged shard will have shard id `<parent prefix>10...` (for example `10010...` + `10110...` = `1010...`). The first block of a merged shard will have `seqno=max(seqno1, seqno2) + 1`.
27
63
28
-
Example:
29
-
* In masterchain block `seqno=34626306`, two of five shards with last blocks `(0,a000000000000000,40492030)` and `(0,e000000000000000,40492216)` merged into one with block `(0,c000000000000000,40492217)` (https://toncenter.com/api/v2/shards?seqno=34626306 and https://toncenter.com/api/v2/shards?seqno=34626307).
* In masterchain block `seqno=34626306` two of five shards with last blocks `(0,a000000000000000,40492030)` and `(0,e000000000000000,40492216)` merged into one with block `(0,c000000000000000,40492217)` (https://toncenter.com/api/v2/shards?seqno=34626306 and https://toncenter.com/api/v2/shards?seqno=34626307).
Copy file name to clipboardExpand all lines: docs/develop/dapps/asset-processing/jettons.md
+17-7Lines changed: 17 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -27,6 +27,7 @@ It is suggested to set several MEMO deposit wallets for better performance.
27
27
28
28
[Memo-less deposits](https://github.com/gobicycle/bicycle) - This solution also exists, but is more difficult to integrate. However, we can assist with this, if you would prefer to take this route. Please notify us before deciding to implement this approach.
29
29
30
+
30
31
### Additional Info
31
32
32
33
:::caution Transaction Notification
@@ -39,16 +40,29 @@ if you will be allowing your users set a custom memo when withdrawing jettons -
39
40
40
41
- For Go, one should consider [tonutils-go](https://github.com/xssnick/tonutils-go). At the moment, we recommend the JS lib.
41
42
43
+
## Ready Solutions for CEX
44
+
45
+
### Tonapi Embed
46
+
47
+
Tonapi Embed - on-premises solution designed to operate with deposits and withdrawals, ensuring high-performance and lightweight deployment.
48
+
49
+
* Trust-less system running on any TON Liteservers.
50
+
* Maintaining deposits and withdrawals for Toncoin and Jettons as well.
51
+
* Solution developed according to the recommended MEMO-deposits and highload withdrawals guidelines provided by TF Core team.
42
52
43
-
## Content List
53
+
For cooperation, please contact to [@tonrostislav](https://t.me/tonrostislav).
44
54
45
55
56
+
## Jetton Processing Global Overview
57
+
58
+
### Content List
59
+
46
60
:::tip
47
61
In following docs offers details about Jettons architecture generally, as well as core concepts of TON which may be different from EVM-like and other blockchains. This is crucial reading in order for one to grasp a good understanding of TON, and will greatly help you.
48
62
:::
49
63
50
64
This document describes the following in order:
51
-
1.Overview
65
+
1.Introduction
52
66
2. Architecture
53
67
2. Jetton Master Contract (Token Minter)
54
68
3. Jetton Wallet Contract (User Wallet)
@@ -58,17 +72,13 @@ This document describes the following in order:
58
72
6. Wallet processing
59
73
7. Best Practices
60
74
61
-
##Overview
75
+
### Introduction
62
76
63
77
:::info
64
78
TON transactions are irreversible after just one confirmation.
65
79
For clear understanding, the reader should be familiar with the basic principles of asset processing described in [this section of our documentation](/develop/dapps/asset-processing/). In particular, it is important to be familiar with [contracts](/learn/overviews/addresses#everything-is-a-smart-contract), [wallets](/develop/smart-contracts/tutorials/wallet), [messages](/develop/smart-contracts/guidelines/message-delivery-guarantees) and deployment process.
66
80
:::
67
81
68
-
:::Info
69
-
For the best user experience, it is suggested to avoid waiting on additional blocks once transactions are finalized on the TON Blockchain. Read more in the [Catchain.pdf](https://docs.ton.org/catchain.pdf#page=3).
70
-
:::
71
-
72
82
Quick jump to the core description of jetton processing:
0 commit comments