With the original launch date coming closer and closer, an in-depth look and summary of the TON project appear essential. In its 524-page whitepaper, TON describes itself as a 5th generation blockchain: a blockchain that is supposedly superior because of its tightly-coupled sharding network with a Byzantine Fault Tolerant Proof of Stake (BFT PoS) consensus mechanism.
This report takes the following structure to shine some light on this potentially game-changing blockchain. After a general introduction to the overall scope and the current status of the project, the three elements of a “5th generation blockchain” are assessed in greater detail. Subsequently, TON will be compared to Libra, and remaining open questions are going to be listed before the report concludes on the exploration of the Telegram Open Network.
TON is intended not merely to be a blockchain. Instead, the crypto project to gather USD 1.7bn from private investors - more than one-fifth of all funds raised in 20181- wants to build a whole ecosystem around it’s “huge superserver capable of handling millions of transactions per second”2.
Overall, the TON ecosystem will supposedly comprise of nine different elements, which revolves around its blockchain of blockchains. This obvious centerpiece will be complemented by:
To facilitate the understanding of this set-up, Chart 1 (displayed below) displays the respective interactions between each of these ../components.
The interface for external integration is of particular interest, as TON is created by Telegram. The integration of non-custodial TON “light wallets” (c.f. Telegram Investor Primer) into the Telegram Messenger could thus quickly build a significant user-base for the platform, comparable even to the previously assessed Libra. While there are no official figures about the current user base of Telegram, an estimation by Binance Research points to a current likely upper bound of 500 million users3.
The intention to integrate the Telegram Chat with TON is clearly stated in an early litepaper, distributed to initial investors (i.e., Telegram Investor Primer):
“Telegram-TON integration will provide a clear path to cryptocurrencies for millions of people. Telegram Messenger will not only serve as an example of the possibilities offered by integrating with TON, but will also add unique features to the TON platform, leveraging Telegram’s massive user base and developed ecosystem4”
As of today, there has not been much information on who exactly is attempting to make this ambitious product suite available to the general public. Based on data collected by Binance Research, at least thirteen other programmers have been working on TON, in addition to the two brothers Nikolay and Pavel Durov.
There is not much known about the team, which makes it difficult to judge their prior engagements and track records in cryptography and distributed systems. Nonetheless, there exists circumstantial evidence that indicates that many TON engineers have already been working for Telegram5.
As a result, the same engineers6 are likely to have derived Telegram’s encryption protocol: the MTProto. Instead of using a well studied, provably secure encryption protocol, the MTProto is a “homebrewed” encryption protocol. This very unusual strategic decision, in turn, violates against the first rule of cryptography, which strongly recommends to “never roll your own crypto”.
While this principle is probably taught in every introductory lesson to cryptography7 and generally considered best practice8, Nikolay Durov has a strong academic track record in a field closely related to cryptography. So far, Telegram has not been subject to any real security leaks, there are, however, already several identified theoretical weaknesses and potential attack vectors9.
The next subsection will discuss the current status of the Telegram Open Network, along with its native cryptocurrency: Gram.
On September 7th 2019, the source code for the TON blockchain was released. Since then, it has been possible to run a full node, validator node, and use the block explorer of the testnet10. Other than that there is (1) a general whitepaper on the Telegram Open Network, (2) a whitepaper on the blockchain, (3) a whitepaper on the virtual machine, (4) a whitepaper on the language used by TON’s smart contracts and a last whitepaper, supposedly describing the details of the consensus mechanism that has been announced, yet not published.
Not regarding the fact that the eventual 5 billion Grams do not yet exist, some of the early investors started trading their Gram placeholder tokens. Curiously, the leaked simple agreements on future tokens (SAFTs)11 explicitly state that the sale of Gram placeholder tokens is not allowed and will forfeit any future claims to Gram.
If the terms of the SAFT are thus upheld, this could imply that neither the old nor the new owner has any longer a claim towards Grams. Irrespectively, it is, of course, possible - but unlikely - that special agreements between the initial investor and Telegram have been agreed upon which would allow for an early sale.
An important point to notice is that the initial offering was conducted under an exemption for security issuance (i.e., Rule 506C of the US Security and Exchange Commission (SEC)) that is essentially building on the fact that all purchasers are accredited investors. While this is generally easy to ensure in a restricted, private sale to wealthy individuals, it is much harder to ensure in a public sale.
The trades themselves have been executed in two different forms. Some individuals were trading IOUs over the counter (OTC), and others were trading placeholder tokens, issued by the exchange Liquid in cooperation with GramAsia12.
According to publicly available information, the earliest investors were already able to sell potential Grams at a premium of almost 1000%.
Unlike early investors, recent buyers now have to worry about three things:
The “generation” of a blockchain can be assessed by two overarching criteria: the deployed consensus mechanism and the addition of at least one new element. A preliminary overview could hence take the following shape, depicted in table 1.
| Generation | Main consensus | New elements | Key blockchains |
|---|---|---|---|
| 1st generation | PoW | - | Bitcoin |
| 2nd generation | PoW | Smart contracts | Ethereum 1.0 |
| 3rd and 4th generations | PoS, dPoS, BFT PoS | Blockchain interoperability (with loose coupling) Multichain networks (heterogeneous) | Ethereum 2.0 (tentative), Bitshares, EOS, Polkadot, Cosmos |
| 5th generation | dPoS | Sharding (dynamic) Blockchain interoperability (with tight coupling) Multichain networks (homogeneous and heterogeneous) | TON |
Consequently, TON will not only support sharding but a whole utility suite that incorporates elements from previous blockchain generations.
Like most of the programmable blockchains, the Telegram Open Network will support a virtual machine (i.e., Telegram Virtual Machine) that will run on nodes and allows for the execution of smart contracts. Similar to Ethereum, this allows for distributed, “sandboxed” execution environments.
The smart contract language itself (i.e., Fift) is a stack-based general-purpose language, similar to Forth. Fift is compiled into bytecode and executed on the TVM. Being a mixture of an interpreter and a compiler, Fift is some hybrid language, which most likely does not require a lot of hardware support. Curiously, Fift uses a special notation (i.e., Reverse Polish notation) that is not widely used by many programmers.14
In an apparent attempt to reverse this trend and foster a respective programming community, Telegram has started to announce programming competitions. Its most recent is targeted towards implementing several smart contracts, TVM improvements, and offers Telegram blockchain bug bounties. While Fift may still be an unusual choice, there might eventually be also several alternatives15. TON intends, after all, to support multiple other languages, as long as they will have static types and support algebraic data types.
TON’s general architecture is unique and very catered towards supporting scaling. With the far-fetched goal of being able to support “millions of transactions per second”, TON does not only set an extremely ambitious goal post but seems to exceed industry demand by 1000 orders of magnitude. In comparison, one of the busiest payment networks worldwide, Visa, averages out on 1,700 transactions per second16.
However, it is worth mentioning that a) TON intends to scale upon demand and will not attempt to start with millions of transactions and b) wants to have more use cases than financial transactions. Irrespectively, chart 2 illustrates the divergent ambitions quite clearly.
Source: Binance Research
All previously mentioned elements are complemented and rooted in the consensus mechanism. A mechanism that has to support scaling and, as synchronous consensus mechanisms require timing margins of safety, slowing down state agreements, be asynchronous.
For this reason, an asynchronous Proof of Stake (PoS) variant has to be deployed17. The TON whitepaper lays out the decision-making process behind the choice and compares delegated PoS to the chosen Byzantine Fault Tolerant (BFT) version of PoS. Unfortunately, the whitepapers lack detail in describing the actual implementation thereof:
“Some subjects have intentionally been left out of this document. One is the Byzantine Fault Tolerant (BFT) protocol used by the validators to determine the next block of the masterchain or a shardchain; that subject is left for a forthcoming document dedicated to the TON Network.”18
As this forthcoming document has not yet come forth, the only details provided of the deployed consensus mechanism are in a general chapter on validators (TON whitepaper 2.6.7 ff.) and a high-level assessment that compares practical BFT to delegated Proof of Stake (see section 2.8.4 of the TON whitepaper).
As the deployed consensus mechanism is one of the most critical components of any blockchain, this lack of detail is concerning. The details of the implementation would be particularly interesting, as this would be the first project to operate BFT on a permissionless network19.
While permissioned blockchains can be operated via some proof-of-authority mechanism, permissionless blockchains typically require an economic incentive system. The related work on Casper, the proof-of-stake implementation of the permissionless blockchain Ethereum has, for example, been continuing for already more than two years and is still not concluded20.
Other than that, especially three elements are worthy of a closer inspection, as they are the key differentiating factors between TON and similarly ambitious projects. These distinct, yet very interlinked factors are:
The next subsection describes sharding and these sub-elements in-depth, with an application to the Telegram Open Network.
The high-level idea of sharding is to split databases (which includes distributed databases, i.e., blockchains) into multiple, independently valid pieces: shards. The database is thus primarily split into rows, not columns. As a result, every shard consists of all the required data.21
Sharding can be either done according to a predefined structure or dynamically, where transactions on shards (in TON called “messages”) can initiate events on other shards. Ton opts for the latter variant.
Generally speaking, TON opts to consequently shard the entire database until the account-basis. All singular shards are then constantly rearranged in a bottom-up fashion to eventually form blocks in up to 2^60 shardchains, which are the shards of up to 2^32 workchains ultimately validated in one masterchain.
Source: Binance Research
As a result, the masterchain contains hashes of all masterchain, shard- and workchain blocks.
It defines some global properties that must be adhered to in all shards thereof, creates settlement finality by using a BFT PoS consensus mechanism and keeps track of information such as the active validators and their current stakes.
Workchains are only “virtual” blockchains, as they are a collection of underlying shardchains.
Consequently, every workchain can contain local rules that may govern the format of account addresses, transactions, virtual machines, native cryptoassets, and the like. Workchains are therefore heterogeneous (i.e., different), while shardchains are homogenous (i.e., equal).
The “tight-coupling” of the TON blockchain network describes a scenario where multiple homogeneous shardchains of heterogeneous workchains can interact with each other seamlessly. This feature is crucial to maintain interoperability and support a vibrant network of purpose-built blockchains. It can be facilitated by standardizing the format of the interactions and the location of input/output queues thereof.
The tight coupling of blockchains also sets the foundation for a “mesh network” for fast transactions - the Instant Hypercube Routing (c.f. 2.4.20). The idea of hypercube routing has already been explored academically, yet was until now never implemented in a blockchain.22
At the prospective launch of the masterchain, there will be only one workchain, the Telegram Open Network workchain. It will use Fift to write smart contracts, TVM to execute them, and uses Grams as a native asset thereon.
Workchains will be created by submitting a particular transaction to the masterchain. As a means to prevent Sybil attacks, masterchain transactions have significant transaction costs and must be approved by a supermajority of validators (i.e., 2⁄3rds of all validators).
With a better understanding of the blockchain network architecture, it is possible to revisit the previously introduced consensus mechanism.
There are four different actors involved in the validation of transactions, all depicted in table 2.
| Actor | Requirednode | Economic incentive | Participation |
|---|---|---|---|
| Validators | Full node | Validation reward | Validate blocks |
| Fisherman | Full node | Partial payout of slashed stake of false validators | Masterchain tx to publish invalidity proofs |
| Nominator | undefined | Partial payout of validation reward | Provide validator with capital |
| Collator | undefined | Partial payout of validation reward | Point out shardchain block candidates |
The most important actors, validators, can become a validator by locking Gram in a smart contract address. With initially lower loads it is expected that 100 validators (later up to 1000) are elected via a smart contract that takes into account multiple factors, such as all submitted stakes and the maximum acceptable load per validator (c.f. Chapter 2.6.7).
The global set of validators validates blocks on the masterchain. The global set of validators is, however, split into multiple validator task groups in a pseudorandom deterministic fashion to match the number of shardchains.
As validators must operate full nodes tracking the complete state of the respective shardchain, it is necessary to inform them before the validation period. This allows them to set up a full node. Otherwise, the load would be too high for validators.
After the currently projected one-hour long validation period, validators are reallocated to a new shardchain.
Once a block candidate gathered 2/3rds of all votes, it is eligible for commitment as the next shardchain block. This is supposedly done in the adapted BFT PoS fashion. After “(almost) all” (not described in detail) shardchain blocks have been finalized, a new masterchain block can be submitted that includes all shardchain block hashes.
To facilitate the work of validators and decrease the often-mentioned risk of an increasing centralization in a PoS-based consensus system, multiple other actors are involved.
It is to be seen whether the above set-up is indeed sufficient to avoid an even further centralization of the ~ 1000 validators. This will most likely also depend on the actual implementation and the distribution of partial payouts.
Either way, the respective set-up is likely to facilitate block validity and is somewhat similar to set-ups of validators and inspectors commonly found in permissioned networks such as Corda and potentially found in permissionless networks like Ethereum 2.0.
There is an obvious comparison to be made between TON and Libra (as a blockchain). Both are created by a parent company with a significant user base. Both want to leverage that user base for adoption. Both have significant assets to support the production of their new products. Both are ambitious, visionary projects. Both are clashing with the original Bitcoin ideology, due to fears of being too centralized. However, there are many differences between the two projects and their general strategy.
While both projects are visionary, Libra attempts to create a new use case for money, while TON aims to radically advance the entire blockchain stack.
The two projects showed very different approaches in their attempt to engage with a broader audience. The results of this diverging strategy are already visible in, for example, the respective Github repositories23. According to publicly available data from Github, Libra has 80 direct contributors and more than 22,000 external contributors, while TON presumably has 15 contributors and 8 known external contributors. The same trend holds when assessing already developed third party services24. This may also be due to the fact that the Libra source code is well documented, whereas hardly any documentation exists for the Ton testnet.
In an apparent attempt to foster the adoption of TON, Telegram recently started a coding challenge that awards up to USD 400,000 to the winner. The winner has to build at least one multi-signature contract, suggest improvements for a Fift compiler and find issues and fixes of the TON testnet25.
In terms of prospective go-live dates, the two projects also diverge. While TON has to be released before the 31st of October 2019, there is no such explicit deadline for the release of Libra. Nonetheless, it is generally expected that Libra will be launched in 202026.
The next subsection discusses the economic analysis of both Libra and Gram, the token of the Telegram Open Network.
The initial price of Grams sold in the two private sales was defined in a USD denominated cost function27. The average price of Grams sold in the first round is set at 0.38 USD, while the price of the second round rose to 1.33 USD. Another cost function defines the primary market price for additional Grams issued in the future (c.f. appendix 4.4.).
The current market price for Gram (i.e., the latest price paid on Liquid) is set at 4 USD. As the original supply of Gram is set to 5 billion units, the respective total market capitalization is set at 20 billion USD. Staking rewards will lead to an annual inflation rate of 2%, or 400 mn USD per year, at the current valuation.
Unlike Libra, Gram is not a currency, but a utility token. Therefore, there is no reason for the price of Gram to be fixed at a certain level. The respective secondary market value will thus fluctuate according to supply and demand. Nonetheless, a Ton Reserve may repurchase Grams to reduce the total circulating amount and thus attempt to increase the price.
As Gram is a utility token, it can also be used for several use cases:
Because the use cases of Gram and Ether are reasonably similar (especially in Ethereum 2.0), it is possible to deduce a likely legal classification of Grams. Adopting the position of the SEC, Ether is likely to not classify as a security “when putting aside the fundraising”.28 This would render Ether a crypto asset29.
As the fundraising of TON was covered via an SEC exemption and Grams have similar use cases as Ether, Grams are thus likely to be classified as crypto assets.
This classification may create short-term benefits for TON, as the respective legislation is often-times still absent or only just being created. Subsequently, short-term opportunities for regulatory arbitrage may exist. Furthermore, regulation is likely to eventually be tailored to crypto-assets, potentially bridging fundamental gaps between existing regulations and new asset properties.30
On the other hand, Libra has a much more restrictive use-case: it is to be used as a currency and aims to remain price-stable. It is projected to realize that goal by collateralizing it with fiat currencies, and short-term government debt securities and its exact reserve breakdown were released recently31.
Due to the lack of official up to date figures, Binance Research had to make an educated guess about the current user base. By using an official figure from March 2018 and statements made by Pavel Durov, it is possible to estimate the current amount of users. The respective figure is treated as a likely upper bound.
| Step | Figure | Description | Source | Date |
|---|---|---|---|---|
| 1 | 200,000 | Total users | Telegram | March, 2018 |
| 2 | 500,000 | Daily user growth | Telegram Investor Primer - "at least 500 000 new users join Telegram daily" | February, 2018 |
| 2 | 3,000,000 | Daily user growth | Pavel Durov, Telegram - "I see 3 milliuon new users signed up for Telegram within the last 24 hours" | March, 2019 |
| 2 | 500,000 | Daily user growth | Chosen as lower bound for daily growth | Sep, 2019 |
| 3 | 520 | Days with known growth | Roughly 520 days have passed after the statement about the official statement about Telegram reaching 200 mn users was released. | Sep, 2019 |
| 3 | 260,000,000 | Total users added | Calculating "520 x 500 000" leads to 260 mn users. | Sep, 2019 |
| 4 | 500,000,000 | Upper likely bound | Adding 260 000 000 suspected new users to 200 000 000 initial users leads to 460 000 000 users. Accounting for an increasing influx due to increased network effects and accepting some level of inaccuracy inherent to such educated guesses leads to an upper likely bound of 500 000 000 users. | Sep, 2019 |
According to the methodology presented in Table 3, Telegram has approximately 500mn users. Facebook alone, on the other hand, reportedly has 2.4 billion of users, which represent approximately 5 times as many as Telegram32.
The team working on TON, under the lead of Nikolay Durov, has to come up with some answers to currently still open questions.
First and foremost - can they ship before October 31st and implement all the technical features laboriously described on over 500 whitepaper pages in a bulletproof manner?
Unlike other popular blockchains (e.g., Polkadots or Selenia), the development has been taken place in a completely isolated manner. While some code has been released publicly on Github, its development thereof remains in a silo and intransparent. As a result, it is difficult to understand design and architecture decisions which may make it harder to identify potential attack vectors.
At the same time, several entrance barriers for developers have been well defined and can pose a severe challenge to the adoption of new blockchains. In the case of TON, some of the multiple challenges are, a currently very unpopular and poorly documented programming language, a very small developer community and an overall new architecture, which is hard to understand for external parties.
Not only is the existing developer community small, but also does circumstantial evidence point towards a clear regional dominance33. As TON intends to be a new global standard, a more diverse community could be helpful.
Instead of a wide, open community that may benefit by network effects and saliently participate in a governance process, there is thus a risk of TON having a small and homogenous (i.e., centralized) developing scene.34
As of now, it remains unclear to Binance Research to what extent transactions could be private. Could Pederson-Commitments be implemented to reduce the need for data storage35? Is the infinite sharding paradigm going to work? Superquadratic sharding is, after all, only one out of several well-known problems of sharding and has been so for a substantiated amount of time. Lastly, the jump towards millions of transactions per second seems hard to reconcile with practical reality (even Alibaba merely has peaks of hundreds of thousands TPS) and a distributed consensus of nodes that are potentially spread globally.36
If successful, the Telegram Open Network will make considerable advancements in the area that has been the most significant pain point for the blockchain ecosystem: scaling of a decentralized database. In combination with a permissionless BFT PoS mechanism, the infinite sharding paradigm would solve many scalability issues. However, TON still raises multiple concerns.
Like most PoS based blockchain networks, TON appears to be vulnerable to centralization. The small and homogeneous developing scene could aggravate this tendency.
Considering the amount and sheer scale of the problems that may be solved by TON, open development of the source-code would also be more than warranted. While the whitepaper documentation is very extensive, it appears to predominantly be a logically consequent set-up. It is, however, not describing the actual implementation thereof. An openly developed source-code would allow anyone to validate their claims and point out potential security loopholes. The absence of any such communication is a clear warning sign. On the other hand, this could also represent a working style; a preference rooted in the core development team.
Lastly, it could be possible that the TON developing team might be forced to launch a minimum viable product. The easiest way to make compromises in such a distributed system is to replace essential elements such as the consensus mechanism with a centralized administration37.
Irrespectively of any concerns, one thing rises above: Telegram has something each project in the crypto-ecosystem desperately seeks: users.
If TON eventually launches along with a user-friendly Telegram Messenger implementation, Telegram users will likely adopt, consciously or not, TON and its underlying crypto asset: Gram. This possibility, by itself, would certainly be enough incentive for any developer to dig into the TON ecosystem, and jump over any initial entrance barrier.
In case this scenario occurs, blockchain will enter into its next generation and become a real backend technology ready to power many decentralized applications for millions of users.
