The developers of Telegram’s Open Network (TON) recently released additional information regarding what will be featured in the lite client version of the highly anticipated software platform.
As the developer of an industry leading encrypted messaging network, Telegram’s management has shared documentation which suggests that the TON platform would compete with major blockchain platforms. These include software releases associated with Ethereum 2.0 and blockchain interoperability platforms Cosmos and Polkadot.
Competing with Polkadot, Cosmos
According to Cointelegraph’s analysis, the TON platform will most likely compete with both Cosmos and Polkadot when it comes to market share and when onboarding new users and development teams.
In 2019, the rapidly evolving blockchain ecosystem has become increasingly competitive as software architects throughout the world are working to build highly secure and scalable networks.
TON Has 300 Million Users, More than Any Other Crypto Network
When comparing how many potential new users a platform would attract, TON may have a significant advantage over Polkadot and Cosmos – as Telegram presently has an estimated 300 million users worldwide.
Currently, there are no crypto networks that have 300 million active users as many of the blockchains of today – including Ethereum (ETH) – are plagued by scalability issues. Because most existing blockchains are unable to process high volume transactions, they have struggled to attract and accommodate new users.
In order to build more scalable crypto platforms, many developers believe that the proof-of-stake (PoS)-based consensus algorithm should be used – instead of the energy intensive proof-of-work (PoW) protocol used by Bitcoin and also presently by Ethereum.
Achieving Higher Throughput With Proof of Stake
Blockchain-powered platforms such as Polkadot, Cosmos, and the highly anticipated Ethereum 2.0 network are based on some form of the PoS consensus model.
Variations of the PoS protocol have been adopted in order to achieve higher throughput as existing PoW networks such as Bitcoin and Ethereum are only able to process 7 and 15 transactions per second (TPS) respectively.
Meanwhile, mainstream payment networks like Visa can handle up to 45,000 TPS. For TON to succeed in the long-term, it would also need to process as many (or at least close to) transactions as Visa.
Notably, TON’s developers claim their network will be able to handle a large number of transactions required by enterprise-grade applications.
Scaling Via Smart Contract-Enabled Hubs
One of the main techniques used to build scalable distributed ledger technology (DLT)-based networks is by making use of smart contract-enabled centralized hubs. Users’ funds are managed through these hubs via automated business logic.
The security of users’ assets is ensured via preprogrammed conditions in their associated smart contracts as they can withdraw their holdings from the platform without having to interact with the hubs.
Scaling Through Sharding
Another commonly applied scalability technique is called sharding – which essentially splits the entire network state into small components or partitions, referred to as shards. Each shard contains its own independent portion of network state and transaction history.
Sharding is mainly used to allow transactions to execute in parallel (or simultaneously) – while separating all data sets into their own independent blockchains that are able to communicate (share data) with each other.
TON Blockchain to Use Sharding and PoS Consensus
As detailed in its design documents, the TON blockchain uses PoS-based consensus and it also implements sharding to help its network scale effectively. Moreover, the TON network has what’s referred to as the Masterchain – which is used to manage the activities of interconnected “workchains.” Both the Masterchain and the TON platform’s workchains have their own “shardchains.”
As described in its technical documentation:
To achieve the necessary scalability, we proposed the TON Blockchain, a ‘tightly-coupled’ multi-blockchain system … with bottom-up approach to sharding (cf. 2.8.12 and 2.1.2).
