1. Introduction
Robert opened the meeting by welcoming all participants, especially Matheus from the SSV Labs R&D team. The primary focus of the discussion was the much-anticipated Allen Fork of the SSV Network. Robert highlighted that the Allen Fork brings numerous exciting improvements, particularly in scalability and performance. He expressed gratitude to Matheus for joining the conversation and looked forward to insights about the upgrade and the team’s pioneering work in consensus mechanisms.
2. Necessity of the Allen Fork
1. Scalability Challenges in Distributed Systems
Matheus began by emphasizing that scalability and performance are critical factors when designing distributed systems. Distributed systems aim to improve the fault tolerance of services, but they involve communication between multiple machines through messages, which can be resource-intensive. Therefore, scalability has always been a significant challenge in distributed systems.
2. Growth Demands of the SSV Network
Robert mentioned that since the Mainnet launch in December, the SSV Network has experienced substantial growth. Currently, over 1.6 million ETH is staked on the network, operated by more than 1,000 globally distributed node operators. From Lido to EtherFi and numerous professional node operators, the adoption of SSV has been remarkable. Addressing scalability now, before potential issues arise, is considered the best approach as the network continues to expand.
3. Details of the Allen Fork
1. Previous Design and Issues
a. Separate Consensus Process for Each Validator
- In the initial design of the SSV Network, node operators needed to execute a series of steps for each validator to fulfill their duties.
- Each validator had its own consensus process, requiring node operators to reach an agreement for each validator and generate corresponding signatures.
- When a committee (a group of operators) managed multiple validators, they needed to perform separate consensus processes for each validator, leading to a significant amount of redundant work.
b. Scalability Bottleneck
- When operators managed a large number of validators, such as 100 or even 500, they had to execute an equivalent number of consensus processes.
- This design led to an explosive growth in the number of messages the system needed to handle, causing a performance bottleneck.
2. Improvements Introduced by the Allen Fork
a. Introduction of Committee-Level Consensus
- The key improvement of the Allen Fork is elevating the consensus process from the “per-validator” level to the “per-committee” level.
- For committees with the same group of operators, regardless of how many validators they manage, only one consensus process needs to be executed per slot.
- This significantly reduces the number of consensus processes that need to be performed.
b. Significant Reduction in the Number of Messages
- By adopting committee-level consensus, the number of messages decreased from 1,800 per second to 300 per second.
- This means that the number of messages has been reduced to approximately 16% of the previous volume, greatly enhancing the efficiency of the network.
c. Optimization of the Publish/Subscribe Module
- Previously, node operators needed to subscribe to specific topics for each validator, which could result in them needing to subscribe to a large number of topics.
- After the Allen Fork, operators only need to subscribe to topics based on committees, significantly reducing the number of topics they need to monitor.
- Actual data shows that the number of topics subscribed to by operators dropped from an average of 81 to just 3.
4. Efficiency Gains from the Allen Fork
1. Reduction in Message Volume
- By elevating the consensus process to the committee level, the number of messages transmitted and processed has been significantly reduced.
- Message handling efficiency has improved, with operators receiving only messages relevant to them, reducing unnecessary communications.
2. Decrease in Bandwidth and CPU Usage
- In the testnet data, operators’ bandwidth usage decreased on average by 80% to 90%.
- CPU usage also dropped by 54% because there were fewer messages to process and fewer cryptographic verifications to perform.
3. Direct Impact on Node Operators
- The reduction in resource demands means that node operators may not need as high hardware specifications as before.
- This could lower operating costs and attract more operators to join the network.
5. Impact on Node Operators
1. Reduced Hardware Strain
- The decrease in bandwidth and CPU usage implies that node operators could potentially run nodes on less powerful hardware.
- This can make running nodes more accessible and cost-effective.
2. Operational Changes
- Node operators need to update their node software to adapt to the protocol changes introduced by the Allen Fork.
- Once updated, they will automatically benefit from the performance and efficiency improvements.
6. Future Plans of the R&D Team
1. Network Topology Optimization
- Matheus mentioned that the next research focus is on optimizing the network topology.
- The goal is to assign committees to topics more intelligently to further enhance message transmission efficiency.
- For example, assigning committees that share common operators to the same topic to improve message relevance.
2. Continuous Performance Improvements
- The research team has numerous ideas and plans aimed at continually enhancing the performance and scalability of the SSV Network.
- They will build upon the Allen Fork to further explore optimization possibilities.
7. Timeline for the Allen Fork Deployment
- On the testnet, the Allen Fork has been successfully implemented, and the node software update package was released recently.
- The anticipated date for the mainnet fork is November 25, 2023; this date may adjust based on actual conditions, but the team’s goal is to complete it before then.
- Robert urged all node operators to update their nodes promptly to ensure a smooth transition.
8. Closing Remarks and Gratitude
- Robert thanked Matheus for taking the time to explain the Allen Fork in detail and how it helps the network maintain efficient operations amidst continuous growth.
- He appreciated Matheus’s clear explanation and looked forward to having more opportunities to discuss new developments with him in the future.
- Robert also invited all those interested in SSV to meet the team in Thailand if they are attending events there, to learn more about the latest developments.
- The meeting concluded in a friendly atmosphere, with Robert expressing gratitude to all participants.
Postscript:
- Node Operator Reminder: Please update your node software as soon as possible to adapt to the upcoming Allen Fork and enjoy the benefits of improved performance.
- Contact and Interaction: Everyone is welcome to join the SSV Discord to communicate with the team and get the latest information.
