We are thrilled to announce Fantom Sonic, the latest breakthrough upgrade to Fantom that will scale the network to new heights.
With a brand-new virtual machine, improved database storage, and optimized consensus, Sonic is anticipated to achieve 2,000+ transactions per second (TPS) at an average finality of one second while consuming a fraction of the storage used by its predecessor, Opera. The upgrade is the latest step in Fantom’s mission to improve its underlying platform without resorting to sharding or additional layers.
Today, we are releasing access to the Fantom Sonic testnet environment to give users and developers a first-hand experience of the groundbreaking speed offered by the upgrade before its mainnet release, which is scheduled for spring 2024. Scroll further to learn more about Sonic and instructions on how to use the testnets.
What is Fantom Sonic?
Fantom Sonic is the name that covers the new Fantom technology stack, replacing the previous Opera. The new technology stack is included in the new Fantom Sonic Client that validators and other nodes will run to power the network, which comprises mainly the Fantom Virtual Machine, Carmen database storage, and an optimized Lachesis consensus mechanism. In other words, Sonic is the next iteration of the Fantom network, with no hard fork required for the upgrade. Existing smart contracts, services, and tools on Fantom Opera should be fully compatible with mainnet Fantom Sonic.
In unison, these three upgraded components elevate Fantom to unprecedented levels and allow the network to achieve an anticipated 2,000 TPS at a finality of around one second with up to a 90% reduction in storage, putting Fantom far ahead of its peers. Learn more about these components in technical detail further below.
As users continue to embrace blockchain-powered applications, a single popular application can slow an entire network. Sluggish performance of the network prevents the overall adoption of emerging decentralized applications. With its innovative technology, Fantom will allow new markets to adopt blockchain technology previously hindered by limited transaction throughput and slow finality.
We envision a new era of DeFi platforms, blockchain games, high-frequency oracles for perpetual trading, and many other applications that can leverage the speed and scalability of Sonic. Additionally, due to the significantly reduced storage requirements, it will be far more affordable and accessible to run a node on Fantom to partake in network consensus or provide data to dApps.
Sonic testnet environment
The Fantom Sonic testnet environment consists of two separate testnets to demonstrate the upgrade before its mainnet release. The closed testnet aims to showcase the maximum theoretical limits of Sonic, whereas the open testnet is interactive, allowing any user to experience Sonic directly.
Closed testnet
The Sonic closed testnet is observable to the public but does not allow users to submit transactions. A web dashboard shows the maximum performance of Sonic, such as transactions per second, time to finality, average block time, and more.
The dashboard shows that the closed testnet Sonic can process around 2,048 TPS with end-to-end transaction confirmation times (finality) of around 1.1 seconds. At the time of writing, the testnet is processing over 175 million transactions per day, showing the stability of the network even when driven to its limits.
In the closed testnet, a transaction feeder submits synthetic transactions and drives the network to its maximum performance. The transaction feeder is throttled when transaction finality rises beyond roughly 1.1 seconds, which occurs when transactions per second surpass roughly 2,048.
There is no room for public interaction in this testnet setup as the transaction feeder drives the network to its maximum performance. The synthetic transactions resemble transactions on the current Fantom mainnet with an average of 210,000 gas. The workload is distributed roughly as follows:
The closed testnet uses an evenly spread stake of 10 million FTM per validator. With 21 validators, the total stake is 210 million FTM. The required consensus quorum is two-thirds of the validators plus one, with a stake of 140,000,001 FTM. The consensus mechanism requires at least 15 validators to confirm blocks for this setup.
We will compare this to the Fantom mainnet, on which the stake is non-uniformly distributed. The total stake on September 25, 2023, at 2:00 PM UTC was 1,379,985,181 FTM. With these numbers, a quorum is reached by a minimum of 919,990,122 FTM. The combined stake of the top 14 validators is 926,970,795 FTM, which was sufficient to confirm blocks with one less validator than the Sonic closed testnet. As such, the closed testnet mimics the consensus of mainnet closely to demonstrate a realistic performance.
With this setup, the closed testnet achieves above 2,000 TPS with a finality of around 1.1 seconds and over 400 million gas per second. This is far beyond the achievable performance of the current Fantom mainnet, which sits at around 30 TPS. There will be a significant reduction in disk space requirements for validators and archive nodes. Currently, for approximately 518 million transactions, an offline pruned validator requires 1,194 GB (i.e. offline pruning removes historical states by stopping the validator), whereas Sonic with online pruning requires 351 GB only. Similarly, archival nodes require 10,893 GB on Opera but only 1,000 GB on Sonic.
We will upgrade and maintain the closed testnet with Fantom’s latest technology regularly. Hence, the closed testnet will be reset every two weeks.
Open testnet
The Sonic open testnet allows anyone to interact with Sonic by submitting transactions and experiencing the true speed the new Fantom upgrade offers.
Similarly to the closed testnet, the open testnet has a transaction feeder that submits synthetic transactions. However, it submits 130 TPS at an end-to-end finality of around 0.6 seconds, which leaves ample throughput for user interactions.
The open testnet dashboard allows users to search for addresses, transactions, and blocks. Note that the open testnet’s history will be retained for longer than the closed testnet’s history. Furthermore, it is possible to deploy dApps on this testnet with a few limitations: the client source code currently is unavailable, and there is no full explorer similar to FTMScan and no transaction tracing support on our public RPCs.
The tutorial below covers the instructions to interact with the open testnet.
How to use Sonic testnet
Follow this tutorial to unveil the capabilities of Sonic and experience the next generation of blockchain technology. We use MetaMask in this tutorial, but any wallet that can mimic MetaMask will work.
- Connect wallet
- Go to the Sonic open testnet dashboard
- In the top-right corner, click on Connect
- Choose your desired wallet account and connect
- Go to the account page, unless automatically redirected
- Configure network
- In the Network section, click on Add to MetaMask
- Ensure the network details in your wallet match those on the web page
- Approve the action in your wallet and click Switch network when prompted
- Get testnet tokens
- In the Faucet section, choose a token to request
- Click Request and sign the transaction in your wallet
- We recommend requesting Fantom for gas and various other tokens to test the swapping feature
- Use Sonic Trade
- In the Sonic Trade section, choose a token to swap for another token
- Click on Swap and confirm the transaction in your wallet
- Witness the incredible speed of Sonic!
Behind the scenes
A range of technological innovations have been introduced to enable Sonic to scale Fantom beyond its current potential. This section will provide a more in-depth technical overview of these innovations.
Fantom Virtual Machine
Sonic uses a new virtual machine that achieves superior execution performance compared to the previous Ethereum Virtual Machine implementation.
The Fantom Virtual Machine (FVM) converts EVM bytecode of smart contracts seamlessly into a new virtual machine format on the fly (while executing transactions). Deployed smart contracts that are available only in EVM bytecode remain executable without retranslating the high-level source code (e.g. Solidity) into the new virtual machine format.
The new virtual machine format accelerates the execution of single operations and permits super instructions, optimized bundles of commonly occurring instruction patterns. Super instructions comprise multiple instructions that are consolidated and executed as one instruction, reducing the instruction dispatch time of the virtual machine. The conversion from EVM bytecode to the new format of the FVM is cached, such that subsequent executions of the same code reuse the previously converted EVM bytecode, saving execution time.
The FVM supports caching of cryptographic hashing for the EVM instruction SHA3. Cryptographic operations, especially hashing, are computationally expensive. Repetitive calculations of the identical hashes can occur due to contract operations, state changes, or transaction verifications. By caching previously computed hashes, the FVM can bypass the need to recalculate the same values, saving time and resources.
Additionally, the FVM supports the caching of JUMPDEST analysis results. In the virtual machine, there are special instructions called JUMP and JUMPDEST. The JUMP instruction allows the code to leap to different locations, while JUMPDEST marks safe places for these jumps to land. The JUMPDEST analysis pre-scans the bytecode to map out all these safe landing spots. By doing so, the FVM ensures that during execution, any jumps are directed only to legitimate and safe points in the code, optimizing performance and increasing security against potential malicious manipulations.
Block processing intense operations, such as synchronizing a new validator with up to 65 million blocks from the first block, can take up to four weeks with Opera. Sonic’s advanced block processing, which includes the FVM and new database storage, can synchronize a new validator in less than two days entirely for the full range from scratch.
Carmen database storage
Sonic uses a new database storage, called Carmen, which reduces node storage requirements and improves performance. Carmen is a new StateDB that stores the world state of Fantom’s blockchain. The world state contains account information, such as balance, nonce, EVM bytecode, and persistent storage of smart contracts.
Carmen features implicit live pruning. Pruning refers to discarding historical data that is no longer needed, which is essential due to a growing blockchain with increasing storage demands. Previously, pruning required nodes to be offline, which burdened validators with financial and operational risks due to their temporary lack of network rewards and the pressure to restart the client software successfully after offline pruning. However, unlike on Opera, validators now can leverage live pruning to remain operational around the clock, preventing disruptions. Consequently, validators will require smaller disks that can yield savings of up to 65% using Sonic’s new database storage.
We achieve live pruning by specializing the database into two types: the LiveDB and the ArchiveDB. The LiveDB contains the world state of the current block only, whereas the ArchiveDB contains the world states of historical blocks of the blockchain. The diagram below shows the interaction of LiveDB and ArchiveDB with the block processing.
The FVM interacts with the LiveDB and the ArchiveDB. As mentioned, the LiveDB contains only the current world state and is optimized for progressing the world state from one block to the next. Validators only have a LiveDB but no ArchiveDB. The FVM reads and writes the data in the LiveDB. In contrast, archive nodes have the LiveDB and ArchiveDB to stay synced. They process requests of historical states via the RPC interface. Its data is read only by the RPC server, and the FVM adds the world state of new blocks.
This specialization of LiveDB and ArchiveDB has been a performance-critical insight for an efficient StateDB design and implementation. We discovered that the access patterns of validators and archive nodes require different implementation techniques. So far, we have developed five evolutionary steps, so called schemas, for LiveDB and ArchiveDB, which differ in how the world state is structured and stored on disk for LiveDB and ArchiveDB, respectively. The version deployed for the Sonic testnet, Schema 3, offers superior storage performance compared to Opera’s MPT data structure.
Schema 3 uses flat storage, which stores data sequentially instead of tree-like or hierarchical structures like the ones used in the MPT. Its flat storage approach simplifies data retrieval. Importantly, Schema 3 still provides cryptographic signatures for a world state and archive capabilities using an incremental version of a prefix algorithm. All schemas utilize a native disk format rather than storing the world state indirectly via key-value stores (e.g. LevelDB/PebbleDB).
Lachesis consensus mechanism
Lachesis is Fantom’s aBFT consensus mechanism. A consensus mechanism is the engine that receives user transactions and serializes them to form blocks. Lachesis has a peer-to-peer module that exchanges events and a transaction pool module for collecting transactions from users and queuing them for validators.
Sonic continues to use the Lachesis technology of Opera, but it has vastly improved the transaction pool for collecting transactions of users. Optimizing and fine-tuning the peer-to-peer network was essential for sustaining such high transaction throughput with a very low time to finality.
Sonic and Opera comparison
A summary of the key differences between Fantom Sonic and the Opera mainnet is shown below.
Summary of Sonic
As shown by the performance of the Sonic closed testnet, the mainnet release will bring a groundbreaking blockchain experience, which we have summarized below for a quick overview.
Sonic is anticipated to achieve beyond 2,000 TPS at a finality of around one second. However, as this is the upper limit, the network will offer a far quicker sub-second finality under real-world circumstances. Storage requirements are reduced by up to 90%, which reduces validator node size from around 2,000 GB to 300 GB and non-pruned archival node size from above 11 TB to below 1 TB.
The storage reductions will allow anyone to launch validator nodes at far lower costs with vastly improved synchronization times and live-pruning support. The Fantom Foundation, and other relevant parties, can deploy archival nodes in approximately 36 hours, which previously would take weeks. If a genesis file for a certain block height is available, or an actual copy of an archive StateDB, the synchronization will be even shorter.
The Sonic mainnet is scheduled for spring 2024, which will transport Fantom into a new era of blockchain technology.
Source:
