TON Core
tg7.3 тыс. подписчиков
Открыть пост ↗
Understanding TON’s New Networking Architecture
Nearly every update over the past year has introduced incremental changes to TON’s network architecture to improve security, reduce traffic and increase performance.
As a result, TON’s network architecture has changed substantially. This article describes the new architecture.
1. Shared private overlays
The masterchain and each shardchain have a separate private overlay. Each now includes all validators (~400) and all collators.
Previously, these overlays included only their respective current validators and collators. Blocks were shared with the remaining validators and collators through a separate block-sync overlay. The block-sync overlay has now been removed, simplifying the network topology.
2. Protected overlay
The protected overlay serves critical infrastructure supporting the blockchain, including rebroadcaster nodes.
It was previously called fast-sync. That name is no longer appropriate: fast synchronization is a requirement for every overlay, including the public overlay. The protected overlay is intended to improve the security and stability of the blockchain and its critical infrastructure.
3. Validator and collator isolation
Validators and collators no longer communicate directly over the public overlay. Rebroadcasters forward blocks to the public overlay and relay external messages in the opposite direction.
This isolation improves security and reduces validators’ network traffic and CPU usage. The freed resources will be used to increase network performance.
4. Rebroadcasters
Rebroadcaster code is open source and will be merged into the main branch soon.
Like collators, rebroadcaster nodes are operated by some validator operators. Additional rebroadcaster deployments are not currently required.
5. Three broadcast types: Gossip, Two-Step and Plumtree
Two-Step Broadcast was developed as part of Sub-Second update for private validator overlays.
Plumtree Broadcast is a new Plumtree-like implementation designed for overlays with dynamic membership. It maintains reliable synchronization even when a large proportion of nodes perform poorly. It is used in the public and protected overlays. The implementation differs from the classic Plumtree algorithm but follows the same underlying ideas.
Gossip Broadcast, the original implementation, remains in limited use for some broadcast types.
6. Replacing RLDP1/2 with QUIC
QUIC was standardized in May 2021 as RFC 9000. TON’s initial networking implementation predated this standardization and used custom RLDP protocols for reliable data transfer, with functionality similar to QUIC.
During 2026, RLDP1/2 have been progressively replaced with QUIC. The next update will complete the migration, after which RLDP1/2 will no longer be used in the TON blockchain.
Nearly every update over the past year has introduced incremental changes to TON’s network architecture to improve security, reduce traffic and increase performance.
As a result, TON’s network architecture has changed substantially. This article describes the new architecture.
1. Shared private overlays
The masterchain and each shardchain have a separate private overlay. Each now includes all validators (~400) and all collators.
Previously, these overlays included only their respective current validators and collators. Blocks were shared with the remaining validators and collators through a separate block-sync overlay. The block-sync overlay has now been removed, simplifying the network topology.
2. Protected overlay
The protected overlay serves critical infrastructure supporting the blockchain, including rebroadcaster nodes.
It was previously called fast-sync. That name is no longer appropriate: fast synchronization is a requirement for every overlay, including the public overlay. The protected overlay is intended to improve the security and stability of the blockchain and its critical infrastructure.
3. Validator and collator isolation
Validators and collators no longer communicate directly over the public overlay. Rebroadcasters forward blocks to the public overlay and relay external messages in the opposite direction.
This isolation improves security and reduces validators’ network traffic and CPU usage. The freed resources will be used to increase network performance.
4. Rebroadcasters
Rebroadcaster code is open source and will be merged into the main branch soon.
Like collators, rebroadcaster nodes are operated by some validator operators. Additional rebroadcaster deployments are not currently required.
5. Three broadcast types: Gossip, Two-Step and Plumtree
Two-Step Broadcast was developed as part of Sub-Second update for private validator overlays.
Plumtree Broadcast is a new Plumtree-like implementation designed for overlays with dynamic membership. It maintains reliable synchronization even when a large proportion of nodes perform poorly. It is used in the public and protected overlays. The implementation differs from the classic Plumtree algorithm but follows the same underlying ideas.
Gossip Broadcast, the original implementation, remains in limited use for some broadcast types.
6. Replacing RLDP1/2 with QUIC
QUIC was standardized in May 2021 as RFC 9000. TON’s initial networking implementation predated this standardization and used custom RLDP protocols for reliable data transfer, with functionality similar to QUIC.
During 2026, RLDP1/2 have been progressively replaced with QUIC. The next update will complete the migration, after which RLDP1/2 will no longer be used in the TON blockchain.
1 картинка
Новый список