Our team is happy to announce a new version of the Aleo Stack! This update includes changes to the node implementation snarkOS and the high-level programming language Leo - as well as their supporting libraries.
This release unlocks fast and reliable end-to-end (E2E) testing of Leo programs, streamlines operations for validators, and introduces a limit on the total supply of Aleo credits.
If you want to try it out, you can build from source today or download the mainnet release from Github February 6th. Find the current release schedule at: https://aleo.org/roadmap .
Please report any issues you might come across!
Consensus Upgrade: V13
The release and hard fork schedule is as follows:
Canary (validator test network)
Release: January 12th
Hard fork: ~January 15th (exact block heights)
Testnet (developer test network)
Release: February 2nd
Hard fork: February 13th (exact block heights)
Mainnet
Release: February 13th
Hard fork: February 20th (exact block heights)
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.
Cap on Total Supply of Aleo Credits
With the approval of ARC-0047, the Aleo network has now established a hard cap on the total supply of Aleo Credits at 5,000,000,000 ALEO. The cap will be enforced by halting block rewards and proving rewards at a predetermined block height (based on theoretical maximum issuance). Note that the emission rates of these rewards are not being modified. Instead, both reward streams will terminate at a predetermined block height in the far future. With the current average block rate, we expect this to occur at the conclusion of Q4 2049.
Improvements for Developers
leo devnode
One of the most important points of software engineering is testing. While Leo recently added support for unit tests, a good E2E test suite was missing. Existing solutions require running a small development network with multiple validators and clients - slow, expensive, and clunky. leo devnode is a new tool that creates a local lightweight development client to enable developers to rapidly test and iterate through Aleo program design.
leo devnode has two commands:
leo devnode start will initiate the development client at localhost:3030
leo devnode advance creates a single block and adds it to the ledger. Optionally, this command takes a value n, which advances the ledger by n blocks.
By default, broadcasting a transaction to the devnode will automatically produce a block and advance the ledger. However, passing the --manual-block-create flag at startup will allow users to broadcast multiple transactions to a queue without creating a block. In order to advance the ledger in this scenario, users will need to use the leo devnode advance command.
Additionally, a --skip-execution-proof flag has been added for the for leo execute command. This flag will create transactions without generating the corresponding ZK proof, further accelerating the testing process.
We have provided some examples of how to use the devnode feature alongside the Javascript/Typescript SDK.
Program Edition Handling in Leo
Leo now handles editions for local and remote programs in a more robust way. As local programs haven't been deployed yet, they do not possess a real onchain edition. We default to edition 1 for certain commands that don’t interact onchain to avoid the check in snarkVM that rejects edition 0 programs without constructors. This keeps local development frictionless.
Command | Local Programs | Network Dependencies |
leo run | Default to edition 1 | Fetch edition from network |
leo execute | Default to edition 1 | Fetch edition from network |
leo synthesize | Default to edition 1 | Fetch edition from network |
leo deploy | N/A | Fetch edition from network + V8 constructor check |
leo upgrade | N/A | Fetch edition from network + V8 constructor check |
Additionally if a network dependency is at edition 0 without a constructor, a more verbose error will now be produced with a clear message explaining the program needs to be upgraded onchain.
External Structs in Leo
This release also introduces an important change to how external structs are handled in Leo.
In previous versions of Leo, external structs did not need to be qualified with the program they came from. All imported structs effectively lived in a global namespace.
Now, external structs must now be explicitly qualified with the program that defines them. Struct names are no longer globally scoped across imports.
For example, given the following program foo.aleo:
program foo.aleo;
struct Foo { x: u32 }
transition main(f: Foo) { .. }Another program (bar.aleo) must qualify struct Foo with foo.aleo in order to use it:
import foo.aleo;
program bar.aleo;
transition main() -> foo.aleo/Foo {
return foo.aleo/Foo {
x: 42
};
}New --json-output flag in the Leo CLI
The Leo CLI now supports a new --json-output flag that writes structured, machine-readable JSON output to disk. This makes it easier to integrate Leo commands into scripts, tooling, and automated workflows.
The --json-output flag is available for the following commands:
deploy
upgrade
run
execute
test
query
synthesize
Save JSON output to the default location:
leo deploy --json-outputSave JSON output to a custom file path:
leo execute main --json-output=my-results.jsonBy default, JSON output files are written to the build/json-outputs/ directory, with one file per command. For example:
build/json-outputs/deploy.json
build/json-outputs/execute.json
build/json-outputs/run.jsonChanges to snarkos developer execute
By default, snarkos developer execute commands will now use the V2 endpoints for api.explorer.provable.com. However, backwards compatibility is still supported for the V1 endpoints.
Attempting to use an account with an insufficient balance of credits now produces clearer error messaging.
A bug was fixed which prohibited fetching and utilizing the right editions of imported programs.
Miscellaneous Updates
Initial support for external structs has been added to snarkVM. This will be supported in Leo program syntax in a future release.
The size of the compiled program (in kB) will be output by the CLI when calling leo build, leo deploy, and leo upgrade.
A --disable-update-check flag has been added to the Leo CLI. This allows for disabling the Leo’s automatic update check, allowing for more consistently reproducible output from the CLI.
Various performance improvements have made their way into AleoVM, such as better block caching and better database deserialization.
SDK
Upgrades to Proving Speed & Proving Key Management
10-20% speedup local wasm-based proving via wasm optimizations made through applying wasm-opt
Adds a new KeyStore interface for storing proving and verifying keys on disk for node JS and storing them in IndexedDB for web and wallet applications. This helps developers cache proving keys for later re-use improving wasm proving times a further 30%
Miscellaneous Upgrades:
Adds support for getting the address of a program from the Program object
Improvements for Node Operators
Improved Database Organization
A new node-data directory has been introduced that contains all node-specific data (essentially everything but the ledger). This is located at ~/.aleo/storage/node-data-{network_id} for production or ./node-data-{network_id}-{dev} for development nodes. Alternatively, users can also pass a value to --node-data and store the data at a custom path.
Previously, these files lived in the similarly-named ledger-* folder. At startup, a node will check for any files that indicate that the old storage format is used. In that case, a message is printed on how to migrate, and the node will not start.
Alternatively, nodes can also be started with --auto-migrate-node-data to move the appropriate files automatically from the ledger-* folder to the node-data-* folder.
Miscellaneous Updates
To enhance security, validators will no longer be able to connect to unknown/untrusted peers. This may cause issues for validators who have some managed nodes which frequently rotate. For now, make sure that you pass in peers explicitly via the --peers flag. A discussion is present here for those interested to pass in hostnames.
A general UnknownReason type has been added for handling connections between peers. This will now be the default DisconnectReason when encountering an unknown value. This is useful for future compatibility, as adding a new disconnect reason should not require a message version bump or a synchronous update.
Nodes will no longer print debug logs when set to the lowest verbosity setting.
The amount of stake of unconnected validators is logged and available via the new snarkos_bft_connected_stake_as_percentage metric
The latest observed height of other validators is logged to aid debugging.
Node restarts are now ~10x faster by cleverly caching the block tree. Good old flamegraphs came to the rescue.
Various stability improvements have made their way to make snarkOS nodes ever more robust and to be able to handle a variety of adversarial and benign edge cases in the network, reducing the impact of race conditions in syncing and consensus logic.
Closing Notes
The work for this release encompassed changes across 500 source code files and touched 20.000+ lines over 350+ commits by the amazing contributors listed below.
The full changelogs for the referenced releases can be found here:
https://github.com/ProvableHQ/snarkVM/compare/v4.4.0...testnet-v4.5.0
https://github.com/ProvableHQ/snarkOS/compare/v4.4.0…testnet-v4.5.0
https://github.com/ProvableHQ/leo/compare/v3.4.0…testnet-v3.5.0
If you want to try it out, you can build from source today or download the mainnet release from Github February 6th. Find the current release schedule at:https://aleo.org/roadmap.
Please report any issues you might come across!
Contributors
A big thank you to all the contributors on Github to this snarkOS, Leo, SDK and snarkVM release!
@AleoAlexander @antonio95
@copilot
@d0cd
@kaimast
@iamalwaysuncomfortable @IGI-111
@ljedrz
@meddle0x53
@mohammadfawaz
@niklaslong
@tenequm
@raychu86
@Roee-87
@vicsn