Solana Changelog: Exciting Updates and Optimizations

The Solana ecosystem continues to evolve at a rapid pace, with new developments and optimizations constantly emerging. In this week's Solana Changelog, hosts Nick from the Solana Foundation DevRel team and Jonas discuss several exciting updates that promise to enhance the performance, efficiency, and developer experience on the Solana blockchain.

SIMD-0180: Leader Schedule Migration

One of the most significant proposals discussed in this changelog is SIMD-0180, which focuses on the leader schedule migration. This improvement document, submitted by Justin Starry from Anza, proposes a fundamental change in how validators are selected for the leader schedule and how they cast their votes.

Currently, the system uses the node ID (the identity of the validator) for these processes. However, the proposed change would switch to using the stake account or vote public key of the validators instead. This seemingly small modification has far-reaching implications for the Solana network.

Nick explains, "In a nutshell, this sort of makes a lot of things easier and faster in the code, a lot simpler in the future. And it'll make things like implementing slashing for validators that are trying to produce double blocks easier in the future, which, you know, it's cool."

The potential for implementing slashing mechanisms is particularly exciting, as it would introduce a new layer of security and accountability to the network. Slashing is a process where validators can be penalized for malicious or negligent behavior, such as attempting to produce double blocks.

Jonas expresses his enthusiasm for this development, stating, "I'm excited if slashing will actually come eventually soon." This sentiment likely resonates with many in the Solana community who are looking forward to enhanced network security and validator accountability.

Banking Stage Optimization

Closely related to the SIMD-0180 proposal is a commit that changes calculations in the banking stage. This modification alters the way stake is calculated, using the vote account instead of the validator identity.

Nick observes, "This basically changes the way some of the calculations are currently happening in the banking stage using the vote account versus the node, the validator identity. So they sort of changed the way that that code works."

This change is not just a minor code adjustment but has broader implications for the network's operation. Jonas points out, "I think the two should definitely be a SIMD since it's like changing also how the reward distribution is done every epoch. So Fire Dancer probably also needs to have a say in this."

The mention of Fire Dancer, another key player in the Solana ecosystem, underscores the collaborative nature of these developments. It's clear that changes of this magnitude require careful consideration and input from various stakeholders to ensure they benefit the entire network.

Geyser Plugin Enhancement

Another noteworthy update discussed in the changelog is the addition of support for completed slot status in Geyser plugins. Geyser plugins are powerful tools that allow developers to create custom extensions for Solana nodes, enabling features like custom RPCs, websockets, and alerts.

Nick elaborates on this new feature: "This PR basically just adds the slot status. So specifically for completed. So you can now subscribe with geyser plugins to completed slots. After every slot's completed, you can do whatever you want within a geyser plugin."

This enhancement opens up new possibilities for developers to create more sophisticated and responsive applications on the Solana network. By being able to subscribe to completed slots, developers can trigger actions or updates in real-time as the blockchain progresses, potentially leading to more dynamic and interactive decentralized applications (dApps).

Validator Optimization

An interesting optimization discussed in the changelog relates to how validators handle packet scheduling during their leader window. The hosts highlight a commit by KV that reduces the waiting time for packets from 100 milliseconds to 10 milliseconds.

Jonas describes the change: "Apparently what he figured out is that, um, during the leader window, there is a parameter which, uh, lets the validator wait for 100 milliseconds if there's no, um, packet scheduled. So, and he just changed this to 10 milliseconds, right?"

Nick explains the significance of this seemingly small change: "And basically it's, uh, it's a hard-coded value to sort of the validator, the leader is specifically would start accepting packets for 100 milliseconds. And that's a fourth of the, the slot time that they have, the sort of the amount of time that they have to actually vote and like create their block."

By reducing this waiting time, validators can potentially create more blocks and fuller blocks, leading to improved network efficiency. This optimization demonstrates the ongoing efforts within the Solana community to fine-tune every aspect of the network's performance.

Standalone SVM Applications

Perhaps the most exciting development discussed in this changelog is the addition of example code for creating standalone Solana Virtual Machine (SVM) applications. This contribution from the Anza team provides developers with a blueprint for building custom applications that leverage the power of the SVM.

Nick expresses his enthusiasm for this development: "So someone from the Anza team added basically example code for how to create a standalone SVM application. So the example code they created was how to create your own JSON RPC that uses the SVM."

