Solana Changelog: Exciting Updates and Developments

In the latest episode of the Solana Changelog, Nick from the Solana Foundation DevRel team and Jonas discuss recent developments and updates in the Solana ecosystem. This week's changelog covers a range of topics, from NixOS builds to Old Faithful RPC nodes on Filecoin, and introduces exciting new features in the Solana Explorer. Let's dive into the details of these updates and their significance for the Solana community.

NixOS Builds: A Step Towards Deterministic Builds

One of the first topics discussed in the changelog was the removal of an outdated Solana Ledger U-diff binary. While this might not seem particularly interesting at first glance, it highlights an important development in the Solana ecosystem: the use of NixOS for builds.

Jonas explains the significance of this update: "Currently it's very hard to get deterministic builds on Solana. But there's a few options you can use Docker. And you can also use NixOS. So I'm very excited that people trying this out."

NixOS is a small Linux subsystem that can be used to create deterministic builds. This is particularly important for Solana, as it allows developers to create consistent and reproducible builds across different environments. The adoption of NixOS for Solana builds represents a step forward in improving the development process and ensuring greater consistency in the ecosystem.

Logging Functions Crate: Streamlining Code Organization

Another minor but noteworthy update discussed in the changelog was the movement of logging functions into their own crate. This change, implemented by John Chink, aims to clean up the codebase and improve organization.

While this might seem like a small change, it has implications for developers working on Solana projects. As Nick points out, "You may need to use a different import now in your programs. So it's like Solana message, Cisco, it's now."

This update serves as a reminder for developers to stay up-to-date with changes in the Solana codebase and adjust their imports accordingly. It's a small step towards better code organization and maintainability within the Solana ecosystem.

Agave Installer: A Word of Caution

An important announcement was made regarding the Agave installer, which is used to update the local CLI for Agave and version 2 related updates. Nick warns users about a potential issue with the installer:

"As everyone's going through the process of updating to Agave and all the version 2 kind of stuff, you need to update your local CLI. As well, when you run the Agave installer in order to use the Agave tool suite, as opposed to the previous tool suite that was put out by Solana Labs, there's a chance that it could remove your local key pairs."

This issue affects the .config/solana directory, which may be wiped during the installation process. To prevent potential loss of important data, Nick advises users to back up their local key pairs, specifically the id.json file used by the Solana CLI, before running the Agave installer.

While a pull request has been opened to address this issue, it's crucial for users to exercise caution and take necessary precautions when updating their tools.

Project Yellowstone and Old Faithful: Revolutionizing Solana's RPC Infrastructure

One of the most exciting updates discussed in the changelog was the progress made on Project Yellowstone and Old Faithful. Brian Long from Triton, the organization behind Project Yellowstone, recently gave a demo of Project Old Faithful on the core dev call.

Old Faithful is a groundbreaking initiative that stores the entire Solana ledger history on Filecoin. Nick explains the significance of this development:

"What Old Faithful now supports is you can run an entire RPC node off of Old Faithful 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 development represents a major step forward in decentralizing Solana's infrastructure. By leveraging Filecoin's decentralized storage network, Old Faithful provides an alternative to traditional centralized RPC nodes. This not only enhances the resilience of the Solana network but also opens up new possibilities for developers and users who can now access historical data directly from a decentralized source.

Jonas emphasizes the importance of this development: "Because at the moment, everyone uses the same thing basically. And now you have a decentralized and Filecoin. You can use it. You can run your queries to it. It's really amazing."

The integration of Old Faithful with Filecoin demonstrates the Solana ecosystem's commitment to innovation and decentralization, potentially setting a new standard for blockchain infrastructure.

Steel: Native SDK for Solana Development

The changelog also highlighted the release of version 2 of Steel, a native SDK for Solana development created by Hearthead. This update brings new features and improvements to the SDK, making it easier for developers to build on Solana.

Jonas mentions that program examples for Steel are now available in the Solana program examples under the developer repository. However, he notes that the SDK is still missing an IDL (Interface Description Language):

"If any one of you is like feels like coding over the weekend, maybe you could just add an ideal for it. I think it would be really help its composability."

This call to action demonstrates the collaborative nature of the Solana ecosystem, where community contributions are encouraged to improve and expand development tools.

Solana Explorer Updates: Enhancing Transparency and Usability

A significant portion of the changelog was dedicated to discussing recent updates to the Solana Explorer, implemented by Noah Gundotra from the Solana Foundation. These updates bring new features and improvements that enhance the transparency and usability of the explorer.

One of the key updates is the display of verified builds for programs. Nick explains:

"We have verified builds displayed here that this program's been verified. And then we have multi-sig support. So the multi-sig, this, 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."

These updates provide users with more detailed information about the programs they're interacting with, including verification status and multi-sig details. This increased transparency is crucial for building trust and security within the Solana ecosystem.

Verified Builds: A Game-Changer for Program Verification

Jonas elaborates on the verified builds feature, expressing his excitement about this development:

"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 verified builds feature works by creating a PDA (Program Derived Address) on-chain that contains all the data needed to verify the program. This includes information about the build process, repository URL, and hashes that can be compared to ensure the on-chain program matches the source code.

