A comparative analysis of distributed ledger technologies: TON vs. EVM-based blockchains

Introduction

Distributed ledger technologies have revolutionised the way transactions are conducted and recorded. They provide secure, transparent, and decentralised substrates for various applications, ranging from financial transactions to data management and supply chain tracking. As a result, numerous blockchain platforms have emerged, each with its unique features and offerings.

In the previous research, we compared Hedera and Polygon, one of the most widely-used blockchain platforms. This paper focuses on two such platforms: TON (The Open Network) and Ethereum (as the main EVM-based blockchain).

TON is a blockchain platform originally developed by the team behind the popular messaging app Telegram. TON was designed with the goal of providing a scalable and efficient infrastructure for decentralised applications, payments, and communication. It features a multi-layered architecture that includes masterchains, workchains, and shardchains, as well as a custom networking protocol (Catchain) for rapid and secure message propagation.

EVM (Ethereum Virtual Machine)-based blockchains, primarily Ethereum, are among the most widely-used platforms for creating and deploying decentralised applications (dApps) and smart contracts. Ethereum is a pioneer in the blockchain space, introducing the concept of programmable smart contracts that can execute autonomously when specific conditions are met. Its single-chain architecture with EVM has become the foundation for numerous dApps and spawned various other blockchain platforms that utilise the EVM execution layer, becoming an industry standard at scale.

In this paper, our blockchain team conducts a comparative analysis of TON and Ethereum as the first and the main EVM-based blockchain by examining their architecture, networking protocols, consensus mechanisms, virtual machines (TVM vs EVM), smart-contract writing and other significant topics. The aim is to provide an in-depth understanding of their similarities and differences, and to highlight the unique features and advantages each platform offers.

High level comparison

In the emerging DLT world, Ethereum and TON became both powerful and promising blockchain platforms, each with its own unique features and advantages. The brief comparison between them is shown in Table 1.

Table 1 – High level comparative analysis of Ethereum and TON [1]

 

Block Creation and Finalization Time

Transaction speeds, such as block creation and finalisation time, are crucial for consumer products as they determine the wait time for money transfers and smart contract execution. The quicker blocks are produced, the shorter the wait time for users.

TON creates a new block on each shardchain and the masterchain approximately every 5 seconds. All shardchain blocks are generated almost simultaneously, while the masterchain block is created about a second later, as it must contain the hashes of the latest shardchain blocks.

Ethereum utilises slots and epochs. A 12-second slot allows a new Beacon Chain and shard chain block to be proposed by a validator. An epoch consists of 32 slots (6.4 minutes). Specific rules state that block finality requires a minimum of 2 epochs, leading to a time-to-finality of at least 12.8 minutes [2].

Performance

Blockchain performance is a measure of the platform’s ability to process smart contracts at scale, essential for more complex blockchain products such as DeFi, GameFi, and DAOs.

TON is a high-performance, Turing-complete blockchain that can handle any transaction complexity on its masterchain and all workchains.

After the Ethereum 2.0 upgrade is completed, there will be a massive jump in performance. It is claimed to be able to perform up to 100000 transactions per second, the real performance being unclear at the moment though [3].

Scalability

Scalability directly relates to the number of users and their interactions, such as transactions, smart contract execution, and infrastructure requests.

TON offers workchains and dynamic sharding, potentially accommodating up to 232 workchains, each capable of being divided into up to 260 shardchains. This allows for near-instant cross-shard and cross-chain communication and millions of transactions per second.

Ethereum will support up to 64 shardchains and the Beacon Chain. At this stage, it is unclear what the exact capabilities of the new 64 shardchains will be and how the shardchains will interact with one another. Furthermore, the additional shards are currently not supposed to be able to run EVM smart contracts at all [4]. Instead, they are supposed to be used as additional data storage in a distributed ledger.

However, Ethereum has many Layer 2 solutions that also solves this problem.

Conclusion

In summary, TON and Ethereum differ significantly in block creation and finalisation time, performance, and scalability. TON produces new blocks every 5 seconds, allowing for quicker transactions, while Ethereum’s current time-to-finality is at least 12.8 minutes. Scalability-wise, TON offers workchains and dynamic sharding, enabling near-instant communication and millions of transactions per second. Ethereum 2.0 will support 64 shardchains and the Beacon Chain, but their exact capabilities and interaction with one another are not clear for now. Although Ethereum’s shardchains are not intended to run EVM smart contracts, Layer 2 (such as Arbitrum, Polygon, Optimism) solutions provide additional scalability to the network.

Quick overview of Ethereum 2.0 roadmap

Ethereum upgrade is a very complex process that improves the blockchain in almost all aspects. The upgrade process was divided into stages. In this document there will be details and mentions of this upgrade, so in this section we try to make a brief overview of each upcoming ETH2 stage.

Figure 1 – Ethereum 2.0 roadmap [5]

The Surge

This phase focuses on improving scalability and privacy by implementing EIP-4844, which enables a new transaction format for Ethereum, supporting Rollup-type scaling models and zk-Rollups, as well as zk-EVM scaling options. It also aims to implement Secret Leader Election (SLE) to protect node operators from being tracked [3].

The Scourge

This stage aims to enhance decentralisation by implementing Proposer/Builder Separation (PBS). This solution prevents a single validator from both proposing and building blocks, making Ethereum more resistant to censorship and opening doors for further scalability improvements [3].

The Verge

This phase intends to simplify transaction verifications by integrating zk-SNARK technology. This allows for smaller and faster proofs, reduces storage space required for the blockchain, and enables more functional light clients [3].

The Purge

Building on the success of The Verge, this stage focuses on making Ethereum more portable and simple. It relies on zk-SNARKs and Verkels trees to enable fast sync for the Beacon Chain and reduce the network’s storage overhead [3].

The Splurge

The final phase addresses remaining issues, such as replacing the current gas cost and token burning scheme with EIP-1559, improving the EVM, and implementing Verifiable Delay Functions (VDFs) for more efficient data verification. This stage is less specific due to the development challenges and problems that may arise during the previous phases [3].

Conclusion

All of these stages aim to resolve the fundamental challenges Ethereum is facing regarding scalability, decentralisation, privacy, and storage overhead while maintaining its core principles and values.

Blockchain Architecture

In this section, both blockchain platforms will be analysed as multi-blockchain architectures with their specific characteristics, primarily focusing on chain layout and messaging mechanisms.

TON — Blockchain of Blockchains

The TON Blockchain introduces a new architectural approach called blockchain of blockchains or 2-blockchains, considered by its authors a novel solution “…capable of achieving our goal of processing millions of transactions per second, as opposed to the now-standard dozens of transactions per second” [6].

The TON Blockchain infrastructure can be characterised as a collection of blockchains made up of a master blockchain or masterchain, several working blockchains known as workchains, and a set of shard blockchains called shardchains within each workchain.

The masterchain holds general information about the protocol, validators and their stakes, active workchains and their shards, and the most recent blocks of all workchains and shardchains.

Workchains contain value-transfer and smart contract transactions and may have different rules, transaction formats and cryptocurrencies. However, all workchains must satisfy basic interoperability criteria to make interaction between different workchains effective and simple.

Each workchain is divided into shardchains responsible for a subset of accounts. Each block in a shardchain and the masterchain is a blockchain in miniature, called a vertical blockchain. The terminology here is quite important in TON-specific mechanism, because it allows to replace detected invalid blocks without making a true fork of all shardchains involved. In the case of incorrect shardchain blocks, a new block is committed into the vertical blockchain to replace the invalid horizontal blockchain block, or a block difference, is used to describe the changes needed.

