The difference of blockchains

In this chapter, we will examine the key differences between the Ethereum blockchain compared to the TON blockchain. The analysis will include an overview of the network architectures, highlight their unique features, and evaluate the advantages and disadvantages of each.

Starting with an overview of the Ethereum and TON ecosystems, we can note that both platforms offer a similar structure of participants and services, including users who hold assets and make transactions, validators who keep the network up and running and secure, and application developers who use the blockchain as the basis for their products and services. Both ecosystems include both custodial and non-custodial services that provide users with different levels of control over their assets.

Additionally, it is worth highlighting that both platforms facilitate the creation of decentralized applications (DApps), offering developers powerful tools and standards for development.

However, despite the similarities in overall structure and features offered, the key technological aspects and network design approaches of Ethereum and TON differ significantly. These differences lay the foundation for a thorough understanding of the unique advantages and limitations of each platform, which is particularly important for developers seeking to maximize the capabilities of each network. In the following subsections, we will explore these differences in more detail, focusing on the network architecture, models, transaction mechanisms, and transaction settlement system to provide developers with the insights they need.

Blockchains architecture

Ethereum, by inheriting and extending the foundational principles of Bitcoin, has provided developers with the flexibility needed to create complex decentralized applications (DApps). A unique feature of Ethereum is its ability to provide each account with an individualized data store, allowing transactions to not only perform token transfers, but also to change the state of the blockchain by interacting with smart contracts. This ability to synchronously interact between accounts, as we know, offers great promise for application development, but also raises the issue of scalability. Each transaction on the Ethereum network requires nodes to update and maintain the full state of the blockchain, which leads to significant latency and increases the cost of gas as network utilization increases.

In response to these challenges, TON offers an alternative approach aimed at improving scalability and performance. Designed with the ambition to provide developers with maximum flexibility to create a variety of applications, TON uses the concept of shards and masterchain to optimize the block creation process. In each TON shardchain and masterchain, a new block is generated on average every 5 seconds, ensuring fast transaction execution. Unlike Ethereum, where state updates are synchronous, TON implements asynchronous messaging between smart contracts, allowing each transaction to be processed independently and in parallel, significantly speeding up transaction processing on the network. Sections and articles to familiarize yourself with:

• Shards
• Comparison of Blockchains document
• Comparison of Blockchains table (much less informative than the document, but more visual)

In conclusion, by comparing the architecture and technological underpinnings of TON and Ethereum, it is clear that TON offers significant advantages. With its innovative approach to asynchronous transaction processing and unique shard and masterchain architecture, TON demonstrates the potential to support millions of transactions per second without compromising security or centralization. This provides the platform with outstanding flexibility and efficiency, making it ideal for a wide range of applications.

Account-based model (Ethereum) vs Actor model (TON)

In the first subsection, we made a comparison between Ethereum and TON, highlighting their key architectural differences and the main challenges faced by Ethereum. Of particular note are the different approaches to organizing interactions in these blockchains and using models. These differences come from the unique architectural choices of each platform. For developers accustomed to Ethereum, it is important to deeply understand these differences in order to effectively transition to developing on TON. This understanding will allow the architecture to adapt and optimize the interaction of smart contracts in the new environment.

So, let's remember how the account-based model works in Ethereum. Ethereum uses this model to track balances. Like a bank account, funds are stored in accounts rather than in individual coins. There are two types of accounts:

• Externally-owned accounts (EOAs) - externally managed accounts are controlled by the user using public and private key pairs. The public key allows others to send payments to the account.
• Contract accounts - are controlled by smart contract code rather than private keys. Because they do not have a private key, contract accounts cannot initiate transactions on their own.

When an Ethereum user creates a wallet, an external account is added to the global state on all nodes in the decentralized network when the first transaction is invoked or the first funds are received. Deploying a smart contract creates a contract account capable of storing and distributing funds programmatically based on certain conditions. All account types have balances, storage, and can trigger transactions by calling functions in other accounts. This structure provides Ethereum's ability to serve as programmable money.

Ethereum has synchronous transaction processing, where each transaction is processed sequentially, in strict order. This ensures that the state of the blockchain always remains consistent and predictable for all participants in the network. All transactions are atomic, it either fully completes successfully or fully completes unsuccessfully, without any partial or incomplete execution. Moreover, when a smart contract is invoked and it in turn invokes another smart contract, the invocation is instantaneous within the same transaction. But here again there are disadvantages, a transaction can grow as much as it is allowed to grow. A negative effect of synchronicity is still overloading, as computations cannot run in parallel. The number of contracts and users grows and the inability to parallelize computations becomes a major limiting factor in the growth of the network.

