Validators Provers Programs Blocks Transactions Docs

Explore AleoNetwork

Ctrl + K

Coinbase Target

536.87M

Program Calls Last 7 Days

3.24K

Total Network Stake

1.31BALEO

Percent staked

80.2%

Proof Target

134.22M

Deployed Programs

2.8K

Total Transactions

1.2M

Total Validators

Total Provers

120

Total Puzzle Reward

15.82MALEO

Ecosystem News

Introducing the Leo native testing framework

With the latest update to the Leo programming language, Aleo developers can now write unit tests directly in Leo code. This new feature enables developers to verify the correctness of their program logic before deploying it to the testnet, allowing for greater confidence in the quality and security of their dApps. Unit testing ensures that your program logic behaves as intended by allowing you to test individual transition functions. This granular level inspection checks that each transition function performs correctly in isolation, thereby helping to identify edge cases and potential vulnerabilities before they can be exploited. Unit tests also facilitate auditing, providing a clear and reproducible method for reviewing code behavior and ensuring compliance with project requirements or regulatory standards. Additionally, by catching bugs early in development, unit tests save you from the headache of redeploying a program to the testnet or mainnet after discovering an issue in production. By incorporating native unit testing into your workflow, your Aleo programs become more reliable, secure, and maintainable. Getting Started First, make sure you are using the latest version of the Leo CLI. The command will automatically generate a test directory containing a file with template code containing a script and a compiled test. leo new <project_name> Wondering why there are two types of tests? That’s because the Aleo blockchain contains both public and private state. Public state is modified through on-chain execution. Async transition functions that access mappings can only be tested using scripts. All other logic, such as minting records or hashing data, can be tested using compiled tests. Importing your main program The test file is a Leo program, so in order to be able to test your main program’s functions, you will first need to import it into your test program. Think of your main program as an external dependency for your test program. All of the transitions that you’ll be testing from your main program will be called as external programs inside of your test function code blocks. Just two more things to keep in mind. First thing to note – every test function must be annotated with the `@test` keyword before the function definition. Second point – test functions do NOT take inputs. All inputs must be hardcoded inside of the test function code block. Running compiled tests Compiled tests can be used to test any regular transition or helper function. The test will contain an external transition or external inline function, followed by an assert, as follows: @test transition test_simple_addition() { let result: u32 = example_program.aleo/simple_addition(2u32, 3u32); assert_eq(result, 5u32); } You can also test that invalid results are caught by adding a `@should_fail` annotation. @test @should_fail transition test_simple_addition_fail() { let result: u32 = example_program.aleo/simple_addition(2u32, 3u32); assert_eq(result, 3u32); } You can also use compiled tests to make sure that structs and records contain correct values for their respective fields. @test transition test_record_maker() { let r: example_program.aleo/Example = example_program.aleo/mint_record(0field); assert_eq(r.x, 0field); } Running scripted tests Now for the fun part! Scripts are useful for checking async transitions that interact with mappings. Since mapping data lives on-chain and since the testing framework can’t fetch on-chain data, we need to populate a mapping with some data before we can test it. Let’s say our main program has an async transition and corresponding async function that updates a mapping called "map": async transition set_mapping(x: field) -> Future { let future_1: Future = finalize_set_mapping(x); return future_1; } async function finalize_set_mapping(x: field) { Mapping::set(map, 0field, x); } How would we write a test to check that the mapping is being updated correctly? First, we need to replace the `transition` keyword with `script` to indicate that we’re running a script. Next, within the test code block, we’ll populate the mapping with a hard coded value. Since `set_mapping` is an async transition that returns a Future, we need to await the Future before checking that the value in the mapping matches the correct value: @test script test_async() { const VAL: field = 12field; let fut: Future = example_program.aleo/set_mapping(VAL); fut.await(); assert_eq(Mapping::get(example_program.aleo/map, 0field), VAL); } How do I run the tests? After you are confident that you have written all the tests required to satisfy unit testing gods, it’s time to give it a spin! If you want to run all of the tests together, simply run the following from the root of your project directory. leo test If you only want to run select tests, you can either supply the test function name or a string that is contained within the name of the test function: leo test test_async Or leo test async Conclusion With Leo's native testing framework, developers can now build more robust and secure Aleo applications by catching bugs early and ensuring their transition functions work correctly before deployment. Get started today by exploring the example repository and diving deeper into the comprehensive Leo language documentation to master unit testing for your dApps.