The TON Blockchain has a unique feature known as Instant Hypercube Routing that enables it to transmit and process messages from a block in one shardchain to the subsequent block in the destination shardchain, regardless of how many shardchains are present in the system.

TON Blockchain contains exactly one masterchain. The system can potentially accommodate up to 232 workchains, each subdivided into up to 260 shardchains [6].

The sharded era of Ethereum 2.0

The Ethereum 2.0 uses sharded blockchain protocol, which ensures scalability by executing transactions in separate shards and provides a protocol to send messages between shards. The core of this architecture is the Beacon Chain, which was initially launched on December 1, 2020. The primary function of the Beacon Chain is to handle attestations, which are essentially votes on the integrity of shard data and the overall validity of the Beacon Chain. Each individual shard in Ethereum 2.0 operates as a distinct blockchain, utilising the Ethereum Wasm (eWasm) interface.

Figure 2 – Ethereum 2.0 chain layout (courtesy of Hsiao-Wei Wang)

 

The primary objective of shardchains is to alleviate network congestion by dividing the main blockchain into 64 smaller, separate blockchains, one of which will be the old Ethereum 1.0 blockchain. This way, nodes are only responsible for processing the transactions of their specific shard, rather than the entire blockchain. In essence, the load of the network is distributed across these shards, which helps to streamline the transaction process and prevent network overload.

Shards in Ethereum 2.0 will have access to each other’s state via their crosslinks and state proofs. In the model of Ethereum 2.0 with 64 shards, each one posts a crosslink in the Beacon Chain for every block, meaning that shards could contain logic that executes based on some light client proof of a transaction on another shard [7].

Conclusion

At present, Ethereum 2.0 has not provided a clear specification on the nodes responsible for passing messages between shards, the specific functionalities of the 63 new shardchains, and how they would operate in various use cases. While Ethereum 2.0 claims to be capable of executing tens of thousands of transactions per second (referring to sidechain and payment channel transactions), TON is capable of performing billions of such transactions per second. This reiterates that the TON 2-blockchain vision and the advanced messaging orchestration between shardchains offer superior reliability and scalability in comparison to Ethereum 2.0.

Consensus Mechanisms

The consensus mechanisms used in Ethereum 2.0 and TON Blockchain are Gasper and Catchain protocol, respectively. Both are variations of PoS consensus approach, where validators (also known as stakers) are chosen to create blocks and validate transactions based on the amount of cryptocurrency they stake or lock up as collateral. This is in contrast to PoW, where miners need to solve computationally intensive puzzles to validate transactions and create blocks. Here, PoS has several benefits, including enhanced security, lower risk of centralization, and improved energy efficiency compared to other consensus mechanisms.

Ethereum 2.0 PoS Gasper

After announcing The Merge in September 2022, Ethereum moved to Proof of Stake (PoS) consensus algorithm, which replaced the Proof of Work used previously. The incentive for this became the launch of Beacon Chain in 2020 and its final merge with the original Ethereum PoW chain, making it possible to significantly enhance the security and decentralisation of the entire system [8].

In the context of Ethereum 2.0, a smooth transition to a new consensus ecosystem has become achievable through the development of a novel Proof of Stake (PoS) consensus mechanism called Gasper, which is currently involved on the Beacon chain. It represents the result of a combination of Casper the Friendly Finality Gadget (Casper-FFG) and the LMD-GHOST fork choice algorithms. Casper-FFG is responsible for upgrading specific blocks to a finalised state, ensuring that new nodes can confidently sync with the canonical chain. The LMD-GHOST fork choice algorithm utilises accumulated votes to facilitate easy selection of the correct chain in case of forks in the blockchain [9].

Gasper operates as a pivotal mechanism atop a PoS blockchain, where participating nodes stake ETH as a security deposit that can be forfeited in case of lazy or dishonest behaviour in proposing or validating blocks. This consensus mechanism governs the rewarding and punishing of validators, as well as the determination of which blocks to accept or reject, and which fork of the blockchain to prioritise for building [9].

In order to become a validator, users must stake a specific amount of the native token (32 ETH), which serves as an investment that can be lost if they try to subvert the system or fail to validate transactions reliably. This requirement incentivizes validators to act in the best interests of the network [10].

The TON Catchain Protocol

TON blockchain comes with another consensus mechanism called Catchain Consensus Protocol, which is a PoS variation of the Practical Byzantine Fault Tolerance (PBFT) scheme.

To create new blocks on a TON blockchain like the masterchain or one of its active shardchains, a distinct group of validators is formed from a preselected list. In this context, validators are special nodes that have deposited stakes (large amounts of TON coins) by a special masterchain transaction to be eligible for new block generation and validation.

This group serves to establish a private overlay network within ADNL (Abstract Datagram Network Layer) and also initiates a relevant instance of the Catchain protocol. The protocol itself involves multiple rounds of consensus-building that take place within the same chain. It’s possible to have multiple rounds happening simultaneously, as different stages of one round can overlap with others.

In each round of the Catchain consensus protocol, the members must collectively agree on a candidate block proposed by one of the validators, or they can choose to accept no candidate at all. To be considered complete, the round requires the candidate block to receive signatures from over two-thirds of all validators. Once this condition is met, the event can be added to a specialised commit sign object, indicating the end of the round and the start of the next with a new identifier [11] .

In case of block forks, the Catchain protocol detects them by creating different versions of the same message and sending them to different groups of peers. Block signatures on Catchain make confirmation of forks simple – once a fork is found, one group of nodes ignores the messages of the neighbouring group and all subsequent messages, and another service message containing a corresponding proof of fork is created and broadcasted to all neighbouring nodes. Every node stores its copy of the list of bad network members and updates it in case of detection of a new fork [11] [12].

Conclusion

The Ethereum 2.0 network proposes a PoS algorithm that involves a significant number of validators – at least 16,384 – which is quite big. These validators, who are essentially standard Ethereum nodes, only need to stake 32 ETH and do not require any additional communication beyond the standard Ethereum network. However, the Catchain protocol offers a more advanced approach to consensus establishment. For instance, it involves a preliminary agreement before a new block is created, as well as advanced tools to prevent mid-way forks from occurring. This proves again that the Ethereum approach does not aim to achieve the level of speed and versatility that has been already reached by the existing implementations of TON.

Networking

Both TON and Ethereum have distinct networking layers that facilitate communication between nodes and enable the respective blockchains to function efficiently.

Network Protocols

The cornerstone of TON is the Abstract Datagram Network Layer (ADNL) – a peer-to-peer datagram protocol running on top of a UDP. There are additional subprotocols built upon the ADNL such as DHT, RLDP, overlay subnetworks and special gossip protocols, which are specifically designed to support multi-blockchain projects like TON. These protocols allow for more flexibility and can support the unique demands of TON’s multi-blockchain system [6] [15].

Ethereum primarily uses the DevP2P protocol for communication between nodes. This protocol is based on the underlying RLPx transport protocol, which is a TCP-based protocol with additional features like encrypted connections and node discovery. After peers are connected and an RLPx session has been started, they can exchange information using specific sub-protocols such as Wire protocol, les, Snap, Whisper, etc [13]. Also, for the early stage of Eth2, Vitalik Buterin offered to keep eth2-client and eth1-engine separately using local RPC connections (Figure 3) [14].

Figure 3 – Network layer schematic for consensus and execution clients [14]

Network Services

