The SSV Network DAO is happy to see SSV Labs release the Alan fork. This article was originally posted by SSV Labs team.

Thank you, Matheus, Taiga, Moshe, and Robert, for co-writing.

The SSV Labs team is excited to see the launch of the latest SSV Network upgrade – Alan. Due to the considerable growth of the network, the Alan Fork is a vital scaling upgrade to ensure the continued stability and performance of the protocol. This blog post will dive into the specifics of the Alan Fork, why it’s important, timelines, and how to get ready for the fork going live on testnet 22/09/2024. 

TL;DR

• Welcome Alan: The Alan Fork is a significant scaling upgrade for the SSV Network, designed to handle its rapid growth and to future-proof the protocol.
• Crunching the Numbers: Resource usage improvements—CPU time reduced by 54%, and bandwidth consumption down by 80-90%, making the network more efficient.
• The Reseach: Key optimizations include Committee-Based Consensus and better subnet assignment, significantly reducing network message volume.
• Start Updating Your Nodes: Operators —update your nodes and start testing Alan on testnet before the fork!
• What’s Next: Further optimizations are being done, focusing on network topology and performance enhancements.

Fork That, We’re Scaling!

Since SSV Network’s mainnet launch in December 2023, the protocol’s growth has far exceeded expectations. Within half a year, SSV has reached the top 5 staking providers on Rated, highlighting SSV’s DVT infrastructure’s crucial role in the ETH staking ecosystem. In just over 9 months, SSV has secured 1.4 million ETH, distributed over 43K validators across 1,000 globally distributed node operators, and has been integrated into the industry’s top Re/Staking applications. This is why scaling is essential. 

The fork is named after Alan Turing – the father of modern computing. Since Alan starts with A, it symbolizes SSV Network’s first official fork on mainnet and the continued evolution of the protocol. As Alan has revolutionized the world of computer science, so will the fork revolutionize how the SSV Network approaches consensus. 

Scaling is necessary to accommodate the influx of participants, users, and builders joining the SSV ecosystem. SSVlabs and other contributors have been working tirelessly to crack the scaling problem. As such, the Alan fork does two things:

• Reduces messages needed for performing consensus by implementing Committee Based Consensus.
• Reduces network message processing by better-assigning subnets to operators.

The above essentially means Alan enables the network to scale by reducing the amount of computation an operator needs to perform. The update will achieve this by reducing the number of messages on the network and optimizing message distribution on the p2p/network layer. 

Timelines:

Timelines are subject to change. Users will be notified if any significant changes occur in the SSV Discord.

Crunching the Numbers for Alan

Overall, the results from internal tests have been staggering. Regarding CPU time, receive/transmit bandwidth, and average consensus time, there have been improvements from 50% to around 90%. Let’s dive into the numbers below! 

CPU-Profiling

One of the methods used to determine Alan’s benefits is to run CPU profiling on the SSV node. It allows the analysis of CPU time spent on each process and function running within the stack over a specific time period. The Holesky-based devnet environment was analyzed for initial testing to see where potential bottlenecks arose. 

Samples

The samples were taken over a ~5h period, collecting 14.1 Trillion CPU samples. Prefork used 3.30 hours of CPU time, whereas postfork used 37.5 minutes. 

Figure 1 is split into two flamegraphs (one above the other below). The top section is prefork; the bottom is postfork. Figure 2 is another flamegraph showing what is commonly known as the “diff”: the difference between prefork and postfork, using prefork as the baseline for comparison.

Figure 1:

Figure 2:

Figure 2 helps to understand precisely where the Alan fork takes less or more CPU time in the code compared to the baseline (prefork). The size of each block indicates the share of CPU taken out of the total graph, whereas the color intensity reflects the magnitude of increase/decrease. In this case, seeing large spans of (intense) green blocks means that there have been significant improvements to the parts that used to take a large share of CPU time.

Important note: While the SSV Labs team is happy to share the fantastic results and benefits observed, these conditions might differ from those on the testnet and later on mainnet. Since there’s no actual data from testnet yet, Alan has only been tested on internal devnet networks. 

Telemetry