The example code demonstrates how to implement both the client and server sides of an application, as well as an on-chain program that can be executed. It specifically shows how to implement a custom "simulate transaction" feature.

This development is significant because it opens up new possibilities for developers to create SVM-compatible applications outside of the main Solana network. Jonas notes, "Like I can use the SVM stack for your own projects, basically. And it's actually in the master of xyz. Yeah. Yeah. So first class citizen now."

The ability to use the SVM stack for custom projects could lead to innovative off-chain solutions that still benefit from the security and efficiency of Solana's virtual machine. This could potentially expand the Solana ecosystem beyond its current boundaries, fostering new types of applications and use cases.

Assembly Programming on Solana

The changelog also touches on the topic of assembly programming on Solana, highlighting the work of a developer named Dean who has created a tool for easily setting up assembly programs.

Jonas explains, "So you might have noticed that there is this person called Dean, who is a big proponent of writing programs in assembly. He calls his followers the compiler disrespectals. And what he built is like a very nice tool which lets you very easily set up assembly programs."

While assembly programming is not typically recommended for larger programs due to its complexity and lack of built-in security checks, it can be useful for specific use cases where high performance is crucial. Jonas provides an example: "So if you like have one primitive that at the end of the transaction should like check your token balances or something, or something where you need very high performance, then you can actually write these primitives in assembly and have them be super fast."

The hosts discuss the benefits of assembly programming, including faster deployment times and lower computational unit (CU) costs. For instance, an assembly program can be deployed in only two transactions and may use as few as four CUs, compared to an Anchor program that might cost around 1.8 SOL to deploy.

This focus on low-level optimization demonstrates the Solana community's commitment to pushing the boundaries of blockchain performance and efficiency.

Cross-Language Program Examples

In addition to the assembly programming resources, the hosts mention a repository by Jean Chinkwe that provides examples of Solana programs written in various languages, including C, Zig, and Rust, alongside assembly.

Jonas explains, "So that's also an assembly example, but there's also a C example, a Zig example, and a Rust example. So if you want to really look into optimization, so you can do that."

These cross-language examples serve as valuable resources for developers looking to optimize their Solana programs. They showcase different approaches to common tasks and allow developers to compare performance across languages.

QUIC Protocol Improvements

The changelog concludes with an exciting development in the realm of networking protocols. Alessandro, an engineer believed to be working at Anza, has made significant improvements to the QUIC protocol implementation used by Solana.

Jonas enthusiastically shares, "Alessandro is now improving on the QUIC implementation, and apparently what he managed to do is that this 500 GPS, he can get 500,000 max size transactions per second."

This improvement is particularly noteworthy because it exemplifies the spirit of open-source development. The QUIC protocol, originally developed by Google, is being improved upon by the Solana community, and these improvements are being contributed back to the public repository.

Nick emphasizes the significance of this collaborative effort: "Yeah, it's like the ultimate open source dream. Like people start using, create open source code and technologies, other people use it, and they sort of send those changes back upstream to the original source to make it faster for everyone. Like this is what open source is all about, and this is beautiful."

This improvement to the QUIC protocol could have far-reaching effects, potentially increasing the throughput and efficiency of not just Solana, but any system that uses this protocol. It's a prime example of how the work done within the Solana ecosystem can benefit the broader tech community.

Stack Exchange Contributions

The hosts also take a moment to acknowledge the contributions of community members on Stack Exchange. They highlight several users who have been actively participating in discussions and providing answers to Solana-related questions.

Jonas mentions, "So we have Jimmy here on top place. Then we have some new faces, I think, Shaldha, Dylan, and Deaf4, I think Deaf4, I've seen a few times already. There's Blackhorse and Valorix, and yeah, thank you for coming with me. You're making it easier for everybody to build on Solana for the current and the future developers."

This recognition of community contributions underscores the collaborative nature of the Solana ecosystem. By sharing knowledge and helping each other, these community members are playing a crucial role in making Solana more accessible and easier to develop on for both current and future developers.

Conclusion

The Solana Changelog for October 16th showcases a wide range of developments that are set to enhance the Solana ecosystem. From fundamental changes to the leader schedule and banking stage calculations to optimizations in validator performance and exciting new tools for developers, these updates demonstrate the ongoing evolution of the Solana blockchain.

The introduction of standalone SVM applications, the exploration of assembly programming for performance-critical tasks, and the improvements to the QUIC protocol all point to a future where Solana can offer even greater speed, efficiency, and flexibility to developers and users alike.

