Solana Changelog: Exciting Updates and Developer Resources

In the latest episode of the Solana Changelog, Nick from the Solana Foundation DevRel team and Jonas dive into the recent developments, commits, and resources in the Solana ecosystem. This week's changelog brings exciting news about Old Faithful RPC, verified builds in the Solana Explorer, and a new transaction size specification, among other updates.

Agave Installer: A Word of Caution

As developers transition to Agave and the version 2 updates, it's crucial to be aware of a potential issue with the Agave installer. When running the installer to update your local CLI, there's a risk that it could remove your local key pairs.

Nick emphasizes the importance of backing up your local key pair before installation:

"Make sure you back up your local key pair. So your ID dot JSON that your Solana CLI uses by default. Back that up before you do the installation, just in case."

A pull request is currently open to address this issue, but until it's merged, developers should exercise caution and ensure their key pairs are safely backed up.

Old Faithful: Revolutionizing RPC Nodes

One of the most exciting developments discussed in this changelog is the progress of Project Old Faithful. Brian Long from Triton, the organization behind Project Yellowstone, recently gave an impressive demonstration of Old Faithful on the core dev call.

Old Faithful is a groundbreaking project that stores the entire Solana ledger history on Filecoin. What's particularly noteworthy is that it now supports running a complete RPC node using Old Faithful and Filecoin as the ledger history source.

Nick explains the significance of this development:

"You can do all of the things like get signatures for account and all of those like historical access sort of RPC methods. You can actually do that directly off of Filecoin."

This advancement represents a significant step towards decentralization in the Solana ecosystem. By leveraging Filecoin for ledger history storage, Old Faithful offers an alternative to traditional centralized RPC nodes, potentially improving the network's resilience and reducing reliance on a single point of failure.

Steel v2: Native SDK Enhancements

The changelog also highlights the release of Steel v2, an updated version of the native SDK developed by HardhatChad. This new version brings improvements and additional features to the SDK, making it easier for developers to build on Solana using native code.

Jonas mentions that there are now program examples available for Steel v2 in the Solana program examples repository. However, he notes that it's still missing an IDL (Interface Description Language):

"What it's missing still is an IDL. So if any one of you is like feels like coding over the weekend, maybe you could just add an IDL for it. I think it would really help its composability."

This presents an opportunity for community contribution, as adding an IDL would significantly enhance the usability and integration capabilities of Steel v2 within the Solana ecosystem.

Solana Explorer: Verified Builds and Multi-sig Support

The Solana Explorer has received notable updates, courtesy of Noah Gundotra from the Solana Foundation. These enhancements provide users with more detailed and transparent information about deployed programs.

Verified Builds

One of the most significant additions to the Explorer is the display of verified builds. This feature allows users to confirm that a deployed program matches its source code, enhancing transparency and trust in the ecosystem.

Jonas expresses his excitement about this feature:

"This is a feature I'm actually super excited about. So it's being built by Autosec and Ellipsis Labs. And what it allows you to do is basically to verify that your program that you deployed is actually built from its source code."

The verification process involves building the program in a controlled environment (such as a Docker container) and comparing the resulting hash with the on-chain hash. This information is then displayed in the Solana Explorer, allowing anyone to verify the authenticity of a deployed program.

Multi-sig Support

Another valuable addition to the Explorer is improved multi-sig support. Users can now view detailed information about multi-sig upgrade authorities for programs. Nick highlights this feature using the token extension program (Token 22) as an example:

"We have multi-sig support. So the multi-sig, this program has an upgrade authority that's a multi-sig. And you can see here it's in particular using the squads V3 multi-sig program. You see all the multi-sig information, all the signers and everything."

This enhancement provides greater transparency and helps users understand the governance structure of deployed programs, particularly those with multi-signature upgrade authorities.

SIMD 186: Transaction Data Size Specification

The changelog also covers a new Solana Improvement Document (SIMD) proposal, SIMD 186, which addresses the need for a standardized transaction data size specification.

SIMD 186, opened by HANA from ANSA, aims to create a clear and consistent method for calculating transaction sizes. Nick explains the current issue:

"The way that transaction, the total size that a transaction uses, the way it's calculated is sort of non-standardized, non-specific. There's no specification."

The proposal seeks to solve problems such as double-counting of certain accounts and standardize the calculation algorithm across validator clients. This standardization will make it easier for any validator client to implement the calculation correctly, ensuring consistency across the network.

Solana StackExchange: Community Engagement

The changelog concludes with a shoutout to the top contributors on the Solana StackExchange. This week's leaderboard features Mitch, Jimmy, Chalda, Callum, and Wicom.

Jonas emphasizes the importance of community participation in the StackExchange:

"Whatever you help here, it helps the current developers and the future developers. So super happy to see so many people participating in stack exchange."

This recognition highlights the collaborative nature of the Solana ecosystem and the vital role that community members play in supporting and educating fellow developers.