Jonas explains the process: "Basically what the Solana Explorer does, it does a call to get this hash the spidery hash. And then it compares it to the on-chain hash. And then there's also a remote API for it. So you can basically send it to the Autosec API. And what they do, they also build it in the same Docker container on the back end and make sure that the hashes are correct."

This permissionless verification process allows anyone to verify a program, promoting transparency and security within the ecosystem. It not only encourages more open-source projects but also provides users with the assurance that the code running on-chain matches the publicly available source code.

SIMD 186: Standardizing Transaction Data Size Calculation

The changelog also covered a new SIMD (Solana Improvement Document) proposal, SIMD 186, which aims to standardize the calculation of transaction data size. This proposal, opened by HANA from ANSA, addresses the current non-standardized approach to calculating transaction sizes.

Nick explains the significance of this proposal: "Basically the problem statement here is the way that transaction, the total size that a transaction uses, the way it's calculated is sort of non-standardized, non-specific. And HANA is basically proposing a specification for it."

The proposed standardization would solve existing issues, such as double-counting of certain accounts, and provide a simple, consistent algorithm for calculating transaction sizes across all validator clients. This standardization is crucial for ensuring consistent behavior across the network and simplifying the implementation process for different validator clients.

Stack Exchange Heroes: Recognizing Community Contributors

The changelog concluded with a shoutout to the top contributors on the Solana Stack Exchange, recognizing their efforts in helping current and future developers. This week's top contributors included Mitch, Jimmy, Chalda, Callum, and Wickham.

Jonas emphasizes the importance of these contributions: "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 importance of community-driven knowledge sharing and problem-solving.

Conclusion: A Week of Progress and Innovation

The Solana Changelog for October 30th showcases the ongoing progress and innovation within the Solana ecosystem. From improvements in build processes with NixOS to groundbreaking developments like Old Faithful's integration with Filecoin, the Solana community continues to push the boundaries of blockchain technology.

The updates to the Solana Explorer, particularly the introduction of verified builds, represent a significant step forward in transparency and security. These developments, combined with ongoing efforts to standardize and improve various aspects of the Solana protocol, demonstrate the ecosystem's commitment to growth, usability, and decentralization.

As the Solana ecosystem continues to evolve, these regular changelogs provide valuable insights into the latest developments and opportunities for community involvement. Whether you're a developer, user, or enthusiast, staying informed about these updates is crucial for navigating and contributing to the rapidly advancing world of Solana.

Facts + Figures

• NixOS is being explored as an option for creating deterministic builds in Solana, alongside Docker.
• Logging functions in Solana have been moved to their own crate for better code organization.
• The Agave installer may potentially remove local key pairs during installation, requiring users to back up their .config/solana directory.
• Project Old Faithful now supports running an entire RPC node using Filecoin for ledger history storage.
• Steel, a native SDK for Solana development, has released version 2 with new program examples available.
• The Solana Explorer now displays verified builds for programs and supports multi-sig information.
• Verified builds feature is being developed by Autosec and Ellipsis Labs to ensure deployed programs match their source code.
• SIMD 186 proposes standardizing the calculation of transaction data size across validator clients.
• Top Stack Exchange contributors for the week include Mitch, Jimmy, Chalda, Callum, and Wickham.

Questions Answered

What is NixOS and why is it important for Solana?

NixOS is a small Linux subsystem that can be used to create deterministic builds for Solana. It's important because it allows developers to create consistent and reproducible builds across different environments, which has been a challenge for Solana. Using NixOS alongside Docker provides options for achieving deterministic builds, improving the development process and ensuring greater consistency in the Solana ecosystem.

What is Project Old Faithful and how does it relate to Filecoin?

Project Old Faithful is an initiative that stores the entire Solana ledger history on Filecoin. It now supports running a complete RPC node using Filecoin as the ledger history storage. This means developers can perform historical access RPC methods, such as getting signatures for accounts, directly from Filecoin. This development represents a significant step towards decentralizing Solana's infrastructure by leveraging Filecoin's decentralized storage network.

What are verified builds in the Solana Explorer?

Verified builds are a new feature in the Solana Explorer that allows users to verify that a deployed program matches its source code. Developed by Autosec and Ellipsis Labs, this feature creates a Program Derived Address (PDA) on-chain containing data needed for verification. The Explorer compares the on-chain hash with the hash generated from the source code, providing transparency and assurance that the deployed code matches the publicly available source.

What is SIMD 186 proposing?

SIMD 186 is a proposal to standardize the calculation of transaction data size in Solana. Currently, the way transaction size is calculated is non-standardized and can lead to issues like double-counting of certain accounts. The proposal aims to create a simple, consistent algorithm for calculating transaction sizes across all validator clients. This standardization would ensure consistent behavior across the network and simplify implementation for different validator clients.

What precaution should users take when using the Agave installer?

When using the Agave installer to update the local CLI for Agave and version 2 related updates, users should back up their local key pairs, specifically the id.json file in the .config/solana directory. This is because there's a chance the installer might remove local key pairs during the installation process. Taking this precaution helps prevent potential loss of important data during the update process.