Understanding the TON Technical Architecture

General
,
1

This document discusses the technical aspects of the TON roadmap, highlighting its advancements in speed and scalability.

TON is built around a high-speed application-centric technology logic: Born from Telegram, transactions are directly on-chain based on messages and support peer-to-peer (P2P) interactions.

  1. Asynchronous Message Passing:Using FunC as the development language, nodes in TON communicate through messages. As TON is an asynchronous chain, logical time (It) is introduced to ensure correct synchronization of inter-chain messages. This concept ensures that messages are executed strictly in chronological order to maintain accurate information processing.

  2. Hypercube Message Routing Mechanism: TON employs both standard and fast routing methods. Standard routing uses a cubic structure to transmit messages between shards through adjacent nodes, while fast routing utilizes Merkle proofs along the hypercube’s edges to relay messages, enhancing speed.

  3. PoS + BFT Consensus for Ecological Development:Proof of Stake (PoS) avoids extensive computations during block creation, leading to higher efficiency and lower costs, which benefits DApp deployment. While Delegated PoS (DPoS) is faster, it has slower trust speeds compared to BFT systems. Thus, TON opts for BFT.

TON’s dynamic sharding architecture supports scalability: TON enhances speed through parallel queries, improves accuracy with dynamic sharding, and expands capability with the “bag of cells” structure.

  1. Dynamic Sharding Architecture:TON has three layers: a single masterchain, multiple workchains, and dynamically adjustable shardchains. Each shardchain is a collection of various workchains, and DApps can activate specific shardchains.

  2. Quickly Updatable Global State:The global state is updated using a “bag of cells” structure similar to DAG. This involves combining new and old cells and deleting the old root to enable fast updates. Vertical block repairs are used to update blocks.

Blockchain Scalability Challenges

Scalability is a critical technical challenge and a key driver for blockchain development. As blockchain applications and users grow, existing networks often face issues with throughput and transaction confirmation times. Traditional blockchain designs limit their ability to handle large-scale transactions and user demands, leading to network congestion, high transaction fees, and inefficiencies.

The challenges of blockchain scalability stem mainly from distributed architecture and consensus mechanisms:

  1. Distributed Architecture: Each node must validate and record all transactions, which restricts network throughput.
  2. Consensus Mechanism:Blockchain’s security and decentralization require every node to maintain a complete copy of the blockchain, increasing storage and transmission burdens.

To address scalability, researchers propose various solutions:

  1. Sharding:Splits the blockchain into smaller segments (shards) to process transactions and data independently. This improves throughput but faces issues with shard communication, cross-shard transactions, and consensus design.

  2. Sidechains:Independent blockchains connected to the main chain for asset transfer, which reduces the main chain’s load and provides flexibility. However, it requires security mechanisms and compatibility with the main chain.

  3. Rollups:Store transaction data off-chain and submit summaries to the main chain for validation, improving scalability and performance. However, it raises concerns about centralization and security.

  4. New Consensus Mechanisms: For example, Solana’s Proof of History (PoH) associates timestamps with transactions to validate order and reduce consensus communication costs. Although Solana claims a TPS of 65,000, actual data throughput is about 6-8k TPS.

TON’s Technical Architecture

Adaptive Infinite Sharding Multi-Chain Design

TON’s sharding approach is bottom-up, unlike the typical top-down design where a single blockchain is decomposed into multiple interacting blockchains. TON organizes workchains into shardchains, treating workchains as virtual or logical entities within shardchains. This “blockchain of blockchains” approach effectively improves system performance.

  1. Masterchain: The sole chain managing protocol parameters, validator sets, and records current workchains and shardchains. If shards reach their limit, each shardchain will only store a single account or smart contract.

  2. Workchain: Conceptually a collection of shardchains, supporting up to 2^32 workchains, with flexible rules. All workchains must have similar message queue formats for communication and security.

  3. Shardchain:Enhances efficiency by automatically splitting or merging based on load. Workchains are further divided into shardchains, with each shardchain serving a subset of accounts.

Information Transmission Mechanism

  1. Message: Transactions consist of inbound messages that trigger transactions and outbound messages sent to other contracts.

  2. Hypercube Routing:A routing mechanism enabling rapid message transmission through a hypercube structure. Messages are processed and transmitted along the hypercube’s edges, verified by validators.

Asynchronous Message Passing

In asynchronous systems, transactions involving multiple smart contract calls are processed over several blocks. Logical time is used to synchronize messages between chains, with messages strictly ordered by their logical time (lt).

Message Hypercube Routing Mechanism

  1. Slow Routing: Messages are packed into blocks and relayed through intermediate shardchains, following the hypercube’s edges. It ensures higher security and decentralization but requires more hops for transmission.

  2. Fast Routing: Messages are handled by the destination shardchain’s validators in advance, using Merkle proofs for quick validation and receipt destruction. It speeds up transmission but has security risks.

Shardchain Global State

  1. “Bag of Cells”: Updates global state using a DAG-like structure, combining new and old cells and deleting the old root for fast updates.

  2. Vertical Block Repair: Each block in the shardchain is part of a chain. New blocks are submitted to a vertical chain for error correction.

Consensus Mechanism

  1. POS Network Roles:

    • Validator Nodes:Stake 300,000 TON to maintain network security, creating blocks with signatures from over 2/3 of staked nodes. Malicious behavior results in slashing.
    • Fisherman: Monitors validators for correct task completion, acting as a supervisor.
    • Proofreader: Suggests new shardchain blocks and earns rewards for successful suggestions.

  2. BFT:TON chooses BFT over DPoS due to its superior trust levels and speed.

TON’s Future Developments

  1. Separation of Sequencers and Validators:
  2. Scalability and Speed Improvements: Parallel expansion for handling high transaction volumes.
  3. Sharding Guidelines and Tools：Providing guidelines and code examples for high-load scenarios in exchanges and payment systems.
  4. Validator Coordination: Enhanced detection and penalization of underperforming validators.