Commits and Technical Updates

The changelog also covers several commits and technical updates to the Solana codebase. While some of these changes may seem minor, they contribute to the overall improvement and maintenance of the Solana network.

Logging Function Refactor

One notable change is the movement of logging functions into their own crate. Nick explains:

"John Chink was moving the logging functions into its own crate just to clean up a little bit. But you may need to use the different import now in your programs. So it's like Solana message, Cisco, it's now."

This refactoring improves code organization and may require developers to update their import statements in existing programs.

NixOS Support

Jonas highlights an interesting development related to NixOS support:

"Someone is trying to build in NixOS, which is really cool. And you can also use NixOS. So I'm very excited that people are trying this out. I also tried it last week. Maybe we come up with an example at some point."

NixOS is a Linux distribution that takes a unique approach to package and configuration management. The fact that developers are working on Solana support for NixOS demonstrates the growing diversity of development environments within the ecosystem.

The Importance of Verified Builds

The introduction of verified builds in the Solana Explorer deserves further exploration, as it represents a significant step forward in terms of transparency and security for the Solana ecosystem.

Verified builds allow developers and users to confirm that the code deployed on-chain matches the source code in a public repository. This feature is crucial for several reasons:

1. Transparency: It allows anyone to verify that the program they're interacting with is indeed the one they expect, based on the public source code.

2. Security: It helps prevent malicious actors from deploying modified versions of open-source programs, as any discrepancies would be easily detectable.

3. Trust: It builds trust in the ecosystem by providing a clear link between on-chain programs and their source code.

4. Auditability: It makes it easier for auditors and security researchers to review programs, as they can be confident they're looking at the correct source code.

Jonas explains the verification process in detail:

"What you basically do is you build your program in a Docker container or in maybe later in a Nix container or something like this. And then you can verify your repository towards a repository. So you put your URL of the repository. And then you can, it creates a PDA on-chain that writes all the data that's needed to verify the program."

This process ensures that the build environment is consistent and reproducible, which is crucial for obtaining consistent results. The use of a PDA (Program Derived Address) to store verification data on-chain is a clever solution that leverages Solana's account model to provide transparent and accessible verification information.

The Future of RPC Nodes with Old Faithful

The advancements in Old Faithful and its integration with Filecoin represent a significant shift in how RPC nodes can be operated in the Solana ecosystem. Traditional RPC nodes require substantial storage and computational resources to maintain a full copy of the ledger history. This can be a barrier to entry for many potential node operators.

By leveraging Filecoin's decentralized storage network, Old Faithful offers several potential benefits:

1. Reduced Resource Requirements: Node operators may not need to store the entire ledger history locally, potentially lowering the hardware requirements for running an RPC node.

2. Improved Decentralization: With lower barriers to entry, more individuals and organizations may be able to run RPC nodes, enhancing the network's decentralization.

3. Data Persistence: Filecoin's incentive structure ensures that data remains available over time, potentially providing more reliable access to historical data.

4. Scalability: As the Solana ledger continues to grow, leveraging a distributed storage solution like Filecoin could help address long-term scalability concerns for RPC nodes.

Nick's excitement about this development is evident:

"You can run an entire RPC node off of Old Faithful and Yellow and Filecoin as your ledger history. So you can do all of the things like get signatures for account and all of those like historical access sort of RPC methods. You can actually do that directly off of Filecoin."

This innovation could pave the way for a more diverse and resilient RPC node infrastructure in the Solana ecosystem, potentially improving the network's overall performance and reliability.

The Significance of SIMD 186

The proposal for a standardized transaction data size specification (SIMD 186) may seem technical, but its implications for the Solana network are substantial. Standardizing how transaction sizes are calculated addresses several important issues:

1. Consistency: By providing a clear specification, all validator clients can implement the calculation in the same way, ensuring consistent results across the network.

2. Fairness: A standardized calculation prevents potential exploitation of ambiguities in the current non-standardized approach.

3. Efficiency: Resolving issues like double-counting of certain accounts can lead to more accurate and efficient use of network resources.

4. Predictability: Developers can more reliably estimate transaction sizes, which is crucial for fee estimation and transaction planning.

Nick describes the proposal as "relatively simple to get approved" but emphasizes its importance:

"It'll make it so the account data calculation, the algorithm, super simple algorithm actually, the way that's gonna be calculated can be standardized across validator clients, which will make it a lot easier for any validator client to implement it."

This standardization effort demonstrates the Solana community's commitment to continual improvement and refinement of the protocol, even in areas that may not be immediately visible to end-users but are crucial for the network's long-term health and scalability.

Community Engagement and Open Source Contributions

The Solana Changelog consistently emphasizes the importance of community engagement and open-source contributions. This week's episode highlights several opportunities for developers to get involved:

1. Steel v2 IDL: Jonas mentions the need for an IDL for Steel v2, encouraging developers to contribute to this project.