The TON ecosystem includes various services such as TON Proxy, TON Sites, and TON Storage, which are built on top of TON’s network protocols. This allows for a diverse range of applications and services within the TON ecosystem[6] [15].

Ethereum’s network focuses on supporting the Ethereum blockchain and smart contract platform. While it enables the development of decentralised applications (dApps), the network itself is not designed to support additional services like TON’s.

Node Discovery

TON uses a Kademlia-like DHT for locating other nodes and storing various information such as IP addresses, node availability, and information related to TON services. This DHT is a crucial part of TON’s networking layer [16].
Ethereum also uses a Kademlia-based DHT for node discovery, known as the Ethereum Node Records (ENR) system. However, it serves a more limited purpose in comparison to TON’s DHT [13].

Node types

Ethereum and TON have similar node types, such as full nodes, archive nodes, and validator nodes with almost identical functionality. However, TON also has Liteservers, which are nodes that can receive and respond to requests from Lite Clients. Lite Clients are used for lightweight access to the blockchain and are particularly useful for mobile devices [17]. On the other hand, Ethereum has an alternative to Liteservers – the Light nodes that have the same functionality as full nodes without powerful hardware or high bandwidth [18].

Network Maintenance

TON has built-in mechanisms for maintaining and updating the neighbour list, optimising the overlay network for lower latency and higher throughput. TON also provides mechanisms for constructing new overlay networks based on existing ones, and creating overlay subnetworks within larger overlay networks [6].
Ethereum’s nodes maintain and update their list of peers, but the networking layer does not include specific mechanisms for optimising connectivity and latency.

Conclusion

In summary, TON’s networking layer is designed to support a multi-blockchain system with a focus on scalability, flexibility, and the integration of various services within the ecosystem. In contrast, Ethereum’s networking layer is primarily designed for a single-blockchain system, with less focus on additional services and multi-blockchain support. Ethereum 2.0 aims to address some of the scalability issues present in the current network.

TVM vs EVM

Both Ethereum Virtual Machine (EVM) and TON Virtual Machine (TVM) are virtual stack-based machines designed for executing smart-contract code. While they share similarities, there are significant differences between the two.

Data representation

EVM primarily works with 256-bit integers. The Ethereum blockchain state is essentially a mapping of 256-bit addresses to 256-bit values represented by the data structure called Merkle Patricia Trie [19]. This simplistic approach limits the variety of data structures that can be used.

TVM represents data as a collection of cells. Each cell contains up to 128 data bytes and up to 4 references to other cells. This “bag of cells” representation allows TVM to work with arbitrary algebraic data types, including trees or directed acyclic graphs of TVM cells, thus providing more flexibility when it comes to data structures [6].

Stack machine

EVM is a stack-based machine, it pushes and pops 256-bit integers. The EVM processes instructions sequentially, utilising a stack to store intermediate values [20].

TVM also is a stack-based machine, but it keeps either 64-bit integers or cell references. This provides more flexibility in handling different data types and sizes [21].

Example of stack operations

Suppose we want to add two numbers (5 and 3) in EVM. The process would involve pushing the numbers onto the stack and then calling the ADD instruction. The result (8) would be left on the top of the stack.

We can do this operation in the same way in TVM. But let’s look at another example with more complex data structures, such as hashmaps and cell reference. Suppose we have a hashmap that stores key-value pairs, where keys are 64-bit integers and values are either 64-bit integers or cell references. Let’s say our hashmap contains the following entries:

{
1: 42,
2: Cell_A
}

Now, we want to perform an operation where we add the values associated with keys 1 and 2 and store the result back into the hashmap with the key 3. Let’s look at stack operations:

1. Push the number 1 onto the stack. The stack now contains one element: (1).
2. Call the DICTGET instruction: The DICTGET instruction retrieves the value associated with the key at the top of the stack. In this case, the value associated with key 1 is 42. The stack now contains the value: (42)
3. Push the key 2 onto the stack: Push the number 2 onto the stack. The stack now contains two elements: (42, 2).
4. Call the DICTGET instruction again: The DICTGET instruction retrieves the value associated with the key at the top of the stack. In this case, the value associated with key 2 is a reference to Cell_A. The stack now contains the value: (42, Cell_A).
5. Assume Cell_A contains a 64-bit integer value 8.
6. Load the value from Cell_A: An instruction to load the value from the cell reference is executed. The stack now contains the values: (42, 8).
7. Call the ADD instruction: When the ADD instruction is executed, the TVM will pop the top two elements from the stack, add them together, and push the result back onto the stack. In this case, the top two elements are 42 and 8. After the addition, the stack will contain the result: (50).
8. Push the key 3 onto the stack: Push the number 3 onto the stack. The stack now contains two elements: (50, 3).
9. Call the DICTSET instruction: The DICTSET instruction takes the top two elements from the stack and stores the value (50) in the hashmap with the key (3). The updated hashmap now looks like this:

{
1: 42,
2: Cell_A,
3: 50
}

To do the same in EVM, we need to define a mapping that stores key-value pairs and the function where we work directly with 256-bit integers stored in the mapping.
It’s essential to note that the EVM supports complex data structures by leveraging Solidity, but these structures are built on top of the EVM’s simpler data model, which is fundamentally different from the more expressive data model of the TVM [21].

Arithmetic operations

EVM supports 256-bit arithmetic. This means operations like addition, subtraction, multiplication, and division can be performed with 256-bit integers [22].

TVM supports 64-bit, 128-bit, and 256-bit arithmetic operations, including unsigned, signed, and modulo integers. It also offers multiply-then-shift and shift-then-divide operations, which simplify implementing fixed-point arithmetic. The additional options allow developers to optimise their smart contracts based on the size and nature of the data being manipulated [21].

Overflow checks

EVM overflow checks are not performed by default. In new versions of Solidity (starting from 0.8.0) the language automatically includes overflow and underflow checks for arithmetic operations. However, this feature is provided by the Solidity language and not by the EVM itself. In older versions, developers needed to manually implement overflow checks to prevent potential bugs and vulnerabilities [22].

All arithmetic operations in TVM perform overflow checks by default, simplifying smart contract development and reducing the chance of errors [6].

Cryptography and hash functions

EVM has support for the Ethereum-specific cryptography scheme, such as the secp256k1 elliptic curve and the keccak256 hash function. Also, EVM does not have built-in support for Merkle proofs, which are cryptographic proofs used to verify the membership of an element in a set [22].

TVM offers support for 256-bit Elliptic Curve Cryptography (ECC) for predefined curves, like Curve25519. It also supports Weil pairings on some elliptic curves, which are useful for fast implementation of zk-SNARKs (zero-knowledge proofs). Popular hash functions like sha256 are also supported, providing more options for cryptographic operations. In addition, TVM can work with Merkle proofs, providing additional cryptographic features that can be beneficial for certain use cases, such as verifying the inclusion of a transaction in a block [6].

High-level languages

EVM primarily uses Solidity as its high-level language, which is an object-oriented, statically-typed language similar to JavaScript and C++. Also, there are other languages for writing Ethereum smart-contracts such as Vyper, Yul, etc [23].

TVM uses FunC as a high-level language designed for writing TON smart contracts. It is a functional language with static types and support for algebraic data types. FunC compiles to Fift, which in turn compiles to TVM bytecode [24].

Sharding support

EVM lacks native support for sharding, which is a technique for partitioning a blockchain network into smaller, more manageable pieces called shards. Ethereum has plans to implement sharding in the future, however it’s not currently available [3].

TVM offers support for large or global smart contracts that are aware of sharding, which can improve the scalability of the network. Usual (local) smart contracts can be sharding-agnostic. This flexibility allows for better optimization and scalability in the TON network [6].