As the Solana community continues to collaborate and innovate, we can expect to see even more exciting developments in the future. The open-source nature of these efforts ensures that the benefits extend beyond just Solana, contributing to the advancement of blockchain technology as a whole.

For developers, these changes offer new opportunities to optimize their applications and explore novel use cases. For users, they promise a faster, more efficient, and more secure blockchain experience. As Solana continues to push the boundaries of what's possible in blockchain technology, it's clear that the future holds great promise for this dynamic and rapidly evolving ecosystem.

Facts + Figures

• SIMD-0180 proposes changing validator selection for the leader schedule from using node ID to using stake account or vote public key.
• The proposed change in SIMD-0180 could make implementing slashing mechanisms easier in the future.
• A commit changes calculations in the banking stage to use vote accounts instead of validator identities.
• Geyser plugins now support subscribing to completed slot status.
• A validator optimization reduces packet waiting time from 100 milliseconds to 10 milliseconds during the leader window.
• Example code for creating standalone SVM applications has been added, including client, server, and on-chain program implementations.
• Assembly programs on Solana can be deployed in only two transactions and use as few as four CUs.
• An Anchor program typically costs around 1.8 SOL to deploy.
• A repository by Jean Chinkwe provides examples of Solana programs in Assembly, C, Zig, and Rust.
• Alessandro's improvements to the QUIC protocol implementation allow for processing 500,000 max size transactions per second.
• The QUIC protocol was originally developed by Google.
• Stack Exchange contributors mentioned include Jimmy, Shaldha, Dylan, Deaf4, Blackhorse, and Valorix.

Questions Answered

What is SIMD-0180?

SIMD-0180 is a Solana Improvement Document proposing changes to the leader schedule migration process. It suggests switching from using the node ID (validator identity) to using the stake account or vote public key of validators for selecting leaders and casting votes. This change aims to simplify the code, make it faster, and potentially enable easier implementation of slashing mechanisms for validators producing double blocks in the future.

How does the banking stage optimization work?

The banking stage optimization involves changing the way stake is calculated during this phase of transaction processing. Instead of using the validator identity (node ID), the new method uses the vote account for calculations. This change is closely related to the SIMD-0180 proposal and affects how reward distribution is handled every epoch. It's a significant change that requires input from various stakeholders in the Solana ecosystem.

What new feature has been added to Geyser plugins?

Geyser plugins now support subscribing to completed slot status. This new feature allows developers to create custom extensions for Solana nodes that can trigger actions or updates after every completed slot. It enables more real-time responsiveness in applications built on Solana, opening up possibilities for more dynamic and interactive dApps.

How has validator performance been optimized?

A recent optimization reduces the waiting time for packets during a validator's leader window from 100 milliseconds to 10 milliseconds. This change allows validators to potentially create more blocks and fuller blocks, leading to improved network efficiency. It's an example of the ongoing fine-tuning efforts within the Solana community to enhance every aspect of the network's performance.

What is the significance of the standalone SVM application example?

The standalone SVM (Solana Virtual Machine) application example provides developers with a blueprint for creating custom applications that leverage the SVM outside of the main Solana network. It includes code for implementing both client and server sides of an application, as well as an on-chain program. This opens up new possibilities for off-chain solutions that still benefit from Solana's virtual machine, potentially expanding the ecosystem beyond its current boundaries.

What are the benefits of using assembly programming on Solana?

Assembly programming on Solana can offer significant performance benefits for specific use cases. Assembly programs can be deployed in as few as two transactions and use only four computational units (CUs), compared to higher costs for programs written in higher-level languages. While not recommended for larger programs due to complexity and lack of built-in security checks, assembly can be useful for performance-critical primitives or operations.

How has the QUIC protocol been improved for Solana?

An engineer named Alessandro has made significant improvements to the QUIC protocol implementation used by Solana. These improvements reportedly allow for processing up to 500,000 max size transactions per second. This enhancement not only benefits Solana but also contributes back to the open-source community, as the improvements are being shared with the public QUIC protocol repository.

Who are some of the top contributors on Solana's Stack Exchange?

The Solana changelog highlights several active contributors on the Solana Stack Exchange. These include Jimmy (in the top place), as well as newer faces like Shaldha, Dylan, and Deaf4. Other mentioned contributors are Blackhorse and Valorix. These community members are recognized for their efforts in making it easier for current and future developers to build on Solana by sharing knowledge and answering questions.