Sharing of smart contracts in the TON blockchain
The main goal of TON is to make blockchain more accessible to the general population. According to Ethereum statistics, several million people worldwide have tried blockchains. Even if we assume 50 million users, that would be a generous estimate. The challenge is how to increase this number to 1 billion. At its peak, the current version of Ethereum can handle about 1 million transactions per day. In contrast, in 2016, Telegram processed 15 billion messages per day. The large volume of data handled by Telegram influenced the architectural decisions behind the design of the TON blockchain. Achieving a 10,000-fold increase in the system’s scalability cannot be accomplished by simple protocol improvements but requires radical changes in approach.
Sharding concept
Sharding is a mature concept that emerged in the world of databases. Roughly speaking, sharding allows you to horizontally scale data by dividing it into independent chunks and distributing them across “shards”. This is the key to transforming the world from simple to big data. When data becomes too large to be processed using standard methods, there is no way to work with it except to split it into parts.
TON was one of many who used sharding in blockchains. Ethereum 2.0 supports a fixed number of shards — up to 64. TON’s approach is radically different, not just because the number of shards is more significant. It is conceptually different:
The number of shards is not fixed — TON supports adding as many shards as needed at the moment, with an upper limit of 2⁶⁰ (for each workchain). This number is practically unlimited. It is enough for everyone on Earth to have ~100 million shards.
The number of shards is dynamic. TON supports automatically splitting a shard chain into two when the load is too high and merging them into one when it drops. This is the only way to deal with dynamically changing network requirements when predicting the load in advance is impossible.
Attempts to fundamentally change the world are rarely in vain. For this radical approach to work, smart contract developers must “design” smart contracts differently. The TON architecture may seem quite alien if you have experience with smart contracts in other blockchains. In this case, I recommend reading the article to ease the transition.
Sharding smart contracts in TON
The basic atomic unit in the TON blockchain is a smart contract instance. A smart contract instance has an address, a code, and data cells (persistent storage or state). We call it an atomic unit because it has synchronous atomic access to its state.
However, communication between smart contract instances in TON is neither synchronous nor atomic. It is best to think of smart contracts in TON as microservices. Each microservice has access ONLY to its local data. Communication between microservices involves sending asynchronous messages over the network.
As every architect knows, large systems are beginning to require a transition from a monolithic to a microservice architecture. Using such a distributed approach requires effort, but it opens up several opportunities in return. A modern approach to scaling relies on an orchestrator (like Kubernetes) to group containerized microservices and launch new instances automatically (autoscaling), effectively distributing them across available machines.
I like the analogy with Kubernetes because TON does the same thing. As the load on a particular shard chain increases, it splits into two. But since the smart contract instances are atomic, they are never separated. This means that smart contracts, once on the same shard chain, can end up on different shard chains simultaneously.
The TON Virtual Machine (TVM) roughly applies the concept of distributed microservices to the Ethereum monolith (EVM).
Designing Smart Contracts for Sharding
A popular question among new system architects is: “How big should microservices be?” — or in other words: “When is a microservice too “monolithic” that it’s time to split it into two?”.
There is no clear answer to this question. It’s an art. The idea is to assist Kubernetes in its task. The smaller the microservice, the easier Kubernetes can optimize the system by initializing new instances and moving resources as needed. On the other hand, the smaller they are, the harder it is for the developer to implement complex mechanisms since the interaction becomes too asynchronous.
I noticed that the same thing works for sharding smart contracts in TON. The idea is to assist TON’s auto-sharding in its task — dividing data across multiple smart contracts to move it to other shard chains efficiently when the load increases. But if you shard too much, you’ll have to deal with the complexity caused by increased asynchrony.
Feel free to drop a “Hi” at Pharos Production, where we bring software to life! 👋✨
“Join our exciting journey with Ludo — the reputation system of the Web3 world! 🌍✨”