Conclusion

In summary, while both EVM and TVM are stack-based machines designed to execute smart contracts, TVM offers more flexibility, support for a wider range of data types and structures, built-in overflow checks, advanced cryptographic features.

TVM’s support for sharding-aware smart contracts and its unique data representation approach make it better suited for certain use cases and scalable blockchain networks.

Wallets

There are several wallets specifically designed for use with the Ethereum or TON blockchain.

Ethereum wallets

For Ethereum, some of the most popular options include:

1. MetaMask – a browser extension that enables users to access Ethereum and Ethereum-based decentralised applications (dApps) from their web browser. It also includes a wallet for managing Ether, ERC20 and ERC721 tokens.
2. MyEtherWallet (MEW) – a free, open-source, client-side interface that allows users to generate an Ethereum wallet to store and manage Ether and other ERC-based tokens.
3. Ledger – hardware wallets that store private keys offline, providing enhanced security for users’ ETH and other assets.
4. Trezor – hardware wallet that stores private keys offline and supports Ethereum, along with the most resilient cryptocurrencies and ERC-20 tokens.
5. Exodus – a software wallet that supports a large spectrum of assets, including ETH and ERC20 tokens, and includes a user-friendly interface and built-in exchange functionality.
6. Trust Wallet – a mobile wallet for Android and iOS that enables users to manage ETH and other cryptocurrencies, as well as interact with Ethereum-based dApps.

TON wallets

For TON blockchain, some of the popular choices are:

1. Tonkeeper – a full-fledged mobile wallet for a variety of transactions on TON; It is available as a mobile app for both iOS and Android devices. It includes features such as a user-friendly interface, support for multiple languages, the ability to import and export private keys, and the ability to track TON transactions.
2. Tonhub – a mobile wallet that supports in-app Toncoin staking. Available for iOS and Android;
3. TON Wallet – an open-source web wallet for Toncoin supported by the community. The extension allows your browser to interact with dApps based on TON Blockchain;
4. SafePal – a crypto management platform with hardware, software, and browser extension wallets. Supports multiple networks (Ethereum and TON as well) and a large variety of assets. Available for iOS, Android and as a browser extension for Chrome, Mozilla and Edge.
5. Coin98 Wallet – a mobile and browser wallet with multichain support, including TON and Ethereum.
6. MyTonWallet – the most full-featured web wallet and browser extension for TON Blockchain, with support of tokens, NFT, TON DNS, TON Sites, TON Proxy, and TON Magic.

Nevertheless, on Ethereum, a user’s wallet is derived from their address, which is 1:1 relationship with their public key. However, on TON, wallets are separate smart contracts that must be deployed by the user. This means that a user can have multiple wallets with different addresses and initial parameters. To send a transaction on TON, the user signs a message with their private key and sends it to their wallet contract, which then forwards it to the dApp smart contract. This approach allows for more flexibility in wallet design, and new wallet contracts can be created over time.

Worth mentioning that Ethereum has so-called Account Abstraction [43] on the development roadmap, which aims to bring natively the smart contract wallets to the EVM.

Conclusion

Both Ethereum and TON blockchain platforms offer a large spectrum of wallets able to keep various chain-based assets and handle different transactions. The TON approach based on the idea of modelling a particular wallet with a smart contract instance leads to more versatile and efficient entities, adaptable to responsive architecture of a sharded-chain system.

Smart Contract Development

Smart contracts are self-executing contracts, with the terms of the agreement between two parties being directly written into lines of code. They are typically stored on a blockchain, which allows for a high degree of security and transparency.

The Ethereum Virtual Machine (EVM) is the most popular standard for developing smart contracts on most modern blockchains. The EVM introduced a new generation of developers to a decentralised software stack, allowing them to create trustless apps [25].

However, as newer blockchains are introduced, Ethereum’s architecture is now the conservative older generation threatening to hold back progress. The very modern TON blockchain came out with some radical new ideas and concepts to smart contract development and further integration.

Development Toolkit

The Ethereum development toolkit is a set of software tools and libraries that developers use to create and deploy decentralised applications on the Ethereum blockchain. These tools include:

• Solidity – a C-like high-level, strongly-typed, object-oriented, compiled programming language used to write smart contracts that run on the Ethereum Virtual Machine (EVM).
• Remix IDE – an online integrated development environment (IDE) used to write, test, and deploy smart contracts written in Solidity.
• Hardhat – a development framework for Ethereum that includes tools for compiling, deploying, and testing smart contracts, as well as managing project dependencies.
• Ethers.js – a JavaScript library that provides a way for applications to interact with the Ethereum blockchain and smart contracts.
• Ganache – a personal blockchain for Ethereum development that allows developers to test their applications in a sandbox environment.
• Infura – a cloud-based service that provides access to the Ethereum network for developers who do not want to run their own Ethereum node.

To begin developing, testing, and debugging smart contracts on TON, were developed a series of products and services, some of them including:

• FunC – a C-like high-level, statically-typed, domain-specific, compiled language used to program smart contracts on TON;
• Blueprint – a development environment for TON for writing, testing, and deploying smart contracts;
• toncli – cross-platform command line interface for deployment and interaction with TON smart contracts;
• Sandbox – a package which allows you to emulate arbitrary TON smart contracts, send messages to them and run get methods on them as if they were deployed on a real network; used for testing purposes.

Specifics of Smart Contract Design

Asynchronous calls and atomicity

Figure 4 – TON Blockchain – transition from synchronous to asynchronous calls

 

In the context of Ethereum, atomicity refers to the property of a transaction being executed as a single, indivisible unit of work. In other words, an Ethereum transaction is atomic if it either succeeds completely or fails completely, without any partial or incomplete execution.

Furthermore, when one smart contract invokes a method of another smart contract, the invocation is executed instantly within the same transaction. This method is similar to running an entire backend on a single server, where each part of the backend can access every other part synchronously, making it easy to understand. However, this method has a drawback: it can only expand as far as it can fit in a single location.

The negative effect of synchronicity is congestion, since computations cannot run in parallel. As the number of contracts and users grows exponentially, the inability to parallelize computations becomes the main limiting factor in network growth. Under these current requirements, the traditional synchronous paradigm will no longer hold [25]. In these circumstances, TON introduces a new concept of asynchronous calls with the purpose to enhance the efficiency and scalability of decentralised systems.

By allowing smart contract calls to be executed asynchronously, the system can continue processing other transactions while waiting for a smart contract to complete its execution. This reduces the risk of bottlenecking and allows for faster processing of transactions.

Moreover, asynchronous smart contract calls provide more flexibility in handling complex transactions. In some cases, a single transaction may require multiple smart contract calls to be executed in a specific sequence. By allowing these calls to be executed asynchronously, developers can more easily design and implement complex transaction flows, which can include multiple parallel operations.

Writing asynchronous smart contracts also brings a new set of challenges for developers.

To better understand the TON Blockchain architecture, we can draw an analogy to a cluster of microservices. In such a system, where multiple microservices are running on separate machines, it becomes impossible to read state memory across services. Similarly, smart contracts on the TON Blockchain can only communicate with each other by sending asynchronous messages. This means that if there is a need to query data from another contract, and you require an immediate response, it will not be possible. Hence, smart contracts cannot execute getter methods, such as getBalance on other contracts. Instead, they must be called by off-chain clients, similar to how your Ethereum wallet uses a full node like Infura to query smart contract states [26].

Code immutability

