Unclaimed project
Are you a maintainer of snarkOS? Claim this project to take control of your public changelog and roadmap.
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!
A consensus change will occur at the following times:
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.
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.
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.ethThe 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.
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.rawNote that all .raw variant inputs must be byte-aligned.
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.rawN::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.
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
|
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.
Further improvements worth mentioning include:
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:
snarkos developer or leo cli tools.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 October 28th. Find the current release schedule at: https://provablehq.github.io/.
A big thank you to all the contributors on Github to this snarkOS, Leo, SDK and snarkVM release!
@antonio95
@copilot
@d0cd
@kaimast
@iamalwaysuncomfortable
@ljedrz
@meddle0x53
@mohammadfawaz
@mikebenfield
@niklaslong
@tenequm
@raychu86
@Roee-87
@vicsn