The other method used to test Alan in the staging environment is telemetry. In the research on the Alan Fork, telemetry was used to track how the SSV Node performs over time. It helped measure CPU usage and network traffic before and after the upgrade.

The presented results are based on sustained duty-performing telemetry for 500-validator SSV node operators. Collected data is from identical time frames and underlying hardware.

Current Holesky-based telemetry averaged over time and adjusted:

Validator count was used to adjust data despite the fact that it is the “pessimistic” case (since the Alan fork specifically targets aggregation). 

Similarly, this led to significant improvement in SSV-specific metrics:

Diving Into the Research

In the SSV Network, a validator is decentralized using multiple operators, termed a cluster, i.e., a group consisting of operators and the validator owner’s address. In many cases, this group of operators manages not only one validator but several. When a specific group of operators shares at least one validator (potentially many), it’s called a committee. Why is the definition of committee important? It’s the root of the ssv.network’s most recent optimization – committee-based consensus.

Until now, every validator’s duty incurred one consensus execution on the network. This seemed reasonable since the operators must agree on the data to be signed for the duty. However, it was noticed that the cost of this process can be reduced. In reality, the many consensuses running in parallel actually decide on the same data. Therefore, they could easily be grouped into a single execution. Let’s understand it with an example.

Suppose a committee of 4 operators runs 500 validators. In some slots, many of these validators will share an attestation duty (on average, 500/32 ~ 15.6). As mentioned, the committee would start one consensus execution for each duty. However, all of these consensuses are equally deciding the blockchain’s current head, source, and target (Casper FFG and LMD GHOST votes). Therefore, the network could instead run a single consensus and use this agreed value for all validators. That is precisely what the ssv.network calls the Committee Consensus. There is a little extra: sync committee duties may also be grouped since it also runs a consensus on the same data.

This optimization forced a rethink about how operators select subnets for exchanging messages. Until now, all messages related to a validator would be exchanged on a subnet computed using the validator’s public key. With this new optimization, that approach would result in unnecessary duplicated messages across different subnets. Calling for a perspective shift, operators now determine subnets based on the committee responsible for the duty, using the committee’s identifier to compute the subnet. This allows the optimization to take place without duplicating messages in the network.

As expected, this optimization will significantly reduce the number of messages exchanged across the network, saving operators’ resources and allowing the network to scale. Using data from Mainnet, estimates show that the total number of messages exchanged per second in the network will drop from approximately 1800 to 300. Moreover, the average number of subnets an operator needs to participate in will fall from 81 to just 3, reducing the number of messages that need to be processed even further.

Alan Fork in a Nutshell 

• Enhances Scalability
• Optimized Resource Usage
• Improved Consensus Efficiency
• Network Load Reduction

Preparing for the Alan Fork 

If you’re a network participant wondering, ‘What should I do?’ The following are step-by-step instructions for getting ready for the fork. 

Important note: The ssv.network asks that all Node Operators update their software to the latest node version as soon as possible. This is not only to test your validators on Alan but also for the ssv.network to gather as much data as possible to see how Alan runs before going to mainnet. 

Node Operators:
Upgrade to this version of the node before the Holesky testnet fork (08/10/2024). This is only for testnet operators, NOT mainnet.

If you need help or have questions, drop a message in the Discord operator-channel or open a support ticket.

Stakers/Builders:
The ssv.network encourages both participants to register validators to the testnet to help test the new version.

What’s Next?

Network Topology

Rethinking the operators’ subnet participation has led to further investigation of the potential gains in this area. One simple and powerful idea is to put similar committees on the same subnet while separating disjoint ones. Simply put, if committee A shares operators with B, and C shares with D, it’s more efficient to put A and B on one subnet and C and D on another. The trade-offs of this optimization are being carefully reviewed, but overall, it promises a great scalability improvement.

Future-Proofing SSV Network
The Alan Fork isn’t just an upgrade – it’s the next step in growing the SSV Network Ecosystem. By unlocking new levels of scalability and efficiency, Alan sets the stage for the SSV Network to support even greater growth and innovation in Ethereum Staking.

Website | Builders Hub | Network Hub | Discord | Dev Center | Documentation | GitHub