Back in Q1 of 2018, the Telegram Open Network (TON) secured USD 1.7bn in funding from private investors. However, if TON is not able to live up to its promise and issue the first TON tokens (i.e., Gram) by October 31st 2019, the capital raised will be returned to investors.
The launch of the Telegram Open Network marks the birth of the 5th generation of blockchains, with features such as dynamic sharding, âtight-couplingâ for blockchain interoperability, and multichain networks (both homogeneous and heterogeneous).
Telegram has an estimated user-base of ~500 million users. This broad user-base could immediately turn TON into one of the largest blockchains.
However, unlike Libra, there are several key differences between the two very ambitious projects:
While Libraâs vision is to reinvent how money circulates across the globe, TON attempts to improve the entire blockchain stack radically.
From an economic perspective, TONâs Gram is a utility token or crypto-asset subject to price fluctuations (in fiat). On the other hand, Libra offers a fairly stable alternative owing to its full collateralization with traditional assets.
Furthermore, there are a lot of unanswered questions that must be raised, partially owing to the chosen development strategy and a resulting lackluster public scrutiny.
Is the proposed scaling strategy going to work and seamlessly intertwine with a radically reinvented general architecture?
Can the proposed combination of stakeholders in the byzantine fault-tolerant Proof of Stake consensus mechanism avoid the centralization of its actors?
Will TON be able to attract a sufficiently large ecosystem of developers?
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.
1. General introduction
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 2.
1.1 The TON Ecosystem
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:
State-channel platform: a platform that is initially used for micropayments and off-chain value transfers, including payment for various TON services.
A Domain Name System (DNS): a predefined service to generate domain names in a human-readable format (c.f. chapter 4.3.1).
A queryable distributed hash-table: this Kademlia-like distributed hash table plays a key rule to locate other nodes in the network (c.f. chapter 3.2).
Many additional services: various interfaces for application interaction on browsers and smartphones.
A proxy to hide IP addresses of users and nodes for purposes such as privacy and preventing the threat of DDoS attacks (c.f. chapter 4.1.11).
A peer-to-peer network: a network user to access the Telegram Open Network, sending transactions, and receiving updates for specific components of the blockchain (e.g., shards) (c.f. chapter 3).
A distributed database to store information: it stores copies of blocks and snapshots of data, along with arbitrary files, with a torrent-like approach (c.f. chapter 4.1.8).
an interface for external integration of TON: this interface serves to integrate on-chain applications, built on the TON, to integrate into other applications (the most evident being Telegram Messenger (c.f. chapter 4.3.19).
To facilitate the understanding of this set-up, Chart 1 (displayed below) displays the respective interactions between each of these ../components.
Chart 1 - Description of TON: Telegram Open Network
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â
1.2 Turning whitepaper pages into code
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.
1.3 Current status of TON & 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.
The OTC traded IOUs are essentially informal agreements between two parties stating that one party owes the other a debt for something it has already received (i.e., âI owe youâ). These trades are entirely based on trust put into a reputable individual (i.e., the seller).
Fundamentally, platforms offering an IEO of these placeholder tokens (e.g., Liquid) are no different than that. The main distinction is that the counterparty of the trade (i.e., the seller) is an exchange platform instead of a private individuum. Investors bought a token that will be used to allocate Grams to placeholder token owners.
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:
Gram might not be issued at all: the mainnet may not launch before October 31st.
The trusted counterparty of the trade might decide to not follow through with the delivery of Gram.
The counterparty of the trade might not be able to follow through, because they acted against the terms and conditions declared in the SAFT13. The next section will discuss in-depth characteristics of 5th generation blockchains, relying mostly on the information provided in the detailed whitepaper of the Telegram Open Network.
2. Under the hood of â5th-generationâ blockchains
2.1 Overview of the different generations of blockchains
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.
Table 1 - Key characteristics of each blockchain generation
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.
2.2 General utility
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 , 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.
Chart 2 - (Projected) capacity of tx per second of various databases (in thousands)
Source: Binance Research
2.3 Consensus finding
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 support for both heterogeneous and homogeneous blockchains.
sharding on demand.
a tight coupling of blockchains.
The next subsection describes sharding and these sub-elements in-depth, with an application to the Telegram Open Network.
2.4 Sharding
2.4.1 General overview of sharding
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.
Chart 3 - Stylized structure of the TON blockchain network
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.
2.4.2 Multivariate blockchains and a tight coupling thereof
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).
2.4.3 Integrating sharding and consensus
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.
Table 2 - Stakeholders in the blockchain network
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.
So-called âFishermenâ can publish a masterchain transaction that includes an invalidity proof and the respective Merkle tree hash to receive a partial payout of slashed stake of false validators.
âNominatorsâ can vote for a validator by providing the validator with some of the Gram denominated capital that is required as stake. By acting accordingly, they are made accounfor the validatorsâ decision: they may receive a part of the validation reward, but may also lose a part of their capital in case the validatorâs stake is slashed. These actors are comparable to miners organizing in a mining pool.
The last actor group are the so-called âCollatorsâ who may point out shardchain block candidates to receive a partial amount of the validation reward.
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.
3. TON vs. Libra Blockchain
3.1 General analysis
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.
3.2 Economic analysis
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:
Staking requirements: it is required to stake Gram to validate blocks.
Transaction fees: to submit a transaction to the masterchain and Ton workchain a Gram-denominated fee is due. Other workchains might instead require transaction fees denominated in their ânative cryptoassetâ.
Gas payments: in a similar fashion to Ethereum, interacting with a smart contract requires the payment of processing fees due in Gram.
Storage payments: when storing something in persistent storage, a fee accrues in Gram.
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.
3.3 User analysis
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.
Table 3 - Methodology for estimating Telegram users
Step | Figure | Description | Source | Date |
---|---|---|---|---|
1 | 200,000 | Total users | 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.
4. Open questions
The team working on TON, under the lead of Nikolay Durov, has to come up with some answers to currently still open questions.
Can they launch before October 31st?
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?
Will they be able to build a developer community around TON?
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
Additional technical questions
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
5. Conclusion
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.
References
Alvarez (2019). Facebookâs Calibra cryptocurrency wallet launches in 2020. Available online at: https://www.engadget.com/2019/06/18/facebook-calibra-libra-cryptocurrency-digital-wallet/
Bullmann, Klemm, Pinna (2019). In search for stability in crypto-assets: are stablecoins the solution? Available online at: https://www.ecb.europa.eu/pub/pdf/scpops/ecb.op230~d57946be3b.en.pdf.
Baydakova (2019). Alive, thriving and totally unauthorized - inside the underground market for Telegramâs cryptocurrency. Available online at: https://www.coindesk.com/alive-thriving-and-totally-unauthorized-inside-the-underground-market-for-telegrams-cryptocurrency
Chow (2019). Introduction to Cyber Security Week 2. Available online at: https://tuftsdev.github.io/DefenseAgainstTheDarkArts/slides/week2-cryptography.pdf
Clayton (2019). Letter to U.S. representative Ted Budd. Available online at: https://coincenter.org/files/2019-03/clayton-token-response.pdf
ECB (2019). Crypto-Assets: Implications for financial stability, monetary policy, and payments and market infrastructures. Available online at: https://www.ecb.europa.eu/pub/pdf/scpops/ecb.op223~3ce14e986c.en.pdf
Hackernoon (2017). How to Create a Stream System with Tens of Millions of Feeds? Available online at: https://hackernoon.com/how-to-create-a-stream-system-with-tens-of-millions-of-feeds-6df06e302c78
Hinman (2018). Digital Asset Transactions: When Howey Met Gary. Available online at: https://www.sec.gov/news/speech/speech-hinman-061418
ICO Holder (2019). Telegram Open Network. https://icoholder.com/en/telegram-open-network-17581
Moares (2019). Forth: A Weird Programming Language. Hereâs Why You Might Like It Anyway. Available online at: https://www.whoishostingthis.com/resources/forth-programming/
Saribekyan & Margvelashvili (2017). Security Analysis of Telegram. Available online at: https://courses.csail.mit.edu/6.857/2017/project/19.pdf
Stackexchange (2012). Information security: Why shouldnât we roll our own? Available online at: https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own
Surane & Cannon (2019). Libra Needs Facebook Users to Help Break Into $714 Billion Payments Market. Available online at: https://www.bloomberg.com/graphics/2019-facebook-libra-world-banking/
TON (2019). Fift: A brief introduction. Available online at: https://test.ton.org/fiftbase.pdf
TON (2019). Telegram Open Network Blockchain. Available online at https://test.ton.org/tblkch.pdf
TON (2019). Telegram Open Network Virtual Machine. Available online at https://test.ton.org/tvm.pdf
TON (2019). Telegram Open Network. Available online at https://test.ton.org/ton.pdf
TON Investor Primer (2018). Available online at: https://drive.google.com/file/d/1ucUeKg_NiR8RxNAonb8Q55jZha03WC0O/view
Vice (2015). Why You Don't Roll Your Own Crypto. Available online at: https://www.vice.com/en_us/article/wnx8nq/why-you-dont-roll-your-own-crypto
Visa (2019). Visa Fact Sheet. Available online at: https://www.visa.gr/dam/VCOM/download/corporate/media/visanet-technology/aboutvisafactsheet.pdf
Warden & Biancuzzi (2009). The Forth language and design. Available online at: https://www.oreilly.com/library/view/masterminds-of-programming/9780596801670/ch04.html
Weck (2019). For Geeks: Telegram Open Network - does it scale & decentralise? Available online at: https://medium.com/@Claudio_Weck/for-geeks-telegram-open-network-does-it-scale-decentralise-ecc3225967e3
Williams (2017). Forth: The Hackerâs Language. Available online at: https://hackaday.com/2017/01/27/forth-the-hackers-language/
Based on calculations by Binance Research, TON raised 21.8% of all funds raised during 2018.â©
Also refer to Chapter 3.3. of this report.â©
For further information on the (leaked) primer please refer to: https://drive.google.com/file/d/1ucUeKg_NiR8RxNAonb8Q55jZha03WC0O/viewâ©
This is true for the individuals listed by ICOholder.â©
While this may be a simplification, it is true for at least Nikolai Durov who was one of the main authors behind MTProto.â©
This is, for example, the case in Dan Bonehâs Cryptography course at Stanford. For more information on why this is violating best practice of cryptography see for example: [1],[2],[3].â©
Less colloquially, this is known as Kerckhoffâs principle.â©
For known issues of Telegramâs encryption protocol see, for example: [1] [2] [3].â©
Coindesk obtained parts of the original SAFTâs: https://www.coindesk.com/alive-thriving-and-totally-unauthorized-inside-the-underground-market-for-telegrams-cryptocurrencyâ©
Updated: Liquid cancelled its sale of Gram token in the beginning of 2020.â©
For further information see Coindesk (2019).â©
A closer inspection is required for a full analysis of Fift. This assessment is predominantly based on previous assessments of Forth, such as: [1], [2], [3].â©
Three types of programming languages are mentioned in the whitepaper: âA Java-like imperative languageâ, with each smart contract being similar to a separate class, a lazy functional language (such as Haskell) or an general-purpose functional language (think of ML).â©
Visa states VisaNet handles around 150million transactions per day, which translates into 1736 transactions per second. Source available here: https://usa.visa.com/run-your-business/small-business-tools/retail.html On another occasion they apparently updated their figures to indicate that they could support up to 56 000 transactions per second. Source available here: https://usa.visa.com/about-visa/visanet.htmlâ©
For further information on asynchronous consensus and BFT please refer to: http://pmg.csail.mit.edu/papers/osdi99.pdfâ©
It is possible that the respective quote was not deleted from a previous version. A paper on the TON Network does exist after all. It is anyhow curious to see the high level of detail for minor added value services and the relatively scarce documentation for the crucially important BFT PoS consensus mechanism.â©
The permissioned blockchain Hyperledger Sawtooth, for example, already makes use of pBFT.â©
While the Github repository on Ethereum/Casper was already opened in 2014 the first commit only occurred in 2017.â©
In order to find answers to frequently asked questions in regards to Sharding please view: https://github.com/ethereum/wiki/wiki/Sharding-FAQâ©
To the best of Binance Researchâs knowledge. Some previous explorations of the idea are as follows: V. Buterin briefly explored Hypercube Routing [1], academic papers have been published [2], [3], [4].â©
The Libra repository has many more pull requests and an open issue tracking. For more information please refer to: https://github.com/libra/libra and https://github.com/ton-blockchain/ton.â©
There are only a handful of third-party services for TON. Binance Research is aware of an API for a wallet, Go and Python wallet wrappers, another Python litecoin client and a block explorer API.â©
Details for the coding challenge are available in respective Telegram groups such as âTelegram Contestsâ.â©
Further information available here: https://www.engadget.com/2019/06/18/facebook-calibra-libra-cryptocurrency-digital-wallet/â©
The cost of the n-th Libra is: p(n) â 0.1 · (1 + 10â9 )^nâ©
The general framework of Hinman (2018) was confirmed by SEC Chairman Clayton in March, 2019.â©
ECB (2019 & 2019). âThere is currently no universally agreed definition of what constitutes a crypto-asset but the ECB has defined it for its own analytical purposes as âa new type of asset recorded in digital form and enabled by the use of cryptography that does not represent a financial claim on, or a liability of, any identifiable entity.ââ©
For further information, please refer to ECB Occasional paper #223.â©
For further information, please see: https://www.reuters.com/article/us-facebook-libra-basket/u-s-dollar-to-be-main-currency-underpinning-facebooks-libra-spiegel-idUSKBN1W522Kâ©
For further information, please refer to: https://www.bloomberg.com/graphics/2019-facebook-libra-world-banking/â©
This conclusion is based on circumstantial evidence from the Telegram group âTON Researchâ where Russians seem to be the dominant faction.â©
Also see C. Weck (2019) in a medium article that started a conversation on open questions of TON.â©
Visit Binance Academy to learn more about MimbleWimble. https://academy.binance.com/blockchain/what-is-mimblewimbleâ©
For further information see Hackernoon (2017).â©
This point has been brought up by D. Gerard (2019) in a blogpost.â©