The concept of smart contracts on Ethereum was originally inspired by legal documents, where the code of the contract was immutable and had to be completely rewritten to change terms. However, the developer community has found ways to work around this limitation, such as using proxy contracts that point to a different contract in order to implement upgrades.

In contrast to this approach, TON allows smart contracts to modify their own code freely, acknowledging that bugs can exist and requirements can change over time. This means that smart contracts can write to their own code variable, making it mutable, or not, making it immutable. This eliminates the need for cumbersome patterns like the proxy contract and makes the process of upgrading contracts more straightforward [9].

Unbounded data structures

Unbounded data structures in smart contracts are entities which can grow without limit. This can cause a problem for normal users if an attacker tries to overload the contract by adding many entries, causing a DoS attack that could prevent other actors from using it. According to the Ethereum fee model, the user who writes new state data is responsible for paying the fee for that data. The fee does not depend on the size of the map, adding a new entry requires a constant amount of gas. Therefore, spamming maps on Ethereum is not economically punished, and the protection provided by the system should be augmented and well thought at the time of designing the contracts/system.

However, the TON gas fee model dictates that writes are not constant in cost, and it is proportional to the data amount already existing in the data structure. Because of the underlying Bag of Cells architecture aligned in a tree-like structure, writing to a leaf necessitates extra work for traversing and rewriting the hashes along the tree. If an attacker were to spam keys in a map, updating user balances would be difficult to get due to gas limit overflow.

As a best practice, TON suggests avoiding unbounded data structures and relying on the idea of contract sharding, when each child contract holds the balance for a single user.

Testing & Deployment

Testing smart contracts on Ethereum

Ethereum is an example of a public blockchain that cannot be altered once a smart contract has been deployed, which makes it challenging to modify its code. Smart contract testing is necessary to ensure that the code of a smart contract performs as intended. This process is useful in evaluating a smart contract’s reliability, usability, and security against predetermined requirements. Several testing tools are available for Ethereum smart contracts, such as Hardhat, Truffle, Remix, and Ganache. These tools offer various features that facilitate smart contract testing, such as automated contract deployment and local blockchain testing.

Before deploying the smart contract to the mainnet, it is essential to test it thoroughly on a testnet like Goerli or Sepolia to ensure that contracts are well suited for various scenarios and constraints of real-world consequences [27].

Testing smart contracts on TON

While there are fundamental differences between TVM and the EVM, testing between the two platforms is not fundamentally different. The only thing is the toolkit used for this purpose. There is a plethora of testing tools that are available, such as [28]:

1. Deploying your contract to testnet – Testnet is a live instance of the TON Blockchain that serves as an alternative to the mainnet. It allows you to obtain TON coins for free and experiment with them. While it is less secure than the mainnet, it provides a sufficient environment for testing and exploration.
2. Local blockchain with MyLocalTon – MyLocalTon is a Java-based desktop executable that runs a personal local instance of TON Blockchain on your machine that you can deploy contracts to and interact with. Another way to run a local private TON network is using Kubernetes with ton-k8s.
3. Writing tests in FunC – toncli is a command-line tool written in Python that runs on your machine and supports debug and unit tests for FunC contracts, where the tests are also written in FunC (example).
4. Bare-bones TVM with Sandbox – Sandbox is a bare-bones version of just the TVM running on WebAssembly with a thin JavaScript wrapper that allows test interactions from TypeScript.
5. Deploying beta contracts to mainnet – To test in production, one can deploy alternative beta versions of contracts to the mainnet and use actual TON coins instead of free ones to interact with them in a real-world setting. If any issues arise, you can deploy new, corrected beta versions while incurring additional expenses.

Deploying on Ethereum mainnet

The typical process for deploying contracts on the Ethereum mainnet involves compiling the smart contract code, creating a transaction to deploy the contract with the specified constructor parameters, signing the transaction using the private key of the deploying account, and broadcasting the transaction to the network for processing. Once the transaction is mined and confirmed, the smart contract is deployed on the Ethereum network and becomes accessible for interactions by users. Tools like Truffle, Hardhat or Remix are sufficient for these tasks.

Deploying on TON mainnet

The deployment of smart contracts on TON is the act of uploading the bytecode to the blockchain. The new address of our deployed contract in TON depends on only two things – the deployed bytecode (initial code) and the initial contract storage (initial data). If two different developers were to deploy the exact same code with the exact same initialization data, they would collide, so it is important to ensure uniqueness of initial input data used.

The actual deployment involves sending the first message that will cause the contract to be deployed. It can be any message that is directed towards the desired contract. To exemplify, sending some TON coins to the contract (an empty message) and piggybacking that is pretty enough for deployment.

Rent fees are a crucial aspect to consider when deploying contracts. Every contract must have a non-zero balance, and it must continuously pay rent fees to avoid being deleted. The documentation states that storage fees are approximately 4 TON per MB per year. Nevertheless, the balance can always be checked through an explorer, and additional TON coins can be sent to the contract if necessary.

Communicating with the live network for the deployment will require an RPC service provider. TON Access is an awesome service that provides un-throttled API access for free. It’s also decentralised, which is the preferred way to access the network.

After successful deployment, you can open your address in a suitable explorer, such as tonscan.org to verify that everything was done properly.

Conclusion

The process of testing & deployment on Ethereum or TON does not differ so much and keeps the similar approach. The only difference is when handling the deployment of smart contracts on TON Blockchain – it is really important to ensure uniqueness of constructor data and providing enough resources for space rent fees.

Solidity vs FunC

Smart contract development involves usage of predefined languages such as Solidity for Ethereum, and FunC for TON.
Solidity is an object-oriented, high-level, strictly-typed language influenced by C++, Python, and JavaScript, and is specifically designed for writing smart contracts that execute on Ethereum blockchain platforms.

FunC is also a high-level language, used to program smart contracts on TON Blockchain, being a domain-specific, C-like, statically-typed language.

In the sections below will be analysed briefly the following aspects of these languages, i.e. data types, storage, functions, flow control structures and dictionaries (hashmaps).

Data types

Solidity includes the following basic data types [29]:

• Signed/Unsigned integers
• Boolean
• Addresses – used to store Ethereum wallet or smart contract addresses, typically around 20 bytes. An address type can be suffixed with the keyword “payable”, which restricts it to store only wallet addresses and use the transfer and send crypto functions.
• Byte arrays – declared with the keyword “bytes”, is a fixed-size array used to store a predefined number of bytes up to 32, usually declared along with the keyword.
• Literals – Immutable values such as addresses, rationals and integers, strings, unicode and hexadecimals, which can be stored in a variable.
• Enums
• Arrays (fixed/dynamic)
• Structs
• Mappings

In case of FunC, the main data types are [30]:

• Integers
• Cell – basic for TON opaque data structure, which contains up to 1,023 bits and up to 4 references to other cells
• Slice and Builder – special objects to read from and write to cells,
• Continuation – another flavour of cell that contains ready-to-execute TVM byte-code
• Tuples – is an ordered collection of up to 255 components, having arbitrary value types, possibly distinct.
• Tensors – is an ordered collection ready for mass assigning like: (int, int) a = (3, 5). A special case of tensor type is the unit type (). It represents that a function doesn’t return any value, or has no arguments.

Currently, FunC has no support for defining custom types, except for the type constructions, thus Solidity being more flexible and developer friendly from this perspective.

Storage layout

Permanent storage data in TON Blockchain is stored as a cell. Cells play the role of memory in the stack-based TVM. A cell can be transformed into a slice, and then the data bits and references to other cells from the cell can be obtained by loading them from the slice. Data bits and references to other cells can be stored into a builder, and then the builder can be finalised into a new cell.

