← BACK
feature image
Contents
About Victor Sint Nicolaas, Protocol Engineer - Provable

Victor Sint Nicolaas is Protocol Engineer at Provable. He loves to further the science of cryptography and mechanism design, and aims to bring them into the real world. Previously, he worked on securing taxation and identity software.

August 5, 2025
By Victor Sint Nicolaas, Protocol Engineer - Provable
Announcing snarkOS v4.1.0
Contents

Our team is happy to announce a new version of the Aleo node implementation, snarkOS, alongside developer tooling updates to snarkVM, Leo and the Aleo SDK. Aleo is a cryptocurrency through which developers can deploy cryptographically secure dApps.

Most notably, this release unlocks program upgradability. This feature, proposed in ARC-6, offers a method for program upgrades that seeks to be timely and cost-effective, while preventing fragmentation of application state. The release also introduces various quality of life improvements for node operators, such as exposing HTTP endpoints for creating backups and retrieving version information.

If you want to try it out, you can build from source today or download the mainnet release from github August 12th. Find the current release schedule at: https://provablehq.github.io/.

Please report any issues you might come across!

What's new in v4.1.0

Consensus change: ConsensusVersion V9

A consensus change will occur at the following times:

  • Canary - ~9AM PT July 29th, 2025

  • Testnet - ~9AM PT August 5th, 2025

  • Mainnet - ~9AM PT August 12th, 2025

The exact block heights will be encoded in the snarkVM library at release.

ATTENTION: Validators that do not upgrade in time will be at risk of forking and require manual intervention. Clients that do not upgrade will be at risk of halting until an upgrade occurs.

Maximum validator set increase to 40

The maximum number of validators securing the Aleo network will increase to 40. The gradual increase of validators on the Aleo network assures a continuous increase in decentralization without sacrificing security and stability of the network.

Program upgradability

With this release, Aleo will facilitate a system for program upgrades with the following highlighted properties:

  • Upgrades preserve the interface of a program.

    • An upgrade can:

      • change logic in a function or finalize

      • define new structs, records, or mappings but cannot modify or remove existing ones

      • add new functions and closures

    • An upgrade cannot:

      • change a function’s input and output interface

      • change a finalize’s input interface

      • change logic in a closure. This is because a change in a closure would invalidate all dependent proving and verifying keys.

      • change existing structs, records, or mappings

Program Component

Delete

Modify

Add

import

❌

❌

✅

struct

❌

❌

✅

record

❌

❌

✅

mapping

❌

❌

✅

closure

❌

❌

✅

function

❌

✅ (logic)

✅

finalize

❌

✅ (logic)

✅

constructor

❌

❌

❌

  • Upgrades can be rejected by dependent applications. While we require that upgrades are atomic and take effect immediately, dependents may want fine-grained control. There should be a way for an application to detect whether a dependent is changed, after which the dependent application will need to be upgraded to the desired logic to be callable again.

  • Developers must be able to ossify their programs. Immutable application logic gives users sovereignty. This is desirable in many blockchain ecosystems.

At a high-level, our proposed design introduces immutable constructors, where you can define your upgrade logic, and new finalize scope operands checksum, edition and program_owner so that users can programmatically define upgrades with the above design goals in mind. Newly deployed programs must contain a constructor, and start at edition 0. As they upgrade, their edition increments by 1. Only the highest edition of the program can be executed.

For more information about program upgradability, check out:

Improvements for node operators

Better peering logging

Peering code has been cleaned up significantly, reducing the amount of spurious ProtocolViolation and Unable to resolve false positive messages.

Rocksdb checkpoints

Native rocksdb checkpoints can now be made with a simple JSON Web Token guarded HTTP call. When you start your node without passing in custom JWT flags, your JWT credentials are printed to stdout at startup.

Creating a checkpoint at location /home/aleo_ledger_checkpoints/1 can be done as follows:

curl -X POST -H "Authorization: Bearer ${TOKEN}" http://localhost:3030/{network}/db_backup?path=/home/aleo_ledger_checkpoints/1

Rolling back to (or, more precisely, switching to) the aforementioned checkpoint, is as easy as pointing --storage to the particular folder:

snarkos --storage=/home/aleo_ledger_checkpoints/1

Alternatively, the original ledger can be removed, and manually substituted with the checkpoint.

Retrieving program information

Due to program upgradability, programs can now be upgraded, and therefore have higher editions. In order to surface this information, snarkOS now supports the following endpoints:

curl http://localhost:3030/{network}/program/{programID} curl http://localhost:3030/{network}/program/{programID}?metadata={true} curl http://localhost:3030/{network}/program/{programID}/edition curl http://localhost:3030/{network}/program/{programID}/edition?metadata={true}

The new metadata query parameter returns a JSON object with the following fields:

{ "program": "", "edition": 0, "transaction_id": "", "program_owner": "", }

Build information

A node’s build information can be surfaced via:

curl http://localhost:3030/mainnet/program/version

Which returns a JSON object with the following fields:

{ "version": "3.8.0", "git_commit": "9359abd0546c39e05b22112c768c90738577e212", "git_branch": "refs/heads/feat-add-version-endpoint" }

Library and tooling updates

snarkVM v4.1.0

snarkVM is a zkVM library. It powers the Aleo network and most of the software used to interact with it. The following contains some of the most relevant changes which were introduced:

  • snarkVM has been upgraded to Rust 1.88

  • Process now exposes pub fn add_programs_with_editions, which allows wallets, provers and other applications to initialize a Process with the latest Program editions.

  • Request’s pub fn verify now takes in an optional program_checksum, required for signing execution requests to upgradable programs

  • pub fn deployment_cost now accounts for the finalize cost of constructor logic.

  • Deployments now contain an optional program_checksum and program_owner, populated from ConsensusVersion::V9 onwards

  • Programs now contain an optional constructor, populated from ConsensusVersion::V9 onwards

Leo 3.1.0

  • Async blocks allow you to elide defining separate async functions, and write your on-chain code in the same location as the rest of the transition:

async transition main(public a: u32, b: u32) -> Future { let f1: Future = other.aleo/main_inner(0u32, 0u32); let f:Future = async { f1.await(); }; return f; }

  • You can use a .aleo file as a local dependency (previously dependencies were programs already deployed to the network, or local Leo projects):

leo add --local this_dependency.aleo

SDK 0.9.4

SDK Version 0.9.4 includes the following enhancements and fixes.

Fixes:

  • Enables the SDK to build fully offline transactions. To use this functionality, set your SDK dependency to 0.9.4-offline-rc

  • Fixes SDK docstrings and completion of underspecified docstrings.

Enhancements:

  • Addition of a buildAuthorizationUnchecked method which allows building authorizations without building a circuit, allowing for build fast requests to trusted external provers.

  • Addition of a ProvingRequest object that can be sent to trusted provers for remote proving

Closing notes

The full changelogs for the referenced releases can be found here:

If you want to try it out, you can build from source today or download the mainnet release from github August 12th. Find the current release schedule at: https://provablehq.github.io/.

Contributors

A big thank you to all the contributors on Github to this snarkVM, snarkOS, Leo and SDK release!

@d0cd

@hritique

@kaimast

@iamalwaysuncomfortable

@ljedrz

@meddle0x53

@mohammadfawaz

@mikebenfield

@niklaslong

@raychu86

@vicsn

About Victor Sint Nicolaas, Protocol Engineer - Provable

Victor Sint Nicolaas is Protocol Engineer at Provable. He loves to further the science of cryptography and mechanism design, and aims to bring them into the real world. Previously, he worked on securing taxation and identity software.