Summary
Since the initial release of the TON whitepaper in 2017, many new blockchain projects have emerged, such as Solana and Ethereum 2.0. In this article, we compare TON with some representative blockchain projects.
1. Comparison Format
We compare blockchain projects based on the categorization in sections 2.8 and 2.9 of the TON whitepaper.
1.1 Comparison Criteria
We classify blockchain projects based on the following criteria, which are explained in more detail in section 2.8 of the TON whitepaper:
– Single-chain/multi-chain projects
– Consensus algorithm: PoW (Proof-of-Work)/PoS (Proof-of-Stake)
– For PoS projects, the precise consensus algorithm (e.g., dPOS or BFT)
For multi-chain projects that support arbitrary (Turing-complete) smart contracts, we must consider further questions:
1> Type and rules of member chains: homogeneous, heterogeneous, hybrid
2> Existence of a main chain
3> Native support for sharding, static and dynamic sharding
4> Interactions between blockchains: loosely coupled/tightly coupled
In addition, simplified classification of blockchain projects is introduced in section 2.8.15 of the TON whitepaper, and a table with basic attributes of the most popular blockchain projects is provided at the beginning of section 2.9.
2. Solana
2.1 Overview of Solana
Solana is an interesting project in the 2020s: it is a single-chain project optimized for extremely fast execution of specialized transactions. In this regard, it is similar to the predecessor of EOS called BitShares, which was developed from 2013 to 2014. However, Solana uses a PBFT variant called Tower Consensus instead of dPOS. Solana claims to generate one block per second or even faster. However, this comes at a cost, as the next block is generated before the previous block is completed, which may result in transient forks. The process of completing a block requires multiple round trips in real life when validators are distributed across different locations worldwide, so the best-case scenario takes several seconds. According to the official documentation, a block is typically finalized after 16 rounds of voting, with each round lasting about 400 milliseconds. This means a completion time of 6.4 seconds.
We can say that Tower Consensus, although formally a variant of PBFT, is better than the dPOS consensus protocol in terms of shorter block generation time, but at the expense of longer block completion time. Another interesting feature of Solana is that it is highly optimized for executing very simple predefined transactions that do not change account data, except possibly the account balance. This allows for massive parallel execution and verification of transactions. In this regard, Solana is similar to the predecessor of EOS called BitShares, which was optimized for the massive execution of very simple predefined transactions using dPOS with short block generation time and long block completion time. Additionally, Solana is designed in a way that the speed of verifying transaction order on high-end GPUs can be thousands of times faster than the time required to generate those transactions. Ultimately, Solana claims to be able to execute as many as 700,000 simple transactions per second (the actual number seems to be 65,000 instead of 700,000), assuming they do not change the account state and do not require too much data, and only if all data of all accounts fit into RAM. This is consistent with the promises made by BitShares several years ago. The main difference is that, compared to BitShares, Solana does provide support for transaction types not predefined by blockchain software. It uses a variant of the Berkeley Packet Filter virtual machine, whose precompiled programs can be uploaded to the Solana blockchain and then referenced in transactions. Although Solana is technically Turing-complete, the performance metrics typically cited are related only to very simple predefined transactions and only apply when all data of all accounts fit into RAM. Therefore, we believe the comparison with BitShares is still valid.
In summary, Solana is the “alternative proposal for a third-generation blockchain project” mentioned in section 2.8.15 of the TON whitepaper, and it is very similar to the predecessor of EOS called BitShares, but with further optimizations. It is technically Turing-complete but can only execute a large number of very simple predefined transactions or a smaller number of more general transactions. It claims to generate more than one block per second on average and to be able to execute 700,000 simple transactions per second after future hardware upgrades (the actual number seems to be 65,000 instead of 700,000). It is inherently non-scalable as a specialized single-chain project and does not provide or cannot provide support for sharding or different workchains without a complete redesign (as explained in section 2.8.16 of the TON whitepaper). In this regard, compared to EOS, TON allows for instant deployment of any complex smart contract, has shorter transaction and block finalization times due to its consensus mechanism, and most importantly, offers dynamic sharding, providing a higher level of security. With increasing load, the latter automatically scales the blockchain into more and more shard chains, offering scalability that is impossible with any single-chain architecture, such as what is implemented in Solana.
Naturally, predecessors of Solana, other single-chain or loosely coupled multi-chain projects such as EOS, which do not have sharding support, may appear impressive in the early stages but ultimately prove to be transient, as these concepts inevitably clash with limitations that negatively impact their scalability and stability in later stages. Early signs of the Solana blockchain crashing in September 2021 [5], where it “stalled for 17 hours after transaction volumes spiked, causing memory exhaustion,” as described in the official document, raise questions about its future performance in real-world transactions instead of specialized very simple transactions involving a small number of different accounts and executed in very specific test environments with hundreds of powerful validating servers located in one or a few data centers nearby. TON seems to be more robust in this regard.
2.2 Metaphor: Solana is a Super Steam Locomotive
Solana is an interesting example that demonstrates an old engineering approach taken to its extreme with all possible technological optimizations, despite its inherent limitations. Therefore, it reminds us of several similar stories in the history of technology that we now want to connect.
One of them is, of course, the world record set by the British LNER A4 4468 Mallard steam locomotive in 1938, reaching a speed of 203 km/h. During regular passenger service, it did not achieve these average speeds but ran at a speed of 150 km/h. Nevertheless, it held the world record for all locomotives, steam, diesel, or electric, at that time. However, it was a technological dead end, and all subsequent high-speed trains, such as Japan’s Shinkansen, France’s TGV, or Germany’s ICE, are multiple-unit electric trains. Interestingly, all modern high-speed trains are like this.
Multiple-unit electric trains mean that there is an engine or even multiple engines in each car, instead of a traditional train pulled by a steam locomotive. We see the power of sharding. We see why even in 1938, it was clear that the future belongs to electric trains: electric engines can be easily scaled and distributed throughout the train, while steam engine technology cannot be scaled in this way.
The second technological story that comes to mind is Intel’s Pentium 4 CPU in the early 2000s. Intel promised to gradually increase the clock frequency of these processors to 10 GHz within a few years, reaching unprecedented levels of performance. In practice, the Pentium 4 often ran actual code slower than the previous generation Pentium 3, with lower clock frequencies, and Intel could not achieve the initially promised clock frequency growth after reaching the 4 GHz limit. After that, Intel completely reconsidered its CPU development roadmap and essentially reverted to the Pentium 3 architecture with lower clock speeds (renamed as Intel Xeon or Intel Core 2) but with an increasing number of CPU cores installed in a physical device. This approach proved to be more scalable and durable, and now we can buy 64-core processors as needed. Similarly, the approach of making a single computing core faster and faster failed, and the multi-core approach (which can be compared to multiple-unit trains and sharding in blockchains) proved to be feasible.
The third technological story is the story of supercomputers, such as Cray, which were popular in the 1970s and 1980s but were later replaced by clusters composed of thousands of commercial CPUs (usually server versions of Intel and AMD CPUs). Today, the top 100 supercomputers are all commercial CPU clusters. Once again, “sharding” or “multi-unit systems” triumphed over single-unit systems with super optimizations.
We want to end our exploration of technological history by comparing Solana to a super steam locomotive, which utilizes all possible technological optimizations based on an ancient paradigm but ultimately becomes non-scalable and a technological dead end. We can admire and appreciate the ingenuity employed in designing and operating these technological wonders.Comparing TON with Ethereum 2.0 is somewhat complicated because as of 2022, the development and deployment of Ethereum 2.0 are still incomplete. Let’s describe the current known situation.
The transition to Ethereum 2.0 will be conducted in several stages. First, a new Beacon blockchain will be deployed, which serves a similar function to the main chain in the original TON whitepaper. This Beacon blockchain will employ a consensus algorithm called Casper, which is a proof-of-stake (PoS) algorithm. Its main purpose is to register the state of up to 64 shard chains (auxiliary blockchains) by their last block hash. The unique aspect of the recommended PoS algorithm is that it involves a large number of validators (at least 16,384), each staking a small amount of ETH (32 ETH per validator). These validators are essentially regular Ethereum nodes, but with a stake of 32 ether. Apart from common Ethereum network issues related to block and mempool propagation, there is no specific communication required between these nodes. In this regard, Ethereum 2.0 seems unusually “democratic” (most other PoS blockchain projects are fairly “oligarchic” with dozens or at most a few hundred validators participating in the actual creation of blocks at any given moment). However, this comes at a cost: both the Beacon blockchain and the 64 shard chains seem to have block confirmation times of around 10 to 15 minutes. In other words, one would have to wait 10 to 15 minutes to ensure that their transaction has indeed been finalized.
Assuming the second stage of the transition, it will involve converting the existing Ethereum 1.0 (PoW) blockchain into one of the 64 shard chains associated with the new Beacon blockchain (e.g., shard zero). Subsequently, the PoW consensus mechanism will be disabled, and Ethereum will continue as a PoS blockchain.
Finally, the third stage will involve the creation of 63 additional shard chains. This way, Ethereum will consist of 64 shard chains, one of which will be the old Ethereum 1.0 blockchain, and one will be the Beacon blockchain, which is primarily dedicated to staking, slashing (penalizing misbehaving validators), achieving consensus, and registering shard chain hash values.
At present, it is unclear what the exact functionality of the new 63 shard chains will be and how these shard chains will interact with each other. Without this information, a true comparison of the multi-chain systems cannot be made.
However, if message passing between shard chains is introduced, one would have to wait 10 to 15 minutes until the issuing shard chain block is finally determined, before the message can be processed in another shard chain. This seems to be the reason why shard chain interaction is not currently considered. Additionally, the additional shard chains should not be able to run EVM smart contracts at all (although there are some indications that this may be reconsidered in the future). Instead, they should serve as additional data storage in the distributed ledger. They will not be used for running arbitrary smart contracts; instead, their preferred use case is to perform off-chain or layer 2 blockchain computations (similar to Bitcoin’s payment channels or Lightning Network), possibly similar to those proposed earlier by the Plasma project (discussed in section 2.9.10 of the original TON whitepaper).
In this way, Ethereum 2.0 seems to completely avoid the inherently complex issues of shard chain interaction and message passing between smart contracts residing in different shard chains. Instead, future users of Ethereum are expected to run all their transactions in unrelated side chains and use Ethereum 2.0’s shard chains to finalize the state of these side chains. It is in this sense that Ethereum 2.0 claims to be able to scale from the current 15 transactions per second to tens of thousands of transactions per second. We consider this claim to be misleading since there are different types of transactions with different consistency and finality guarantees. The current 15 transactions per second are typical on-chain Turing-complete EVM smart contract executions; the promised tens of thousands of “transactions” in the near future are completely different and may be highly specialized transactions with a limited number of participants and only becoming generally visible after they have occurred. One may also compare this to the performance of Bitcoin with and without the use of the Lightning Network.
However, in this case, it should also be possible to refer to the TON blockchain, including all possible payment channels and “transactions” within payment networks bound to smart contracts residing in TON blockchain shard chains. Therefore, if we accept the claim that Ethereum 2.0 can execute tens of thousands of “transactions” per second (referring to sidechain and payment channel transactions), then, by this definition, TON would be capable of executing billions of such “transactions” per second.
In conclusion, Ethereum 2.0 seems to avoid the truly complex issues of shard chain interaction unless the EVM and smart contract interaction models are completely rethought (for more information, refer to section 2.8.16 of the original TON whitepaper) and expands the original Ethereum blockchain with 63 additional shard chains (with completion times of 10-15 minutes) only for storing the final state of side chains and payment channels. This is a somewhat defeatist approach, and one would expect more ambitious goals from the world’s second oldest core blockchain project that was the first to introduce Turing-complete smart contracts!
In its current envisioned and tested form, the goal of Ethereum 2.0 is not to reach the speed and versatility levels that the existing TON implementation has already achieved.
TON blockchain was initially conceived and described in 2017. Its whitepaper 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 in the future without any essential 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 emerged. One would expect them to overcome all the limitations of the old blockchain projects discussed in the TON whitepaper and possibly propose new approaches to blockchain development. Instead, we see the re-emergence of blockchains based on ideas that were already outdated even in 2017. For example, Solana, designed since 2019, is, in terms of the TON whitepaper, an essentially unscalable “third-generation blockchain project” alternative to the 2013 BitShares project, a precursor to EOS. It may be quite frustrating to repeatedly compare Solana with a seemingly insignificant project from 2013 that claimed to offer similar performance, but there may be good reasons for that: if we can predict the future to some extent based on the past, we might predict that Solana will face similar challenges nine years after its founding (i.e., in 2028). Furthermore, due to the reasons explained in the original TON whitepaper, it is almost impossible to add sharding to Solana later to overcome its inherent unscalability. Another disappointing blockchain solution is Ethereum 2.0, which essentially negates one of Ethereum’s main achievements: Turing-complete smart contracts and claims that they are not particularly useful after all. On the other hand, Ethereum 2.0 nicely exemplifies the general principle mentioned above in relation to Solana: without considering these issues, it is impossible to retrofit sharding and scalability into an initially designed blockchain project.
As of 2022, the TON blockchain remains one of the few truly scalable blockchain projects. Therefore, it is still the most advanced blockchain project (the “fifth-generation” in the original whitepaper) capable of executing millions of transactions per second and, if necessary, executing tens of millions of true Turing-complete smart contract transactions per second with only minor internal changes. Over the five years since its inception, it has remained at the forefront of general-purpose blockchain technology.
Since 2017, the implementation of TON technology based on the past few years’ development has further validated the efficiency of the architectural approach proposed in the TON whitepaper through various testnets and mainnets.
References:
[1] TON Whitepaper, available online at https://ton-blockchain.github.io/docs/ton.pdf
[2] Solana: Architecture for a high-performance blockchain v0.8.13, https://solana.com/solana-whitepaper.pdf
[3] Tower BFT: Solana’s high-performance implementation of PBFT, Jul 17, 2019, https://medium.com/solana-labs/tower-bft-solanas-high-performance-implementation-of-pbft-464725911e79
[4] 8 Innovations that make Solana the first web-scale blockchain, https://solana.com/news/8-innovations-that-make-solana-the-first-web-scale-blockchain
[5] Explained: How system outage disrupted Solana’s high-profile activity, https://www.cnbctv18.com/cryptocurrency/solana-sol-token-solana-outage-cryptocurrency-10822571.htm
[6] The Beacon Chain Explained, a must-read for Ethereum 2.0, https://ethos.dev/beacon-chain
[7] Ethereum Upgrades: Shard Chains, https://ethereum.org/en/roadmap/danksharding/
[8] EOS.IO Technical Whitepaper, https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
[9] S. Larimer, History of BitShares, 2013, https://docs.bitshares.org/bitshares/history.html
[10] M. Castro, B. Liskov, et al., Practical Byzantine Fault Tolerance, 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/