Solidity provides a flat storage model, which means that all state variables are stored in a single, continuous block of memory called the storage. The storage is a key-value store where each key is a 256-bit (32-byte) integer that represents the storage slot number, and each value is the 256-bit word stored at that slot. The slots are numbered sequentially starting from zero, and each slot can store a single word. Solidity allows the programmer to specify the storage layout by using the storage keyword to define state variables. The order in which the variables are defined determines their position in the storage.

Functions

The FunC program is essentially a list of function declarations/definitions and global variable declarations. Any function in FunC matches the following pattern:

[<forall declarator>] <return_type> <function_name>(<comma_separated_function_args>) <specifiers>
Specifiers are keywords which alter the behaviour of a function, especially its visibility and state mutability. In the case of FunC, it has three types of specifiers: impure, inline/inline_ref, and method_id. One, several, or none of them can be put in a function declaration in the right order.

To exemplify, we should put impure specifier if the function can modify contract storage, send messages, or throw an exception when some data is invalid and the function is intended to validate this data.

Functions in Solidity are declared using the function keyword, followed by the name of the function and its parameters (if any). The body of the function is enclosed in curly braces, and any output or return values are specified using the returns keyword.
Solidity functions can be either public, private, internal, or external, which determines how they can be accessed and called by other parts of the contract or external programs.

In addition, functions can have different modifiers that allow developers to define conditions under which the function can be executed. In the context of Solidity, a modifier is a special type of Solidity function that is used to modify the behaviour of other functions, rather than being a keyword like in FunC. For example, a function can be restricted to only be called by a certain address, or require a certain condition to be met before execution.

Flow control structures

Most of the control structures known from curly-braces languages are available in Solidity, including: if, else, while, do, for, break, continue, return, with the usual semantics known from C or JavaScript [31].

Solidity also supports exception handling in the form of try/catch-statements, but only for external function calls and contract creation calls. Errors can be created using the revert statement [31].

FunC supports classical if-else statements, repeat, while and do/until loops. The for loop is not yet supported though [32].

Dictionaries

Dictionary (hashmap/mapping) data structure is very important for Solidity and FunC contract development because it allows developers to efficiently store and retrieve data in smart contracts, specifically data related to a specific key, such as a user’s balance or ownership of an asset.

Mapping is a hash table in Solidity that stores data as key-value pairs, where the key can be any of the built-in data types, excluding reference types, and the value of the data type can be any type. Mappings are most typically used in Solidity and the Ethereum blockchain to connect a unique Ethereum address to a corresponding value type. In any other programming language, a mapping is equivalent to a dictionary.

In Solidity, mappings do not have a length, nor do they have the concept of setting a key or a value. Mappings are only applicable to state variables that serve as store reference types. When mappings are initialised, they include every possible key, and are mapped to values whose byte-representations are all zeros.

An analogy of mappings in FunC are dictionaries, or TON hashmaps. In the context of TON, a hashmap is a data structure represented by a tree of cells. Hashmap maps keys to values ​​of arbitrary type so that quick lookup and modification are possible. The abstract representation of a hashmap in TVM is a Patricia tree, or a compact binary trie [21].

Conclusion

Solidity and FunC are both robust and fully functional programming languages for building smart contracts that are compatible with certain blockchain platforms. The syntax of Solidity is akin to that of TypeScript, which makes it more accessible for programmers to comprehend and create contracts with advanced functionality like mapping, events, and inheritance. FunC, on the other hand, is a language that has a C-assembly-like structure and operates on a somewhat different architecture. Ultimately, the selection of one language over the other will be determined by the precise specifications of the system, as well as the user’s and application’s requirements.

Token standards

There are several token standards for Ethereum-based tokens, which are essentially templates that define the rules for creating and managing tokens on the Ethereum network. In Table 2 are described the most common ones.

Table 2 – Description of Ethereum token standards [33]

 

The TON blockchain, due to their novel vision in asynchronicity and sharded blockchains, implements new concepts and standards that were unavailable in previous-generation blockchains. This includes development of the following standards:

• Jettons standard
• NFT standard
• SBT (Soulbound NFT) standard
• NFTRoyalty standard extension

In Table 3 are shown specifications for each standard in part.

Table 3 – Description of TON token standards [34]

Conclusion

Different blockchains have different architectures and designs, which means that they may not support the same features and functionality. Tokens are a way to represent assets or utility within a blockchain ecosystem, and different blockchains may have different requirements and use cases for these tokens. Thus, different token standards have been developed to meet the specific needs of each blockchain platform. To exemplify, the ERC-20 token standard was developed specifically for Ethereum (valid for any EVM blockchain) and its unique features, while the Jetton token standard was created for TON. These standards provide a common set of rules and guidelines for the development of tokens, ensuring their compatibility with the specific blockchain platform and facilitating their wide adoption by integrating with as many applications and services as possible.

dApps

A decentralised application (dApp) is a type of application that runs on a decentralised network, such as a blockchain. It uses smart contracts as its backend, which are self-executing contracts with the terms of the agreement directly written into code. This allows for trustless interactions between users and the dApp without the need for intermediaries [37].

Table 4 – dApp main principles [35] [37]

Both networks provide a secure environment to develop smart-contracts, which serve as the dApp backend side.

On the other hand, TON network has some built-in services which empower and help dApps to be more user-friendly and scalable.

dApp development frameworks

Developing a complete decentralised application (dApp) requires the use of various technologies. Software frameworks often offer the necessary features or enable easy integration of tools via plugin systems, simplifying the process for developers.

Ethereum provides a large spectrum of frameworks for dApp development, some of them including:

• Truffle – one of the most widely used dApp development frameworks. It provides a suite of tools for developing and testing smart contracts, as well as a built-in Ethereum client for deploying and interacting with web3 ecosystem;
• Hardhat – an open-source development environment for building and testing smart contracts on Ethereum. One of the key benefits of using Hardhat is its flexibility and extensibility. It is highly customizable, and developers can use it to build their own plugins and add-ons to tailor it to their specific needs. It is widely used by Ethereum developers and is a popular choice for dApp building on the Ethereum blockchain.
• OpenZeppelin – a collection of reusable smart contracts and libraries for building secure and upgradable dApps on Ethereum, including contracts for token creation and management, access control, and more.
• Brownie – a Python-based dApp development framework that offers a range of tools for smart contract development, testing, and deployment, as well as integration with popular testing frameworks such as Pytest.
• Scaffold-Eth – an Ethereum dApp development framework that provides a set of pre-built tools, libraries, and templates to make it easier and faster for developers to build and deploy dApps on the Ethereum blockchain. It includes tools like Ethers.js, Hardhat, React components and hooks for web3, everything you need to get started building decentralised applications powered by smart contracts.
• Foundry – a blockchain development platform that provides tools and services for building dApps on Ethereum and not only. It offers a suite of services, including smart contract development, tokenization, wallet integration, and project management tools. It is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.

To develop dApps on the TON blockchain, one must use different tools and frameworks than those used for Ethereum since the TON is based on a different substrate. Because the TON ecosystem is not as developed yet, there is currently a shortage of frameworks dedicated to TON dApp development. However, a widely used framework for this purpose is Blueprint, which provides a simplified workflow for building, testing, and deploying smart contracts on TON.

Hosting, DNS, WWW and proxy

dApp hosting

