Learn about Solana's v1.16 update, the latest upgrade to the Solana Labs validator client
What’s this Article About?
Solana’s network of validators has successfully reached a super-majority in the adoption of version 1.16, the latest upgrade to the Solana Labs validator client. After an exhaustive period of auditing, bolstered by the dedicated efforts of volunteers and canary nodes, this milestone is the culmination of nearly ten months of rigorous development.
In the following sections, we’ll delve into how v1.16 was tested as well as Solana’s feature gate system; a framework that governs how new features are phased into the network. Then we’ll turn to the new features that were implemented in v1.16.
How v1.16 was Tested
v1.16 has been subject to rigorous testing over the past few months. The v1.16 release has been running on testnet since June 7, 2023, and has underwent numerous stress tests. In addition, a small subset of volunteer nodes updated to v1.16 starting on August 23, 2023. These volunteers were able to identify and resolve various issues such as slow startups for RPC nodes as well as general protection faults. Solana Labs also deployed several canary nodes to mainnet-beta. This was done to monitor the stability of the v1.16 nodes under real-world conditions. To see the past activity and progress these canary nodes made, visit the #canaries-monitoring channel in the Solana Tech Discord.
To catch edge cases or infrequent race conditions, multiple runtime fuzzers have been used to execute partially randomized transactions. These transactions were executed across different runtime versions to ensure consistent performance. v1.16 has also been audited extensively by Halborn. Audit reports are published to this repository as they become available over time.
Feature Gates
It is important to note that some of the features we will discuss in the following sections are not currently live. Instead, features are slowly rolled out using a feature gate system. Features are activated at certain epochs based upon relative priority, and the order in which they were activated on other networks. The feature gate activation scheduling has been ad-hoc so far based on a list of criteria, which you can find here. Essentially, these gates should be activated first on tesnet, followed by devnet, and finally on mainnet-beta. To activate a feature, an engineer with the requisite activation keypair sends a transaction that gets processed and makes the feature go live on the next epoch. Only one feature gate is to be activated at a time per network to ensure proper performance. It is important to note that some features may require a “soak” period, which could delay the activation of lower-priority gates.
This feature gate system is in place to ensure that consensus-breaking changes do not cause a validator running a newer version to fork off from the canonical chain and continues producing blocks. For example, a v1.14 validator doesn’t know about new v1.16 features and could crash the network when disputes arise. A commit merged this week to Solana’s codebase encourages all consensus-breaking changes to have a Solana Improvement Document (SIMD). The feature gate issue template will now include a request to the issue’s SIMD. This helps in standardizing the development process and provides greater transparency via documentation to new changes.
Confidential Transfers
Confidential Transfers, a feature introduced by Token2022, utilizes zero-knowledge proofs to encrypt the balances and transaction amounts of SPL tokens. The primary focus of this feature is to improve user privacy through a renowned emphasis on confidentiality rather than anonymity.
Confidential Transfers leverage Twisted ElGamal Encryption for mathematical operations on the encrypted amounts. These transfers are validated using Sigma Protocols, a specialized category of zero-knowledge proofs where one party (the prover) can demonstrate to another party (the verifier) that they know of a certain secret without actually disclosing the secret itself. Be sure to read our article What is Token2022? for a deeper dive into the intricacies of Confidential Transfers.
A nice feature to accompany the rollout of Confidential Transfers is the addition of Command Line Interface (CLI) support. The create-token command has been extended to include a --enable-confidential-transfers flag, which allows users to mint tokens with confidential transfers enabled. Also, the update-confidential-transfer-settings command has been added to enable dynamic changes to confidential transfer configurations for a given mint. This allows for the auditor key and approval settings to be updated.
Better Runtime Support for Zero-Knowledge Proofs
The v1.16 release boosts Solana’s zero-knowledge capabilities with enhanced runtime support for zero-knowledge computations, specifically 128-bit elliptic curve operations. v1.16 introduces alt_bn128 syscalls, which are crucial for generating proofs efficiently.
alt_bn128 refers to a specific implementation of an elliptic curve used for cryptographic operations known as the Barreto-Naehrig curve (BN-128). BN-128 is a specific type of pairing-friendly elliptic curve that allows for the efficient implementation of zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge). As an aside, an elliptic curve is considered “pairing-friendly” if it allows for certain calculations to be done more efficiently. So, in our case, using the BN-128 curve makes working with zero-knowledge math and proofs a lot faster.
Syscall, or a system call, is used to request services from the operating system kernel. Within the context of Solana, a syscall allows programs running in the Solana Virtual Machine (SVM) to interact with outside resources.
An alt_bn128 syscall, then, is a call that Solana programs can use to interact with the highly efficient BN-128 curve. This makes the verification of zero-knowledge proofs streamlined, offering better security and privacy features on Solana. alt_bn128 g1 and g2 syscalls were also added recently, which allows for the compression of Groth16 proofs. This is important as these types of proofs take up 256 bytes of instruction data per proof and private Solana programs (PSPs) currently need to verify two Groth16 proofs. With g1 and g2 compression, the bytes required per proof can be halved to 128 bytes, which is crucial for space efficiency.
Moreover, Solidity-based contracts face compatibility issues with Solana if they contain calls to the following precompiled contracts for elliptic curve operations:
bn256Add - Performs addition on the elliptic curve operations
bn256ScalarMult - Performs scalar multiplication on elliptic curve operations
bn256Pairing - Elliptic curve pairing operations to perform zkSNARKs verification within the block gas limit
These operations are standardized on Ethereum through EIP-196, EIP-197, and EIP-198. The introduction of alt_bn128 syscalls is a significant leap towards bridging the compatibility gap. Solidity contracts that rely on these elliptic curve operations may now find it easier to transition to or even interoperate with Solana.
The inclusion of the alt_bn128 syscall in Solana’s v1.16 update marks a major advancement in Solana’s ability to efficiently and securely handle zero-knowledge proofs.
