Releases: ProvableHQ/snarkOS
v4.4.0
Announcing Aleo Stack v4.4.0
Our team is happy to announce a new version of the Aleo Stack, which includes the node implementation snarkOS and the programming language Leo. These applications are built on top of the developer-friendly snarkVM and Aleo SDK libraries. Aleo is an open source cryptocurrency through which developers can deploy cryptographically secure dApps.
Most notably, this release unlocks using block timestamps in Aleo smart contracts. A number of stability improvements have made their way into the nodes. Costs can now be estimated using Authorizations instead of Executions, making it easier for wallets to determine fees. \
If you want to try it out, you can build from source today or download the mainnet release from Github November 25th. Find the current release schedule at: https://provablehq.github.io/.
Please report any issues you might come across!
What's new in snarkOS v4.4.0
Consensus change: ConsensusVersion V12
A consensus change will occur at the following times:
- Canary - ~9AM PT November 14th, 2025
- Testnet - ~9AM PT November 21st, 2025
- Mainnet - ~9AM PT December 2nd, 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.
New operand: block.timestamp
This PR added a new block.timestamp operand that can be used in finalize. This adds to the existing block.height operand for accessing block state, and allows for richer smart contract logic on the Aleo chain.
Improvements for node operators
Further improvements worth mentioning include:
- Logging has been improved to allow for better debugging of potential consensus or operational issues.
- Bootstrap validator peering has been stabilized, lowering the risk of DoS attacks
- A new BLOCK_LAG histogram metric to track the validator's system time with the block timestamp of the latest processed block. This is tracked in milliseconds..
- This PR introduces a
--trusted_peers_onlyflag, while deprecating--allow_external_peersand--rotate_external_peers. The new flag can be used by a node to sync with just the peers passed explicitly via --validators and --peers. - Reduced erroneous reporting of stale transmissions
What’s new in Leo v3.4.0
Empty arrays and empty loop
Arrays of size 0 and loops over empty ranges are now supported in Leo. While these constructs do not produce any instructions in the compiled Aleo bytecode, they enable more generic or pattern-based programming styles in Leo, especially when writing code that abstracts over sizes, iterates conditionally, or uses compile-time parameters. For example:
Stability improvements
- Improved identifier validation in Leo, resulting in clearer and more precise error messages, especially when Leo identifiers conflict with reserved Aleo identifiers.
- Fixed an issue where local
constvalues failed to compile correctly when used in loop ranges. - Resolved a crash in the common subexpression elimination optimization pass that occurred for certain patterns of function calls.
Library and tooling updates
snarkVM v4.4.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:
- Support was added to compute a fee based on an Authorization instead of an Execution:
execution_cost_for_authorization execution_cost_v*functions have been made private and are no longer accessible, useexecution_costinstead- The tracing feature has been removed from snarkvm-ledger-store
Closing notes
The full changelogs for the referenced releases can be found here:
- ProvableHQ/snarkVM@v4.3.0...testnet-v4.4.0
- https://github.com/ProvableHQ/snarkOS/compare/v4.3.0…testnet-v4.4.0
If you want to try it out, you can build from source today or download the mainnet release from Github November 25th. Find the current release schedule at: https://provablehq.github.io/.
Contributors
A big thank you to all the contributors on Github to this snarkOS, Leo, SDK and snarkVM release!
@copilot
Contributors
Assets 5
testnet-v4.4.0
Announcing Aleo Stack v4.4.0
Our team is happy to announce a new version of the Aleo Stack, which includes the node implementation snarkOS and the programming language Leo. These applications are built on top of the developer-friendly snarkVM and Aleo SDK libraries. Aleo is an open source cryptocurrency through which developers can deploy cryptographically secure dApps.
Most notably, this release unlocks using block timestamps in Aleo smart contracts. A number of stability improvements have made their way into the nodes. Costs can now be estimated using Authorizations instead of Executions, making it easier for wallets to determine fees. \
If you want to try it out, you can build from source today or download the mainnet release from Github November 25th. Find the current release schedule at: https://provablehq.github.io/.
Please report any issues you might come across!
What's new in snarkOS v4.4.0
Consensus change: ConsensusVersion V12
A consensus change will occur at the following times:
- Canary - ~9AM PT November 14th, 2025
- Testnet - ~9AM PT November 21st, 2025
- Mainnet - ~9AM PT December 2nd, 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.
New operand: block.timestamp
This PR added a new block.timestamp operand that can be used in finalize. This adds to the existing block.height operand for accessing block state, and allows for richer smart contract logic on the Aleo chain.
Improvements for node operators
Further improvements worth mentioning include:
- Logging has been improved to allow for better debugging of potential consensus or operational issues.
- Bootstrap validator peering has been stabilized, lowering the risk of DoS attacks
- A new BLOCK_LAG histogram metric to track the validator's system time with the block timestamp of the latest processed block. This is tracked in milliseconds..
- This PR introduces a
--trusted_peers_onlyflag, while deprecating--allow_external_peersand--rotate_external_peers. The new flag can be used by a node to sync with just the peers passed explicitly via --validators and --peers. - Reduced erroneous reporting of stale transmissions
What’s new in Leo v3.4.0
Empty arrays and empty loop
Arrays of size 0 and loops over empty ranges are now supported in Leo. While these constructs do not produce any instructions in the compiled Aleo bytecode, they enable more generic or pattern-based programming styles in Leo, especially when writing code that abstracts over sizes, iterates conditionally, or uses compile-time parameters. For example:
Stability improvements
- Improved identifier validation in Leo, resulting in clearer and more precise error messages, especially when Leo identifiers conflict with reserved Aleo identifiers.
- Fixed an issue where local
constvalues failed to compile correctly when used in loop ranges. - Resolved a crash in the common subexpression elimination optimization pass that occurred for certain patterns of function calls.
Library and tooling updates
snarkVM v4.4.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:
- Support was added to compute a fee based on an Authorization instead of an Execution:
execution_cost_for_authorization execution_cost_v*functions have been made private and are no longer accessible, useexecution_costinstead- The tracing feature has been removed from snarkvm-ledger-store
Closing notes
The full changelogs for the referenced releases can be found here:
- ProvableHQ/snarkVM@v4.3.0...testnet-v4.4.0
- https://github.com/ProvableHQ/snarkOS/compare/v4.3.0…testnet-v4.4.0
If you want to try it out, you can build from source today or download the mainnet release from Github November 25th. Find the current release schedule at: https://provablehq.github.io/.
Contributors
A big thank you to all the contributors on Github to this snarkOS, Leo, SDK and snarkVM release!
@copilot
Contributors
Assets 2
v4.3.0
Announcing Aleo Stack v4.3.0
Our team is happy to announce a new version of the Aleo Stack, which includes the node implementation snarkOS and the programming language Leo. These applications are built on top of the developer-friendly snarkVM and Aleo SDK libraries. Aleo is an open source cryptocurrency through which developers can deploy cryptographically secure dApps.
Most notably, this release unlocks native Keccak+ECDSA-based signature verification, allowing for messages from other popular cryptocurrency ecosystems like Ethereum to be verified in Aleo’s public smart contract scope - while still having access to native zero knowledge proofs verification too. Moreover, maximum array sizes have increased, node syncing is 5x faster, and both transaction and solution broadcasting has been greatly stabilized. \
If you want to try it out, you can build from source today or download the mainnet release from github October 28th. Find the current release schedule at: https://provablehq.github.io/.
Please report any issues you might come across!
What's new in snarkOS v4.3.0
Consensus change: ConsensusVersion V11
A consensus change will occur at the following times:
- Canary - ~9AM PT October 17th, 2025
- Testnet - ~9AM PT October 24th, 2025
- Mainnet - ~9AM PT November 4th, 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.
Keccak+ECDSA signature verification opcodes
Aleo added native ECDSA signature verification to on-chain (finalize) execution to improve interoperability and broaden supported signature formats. With on-chain verification, programs can trust externally signed messages and approvals without off-chain helpers, enabling cross-chain messaging, asset flows, multisig/governance, etc. The initial scope focuses on verification with a simple canonical representation and deterministic, consensus-safe behavior, while leaving room to add other schemes and encodings over time.
The core design revolves around the new ecdsa.verify.* instructions that will be available to new programs. In order to support this, we require a lot of supporting features that enable the use of the new signature verification algorithm.
ECDSA
This PR introduces native ECDSA signature verification to on-chain (finalize) execution to improve interoperability and broaden supported signature formats. With on-chain verification, programs can trust externally signed messages and approvals without off-chain helpers, enabling cross-chain messaging, asset flows, multisig/governance, etc. The initial scope focuses on verification with a simple canonical representation and deterministic, consensus-safe behavior, while leaving room to add other schemes and encodings over time.
The list of new ecdsa.verify.<variant> instructions are as follows:
ecdsa.verify.keccak256ecdsa.verify.keccak256.rawecdsa.verify.keccak256.ethecdsa.verify.keccak384ecdsa.verify.keccak384.rawecdsa.verify.keccak384.ethecdsa.verify.keccak512ecdsa.verify.keccak512.rawecdsa.verify.keccak512.ethecdsa.verify.sha3_256ecdsa.verify.sha3_256.rawecdsa.verify.sha3_256.ethecdsa.verify.sha3_384ecdsa.verify.sha3_384.rawecdsa.verify.sha3_384.ethecdsa.verify.sha3_512ecdsa.verify.sha3_512.rawecdsa.verify.sha3_512.eth
The variant types allow the users to select the underlying hash function used, the serialization type (with .raw), and if the address being verified is a 20-byte Ethereum address. The .raw variants indicate if the message should be serialized in it's raw bit form or with Aleo specific variant bits; this is necessary to ensure compatibility with external signing libraries. By default the .eth variants will serialize the message in it's raw form, so there is no need for an additional .eth.raw suffixed variant. Both .raw and .eth variant messages must be "byte-aligned", meaning that the length of it's bit representation must be a multiple of 8.
Hash Functions
To further interoperability of AVM programs between EVM programs, this PR introduces .native variants of the hash.keccak* and hash.sha3* opcodes that allow the user to output the hash as a bit array. These opcodes do not implicitly perform the BHP hash on the result. The PR also introduces .raw variants use the raw serialization of the pre-image that does not contain any Aleo specific variant bits.
The list of new instructions are as follows:
hash.keccak256.nativehash.keccak384.nativehash.keccak512.nativehash.sha3_256.nativehash.sha3_384.nativehash.sha3_512.nativehash.keccak256.native.rawhash.keccak384.native.rawhash.keccak512.native.rawhash.sha3_256.native.rawhash.sha3_384.native.rawhash.sha3_512.native.rawhash.keccak256.rawhash.keccak384.rawhash.keccak512.rawhash.sha3_256.rawhash.sha3_384.rawhash.sha3_512.raw
Note that all .raw variant inputs must be byte-aligned.
Serialization Operations
This PR also introduces serialize.* and deserialize.* opcodes which allow encoding and decoding AVM values to and from bits respectively.
The list of new instructions are as follows:
serialize.bitsserialize.bits.rawdeserialize.bitsdeserialize.bits.raw
Increase Array Size Limit to 512
N::MAX_ARRAY_ELEMENTS is updated from 32 to 512. This provides more general flexibility for handling inputs to hash and signature verification functions without having to construct custom structs to get around the existing limitation.
Faster syncing for Aleo nodes
By combining faster deserialization and better pipelined fetching of blocks, syncing was sped up by up to 5 times! Syncing speed is continuously monitored in CI to prevent regressions.
| Benchmark suite | Current: 50aa002 | Previous: 83805f6 | Ratio |
rest-get-block
|
2.68524245510956 ops/s
|
0.65 ops/s
|
0.24
|
rest-block-height
|
7863.4395405039495 ops/s
|
185.18 ops/s
|
0.023549491166830062
|
p2p-sync
|
1.3 blocks/s
|
0.25 blocks/s
|
0.19
|
p2p-sync-speed-variance
|
1.240252 blocks^2/s^2
|
0.202773 blocks^2/s^2
|
0.16
|
bft-sync
|
1.16 blocks/s
|
0.2 blocks/s
|
0.17
|
cdn-sync
|
1.23 blocks/s
|
0.43 blocks/s
|
0.35
|
More stable transaction and solution broadcast
Both transaction and solution broadcast now offer the same broadcast strategy to ensure even when clients are out of sync they may still propagate transactions and solutions.
Moreover, transactions which hit a "global state root not found" errors are still propagated. In all likelihood, these are caused by nodes temporarily being behind. This PR improves the network's UX by letting those transactions propagate anyway.
Improvements for node operators
Further improvements worth mentioning include:
- A local peer cache was introduced for client, prover and validator nodes. The cache is stored in the ledger folder, and allows a node to be able to find its previous (high quality) peers again. Ultimately this paves the way for clients not having to manually specify other clients anymore, as after an initial connection via bootstrap peers, they will always be able to find each other again directly. Connections to new nodes are partially guided by whether they are ahead or not.
- Nodes will now shut down when a panic occurs and log a clean error.
- This PR implements snarkos account import to allow derivation of view key and address from a given private key, allowing easier testing without the use of the leo binary.
- Log...
Contributors
Assets 5
testnet-v4.3.0
Announcing Aleo Stack v4.3.0
Our team is happy to announce a new version of the Aleo Stack, which includes the node implementation snarkOS and the programming language Leo. These applications are built on top of the developer-friendly snarkVM and Aleo SDK libraries. Aleo is an open source cryptocurrency through which developers can deploy cryptographically secure dApps.
Most notably, this release unlocks native Keccak+ECDSA-based signature verification, allowing for messages from other popular cryptocurrency ecosystems like Ethereum to be verified in Aleo’s public smart contract scope - while still having access to native zero knowledge proofs verification too. Moreover, maximum array sizes have increased, node syncing is 5x faster, and both transaction and solution broadcasting has been greatly stabilized. \
If you want to try it out, you can build from source today or download the mainnet release from github October 28th. Find the current release schedule at: https://provablehq.github.io/.
Please report any issues you might come across!
What's new in snarkOS v4.3.0
Consensus change: ConsensusVersion V11
A consensus change will occur at the following times:
- Canary - ~9AM PT October 17th, 2025
- Testnet - ~9AM PT October 24th, 2025
- Mainnet - ~9AM PT November 4th, 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.
Keccak+ECDSA signature verification opcodes
Aleo added native ECDSA signature verification to on-chain (finalize) execution to improve interoperability and broaden supported signature formats. With on-chain verification, programs can trust externally signed messages and approvals without off-chain helpers, enabling cross-chain messaging, asset flows, multisig/governance, etc. The initial scope focuses on verification with a simple canonical representation and deterministic, consensus-safe behavior, while leaving room to add other schemes and encodings over time.
The core design revolves around the new ecdsa.verify.* instructions that will be available to new programs. In order to support this, we require a lot of supporting features that enable the use of the new signature verification algorithm.
ECDSA
This PR introduces native ECDSA signature verification to on-chain (finalize) execution to improve interoperability and broaden supported signature formats. With on-chain verification, programs can trust externally signed messages and approvals without off-chain helpers, enabling cross-chain messaging, asset flows, multisig/governance, etc. The initial scope focuses on verification with a simple canonical representation and deterministic, consensus-safe behavior, while leaving room to add other schemes and encodings over time.
The list of new ecdsa.verify.<variant> instructions are as follows:
ecdsa.verify.keccak256ecdsa.verify.keccak256.rawecdsa.verify.keccak256.ethecdsa.verify.keccak384ecdsa.verify.keccak384.rawecdsa.verify.keccak384.ethecdsa.verify.keccak512ecdsa.verify.keccak512.rawecdsa.verify.keccak512.ethecdsa.verify.sha3_256ecdsa.verify.sha3_256.rawecdsa.verify.sha3_256.ethecdsa.verify.sha3_384ecdsa.verify.sha3_384.rawecdsa.verify.sha3_384.ethecdsa.verify.sha3_512ecdsa.verify.sha3_512.rawecdsa.verify.sha3_512.eth
The variant types allow the users to select the underlying hash function used, the serialization type (with .raw), and if the address being verified is a 20-byte Ethereum address. The .raw variants indicate if the message should be serialized in it's raw bit form or with Aleo specific variant bits; this is necessary to ensure compatibility with external signing libraries. By default the .eth variants will serialize the message in it's raw form, so there is no need for an additional .eth.raw suffixed variant. Both .raw and .eth variant messages must be "byte-aligned", meaning that the length of it's bit representation must be a multiple of 8.
Hash Functions
To further interoperability of AVM programs between EVM programs, this PR introduces .native variants of the hash.keccak* and hash.sha3* opcodes that allow the user to output the hash as a bit array. These opcodes do not implicitly perform the BHP hash on the result. The PR also introduces .raw variants use the raw serialization of the pre-image that does not contain any Aleo specific variant bits.
The list of new instructions are as follows:
hash.keccak256.nativehash.keccak384.nativehash.keccak512.nativehash.sha3_256.nativehash.sha3_384.nativehash.sha3_512.nativehash.keccak256.native.rawhash.keccak384.native.rawhash.keccak512.native.rawhash.sha3_256.native.rawhash.sha3_384.native.rawhash.sha3_512.native.rawhash.keccak256.rawhash.keccak384.rawhash.keccak512.rawhash.sha3_256.rawhash.sha3_384.rawhash.sha3_512.raw
Note that all .raw variant inputs must be byte-aligned.
Serialization Operations
This PR also introduces serialize.* and deserialize.* opcodes which allow encoding and decoding AVM values to and from bits respectively.
The list of new instructions are as follows:
serialize.bitsserialize.bits.rawdeserialize.bitsdeserialize.bits.raw
Increase Array Size Limit to 512
N::MAX_ARRAY_ELEMENTS is updated from 32 to 512. This provides more general flexibility for handling inputs to hash and signature verification functions without having to construct custom structs to get around the existing limitation.
Faster syncing for Aleo nodes
By combining faster deserialization and better pipelined fetching of blocks, syncing was sped up by up to 5 times! Syncing speed is continuously monitored in CI to prevent regressions.
| Benchmark suite | Current: 50aa002 | Previous: 83805f6 | Ratio |
rest-get-block
|
2.68524245510956 ops/s
|
0.65 ops/s
|
0.24
|
rest-block-height
|
7863.4395405039495 ops/s
|
185.18 ops/s
|
0.023549491166830062
|
p2p-sync
|
1.3 blocks/s
|
0.25 blocks/s
|
0.19
|
p2p-sync-speed-variance
|
1.240252 blocks^2/s^2
|
0.202773 blocks^2/s^2
|
0.16
|
bft-sync
|
1.16 blocks/s
|
0.2 blocks/s
|
0.17
|
cdn-sync
|
1.23 blocks/s
|
0.43 blocks/s
|
0.35
|
More stable transaction and solution broadcast
Both transaction and solution broadcast now offer the same broadcast strategy to ensure even when clients are out of sync they may still propagate transactions and solutions.
Moreover, transactions which hit a "global state root not found" errors are still propagated. In all likelihood, these are caused by nodes temporarily being behind. This PR improves the network's UX by letting those transactions propagate anyway.
Improvements for node operators
Further improvements worth mentioning include:
- A local peer cache was introduced for client, prover and validator nodes. The cache is stored in the ledger folder, and allows a node to be able to find its previous (high quality) peers again. Ultimately this paves the way for clients not having to manually specify other clients anymore, as after an initial connection via bootstrap peers, they will always be able to find each other again directly. Connections to new nodes are partially guided by whether they are ahead or not.
- Nodes will now shut down when a panic occurs and log a clean error.
- This PR implements snarkos account import to allow derivation of view key and address from a given private key, allowing easier testing without the use of the leo binary.
- Log...
Contributors
Assets 2
v4.2.2
- Allow you to specify hostnames as part of both the --peers and --validators flags.
- Improves reliability of solution_broadcast, with a
check_solutionquery parameter.
testnet-v4.2.3
- Allow you to specify hostnames as part of both the --peers and --validators flags.
- Improves reliability of solution_broadcast, with a check_solution query parameter.
v4.2.1
Our team is happy to announce a new version of the Aleo Stack, which includes the node implementation snarkOS and the programming language Leo. These applications are built on top of the developer-friendly snarkVM and Aleo SDK libraries. Aleo is an open source cryptocurrency through which developers can deploy cryptographically secure dApps.
Most notably, this release unlocks a reduction of base fees by 90%, as well as the introduction of priority fees. This effectively creates a fee market, allowing users to bid in order to get a higher priority in the mempool. The release also introduces various quality of life improvements such as new /v2/ snarkOS endpoints with more informative responses, performance improvements, as well as a Leo update command.
If you want to try it out, you can build from source today or download the mainnet release from github September 9th. Find the current release schedule at: https://provablehq.github.io/.
Please report any issues you might come across!
What's new in snarkOS
Consensus change: ConsensusVersion V10
A consensus change will occur at the following times:
- Canary - ~9AM PT August 29th, 2025
- Testnet - ~9AM PT September 5th, 2025
- Mainnet - ~9AM PT September 16th, 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.
Reduced Fees + Priority Fees
The use of zero knowledge cryptography in Aleo enables a highly scalable blockchain network. However, those scalability benefits have not translated into low fees on the Aleo network - yet. Because of a large focus on security, high fees have served as an additional layer of defense against Denial of Service attacks. The time has come to deliver on the promise of zero-knowledge proofs, and to make transactions cheap.
Technically, this will soon be possible because of the spend limits which are introduced, acting as another layer of defense against high compute. As such, this ARC proposes to reduce compute-related costs by a factor of 25x, which will significantly bring down average transaction costs by up to 92%. Note that private transfers are not impacted, because they did not incur any compute costs, which was the aspect which has been discounted.
Example deployment cost reduction
| Program | Price before [microcredits] | Price after [microcredits] | Reduction [%] |
| credits.aleo | 134,619,400 | 115,123,243 | 14.4 |
| grant_disbursement_arcane.aleo | 13,805,525 | 8,953,181 | 35.1 |
Example execution cost reduction
| Function | Price before [microcredits] | Price after [microcredits] | Reduction [%] |
| credits.aleo transfer_public execution | 34,060 | 2,725 | 91.9 |
| credits.aleo transfer_private execution | 2,242 | 2,242 | 0 |
Priority fees
This release also introduces priority fees which effectively create a fee market, allowing users to bid in order to get a higher priority in the mempool.
In more technical detail, this PR introduces a priority queue for transactions containing a nonzero priority fee. This is drained before the pre-existing transactions queue when sending transactions to the BFT.
A few notes on the current design:
- Priority fees for transactions already in the mempool cannot be updated.
- There is no protection against starvation: if the priority pool stays full enough, transmissions from the standard queue will not be sent to the BFT.
- Batch building is not atomic w.r.t. the memory pool.
New endpoints
Check transaction on broadcast
Submitting transactions to blockchains and developing on them can be difficult. In order to verify transactions, you need the latest state, and it is ultimately up to consensus to include a transaction into a block, which is a multi-stage opaque process. To improve the quality of life for users and developers, this PR introduces a new feature for nodes allowing them to perform an early optional check on the transaction, and to return the result synchronously to the user:
The reason this is optional, is that for many applications, performance is critical, so the default behaviour is the same as before: the user gets a response just confirming receival, not approval.
Fetching a batch of statePaths
This PR adds a new REST endpoint that allows users to fetch multiple state paths at once. This will help mitigate the global state root to be the same across iterations issues seen when users/provers are querying for state.
The commitments in the query string are comma separated. At most 16 commitments can be fetched at a time
Informative snarkOS JSON-RPC responses
snarkOS now supports versioned API endpoints. This change is backwards compatible, meaning by not indicating any version, or by using the /v1/ prefix, the original responses will be used.
New /v2/ snarkOS endpoints have been introduced which return more informative error messages. Instead of only returning a 500 or 429, the REST API now returns the error chain as JSON It will (try to) set the HTTP status code correctly:
-
/// 200 Success -
/// 203 Non-Authoritative Information -
/// 400 Bad Request - Invalid input, malformed parameters, validation errors -
/// 404 Not Found - Resource not found -
/// 422 Unprocessable Entity - Business logic validation errors -
/// 429 Too Many Requests - Rate limiting -
/// 503 Service Unavailable - Temporary service issues (node syncing, feature unavailable) -
/// 500 Internal Server Error - Actual server errors, unexpected failures
For example, the /transaction_broadcast endpoint will now return detailed information with regards to whether or not a transaction could be checked and whether the node is synced:
We encourage explorer APIs to support the new version and new These new return codes as wellmay become available via updated explorer APIs as well.
Improvements for node operators
Some further improvements worth mentioning include:
- Networking code has been significantly cleaned up, leading to fewer spurious connection issues. (#3754)
- Syncing has been further sped up and stabilized (#2745)
- Running a network with the
test_networkfeature now prints more low level debugging information. - Peers can now be specified both by IPs and hostnames. (#3768)
- The "Overview" page in the terminal UI (display) is usable again. It now shows the currently connected peers and information about the latest block. (#3767)
testnet-v4.2.2: Merge pull request #3838 from ProvableHQ/release-mainnet-4.2.1
[Release] Mainnet 4.2.1
v4.2.0
Merge pull request #3834 from ProvableHQ/release-4.2.0 [Release] Mainnet 4.2.0
v4.1.0
Check out https://provable.com/blog/announcing-snarkOS-v4.1.0 for an overview of changes