2. Solana StackExchange: The recognition of top contributors on StackExchange underscores the value of knowledge sharing within the community.

3. Verified Builds: The open-source nature of the verified builds feature in the Solana Explorer allows developers to understand and potentially contribute to its implementation.

4. SIMD Discussions: The changelog encourages community members to participate in discussions around SIMDs like the transaction size specification proposal.

This focus on community involvement is a key strength of the Solana ecosystem, fostering innovation and rapid development through collaborative efforts.

Conclusion: A Thriving Ecosystem

This week's Solana Changelog demonstrates the vibrant and rapidly evolving nature of the Solana ecosystem. From groundbreaking developments in RPC node technology with Old Faithful to improvements in transparency with verified builds, the community continues to push the boundaries of what's possible in blockchain technology.

The ongoing work on core protocol improvements, as seen with SIMD 186, shows a commitment to refining and optimizing the network's fundamental operations. Meanwhile, the development of tools like Steel v2 and the enhancements to the Solana Explorer provide developers with increasingly sophisticated resources for building on Solana.

As Nick and Jonas wrap up the changelog, their enthusiasm for these developments is palpable. The Solana ecosystem is clearly in a state of constant innovation, driven by a passionate community of developers, researchers, and users. As these projects mature and new ideas emerge, it's clear that Solana is positioned for continued growth and success in the blockchain space.

Facts + Figures

• Old Faithful now supports running a complete RPC node using Filecoin as the ledger history source
• Steel v2, an updated version of the native SDK, has been released with new program examples available
• The Solana Explorer now displays verified builds, allowing users to confirm that deployed programs match their source code
• Multi-sig support has been added to the Solana Explorer, providing detailed information about multi-sig upgrade authorities
• SIMD 186 proposes a standardized transaction data size specification to address inconsistencies in calculation across validator clients
• The Agave installer may potentially remove local key pairs, requiring users to back up their ID.json file before installation
• Verified builds in the Solana Explorer use a PDA (Program Derived Address) to store on-chain verification data
• The verified build process involves building programs in controlled environments like Docker containers
• NixOS support for Solana development is being explored by community members
• The Solana StackExchange leaderboard for the week features Mitch, Jimmy, Chalda, Callum, and Wicom as top contributors
• Logging functions in the Solana codebase have been moved to their own crate for better organization
• The Old Faithful project stores the entire Solana ledger history on Filecoin
• Verified builds in the Solana Explorer are implemented by Autosec and Ellipsis Labs
• The Solana Explorer updates were made by Noah Gundotra from the Solana Foundation
• The token extension program (Token 22) is used as an example to demonstrate multi-sig support in the Explorer

Questions Answered

What is Old Faithful and how does it work with Filecoin?

Old Faithful is a project that stores the entire Solana ledger history on Filecoin. It now supports running a complete RPC node using Filecoin as the ledger history source. This means developers can perform historical access RPC methods directly from Filecoin, potentially improving decentralization and reducing resource requirements for running RPC nodes.

How do verified builds enhance transparency in the Solana ecosystem?

Verified builds, now displayed in the Solana Explorer, allow users to confirm that deployed programs match their source code. The process involves building the program in a controlled environment (like a Docker container) and comparing the resulting hash with the on-chain hash. This feature enhances transparency by providing a clear link between on-chain programs and their public source code, increasing trust and security in the ecosystem.

What is SIMD 186 and why is it important?

SIMD 186 is a proposal for a standardized transaction data size specification in Solana. It aims to create a consistent method for calculating transaction sizes across all validator clients. This standardization is important because it addresses issues like double-counting of certain accounts, ensures fairness in resource usage, and makes it easier for developers to accurately estimate transaction sizes and fees.

What new features have been added to the Solana Explorer?

The Solana Explorer now displays verified builds and provides enhanced multi-sig support. The verified builds feature allows users to confirm the authenticity of deployed programs. The multi-sig support provides detailed information about multi-signature upgrade authorities for programs, improving transparency around program governance structures.

What is Steel v2 and what improvements does it bring?

Steel v2 is an updated version of the native SDK for Solana development. It brings improvements and additional features to make it easier for developers to build on Solana using native code. While specific improvements weren't detailed in the changelog, it was mentioned that program examples for Steel v2 are now available in the Solana program examples repository.

How can developers contribute to the Solana ecosystem based on this changelog?

Developers can contribute by adding an IDL (Interface Description Language) to Steel v2, participating in discussions around SIMDs like the transaction size specification, contributing to the Solana StackExchange by answering questions, and exploring NixOS support for Solana development. The open-source nature of many Solana projects also provides opportunities for direct code contributions.

What precaution should developers take when using the Agave installer?

Developers should back up their local key pair (ID.json file) before running the Agave installer. There's a potential issue where the installer might remove local key pairs during the update process. A pull request is open to address this, but until it's merged, backing up key pairs is crucial to prevent potential loss of access to accounts.