Announcing snarkOS v3.8.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 June 17th, 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.8.x snarkVM Consensus change A consensus change solidifying consensus logic will occur at the following block height: Canary - Block 6_895_000 (~June 6th, 2025 at the current block times) Testnet - Block 8_365_000 (~June 15th, 2025 at the current block times) Mainnet - Block 8,392,501 (~June 18th, 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. New bootstrap peer IPs This PR introduced new bootstrap peer IPs, which are nodes run by the Aleo Network Foundation! They are an optional gateway into the Aleo network. Improvements for developers When you issue cargo run or even cargo test with no code changes at all, cargo would still re-build the snarkOS binary (and this can take a long time) on every single invocation. With a single clean “cargo:rerun-if-changed=” line removed, you will no longer have a rebuild on every run. A bug was present in the previously added unconfirmed transaction endpoint, causing it to return confirmed transactions. This has now been fixed, the endpoint now returns unconfirmed transactions. There were a few things that made the CLI a little awkward to use, which is now improved. The power of Rust shines through scary idiomatic code such as the following: #[clap(default_value_t=MainnetV0::ID, long = "network", value_parser = clap::value_parser!(u16).range((MainnetV0::ID as i64)..=(CanaryV0::ID as i64)))] Improvements for validators A number of stabilization improvements are coming to consensus and peering. For example, the heartbeat logic has no notion of pending connections, so it might call Router::connect multiple times for the same peer while the handshake is happening. This change prevents frequent warnings being generated when a node attempts to connect to a peer, that it already connected or is currently connecting to, by not considering those cases an error. This PR clears the partially_verified_transactions on all the ConsensusVersion changes. All ConsensusVersions change consensus rules and regardless if it is transaction related or not, we clear the partially_verified_transactions out of abundance of caution. Leo 2.7.0: now with type inference! Alongside the new snarkOS release, there will also be a new Leo release. 🦁Leo is a programming language for formally verified, zero-knowledge applications on the Aleo network. From now on, we’ll be using these release notes to give an overview of new exciting features which landed in the programming language. Unsuffixed Literals and Basic Type Inference In many cases it’s now possible to avoid explicitly writing types, or to avoid the type suffix of numeric literals. let x: u8 = 12; // We no longer have to write `12u8`. let y = 12u8; // Or, instead of `let y: u8 = ...`, we omit the type. for i in 10u8..16u8 { // Can also omit the type here, instead of `for i: u8`. // ... } Clearer Reporting for execute and deploy Now when you use deploy and execute, you’ll get better messaging, including checking the status of your transaction. Closing notes The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/v3.7.1...testnet-v3.8.0 https://github.com/ProvableHQ/snarkOS/compare/v3.7.1…testnet-v3.8.0 https://github.com/ProvableHQ/leo/compare/v2.6.0...testnet-v2.7.0 Contributors A big thank you to all the contributors to this snarkVM, snarkOS and Leo release! @cypherpepe @d0cd @ljedrz @kaimast @kpandl @ljedrz @mikebenfield @mohammadfawaz @niklaslong @raychu86 @vicsn @VolodymyrBg

ProvaHack 2.0: Building Privacy dApps on Aleo

Earlier this month (May 2–15, 2025), Provable hosted ProvaHack 2.0, a two-week internal codefest where our team built open-source, privacy-preserving dApps on Aleo. Participants used Leo programs and deployed projects to the Aleo mainnet. What We Built on Aleo Each team leaned into Aleo’s strengths—proofs that keep data private, seamless on-chain deployments, and the flexibility of Leo. Here’s a deeper dive: Verifaleo Description: Verifaleo addresses the need for privacy-preserving identity verification (KYC) in dApps. It uses Aleo to link verified identities to soulbound NFTs, allowing users to prove their KYC status to services without repeatedly exposing sensitive personal data. Aleo's ZK proofs ensure that dApps can trust the verification status tied to an NFT without accessing the underlying private information, facilitating compliance while upholding user privacy. Codebase: https://github.com/esren0x/kycNFT PriceProof Description: PriceProof creates decentralized price prediction markets on Aleo, focusing on security and user privacy. The core problem it solves is enabling users to stake on future price movements anonymously, with Aleo's ZK proofs validating that reported outcomes verifiably match on-chain oracle data. This ensures a trustless and transparent market where participants are protected, and their strategies remain private. Codebase: https://github.com/bendyarm/priceproof/tree/main/leo/price_proof_test_1 The Solo Gambit (Pawnstorm) Description: Pawnstorm, from The Solo Gambit, introduces a chess variant with a twist: hidden bombs! The core challenge solved on Aleo is managing this hidden information and validating moves without a trusted third party. Aleo's ZK proofs allow each player's secret bomb placements to be tracked privately on-chain, ensuring fair play and strategic depth as moves are validated against both public game rules and private, hidden states. Codebase: https://github.com/mikebenfield/pawnstorm Proof of Bitcoin Description: Proof of Bitcoin tackles the challenge of privately proving ownership of Bitcoin reserves. Using Aleo, this project allows users to generate ZK proofs demonstrating they hold a certain amount of BTC without revealing their Bitcoin addresses or transaction histories. This is achieved by implementing critical cryptographic components on Aleo, such as ECDSA signature verification for Bitcoin's secp256k1 curve and necessary hash functions, enabling publicly verifiable yet private attestations of off-chain assets. Codebase: https://github.com/vicsn/snarkvm-btc-balance-verification/tree/ecdsa RetroBeatz Description: RetroBeatz offers a nostalgic quiz on classic game soundtracks, aiming to boost Aleo engagement through a fun, community-oriented dApp. The challenge lies in creating an interactive experience on Aleo that can manage quiz mechanics and potentially track high scores in a decentralized manner. It demonstrates Aleo's versatility for building user-friendly applications that can foster community and showcase the platform's accessibility. Codebase: https://github.com/wei-provable/midi-player Daddy’s Orders Description: Daddy’s Orders tackles decision fatigue with a fun, privacy-preserving randomizer on Aleo. The core challenge is generating a verifiably random Taco Bell order (main, side, drink) without a trusted central party. Aleo's ZK proofs ensure the randomness is generated on-chain and the outcome is truly unpredictable, offering a private and amusing way to let fate decide your meal. Codebase: https://github.com/christianwwwwwwww/daddys-orders snorkle Description: Snorkle provides a privacy-preserving oracle, tackling the challenge of securely bringing real-world data on-chain. Using secure enclaves and Aleo's zero-knowledge proofs, this service fetches external data feeds and attests to their authenticity without exposing sensitive API keys or endpoints. This allows dApps to trust and use external information privately and securely. Codebase: https://github.com/d0cd/snorkle lodive Description: Lodive addresses privacy and security in event ticketing by building a platform on Aleo. The core problem it solves is enabling the sale of soulbound tickets where attendee data is encrypted, ensuring buyer anonymity and preventing common issues like scalping and secondhand market scams. Aleo's ZK proofs allow event organizers to verify ticket authenticity and admission without accessing attendees' personal information, enhancing privacy throughout the ticketing lifecycle. Codebase: https://github.com/alexpitsikoulis/lodive Knightfall Description: Knightfall introduces Fog-of-War Chess to the Aleo blockchain, tackling the challenge of hidden information in strategy games. Aleo's zero-knowledge proofs conceal players' pieces from their opponent until they enter attack range, creating tactical suspense. This approach ensures fair play and privacy by managing hidden game states on-chain without revealing them prematurely. Codebase: https://github.com/dgrkotsonis/knightfall-aleo https://github.com/emmaprice082/knightfall Feeling inspired? Explore the Awesome Aleo GitHub repo! This is your go-to hub for Aleo developers and ZK enthusiasts. It gathers tutorials (from beginner to advanced), project ideas, and useful tools to jumpstart your work with Aleo’s privacy-focused platform. Whether you’re building dApps, exploring zero-knowledge proofs, or contributing to the Aleo ecosystem, it’s the perfect launchpad. Take the next step and immerse yourself in the Aleo ecosystem. By joining this ecosystem, you'll connect with like-minded individuals, gain access to exclusive resources, and have the opportunity to contribute to groundbreaking projects. Whether you're a seasoned developer, a curious newcomer, or simply passionate about ZK, the Aleo ecosystem welcomes your participation in building a more secure digital future.

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. 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: https://github.com/ProvableHQ/snarkVM/compare/v3.6.0...canary-v3.7.0 https://github.com/ProvableHQ/snarkOS/compare/v3.6.0...canary-v3.7.0 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

Deploy Aleo Nodes with One Click on Google Cloud Marketplace

Running an Aleo node with snarkOS just got a whole lot faster.

Announcing snarkOS v3.6.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 April 22nd, 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.6.x snarkVM Consensus changes: increase to 30 validators and spend limits A consensus update is going to take place, allowing the validator count to increase to 30! 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 to around 65 transactions per second! Additionally, spend limits have been introduced, which are discussed in more detail below. The consensus changes will occur at the following block heights: Canary - Block 5_780_000 (~April 11th, 2025 at the current block times) Testnet - Block 6_765_000 (~April 15th, 2025 at the current block times) Mainnet - Block 7_060_000 (~May 4th, 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 validators Initialization runtime performance has improved significantly. Program loading on initialization now avoids an exponential slowdown incurred previously from recursive loading of the same program; and fetching from CDN has been sped up through increased parallelization. Overall runtime performance has also been improved. Validator committees are expensive to construct, and they are now cached in more places. Deployment synthesis has been sped up by almost 2x with help from a statically allocated vector and further allocation reductions. Peering and syncing logic has been overhauled to be more robust. Finally, proposal spend limits have been introduced to limit the maximum blocktime. Validator storage changes This PR fixed the storage path configuration for the proposal cache for validators, to ensure it is stored in the location indicated by the --storage flag. Previously, it was always stored in the default Aleo ledger directory. Validators using this flag should review whether they are backing up the entire indicated folder. Improvements for provers Support for CUDA has been merged which will speed up running a snarkOS prover out of the box. API changes This PR is an initial iteration of a validator telemetry implementation used for tracking metrics and performance of other validators. This will allow validators to better monitor the behavior of its peers (and itself) and react accordingly - directly via connections or off-chain via alerts. This new feature is currently guarded with a new telemetry feature flag for optional use by validators. There is a rudimentary concept of participation score that is exposed via logs and a new REST api: // GET /{network}/validators/participation // GET /{network}/validators/participation?metadata={true} Improvements for developers A locktick feature has been added which allows for logging of currently-held locks. This has proven extremely useful for hunting down deadlocks. Cargo doc now compiles again! Moreover, many parts of the codebase have been documented in much more detail - this ongoing documentation effort will improve the developer experience for new contributors. A regression testing suite has been developed to ensure all deployed programs continue to be valid on new versions of snarkVM - ensuring for example that R1CS synthesis does not change. Moreover, a small devnet is now automatically launched in CI on every open PR, catching more issues in a fully automated way. Closing notes This release, there is no update required for Leo, but a new release is on its way bringing several exciting updates, so stay tuned. The full changelog for this upcoming release can be found here: https://github.com/ProvableHQ/snarkVM/compare/v1.4.0...a296d35 https://github.com/ProvableHQ/snarkOS/compare/v3.4.0...a1e4a28 Contributors A big thank you to all the contributors to this release! @acoglio @d0cd @ljedrz @kaimast @kpandl @mikebenfield @niklaslong @onetrickwolf @raychu86 @vicsn

Announcing snarkOS v3.4.x

The Leo programming language: fast, safe and worth the await! 🦁

TL;DR Leo is a statically-typed programming language for private smart contracts designed for intuitive Aleo blockchain development. It is powered by ZK, with unique syntax to compose on-chain and off-chain logic. What the heck is even a Leo? Most features you’re used to from smart contracts can be expressed in Leo. You can define a cryptocurrency program which mints, transfers and airdrops tokens; you can define a voting program, or a DAO; and much more. However, in contrast to, for example, Bitcoin or Ethereum transactions, users do not send signed instructions into the network for execution. Users execute the code off-chain and send, on-chain, a zero-knowledge proof (or more technically, a SNARK) of the off-chain execution. This is possible because, under the hood, Leo program functions compile to a set of constraints (expressed in R1CS). As a result, even transactions expressing truly enormous state updates are small, can be verified ultra-fast, and, most importantly, keep user data private from the network. Very cool bro, but why create a whole new language? The first version of Leo was released back in 2020, making it one of the first ZK programming languages, and it still shines today on three fronts: proving speed, safety, and developer experience. Leo Advantage #1: Fast proving speed Despite the magic of zero-knowledge proofs, they have a drawback: they require a lot of computational power to create. A very optimistic estimate of future ZK systems is that they’ll still incur a 1000x proving overhead over native computation (assuming similar hardware). A custom “zk-friendly” “zk-DSL” language is essential to minimize the footprint of the function when expressed as constraints and to speed up proving. Despite the breathtaking and amazing progress in the last couple of years proving Solidity or Rust logic (almost) out of the box, such “zk-VM”-based approaches still lag behind on performance. Over the last few years, many exciting new proof systems have emerged, and due to the Leo compiler’s modular nature, the existing Varuna proof system can easily be swapped with a more novel proof system, while retaining the benefit of constraint-optimized compilation. Leo Advantage #2: Safety The number one challenge facing blockchain developers is a lack of safety. Smart contract and bridge hacks are responsible for more losses than anything else. Expressing transactions as zero-knowledge proofs adds an extra security risk: if an invalid state becomes accepted, there could be hidden inflation, similar to the Zcash inflation bug in their proof system. In order to minimise security risks, various parts of the Aleo toolchain have been formally modeled and verified. In the future, Leo will also fulfill its promise of utilizing a formally verifying compiler. Keeping the language footprint small is essential to achieve that goal. Cryptography researcher Thaler mentions that a big advantage of proving statements about programs built in pre-existing languages like Rust is that its creators don't have to build their own compiler. However, it’s worth taking into consideration that the majority of compiler logic of pre-existing languages is not relevant in the context of generating proofs. Rust's most complex and useful feature - memory safety - is not by itself meaningful in the context of generating a proof. Neither is language syntax related to concurrency. Going one level lower, a significant portion of compiler middleware is dedicated to hardware-independent and hardware-dependent optimizations. While these optimizations are essential if you want to prove statements about, e.g., the Rust programming language, it would be silly for a zk-VM to reflect all of that logic if you have no intention of proving statements about Rust programs. Moreover, the added logic introduces a ton of chance for bugs: “Even with conservative estimates, every month, there should be at least a dozen new known vulnerabilities likely to lead to an exploit in a formally verified RISC-V ZKVM, where proofs are verified against assembly generated by one of the two major compilers (GCC or LLVM). This does not count unreported bugs.” (source) Leo Advantage #3: Developer experience Third, the developer experience. Leo's main purpose is to generate proofs on the Aleo cryptocurrency network, and its async-await syntax explicitly models moving data between an on-chain and off-chain environment. “The unique part of Leo is that it separates transition and function. The transition is executed off-chain with privacy. The correctness of the execution is proved by a zero-knowledge proof and verified by the network. All the inputs [...] and the intermediate variables are hidden by default. The function is executed publicly on-chain so that it can read and write the public state on-chain.” - (source) Async functions are executed publicly. Async transitions can call async functions. A call to an async function returns a Future object. It is asynchronous because the code gets executed at a later point in time. Async functions are atomic; they either succeed or fail, and the state is reverted if they fail. Which apps can be built with Leo? Smart contracts are powerful tools, allowing users to manipulate on-chain state without permission and powering crazy economic concepts such as Flash Loans, Time-locked Liquidity and Continuous Auctions. As Tarun mentioned, DeFi intrinsically embeds collateral reqs. By adding the power of zero-knowledge proofs, that collateral can now also be privately owned. Add oracles on top, and we can do private credit scoring, private auctions, private DeFi vaults, and much more. Today, Aleo is live with the liquid staking protocol Pondo, Automated Market Makers, and many more applications built with Leo. In the Future, Leo will become ever more performant, safe and easy to use. To meet the vibrant developer community, come and follow: Leo Telegram Leo Discord Leo’s Github Repository Leo’s documentation: https://docs.leo-lang.org

Aleo Network Foundation and Provable Collaborate with Google Cloud to Scale the Layer 1 ZK Privacy-Focused Network

Aleo becomes one of the first zero-knowledge and privacy-first Layer 1 blockchain networks to integrate with Google Cloud, reinforcing its leadership in the growing ZK ecosystem.

Announcing snarkOS v3.3.0

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 (build from source on the commit d269988) - it is planned to land on mainnet by February 11th, 2025, when v3.3.0 will also be available as a release from GitHub. Please report any issues you might come across! What's new in v3.3.0 snarkVM Consensus Changes: increase to 25 validators A consensus update is going to take place, allowing the validator count to increase to 25! 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 to around 50 transactions per second! The consensus changes will occur at the following block heights: Canary - Block 4,560,000 (~Jan 25, 2025 at the current 4s block times) Testnet - Block 4,800,000 (~Jan 31, 2025 at the current 3.4s block times) Mainnet - Block 4,900,000 (~Feb 18, 2025 at the current 3.0s 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. Syncing close to tip many times faster Whenever a validator or client is lagging behind, they request blocks from other peers. This process had a subtle bug which caused many seconds of delay on fresh requests. Now that this has been fixed, syncing will be multiple times faster. (PR). Other changes Previously, the 'snarkos developer scan' command was broken because it used an outdated endpoint internally. This is now fixed (PR). Various performance and documentation improvements were included, such as adding a cache for block requests (PR). Validators will consume slightly more memory, but this should be offset in the near future by deployments no longer being held in memory (WIP PR). This release, there is no update required for Leo, the programming language allowing you to write, deploy and execute programs on Aleo. Several exciting updates are underway, so stay tuned. Contributors to v3.3.0 A big thank you to all the contributors to v3.3.0! @acoglio @d0cd @ljedrz @kaxxa123 @kpandl @niklaslong @raychu86 @vicsn

Programs

credits.aleo	1,831,667 CALLS
puzzle_arcade_coin_v001.aleo	251,902 CALLS
alphaswap_v1x5.aleo	111,934 CALLS
puzzle_arcade_ticket_v001.aleo	97,624 CALLS
puzzle_spinner_v004.aleo	48,116 CALLS

Validators

aleo17m3l8a4hmf3wypzkf5lsausfdwq9etzyujd0vmqh35ledn2sgvqqzqkqal	TVL $38,011,804
aleo1u4hqhsukjqkm6q02kc5cjm470srwt77x9yt0fa2j263wtqzrevyqmdccy3	TVL $37,970,972
aleo1czp8gure8caqnpqgxsacc2kv2zhggz4ujp065wwfa76qwxggrups6ap3jg	TVL $37,957,089
aleo17mp7lz72e7zhvzyj8u2szrts2r98vz37sd6z9w500s99aaq4sq8s34vgv9	TVL $37,646,436
aleo1anfvuep47h0r9q349gu76d8twga8w98p0z2ggrktupcj450d5g8q7w3e2p	TVL $37,566,699