← 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.

Announcing snarkOS v3.7.x

The Provable team is happy to announce a new version of the snarkOS Aleo implementation. Aleo is a cryptocurrency enabling developers to build cryptographically secure dApps.

You can already use this version on testnet and it is planned to land on mainnet by May 20th, 2025 - at which point you can also download the release from github. Or, if you’re keen to dive in, build from source anytime you want.

Please report any issues you might come across!

What's new in v3.7.x

snarkVM Consensus changes: increase to 35 validators

A consensus update is going to take place, allowing the validator count to increase to 35! Extensive load-testing was performed to confirm the robustness of the larger network. In future releases, the validator set will continue to increase in a responsible manner. Excitingly, due to the use of the Bullshark-based AleoBFT consensus algorithm, this increased validator set will increase the throughput of Aleo!

The consensus changes will occur at the following block heights:

  • Canary - Block 6_240_000 (~May 2nd, 2025 at the current block times)

  • Testnet - Block 7_600_000 (~May 18th, 2025 at the current block times)

  • Mainnet - Block 7_557_000 (~May 21st, 2025 at the current block times)

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.

Improvements for developers

Many developers and auditors are working hard to add program upgradability to Aleo. While this feature itself is not yet merged yet, several components which lead up to it, such as a cleanup of how imports are managed in snarkVM. This change, combined with program upgradability, will allow for cycles in the import graph, further increasing the expressivity of Aleo programs.

snarkOS Stack Management

We also got help from the wider ecosystem to harden the codebase. When deserializing an Authorization from a string that included multiple transitions, the structural assertion logic would erroneously fail - and this has now been fixed.

Moreover, the height metric is now being updated during syncing so you can better see whether your node is almost ready or whether you have time to grab another cup of coffee.

Finally, lots of documentation was improved across the snarkVM and snarkOS codebase.

Improvements for validators

Several improvements were made to harden the security of the consensus algorithm and node implementations. For example, deserialization of nested structs was hardened to reduce the chance of DoS attacks - we thank the anonymous HackerOne submissions for helping to strengthen the Aleo codebase.

This PR brought 80%-95% improved RAM usage to load deeply nested programs into memory.

Finally, increases in message versions should no longer cause immediate disconnects - they can now be introduced gradually at a future new consensus version.

API changes

Recall that a Transaction processed by Aleo validators can achieve the following states:

  • accepted: This means that the underlying Deployment or Execution was successful, and that an associated Fee was consumed. The transaction has a confirmed id.

  • rejected: If the Deployment or Execution logic fails, validators will try to process the Fee as an independent Fee transaction. The original transaction is associated with an unconfirmed id, the Fee transaction is associated with a confirmed id.

  • aborted: If the Deployment or Execution logic fails, and the Validators also cannot process the Fee, the transaction is aborted.

Tracking accepted and aborted transactions was previously possible, but tracking rejected transactions proved difficult for many ecosystem members. The following endpoint should help resolve this - you can now query an unconfirmed transaction by its confirmed id.

GET /{network}/transaction/unconfirmed/:id

Closing notes

The full changelog for this upcoming release can be found here:

Contributors

A big thank you to all the contributors to this release!

@acoglio

@d0cd

@ljedrz

@kaimast

@kpandl

@lipsyre

@ljedrz

@lukenewman

@mikebenfield

@niklaslong

@onetrickwolf

@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.