That’s right. PIVX-blockchain specific (custom) Sapling integration code has just been published for public audit/review! The implementation has been tested running on regtest (private chain) with shielded zk-SNARKs transactions working already! (wow) It also includes a whole suite of unit & functional tests from the get go.
What does this actually mean?? It means that PIVX (an advanced blockchain development-focused project that we always were) is finally showing to the world that we have been developing the privacy solution that we said we would (back in Feb), and that our developers really have the chops to make it happen!
So be proud and be excited Pivians; we are now much closer to owning our own shielded PIVX using highly respected technology with proven cryptography. 5.0 is gonna be sweet!
Sapling integration, milestone 3 and 4.
Essentially, Sapling running on the regtest network -- yeah :), -- and being covered by a good amount of unit and functional tests . (Still, not enough tests. We definitely need more).
This is the last big PR for Sapling work that have (fulfilling the complete base protocol functionality). All of the remaining work can be covered in smaller PRs.
Covering the following points:
Sapling transaction data:
- Signature hash personalization + sigversion (custom ZIP243).
- Sapling transaction primitive data (OutputsDescription, SpendDescription, value and bindingSig)
- Transaction version bump, Sapling will be using version 2.
Sapling transactions management:
- Wallet: notes, nullifiers and witnesses data management.
- Shielded transaction builder.
- Wallet Shielded transaction creation flow.
- Wallet's transactions in-chain detection (note decryption + addToWalletIfInvolveMe).
- Wallet's transactions rescan.
- SaplingOperation class to decouple the Shielded tx creation + broadcast flow from the wallet sources.
- Incremental merkle integration for Sapling notes (sapling tree root hash stored on the block header).
- Chain: final merkle tree root calculation.
- Nullifiers & Anchors db, coins view integration.
- Block version bump + miner v8 block generation.
- spent/unspent notes validation.
- sapling transaction validation (sapling_validation.h).
- Negative shielded pool value detection (zip209).
- Coins: check transaction shielded requirements validation.
Unit test coverage:
- Sapling test fixture.
- Coins nullifiers & anchors check in coins_tests.
- sighash_tests checking the Sapling signature.
- transaction builder tests.
- rpc wallet sapling tests.
- wallet import/export keys test.
- wallet keys encryption/decryption test.
- sapling_wallet_tests (coverage for internal wallet methods: FindMySaplingNotes, SetSaplingNoteAddrsInCWalletTx, GetConflictedSaplingNotes, SaplingNullifierIsSpent, NavigateFromSaplingNullifierToNote, SpentSaplingNoteIsFromMe, CachedWitnessesEmptyChain, CachedWitnessesChainTip, CachedWitnessesDecrementFirst, CachedWitnessesCleanIndex, ClearNoteWitnessCache, UpdatedSaplingNoteData, MarkAffectedSaplingTransactionsDirty).
TODO, upcoming work:
- Connect txmempool nullifiers.
- Fix memo field issues.
- Cache shielded credit/debit amounts.
- Main.cpp validations further review.
- Wallet: implement locked notes.
- Wallet: back port clear witness caches.
- Rewind to last NU functionality.
- Migrate functional test using the deprecated accounts system.
- Cleanup sprout code (remnant, not used).
- Migrate sapling tests using the deprecated accounts flag.
- Connect GUI.
Need further discussion:
- Shielded transactions fees (current placeholder hardcoded to 1 PIV).
- Mixed transactions validation (Transaction with transparent and shielded inputs/outputs). Currently these type of transaction are being checked on the sapling_validation file, as well as the version 2 tx with purely transparent inputs and outputs.
- We need to think whether should decouple the net validations commits from this PR or not (those who touches the network consensus). It's a hard choice as the vast majority of unit and functional tests validating the correct behavior comes by the middle-end of this work. --- Hopefully commits are atomically enough to make the review process easier ---
Work based on the ECC implementation. It's NOT one-to-one. Have adapted it into our network + modified the architecture and improved specific areas of the sources. There is still lot of work to do, plenty of space for improvements :) .
Sorry for the massive PR but couldn't resist myself. We can definitely think on how to decouple it in smaller PRs if things get hard to review. As said above, commits should be atomic enough but i know that it's not, commit wise, a 100% incremental work.