To follow dApp principles, a dApp website (frontend) should be hosted in a secure and decentralised way. On Ethereum there are no such solutions and developers need to use decentralised storage host services such as IPFS. By contrast, the TON network supports hosting solutions with mandatory encryption and automatic verification of data authenticity, providing a secure environment for dApps [38].

Domain Name Systems

TON DNS (Domain Name System) is a decentralised service on the TON Blockchain that allows users to register human-readable domain names for their smart contracts, websites, or any other online content. This makes it easier for people to interact with decentralised applications (dApps) and other resources on the TON Blockchain [39].

The DNS system on TON functions similarly to the traditional DNS systems on the internet. However, TON DNS is decentralised, eliminating the need for a centralised authority to control and manage domain names. As a result, it reduces the risks of censorship, fraud, and domain name hijacking [39].

By utilising a user-friendly naming system, TON DNS simplifies the process of accessing and using dApps and other resources on the TON Blockchain, making it more accessible to a wider audience. This, in turn, encourages the growth and development of the dApp ecosystem on TON [39].

While Ethereum does not have its own DNS, there are some projects built on top of Ethereum that aim to supplement the lack of such systems.

One such project is Ethereum Name Service (ENS) [41], which is a decentralised naming system built on top of the Ethereum blockchain. ENS allows users to register human-readable domain names that can be used to access decentralised websites, applications, and services. ENS names are stored on the Ethereum blockchain and can be resolved to Ethereum addresses, which are used to interact with smart contracts and dApps.

The Unstoppable Domains [44] is another noteworthy project in this field, offering NFT domains that allow users to establish and own their digital identities. The Unstoppable Name Service (UNS) is the technology behind it, built on the Ethereum network with the help of Polygon as a Layer 2 scaling mechanism. This feature enables Unstoppable Domains to provide NFT domains to individuals and businesses with a one-time acquisition fee, without the need for renewal fees, minting fees, or gas fees [45].

An Unstoppable NFT domain has multiple functions, such as serving as a cryptocurrency address, login credentials, universal username, and decentralised website URL. Essentially, it acts as an all-in-one tool to facilitate blockchain-based activities [45].

Both ENS and Unstoppable Domains aim to create a decentralised naming system that is not controlled by any central authority, making it resistant to censorship and domain hijacking.

WWW and proxy

The combination of TON sites and domain names provides such use cases as donation or trades. Let’s say you go to Alice’s personal page at alice.place.ton on the place.ton social network dApp. You can send 10 TON as a gift to Alice by entering alice.place.ton as the recipient’s address, and Alice will receive the TON in the crypto wallet which she assigned to her account when she created it [38].

Integrated with TON Crypto Wallet, it simplifies the authorization process for users, enabling them to access dApps without having to remember multiple passwords or share their email addresses [38]. On Ethereum there is also such functionality, using wallet connection.

TON Proxy provides secure access to the TON Network, with plans for future updates to enhance privacy and incorporate decentralised finance [38].

Similar to the TON Proxy, there are blockchain node providers available for Ethereum such as Alchemy, Infura, QuickNode that offer a way to connect to the Ethereum network with reduced financial costs and without the need for significant development time or maintenance risks. These providers offer a reliable alternative to setting up and maintaining individual blockchain nodes, which can be expensive and time-consuming.

Ethereum node providers offer developers APIs and RPC proxy nodes that enable them to interact with smart contracts and read and write data to the blockchain. Similarly, a variety of tools and services are available for decentralised storage purposes. For instance, Infura provides an Infura IPFS API gateway that allows applications that don’t natively support IPFS to access IPFS content [48]. Other IPFS public endpoints, such as Pinata, Temporal, and Eternum, are also popular among developers. By leveraging these services, software engineers can concentrate on developing their applications without having to worry about the underlying infrastructure.

Payment services

TON Payments is a solution for lightning-fast transactions with zero network fees on the TON Blockchain. While TON Blockchain is sufficient for most tasks, some applications like TON Proxy, TON Storage or a certain dApp require microtransactions at a much faster speed and lower cost. To address this issue, Payment Channels, also known as Lightning Network, were created. Payment Channels allow two parties to transact off-chain by creating a special smart contract on the blockchain with their initial balances. They can then perform as many transactions between themselves as they want without any speed restrictions or fees. A network fee is only paid when opening and closing the channel. The technology also guarantees proper operations, allowing a party to close the channel independently if the other party cheats or disappears [40].

As the technology evolves, Payment Channels can unite into a network off-chain, allowing more than two parties to participate. This makes TON Payments suitable for various applications, such as payments for internet data, streaming, games, DeFi, and more [40].

Payment channels were one of the earliest solutions developed to minimise the cost of simple user interactions on the Ethereum network, such as ETH transfers, micropayments, and atomic swaps. Participants can conduct an unlimited amount of instant, feeless transactions as long as the net sum of their transfers doesn’t exceed deposited tokens. It’s like a two-way ledger maintained by two users, and when there’s a change in balance, all parties involved must approve it. This allows for efficient transfers without the need for each transfer to be recorded on the main blockchain [46].

Additionally, rollups are one of the scaling Layer 2 solutions for rapid and secure payments on the Ethereum network, which resides in combining multiple transactions into a single transaction that is submitted to the network. The execution of the transaction occurs outside Layer 1, and the resulting data is then posted to Layer 1 where the consensus is reached. Rollups leverage the native Ethereum security, as transaction data is included in Layer 1 blocks. This approach reduces the number of transactions that need to be processed on the Ethereum main chain, thereby improving scalability and decreasing transaction fees [42].

Decentralised storage

Finally, TON network has its own decentralised storage service, that is used by the TON Blockchain to store archive copies of blocks and status data (snapshots), but also available for storing users’ files or other services running on the platform, with torrent-like access technology [6].

The most popular use case is to store NFT metadata directly on TON storage, not using additional distributed file storage services like IPFS.

Decentralised storage on Ethereum typically involves the use of distributed file systems to store and retrieve data in a decentralised and secure manner.

While Ethereum can function as a decentralised storage system for smart contract code, it is not well-suited for storing large amounts of data. Ethereum was not specifically designed for this purpose, and its limitations in terms of scalability and transaction fees make it impractical for storing large datasets.

One popular approach to decentralised storage on Ethereum is the InterPlanetary File System (IPFS), which is a peer-to-peer file system that allows users to store and retrieve files from a network of distributed nodes. IPFS provides a reliable and censorship-resistant way to store data by breaking files into smaller chunks, distributing them across the network, and using cryptographic hashes to ensure data integrity [47].

Conclusion

To summarise, both Ethereum and TON offer decentralised platforms for developing and deploying dApps. However, Ethereum has a more established ecosystem and community with a variety of development tools and frameworks available that make it easier to develop and deploy dApps on its blockchain. Conversely, TON is a newer platform, and its development tools and frameworks are not as mature as those available for Ethereum.

Additionally, Ethereum is geared towards power users, while TON is focused on mass adoption with its mobile-first and consumer-oriented approach. TON aims for greater scalability to accommodate billions of users and offers more flexibility and convenience in its system by providing services that cover all the needs for dApp creation and making user-friendly applications.

Choosing between the two platforms for dApp development will depend on specific project requirements, the expertise of the development team, and the availability of resources and support.

 

References

