Translation: MetaCat
Abstract
Since the original TON white paper was written in 2017[1], many new blockchain projects have emerged, such as Solana and Ethereum 2.0. In this article, we compare TON with some of the more representative blockchain projects.
1. Comparative Form
Formal comparison of the classification of blockchain projects based on Sections 2.8 and 2.9 of the original TON white paper
1.1 Comparative Guide
We classify blockchain projects based on the following criteria, which are explained in more detail in Section 2.8 of the TON white paper [1]:
Single blockchain/multi-blockchain projects
Consensus algorithm: PoW (proof-of-work) / PoS (proof-of-stake)
For PoS projects, the exact consensus algorithm (e.g. dPOS or BFT)
For multi-blockchain projects that support arbitrary (Turing complete) smart contracts, we must further consider the following issues:
1> Types and rules of member blockchains: homogeneous, heterogeneous, hybrid
2> Existence of a main chain
3> Native support for sharding, static and dynamic sharding
4> Interactions between blockchains: loose coupling/tight coupling
In addition, a simplified classification of blockchain projects is introduced in 2.8.15 of the TON white paper [1], and a table containing basic properties of the most popular blockchain projects is given at the beginning of Section 2.9.
2. Solana
2.1 Overview of Solana
Solana [2] is a somewhat unusual project for the 2020s: it is a single blockchain project optimized for executing specialized transactions very quickly. In this respect, it is similar to the BitShares project [9] (developed in 2013-2014), the predecessor to EOS [8] (developed in 2016-2018), but uses a PBFT [10] variant called Tower Consensus [3] instead of dPOS. Solana claims to produce one block per second, or even faster; however, this comes at a cost, as the next block is produced before the previous block is completed (to quote the official blog post [4], "Unlike PBFT, Tower Consensus favors liveness over consistency"). This can result in the creation of short-lived forks. When validators are distributed in different locations around the world, finalizing a block in real life requires multiple round trips (PBFT is essentially a three-phase commit protocol in the optimistic case), so it takes a few seconds in the best case. The official documentation's explanation seems to imply that a block is typically finalized after 16 rounds of voting, with each round expected to last about 400 milliseconds; this means a finalization time of 6.4 seconds.
We can say that Tower Consensus, while officially a variant of PBFT, compares better to dPOS consensus protocols, which offer shorter block generation times at the expense of longer block finalization times.
Another interesting feature of Solana is that it is highly optimized to execute very simple predefined transactions that do not change account data, with the possible exception of account balances. This allows for massively parallel execution and verification of transactions. In this respect, Solana is similar to EOS’s predecessor BitShares, which uses dPOS (with short block generation times and long block finalization times) and is optimized for large-scale execution of very simple predefined transactions. Among other things, Solana is designed in such a way that verifying the correct order of transactions on a high-end GPU can be potentially a thousand times faster than the time required to generate those transactions. Ultimately, Solana claims to be able to execute up to 700,000 simple transactions per second (the actual number according to [11] is 65,000 rather than 700,000), provided they do not change account state and do not require much data, and only if all the data for all accounts fits in RAM. Again, this is very consistent with the promises made by BitShares [9] a few years ago. The main difference is that, in contrast to BitShares, Solana does provide support for transaction types that are not predefined by the blockchain software; to do this, a variant of a virtual machine called the Berkley Packet Filter is used, a precompiled version of which can be uploaded to the Solana blockchain and then referenced in transactions[12][13]. Solana is formally Turing complete, but the performance metrics commonly quoted only relate to very simple predefined transactions, and only apply if all data for all accounts fits into RAM, so we believe that the comparison with BitShares remains valid. In summary, Solana is a "third-generation blockchain project alternative" in the terms of 2.8.15 of the TON whitepaper[1], and is ultimately very similar to EOS[8]'s predecessor BitShares[9], but with further optimizations. It is formally Turing-complete, but in practice can only execute a large number of very simple transactions of a variety of predefined types, or a smaller number of more general transactions; it claims to be able to produce an average of more than one block per second, and to execute 700,000 simple transactions per second after future hardware upgrades (the actual number appears to be 65,000 rather than 700,000 [11]). It is an inherently non-scalable specialized single-blockchain project, and support for sharding or different workchains is not or cannot be provided without a complete redesign (we refer to 2.8.16 of the TON white paper [1] for an explanation of why such a redesign is very difficult). In this respect, it is comparable to EOS [8], which allows the instant deployment of any complex smart contract, offers a higher level of security due to the consensus mechanism with shorter transaction and block finality times, and perhaps most importantly, dynamic sharding. As the load increases, the latter will automatically expand the blockchain into more and more shard chains, thus providing scalability that is impossible with any single blockchain architecture (such as implemented in Solana).
Naturally, Solana’s predecessors, other single blockchain or loosely coupled multi-blockchain projects like EOS without sharding support, looked spectacular in the early stages but proved to be short-livedas these concepts inevitably hit limitations that negatively affected their scalability and stability in the later stages. Early signs of the Solana blockchain crash in September 2021[5] indicated that the blockchain was effectively stalled for 17 hours after an unexpected surge in transactions “caused a memory overflow, which caused many validators to crash, forcing the network to slow down and eventually stop,” according to an official document describing the outage. This raises questions about Solana’s future performance in real-world transactions, rather than specially crafted, very simple transactions involving only a small number of different accounts and executed in a very specific test environment with hundreds of powerful validation servers located in a single data center or in a few nearby data centers. TON appears to be more robust in this regard.
2.2 Metaphor: Solana is a Super Steam Locomotive
Solana is an interesting example of an old engineering approach pushed to its limits with well-known inherent limitations. As such, it reminds us of several similar stories in the history of technology that we would now like to connect.
One of these is, of course, the 20350 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 kilometres per hour. During regular passenger service it did not reach these average speeds, instead operating at 150 kilometres per hour. Yet at the time it held the world record for all locomotives, steam, diesel or electric. Nevertheless, this was a technological dead end, and all subsequent high-speed trains, like Japan's Shinkansen, France's TGV or Germany's ICE, are multi-unit electric trains. Interestingly, all modern high-speed trains are like this.
Multi-unit electric trains mean that there is one or even multiple engines in each carriage, as opposed to a conventional train pulled by a steam locomotive. We see the power of sharding. We see why it was clear even in 1938 that the future belonged to electric trains: electric engines could be easily scaled and distributed throughout the train, whereas steam engine technology could not be scaled in this way.
The second technological story that comes to mind is Intel's Pentium 4 CPUs in the early 2000s. Intel promised to gradually increase the clock frequency of these processors to 10 GHz and reached unprecedented performance levels. In practice, the Pentium 4 often ran actual code slower than the previous generation Pentium 3, with lower clock frequencies, and Intel was unable to deliver on the clock frequency increases it had initially promised after reaching the 4 GHz boundary. After that, Intel completely rethought its CPU development roadmap and essentially reverted to the Pentium 3 architecture (better known as Intel Xeon or Intel Core 2) with lower clock speeds, but with more and more CPU cores installed in one physical device. This approach proved to be more scalable and durable, and now we can buy a 64-core processor as needed. Similarly, an approach based on making one computing core faster and faster failed, and a multi-core approach (which can be likened to multi-unit trains and sharding in blockchains) proved to be viable.
The third technology story is that of supercomputers, such as Cray, which were popular in the 1970s and 1980s but were replaced by clusters of thousands of commodity CPUs (usually server versions of Intel and AMD CPUs). Today, the top 100 supercomputers are clusters of commodity CPUs. Once again, “sharding” or “multi-unit systems” triumphed over super-optimizations of single-unit systems.
We would like to end our exploration of technology history by comparing Solana to a super steam locomotive that exploits every possible technical optimization of an ancient technological paradigm but is ultimately unscalable and a technological dead end. We can praise and admire the ingenuity that went into designing and running these technological marvels; but they are still technological dead ends.
3. Ethereum 2.0
Comparing TON to Ethereum 2.0 is somewhat complicated, as the development and deployment of Ethereum 2.0 is still incomplete as of 2022. Let us describe what is known so far [6]-[7].
The transition to Ethereum 2.0 will take place in several stages. First, a new Beacon blockchain [6] will be deployed (which acts like the main chain in the terminology of the original TON white paper). This Beacon blockchain will use an original PoS consensus algorithm called Casper. Its main purpose is to register the state (the hash of the last block) of up to 64 shard chains (auxiliary blockchains). The proposed PoS algorithm is unusual in that it will involve and even require a large number of participating validators (at least 16,384), each of which stakes a small amount of ETH (32 ETH each). These validators are essentially regular Ethereum nodes, but with a stake of 32 ether. No specific communication between these nodes is required, aside from the usual Ethereum network issues related to block and mempool propagation. In this regard, Ethereum 2.0 seems unusually "democratic" (almost all other PoS blockchain projects are rather "oligarchy" with dozens or at most hundreds of validators participating in the actual creation of blocks at a given moment). However, this comes at a cost: block confirmation times appear to be around 10 to 15 minutes for both the Beacon blockchain and the 64 shard chains. In other words, one has to wait 10 to 15 minutes to be sure that their transaction has actually gone through. The second phase of the assumed transition will consist of converting the existing Ethereum 1.0 (PoW) blockchain to one of the 64 shard chains associated with the new Beacon blockchain (e.g., Shard Zero). Afterwards, the PoW consensus mechanism will be disabled and Ethereum will continue to be a PoS blockchain.
Finally, the third phase will involve the creation of 63 additional shard chains[7]. Ethereum will then consist of 64 shard chains, one of which will be the old Ethereum 1.0 blockchain, and a Beacon blockchain, which is the main chain primarily dedicated to staking, slashing (punishing misbehaving validators), reaching consensus, and registering shard chain hashes.
It is not clear at this stage what the exact functions of the new 63 shard chains will be, and how these shard chains will interact with each other. Without this information, we cannot really complete our comparison of multi-blockchain systems. But if messaging is introduced between shard chains, you will have to wait 10 to 15 minutes until the shard chain block from which the message was sent is finalized before you can process that message in another shard chain. This seems to be the reason why shard chain interactions are not currently considered. Furthermore, currently the additional shards should not be able to run EVM smart contracts at all (although there are some indications that this could be reconsidered in the future)[7]. Instead, they should be used as additional data storage in the distributed ledger. They will not be used to run arbitrary smart contracts; instead, their preferred use is to complete off-chain or layer 2 blockchain computations (similar to Bitcoin’s payment channels or the Lightning Network), perhaps similar to those previously proposed by the Plasma project (discussed in 2.9.10 of the original TON whitepaper). In this way, Ethereum 2.0 appears to completely avoid the issues of shard chain interactions, message passing between smart contracts residing in different shard chains, etc. Instead, future users of Ethereum are expected to run all of their transactions in unrelated sidechains and use Ethereum 2.0 shard chains to finalize the state of those sidechains. It is in this sense that Ethereum 2.0 claims to be able to scale to tens of thousands of transactions per second from the current 15 transactions per second. We believe this claim is misleading because there is a comparison of different types of transactions with different consistency and finality guarantees. The current 15 transactions per second are the usual on-chain Turing-complete EVM smart contract execution; the tens of thousands of "transactions" promised in the near future are completely different, likely very specialized transactions with a limited number of participants that become generally visible only after they have been generated. One can also compare this to the performance of Bitcoin with and without the Lightning Network.
However, in this context, one should also be allowed to refer to the TON Blockchain, including "transactions" within all possible payment channels and payment networks that are bound to smart contracts residing in the TON Blockchain shard chains. So, if we accept that Ethereum 2.0 is capable of executing tens of thousands of "transactions" per second (actually referring to sidechain and payment channel transactions), then by this definition, TON will be able to execute billions of such "transactions" per second.
In summary, Ethereum 2.0 appears to sidestep the truly complex shard chain interaction problem, which cannot be solved without completely rethinking the EVM and smart contract interaction model (we refer to section 2.8.16 of the original TON whitepaper [1] for more details), and augmenting the original Ethereum blockchain with 63 additional shard chains (10-15 minutes finalization time) used only to store the final state of sidechains and payment channels [7]. This is a somewhat defeatist approach, as one would expect more ambitious things from the world’s second oldest core blockchain project, which was the first to introduce Turing-complete smart contracts!
In its currently conceived and tested form, Ethereum 2.0 does not aim to reach the levels of speed and versatility already achieved by the existing TON implementation.
4. Conclusion
The TON blockchain was originally conceived and described in 2017. Its white paper [1] carefully explains why the design choices made by TON seemed necessary to build a truly scalable blockchain project that could handle millions of transactions per second without any future changes involving its smart contract logic and their interactions. This is why TON was chosen as the only fifth-generation blockchain project at the time. Since then, new blockchain projects have continued to emerge. One would expect them to overcome the limitations of all the older blockchain projects discussed in the TON white paper and perhaps propose some new approaches to blockchain development. Instead, we see the re-emergence of blockchains based on ideas that were outdated even in 2017. For example, Solana, designed from 2019, is an alternative to an inherently non-scalable “third-generation blockchain project” in the terms of the TON white paper, similar in type to the 2013 BitShares project, the predecessor to EOS. If readers are frustrated by the repeated comparisons of Solana to a seemingly obscure project from 2013 that claimed to offer similar performance, it’s probably for good reason: if we could use the past to some extent to predict the future, we might predict that Solana would be similarly struggling nine years after its founding (i.e., in 2028). Moreover, adding sharding to Solana later on to overcome its inherent non-scalability would be nearly impossible for the reasons explained in the original TON whitepaper. Another blockchain proposal that has disappointed us is Ethereum 2.0, which essentially undoes Ethereum’s main achievement: Turing-complete smart contracts, and claims that they aren’t particularly useful after all. Ethereum 2.0, on the other hand, illustrates well the general principle mentioned above in relation to Solana: Sharding and scalability cannot be retrofitted into a blockchain project that was originally designed without taking these issues into account.
As of 2022, the TON blockchain remains one of the few truly scalable blockchain projects. As such, it remains a state-of-the-art blockchain project ("fifth generation" in the original whitepaper), capable of executing millions of transactions per second and, if necessary in the future, tens of millions of true Turing-complete smart contract transactions per second with only minor internal changes. Five years since its inception, it remains at the forefront of general blockchain technology. The high performance of various testnets and mainnets since 2017, based on implementations of TON technology developed over the past few years, further validates the efficiency of the architectural approach proposed in the TON whitepaper.
References
[1] TON Whitepaper, available online at https://ton-blockchain.github.io/docs/ton.pdf
[2] Solana: A New Architecture for High-Performance Blockchain v0.8.13, https:// solana.com/solana-whitepaper.pdf
[3] Tower BFT: Solana’s High-Performance Implementation of PBFT, 17.07.2019, https://medium.com/solana-labs/tower-bft-solanas-high-performance-implementation-of-pbft-464725911e79
[4] 8 Innovations That Make Solana the First Web [5] Explained: How a system outage disrupted Solana’s massive activity, https://www.cnbctv18.com/cryptocurrency/solana-sol-token-solana-outage-cryptocurrency-10822571.htm
[6] The Beacon Chain Ethereum 2.0 Explainer You Need to Read First, https://ethos.dev/beacon-chain
[7] Ethereum Upgrade: Sharding Chain, https://ethereum.org/en/roadmap/danksharding/
[8] EOS.IO Technical White Paper, https://gith [9] S. Larimer, The History of BitShares, 2013, https://docs.bitshares.org/bitshares/history.html [10] M. Castro, B. Liskov, et al., Practical Byzantine Fault Tolerance, in Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173. http://pmg.csail.mit.edu/papers/osdi99.pdf
[11] Crtomir Ipavec, Solana, https://medium.com/crypto-articles-randomly/solana-9c432a1b84a8
[12] https://docs.solana.com/developing /on-chain-programs/
[13] https://docs.solana.com/developing/programming-model/
Jasper
Jixu
Hui Xin
Aaron
Davin