Now let's understand what is actor model? Actor model is an approach to parallel and distributed computing where the main element is an actor - an independent executable block of code. Originally developed for cluster computing, this model is widely used in micro-server architectures to meet the needs of modern distributed systems due to its ability to scale, parallelism and fault tolerance. Actors receive and process messages, depending on the logic of the message, respond by accepting local changes or performing actions in response, can create other actors or send messages onward. They are thread-safe and reentrant, eliminating the need for locks and simplifying parallel processing of tasks. This model is ideal for building scalable and reliable server solutions, providing efficient concurrent access control and support for both synchronous and asynchronous messaging.

In TON, everything is represented by smart contracts, which can also be called actor in the context of actor model. A smart contract is an object with properties such as address, code, data and balance. It has the ability to store data and behaves according to instructions received from other smart contracts. After a contract receives a message and processes it by executing its code in the TVM, various scenarios can occur:

• The contract changes its properties code, data, balance
• The contract optionally generates an outgoing message
• The contract goes into standby mode until the following event occurs

The result of scripts is always the creation of a transaction. The transactions themselves are asynchronous, meaning that the system can continue processing other transactions while waiting for past transactions to complete. This provides more flexibility when processing complex transactions. Sometimes a single transaction may require multiple smart contract calls to be executed in a specific sequence. Because these calls are asynchronous, developers can more easily design and implement complex transaction flows that may involve multiple concurrent operations. A developer coming from Ethereum needs to realize that smart contracts in the TON blockchain can only communicate with each other by sending asynchronous messages, which means that if there is a need to request data from another contract and an immediate response is required, this will not be possible. Instead get methods must be called by clients outside the network, much like a wallet in Ethereum uses RPC nodes such as Infura to request smart contract states. This is an important limitation for several reasons. For example, flash loans are transactions that must be executed within a single block, relying on the ability to borrow and repay in the same transaction. This is facilitated by the synchronous nature of Ethereum's EVM, but in TON, the asynchronous nature of all transactions makes executing a flash loan infeasible. Also Oracles, which provide smart contracts with external data, involve a more intricate design process in TON. What Oracles are and how to use them in TON can be found here.

The difference of wallets

We have already discussed that in Ethereum, a user's wallet is generated based on their address, which is in a 1-to-1 relationship with their public key. But in TON, all wallets are smart contracts that must be deployed by the user himself. Since smart contracts can be configured in different ways and have different features, there are several versions of wallets, which you can read about here. Due to the fact that wallets are smart contracts, a user can have multiple wallets with different addresses and initial parameters. To send a transaction, the user must sign the message with his private key and send it to his wallet contract, which in turn forwards it to the smart contract of a particular DApp application. This approach greatly increases flexibility in wallet design and developers can add new versions of the wallet in the future. In Ethereum at the moment developers are actively using multi-sig wallets (smart contracts) like gnosis and are just starting to introduce so-called `account-abstractions' like ERC-4337, where wallets will be filled with such functionality as sending transactions without a native token, account recovery, after its loss, etc., but it's worth noting, wallet accounts are much more expensive to use in terms of gas fees compared to EOA in Ethereum.

Messages and Transactions

What happens between two contracts is called a message - a small number of tokens and arbitrary data are sent to a specified address. When the message arrives at the contract, it is processed by the contract code, the contract updates its state and optionally sends a new message. All these actions on the contract are recorded as transactions. Let's imagine an example, we have a chain of messages, from contract A to contract B, from contract B, to contract C, then we will have two messages and three transactions. But initially, to change the state of the blockchain, you need an outside signal. To invoke a smart contract, you need to send an external message that goes to the validators and they apply it to the smart contract. And we already discussed in the last subsection that a wallet is a smart contract, so this external message usually first goes to the wallet's smart contract, which records them as the first transaction and that first transaction usually contains an embedded message for the actual destination contract. When the wallet smart contract receives the message, it processes it and delivers it to the destination contract (in our example, contract A could be a wallet and when it receives the external message, it will have the first transaction). The sequence of transactions forms a chain. So you can see that each smart contract has its own transactions, which means that each contract has its own little blockchain (you can read more about it here), so the network can process the transactions due to this completely independent of each other

The difference of Gas system

In Ethereum, the cost of a transaction is measured in gas, which reflects the amount of computing resources required for the transaction. The gas cost is divided into a base fee set by the protocol and a priority fee that the user adds to speed up transaction processing by validators. The total fee will be = units of gas used * (base fee + priority fee). Additionally, storage in Ethereum is essentially free, meaning that once data is stored on the blockchain, there is no ongoing cost for keeping it there.

In TON, the calculation of transaction fees is complex and includes several types of fees: for storing smart contracts in the blockchain, for importing messages into the blockchain, for executing code on a virtual machine, for processing actions after code execution, and for sending messages outside the TON blockchain. The price of gas and some other parameters can be changed by voting on the main network. Unlike Ethereum, TON users cannot set the gas price themselves. Also, the developer needs to return the remaining gas funds to the owner manually, otherwise they will remain locked. The use of smart contract storage also affects the price: if a wallet's smart contract has not been used for a long time, the next transaction will cost more.