What’s this Article About?
Solana is the fastest and most scalable blockchain currently on the market. It is renowned for its transaction speeds, making it the perfect chain for use cases such as payments, gaming, and finance. Irrespective of these feats, Solana’s network has been subject to fear, uncertainty, and doubt (colloquially abbreviated as FUD) regarding downtime. While this FUD has been a legitimate concern in the past, it is currently unwarranted. Why? The engineers at Solana Labs have been working on various network upgrades over the past year, most notably, replacing Solana’s custom raw UDP-based protocol for ingesting transactions with QUIC. We will go over the other network upgrades (Stake-weighted QoS, Fee Markets) that improved Solana’s reliability in future articles.
In this article, we will delve into the mechanics of network protocols, examining TCP and UDP, and explore how QUIC stands as an improvement over both. We will then shift our focus to Solana, discussing the particular advantages this protocol offers. The goal of this article is to give you a comprehensive understanding of why this network upgrade is a significant technical milestone for Solana.
Solana Network Upgrades
On December 13th, 2022, the Solana Foundation published a news article entitled “Solana Network Upgrades”. In this article, they outlined a number of upgrades being made to the network and their respective progress. The upgrades are as follows:
QUIC
- Currently live on Mainnet-beta
Stake-weighted QoS
- Currently live on Mainnet-beta
Fee markets
- Currently live on Mainnet-beta, with RPC and wallet support coming soon
- You can follow its progress here
Transaction size increase
- Currently under development
Compact vote state
- Currently live on Testnet
One of the big reasons as to why Solana has experienced downtime in the past has been due to spam. Some examples include:
- The Grape IDO Spam on Sept 14 2021
- DDoS Attacks that occurred from Jan 6-12 2022
- NFT Mint Spam that occurred from Apr 30 - May 1 2022
Solana has had no reported case of downtime related to spam since the implementation of QUIC. This marks QUIC as a landmark achievement in improving Solana’s network traffic and data ingestion. Before we learning about QUIC, we must first explore the mechanics of network protocols. This better understanding of network fundamentals allows us to recognize the true impact QUIC has on Solana’s network.
What's a Network Protocol?
A network protocol is an established set of rules regarding how data is sent between devices on the same network. Network protocols allow connected devices to easily communicate with one another, regardless of their internals, structure, or design.
Imagine you’re seated across from your friend in a restaurant in Paris. You both decide to speak French, and, as a result, your conversation flows smoothly. Your mutual decision to speak French is an agreement upon a set of grammatical rules, vocabulary, and pronunciation that both parties understand.
Network protocols function in a similar manner for connected network devices, much like how French serves as a “protocol” for your Parisian restaurant conversation. The decision to use TCP, UDP, or QUIC is a decision to agree upon an established set of rules and conventions to exchange information. Adhering to a specific network protocol ensures that connected devices can understand one another without any confusion.
What’s TCP?
Transmission Control Protocol (TCP) is a standardized communications interface for sending streams of data between two endpoints on a network. Vint Cerf and Bob Kahn made the Transmission Control Program, a monolithic protocol that was divided it into a modular architecture consisting of TCP and the Internet Protocol (IP). The entire suite is referred to as TCP/IP. In our case, I am referring to the Transmission Control Protocol and not the entire suite when I use the abbreviation TCP.
Source: Differences between TCP and UDP by Palak Jain S for GeeksforGeeks
TCP is connection-oriented; it requires an established connection between the client and server before data is sent. TCP uses a three-step handshake to establish a connection: synchronize (SYN), synchronize-acknowledge (SYN-ACK), and acknowledge (ACK). You can think of SYN as extending your hand for a handshake and asking if the other person is ready to talk; SNY-ACK as the other person shaking your hand saying they’re ready to talk and asking if you’d like to continue; and ACK as you shaking their hand back saying you’d like to continue talking. Here, a session is established. Both parties know they are connected to one another, and they both agree that they are ready to share information.
TCP breaks data into packets, which are sent across the network. Small amounts of data are added to each packet. This additional data includes a sequence number that is used to detect lost or out of place packets, and a checksum that allows for errors within a packet to be detected.
When a conversation is interrupted, we ask the other person to repeat themselves so we’re sure we heard them correctly. TCP handles interruptions similarly with Automatic Repeat Request (ARQ). When a problem occurs, ARQ to tell the sender to re-send the damaged or lost packet. Then, TCP informs the user to slow down its rate of data transmission and limits the number of unacknowledged packets that can be in transit. Once the error is resolved, TCP has mechanisms in place to avoid congestion and gradually increases its speed.
TCP is not the right protocol for every use case as it sequences all of the traffic. Thus, if one portion of the data is lost or damaged, everything after that package needs to wait. But what if we didn’t have to wait?
What’s UDP?
User Datagram Protocol (UDP) is a standardized communications interface used for transmitting data over a network. Unlike TCP, UDP is connectionless and does not guarantee the delivery, ordering, or duplication of data packets. UDP does not have any handshaking dialogues, which makes data transmission susceptible to any unreliability in the underlying network. This makes UDP faster than other protocols because it does not spend time establishing a connection with the destination. This, however, also leads to people referring to the protocol as the “Unreliable Datagram Protocol”.
Source: Differences between TCP and UDP by Palak Jain S for GeeksforGeeks
UDP works by sending datagrams across the network. Datagrams are a more self-contained set of data with information used for routing from the source to the destination. Datagrams do not rely on other datagrams for routing because of this included information. These datagrams consist of a header and data. The header has four fields, all of which are 16-bits long: an optional source port, a destination port, a length, and an optional checksum. The sending process is as follows:
- The sending application creates a UDP socket
- The sending application puts the data it wishes to send in a UDP datagram, with a header containing the destination port and any other relevant information
- The datagram is sent to the IP layer for routing and delivery
- The IP layer takes the datagram and transfers it to the UDP layer, and is stripped of its header
- The datagram is sent to the application listening on the specified port
Think of UDP as talking to someone across a busy room. You shout at this person, without worring if they’ve heard you or await their response. Here, you want to get your message across quickly without any sort of prolonged conversation. This is risky as they might not have heard everything you’ve said, but it could be very effective.
Why would you want to use a connectionless communications protocol like UDP when you have something more reliable such as TCP? UDP is extremely useful for time-sensitive applications, or cases where some loss of data is acceptable. Losing a few frames playing video games with your friends is infinitely better than continuous pausing and buffering. UDP is also used for VoIP calls, Domain Name System (DNS) queries, and monitoring and logging.
QUIC: An Improvement to TCP and UDP
QUIC, is a standardized transport layer network protocol designed by Jim Roskind at Google in 2013. QUIC aims to be a general-purpose protocol, combining the best of TCP and UDP. It is designed for fast asynchronous communication, like UDP, but has sessions and flow control like TCP.
Source: A Comprehensive Guide to HTTP/3 and QUIC by Anna Monus for DebugBear
QUIC reduces connection time by making the exchange of setup keys and supported protocols as part of the initial handshake. This is crucial because most HTTP connections require Transport Security Layer (TLS) encryption. QUIC creates multiplexed connections between two endpoints using UDP. Here, streams of data reach their endpoint independently of one another. Each QUIC stream is flow controlled so if an error occurs in one stream, the protocol can continue servicing the other streams independently. If a packet is lost or damaged, the data is re-transmitted at the UDP level, and not at the level of QUIC. Even if your network or IP address changes, QUIC allows for a smooth transition since it includes a connection identifier that uniquely identifies the connection to the server, regardless of the source. So, connection can be reestablished by sending another packet because every packet contains this ID, meaning the original connection is still valid.
Imagine you’re in that busy room again, trying to talk to your friend. Except this time you each have an encrypted walkie-talkie. You can talk to your friend, changing topic to topic, without blocking one another. Every time you say something, your friend gives you a thumbs up to acknowledge what you’ve said. If they make a weird face, you know to repeat your message, or even to slow down and enunciate your words. If, for whatever reason, your friend decides to move to another room, you can still continue talking to them without interruption. That is the power of QUIC.
How Solana Implements QUIC
Source: RL1: Surveying Solana by Sal Qadir for Galaxy Digital Research
Solana previously implemented a custom raw UDP-based protocol to pass transactions between RPC nodes and the current leader. This was problematic because of UDP’s connectionless nature - there is no meaningful way to discourage or mitigate abusive behavior. This resulted in the few aforementioned instances of spam- and DDos-related downtime. During a DDoS attack, an attacker bombards the target with a large amount of datagrams. This prevents any sort of legitimate communications from going through, rendering the application unusable. Any sophisticated hacker could spam leaders with transactions directly bypassing RPC nodes with the leader schedule public.
Solana could not have implemented a TCP-based protocol to account for these issues. TCP’s handshake mechanism would incur latency. TCP has a heavier overhead compared to UDP. TCP has ordered delivery, and its algorithms for dealing with network congestion aren’t suited for the quick propagation of transactions and blocks. Solana couldn’t continue using its custom raw UDP-based protocol or it would have an unstable network. Re-implementing core protocols atop QUIC is the most logical choice for Solana to improve its network, and that’s exactly what they did.
QUIC offers a number of advantages to Solana, namely:
- QUIC has a reduced connection establishment time, resulting in lower latency
- QUIC has multiplexing without head-of-line blocking, significantly improves transaction throughput
- QUIC can adapt fast to changing network conditions, a vital requirement for a distributed, decentralized system such as Solana
- Nodes can change their Internet connection or IP address. This does not disrupt ongoing transactions due to the fact that QUIC is not tied to a specific IP address or port
- QUIC is designed with customization in hand, allowing Solana to tweak the protocol to best suit its needs
QUIC has been added to the port(s) that ingest user transactions. This allows for limits to be placed on an actor’s traffic so that the network can focus on processing genuine transactions. QUIC is now live on Solana and was fully adopted to Mainnet-beta with release 1.13.4. Since the adoption of QUIC, Solana has had no downtime related to spam or DDoS attacks. Don’t just take my word for it, verify it for yourself here.
While QUIC is a significant improvement to Solana’s network, the team at Jump Crypto are pushing its boundaries. The team created their own robust and scalable implementation of QUIC in their development of Firedancer, a new validator client for Solana. Firedancer’s networking is designed from the ground up to take advantage of receive-side scaling, a type of hardware-accelerated load balancing. This parallel architecture allows for each CPU core to handle a segment of incoming traffic efficiently. The team has tweeted that:
A demo and thread on Firedancer’s QUIC technical milestone can be found here.
Conclusion
Congratulations! In this article we delved into the fundamentals of network protocols, looking at TCP and UDP in relation to QUIC, and how QUIC benefits the Solana network. Solana’s network has proven to be stable and resilient recently in the face of spam. This is evident by the lack of any downtime with respect to spam or DDoS attacks since the adoption of QUIC. QUIC is a significant technical milestone for Solana as it perfectly aligns with Solana’s design goals of high throughput and low latency. From multiplexing capabilities to efficient packet loss recovery, QUIC puts Solana at the forefront of discussions regarding performance and scalability. QUIC is also highly customizable, as evident by Firedancer’s QUIC technical implementation. This allows Solana Labs and other teams building on Solana to optimize the protocol for specific requirements that change over time.
It is crucial that developers should understand the underlying fundamentals of the network they are building on because of the following reasons:
- It helps with troubleshooting
- It makes developers aware of built-in security features
- It makes developers aware of scalability capabilities and limitation
- It helps developers understand how to optimize their applications for speed, efficiency, and reliability
Understanding QUIC as a Solana developer helps you make more informed decisions on topics from application architectures to transaction errors. Solana is constantly evolving, and so is QUIC. Staying up to date with the latest network changes is the best way to build performant applications on top of Solana. Even if you aren’t a developer, a more technical understanding of QUIC can help you understand why Solana is a performant blockchain, renowned for its speed and scalability.
If you’ve read this far anon, thank you!
Additional Resources / Further Reading