1. Blockchain Analysis [online], last update 2/21/2023. [accessed 4/20/2023]. Available: https://ton.org/analysis
2. JosephC (@josephch), The Beacon Chain Ethereum 2.0 explainer you need to read first [online], last update 12/12/2022. [accessed 4/21/2023]. Available: https://ethos.dev/beacon-chain
3. Maldonado, J., The new Ethereum roadmap, explained step by step [online], 11/24/2023. [accessed 4/25/2023]. Available: https://academy.bit2me.com/en/the-new-ethereum-roadmap-explained-step-by-step/
4. Danksharding [online], last update 4/26/2023. [accessed 4/25/2023]. Available: https://ethereum.org/en/roadmap/danksharding/
5. Buterin, V., Ethereum 2.0 update roadmap [online], 11/5/2022. [accessed 4/21/2023]. Available: https://twitter.com/VitalikButerin/status/1588669782471368704
6. Durov, N., The Open Network [online], 7/26/2021. [accessed 4/17/2023]. Available:
   https://ton.org/whitepaper.pdf
7. Alfaro, K., Polkadot and Ethereum 2.0 [online], last update 12/21/2022. [accessed 4/14/2023]. Available: https://wiki.polkadot.network/docs/learn-comparisons-ethereum-2
8. The Beacon Chain [online], last update 4/26/2023. [accessed 4/18/2023]. Available: https://ethereum.org/en/roadmap/beacon-chain/
9. Gasper [online], last update 8/15/2022. [accessed 4/13/2023]. Available: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/
10. Gaurav, R., Understanding Ethereum’s Proof of Stake Consensus Algorithm [online], last update 2/22/2023. [accessed 4/19/2023]. Available:
    https://www.ledger.com/academy/ethereum-proof-of-stake-pos-explained#:~:text=Proof%20of%20stake%20(PoS)%20is,for%20implementing%20new%20scaling%20solutions
11. Mercuryo, H., Catchain: The Consensus Algorithm of TON Blockchain [online], 3/18/2020. [accessed 4/17/2023]. Available:
    https://medium.com/the-capital/catchain-the-consensus-algorithm-of-ton-blockchain-224b85d9055c#:~:text=The%20Catchain%20consensus%20model%20is,algorithms%20(Neo%2C%20Algorand)
12. Durov, N., Catchain Consensus: An Outline [online], 2/19/2020. [accessed 4/12/2023]. Available: https://docs.ton.org/catchain.pdf
13. Networking Layer [online], last update 4/7/2023. [accessed 4/20/2023]. Available: https://ethereum.org/en/developers/docs/networking-layer/
14. Ryan, D., Eth1+eth2 client relationship [online], 4/7/2020. [accessed 4/19/2023]. Available:
    https://ethresear.ch/t/eth1-eth2-client-relationship/7248
15. TON Networking [online], last update 11/16/2022. [accessed 4/19/2023]. Available: https://docs.ton.org/learn/networking/overview
16. TON DHT Service [online], last update 3/28/2023. [accessed 4/20/2023]. Available: https://docs.ton.org/learn/networking/ton-dht
17. TON Node Types [online], last update 4/24/2023. [accessed 4/18/2023]. Available: https://docs.ton.org/participate/nodes/node-types
18. Nodes and clients [online], last update 4/12/2023. [accessed 4/18/2023]. Available: https://ethereum.org/en/developers/docs/nodes-and-clients/#node-types
19. Merkle Patricia Trie [online], last update 4/17/2023. [accessed 4/25/2023]. Available: https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/
20. Ethereum Virtual Machine (EVM) [online], last update 1/19/2023. [accessed 4/20/2023]. Available: https://ethereum.org/en/developers/docs/evm/
21. Durov, N., Telegram Open Network Virtual Machine [online], 3/23/2020. [accessed 4/20/2023]. Available: https://docs.ton.org/tvm.pdf
22. The Ethereum Virtual Machine [online]. [accessed 4/19/2023]. Available:
    https://cypherpunks-core.github.io/ethereumbook/13evm.html
23. Smart Contract Languages [online], last update 9/2/2022. [accessed 4/25/2023]. Available: https://ethereum.org/en/developers/docs/smart-contracts/languages/
24. FunC Overview [online], last update 1/30/2023. [accessed 4/25/2023]. Available: https://docs.ton.org/develop/func/overview
25. Kol, T., Asynchronous Smart Contracts: A Paradigm Shift [online], 2/14/2023. [accessed 4/24/2023]. Available: https://beincrypto.com/learn/asynchronous-smart-contracts/
26. Kol, T., Six unique aspects of TON Blockchain that will surprise Solidity developers [online], 4/28/2022. [accessed 4/25/2023]. Available:
    https://blog.ton.org/six-unique-aspects-of-ton-blockchain-that-will-surprise-solidity-developers
27. Testing smart contracts [online], last update 4/14/2023. [accessed 4/26/2023]. Available: https://ethereum.org/en/developers/docs/smart-contracts/testing/
28. Kol, T., TON Hello World part 4: Step by step guide for testing your first smart contract [online]. [accessed 4/26/2023]. Available:
    https://ton-community.github.io/tutorials/04-testing/
29. Solidity Types [online]. [accessed 4/26/2023]. Available:
    https://docs.soliditylang.org/en/v0.8.17/types.html
30. FunC Types [online]. [accessed 4/26/2023]. Available:
    https://docs.ton.org/develop/func/types
31. Solidity Expressions and Control Types [online]. [accessed 4/26/2023]. Available: https://docs.soliditylang.org/en/v0.8.19/control-structures.html
32. FunC Loops [online]. https://docs.ton.org/develop/func/statements#loops
33. Token Standards [online], last update 8/15/2022. [accessed 4/25/2023]. Available: https://ethereum.org/en/developers/docs/standards/tokens/
34. Tokens (FT, NFT) [online], last update 3/28/2023. [accessed 4/25/2023]. Available: https://docs.ton.org/develop/dapps/defi/tokens
35. DeFi Belief System [online]. [accessed 4/21/2023]. Available:
    https://defi.org/defi-belief-system/#practical-decentralization
36. The Open Network (TON) [online]. [accessed 4/18/2023]. Available:
    https://defi.org/ton/
37. Introductions to dapps [online], last update 9/22/2022. [accessed 4/18/2023]. Available: https://ethereum.org/en/developers/docs/dapps/
38. TON Sites, TON WWW and TON Proxy [online], last update 4/18/2023. [accessed 4/20/2023]. Available: https://docs.ton.org/learn/services/sites-www-proxy
39. What is TON DNS? [online], last update 3/6/2023. [accessed 4/20/2023]. Available: https://docs.ton.org/learn/services/dns
40. TON Payments [online], last update 3/28/2023. [accessed 4/20/2023]. Available: https://docs.ton.org/learn/services/payments
41. https://ens.domains/
42. Scaling [online], last update 4/7/2023. [accessed 5/3/2023]. Available:
    https://ethereum.org/en/developers/docs/scaling/#rollups
43. Account Abstractions [online], last update 05/01/2023. [accessed 2/5/2023]. Available: https://ethereum.org/en/roadmap/account-abstraction/
44. Unstoppable Domains [online]. [accessed 5/2/2023]. Available:
    https://unstoppabledomains.com/
45. Unstoppable Domain Github page [online]. [accessed 5/3/2023]. Available:
    https://github.com/unstoppabledomains
46. State Channels [online], last update 1/19/2023. [accessed 5/3/2023]. Available: https://ethereum.org/en/developers/docs/scaling/state-channels/
47. Decentralized Storage [online], last update 4/7/2023. [accessed 5/3/2023]. Available: https://ethereum.org/en/developers/docs/storage/
48. IPFS Public API and Gateway Deprecation [online], 7/13/2023. [accessed 5/3/2023]. Available: https://blog.infura.io/post/ipfs-public-api-and-gateway-deprecation