Introducing Yona Network Real-time Blockchain

Yona Network introduces the concept of an SVM-based real-time blockchain with such minimal on-chain response times and latencies that, instead of competing for a higher TPS count, transactions are now simply processed in real time. How was this achieved?

To understand the process, which showcases the results of the Yona Labs engineering team's R&D, it's necessary to clarify a few definitions:

• Transaction latency: the time between receiving a transaction via a node's RPC API and including it in a finalized block.
• Transaction throughput: the number of transactions per second that a node can process.
• Finality: in blockchain, this refers to the irreversible confirmation of a transaction or group of transactions.

Thus, latency is the time between issuing a transaction and its completion. It's crucial for this time to be as short as possible so that the average consumer doesn’t feel frustrated. However, more significant consequences can arise if high latency affects institutions in the financial world.

The second key concept to understand is finality. Finality is the process by which the protocol guarantees the acceptance of a transaction. Latency and finality are closely related, as latency impacts finality. This process ensures that no entity can cancel or alter transactions. Finality is exactly what users expect when performing a transaction on the blockchain. It’s important to note that the finality offered by first-generation blockchain technology is probabilistic. This means that a certain number of blocks need to be added to the chain before a transaction is considered fully completed.

For example, in the Bitcoin blockchain, a transaction becomes immutable after approximately six blocks. Since it takes about 10 minutes to add a new block to the Bitcoin blockchain, it means that around an hour will pass before the transaction becomes irreversible.

The current transaction latency on Solana's mainnet can be roughly calculated as 400 ms (slot time) * 32 (number of blocks needed to be added on top of the transaction block) — about 12 seconds.

Transaction throughput depends on the configuration of the specific blockchain instance and the characteristics of the servers that support its operation. Essentially, this is the upper limit of the data transmission capacity, both from the hardware side and the on-chain side. In its current implementation, Solana’s time synchronization mechanism between nodes can theoretically support a peak performance of 65,000 transactions per second.

In the test configuration for determining the potential speed of Yona Network, only one leader node was used, allowing transactions to be considered final as soon as they were included in a confirmed block (as if the majority of 66% had voted).

The current lifecycle of a transaction in Solana looks like this:

The transaction enters via RPC -> decoding -> simulation -> tx is serialized and sent to the node via gossip -> tx arrives via gossip -> decoding, sanitization -> actual processing.

This process introduces a lot of overhead, delaying transaction processing and reducing throughput. Even with a significant reduction in slot time, maximum latency can still reach several seconds.

Therefore, Yona Network engineers proposed a simultaneously elegant and simple solution: transmitting transactions from RPC directly to the transaction processing block using intra-process messaging. This significantly reduces all network latencies.

Research and Latency Reduction

How latency was measured: The Yona node records the time a transaction is received via RPC and sends this information to a "latency measurement" stream. To reduce overhead, only one transaction is checked at any given time (randomly selected). The stream continuously checks whether the transaction is included in the "Optimistically Confirmed Bank." Once inclusion is detected, the time (in milliseconds) is recorded using Solana's metrics library.

Solana uses slots. A slot in Solana is a fixed time interval, currently set to 400 milliseconds, during which a validator can issue a block. Slot duration and related constants are controlled by the DEFAULT_TICKS_PER_SECOND value in the sdk/clock/src/lib.rs file. Increasing this value reduces the slot time. During research, it was found that this value could be increased to 2000, resulting in a slot duration of about 40 milliseconds.

And the Yona Network engineers managed to achieve these results without using high-end hardware! According to research data, slot time was reduced to 40 ms, with maximum latency dropping from 2 seconds to 100 ms. The 95th percentile is around 40-50 ms, meaning 95% of transactions are processed in the next slot. Experimental results were also achieved with a slot time of 10 ms.

Benchmark results

1. Hardware specs: Gigabyte B550 AORUS ELITE V2, AMD Ryzen 5900x, 32 Gb DDR4 RAM. OS: Ubuntu 22.04 LTS.

2. With Yona Optimizations and bench arguments: --threads 24 --tx-count 60000 and 40ms slot time.

3. Without optimization, agave client is not able to handle --threads 24 --tx-count 60000 with 40ms slot time. Latency peaks increase greatly, TPS doesn't go above 20000.

4. Unoptimized node can handle --threads 24 --tx-count 60000 only if slot time is increased to around 70ms. Peak latency values are still above 1 second. TPS is around 35000.

It was also observed during the research that further reducing the slot time leads to a decrease in throughput and an increase in transaction latency. Therefore, the development team is currently focused on investigating why performance drops after reducing the slot time to 40ms, with the goal of bypassing this limitation and achieving even greater speed. Additionally, there are plans to implement faster synchronization primitives (the Solana client primarily relies on the standard Rust library). Introducing more efficient data structures is also expected to improve speed — for instance, using SmallVec instead of the standard Vector to reduce heap allocations.

Moreover, increasing speed to real-time will enable new use cases, which could be related to high-frequency trading (HFT), various fast markets and events, the full development of on-chain messengers, and others that will emerge over time as new primitives and mechanics are introduced.

About Yona Network

Yona is a real-time latency Bitcoin L2 blockchain enabling Web2 experience for dApps. We use custom hyper-optimized modularized SVM to achieve superior performance with less than 10ms latency and block time. Yona enables lightning-fast transactions and offers limitless scalability, paving the way for next-generation protocols tailored to enhance the user experience within the Bitcoin ecosystem.

Yona Network links:

Website | Documentation | Twitter | Discord | Blog