PIVX has implemented SHIELD, its custom implementation of Sapling protocol using Groth16 zk-SNARKs zero-knowledge proofs. This new protocol improves financial user data protection, usability, and overall performance compared to our earlier solutions. SHIELD was our highest priority item for 2020; goal achieved. SHIELD in simple terms, will transcend PIVX user data protection to a whole new level! Users can directly securely transfer coins from one address to another without anyone else knowing the coins' source, how many coins were sent, nor which addresses are involved in sending and receiving.
Improved P2P network code for better interaction between peer nodes. Furthermore, change to the network encapsulation code by decoupling it from the validation layer, leading to much better mutex & race conditions management that reduces the network latency by 30%, and many other improvements. Simply put: This will mean a faster, more stable, and more reliable connection to other peers in the network.
An enhanced governance tab will allow masternode owners to monitor live proposals and easily vote on them from within the QT wallet's graphic user interface. Users will no longer have to rely on masternode proposal websites or use the debug console/command terminal to vote.
In-wallet proposals will add a more accessible and user-friendly interface in the Qt wallet to create PIVX budget proposals that the community can review and vote on. This will mean no more creating proposals through the use of complex and error-prone command lines.
Reduction of bloated code by removing unused, non-essential code such as the old accounting system, Zerocoin protocol, and ZLNP. Simply put: Cleaner code means better performance, less developer confusion, and improved future-proofing of wallet development.
More stable, faster, less network bloat, reduced redundancy, and less resource consumption at the Tier Two masternode network layer.
Implement custom versions of DIP002 and DIP003 to introduce multiple enhancements to the masternode network. These include blockchain-derived masternode lists, custom reward address, voting delegations, and more.
As outlined in DIP 6, this is a decentralized BLS M-of-N threshold scheme, based on Shamir's Secrete Sharing, and it consists in 7 phases; Initialization, Contribution,Complaining, Justification, Commitment, Finalization and Mining. These steps allow for a Quorum to be defined in advance, and used for a certain time frame, to instantly reach consensus.
Based on the Long Living Masternode Quorums underling Deterministic Key Generation protocol, this functionality allows the network to validate the correct behavior of Deterministic Masternodes.
Complete refactor of the code to more efficiently reach consensus of the proposal status, and budget finalization. Also included are improvements to Masternode Payments System to funded proposals in a single block at Super Block, instead of being spread out over several blocks following Super Block. Further, refactoring of the P2P layer and network messages synchronization is included.
This functionality adds a basis for new transaction types that will provide on-chain metadata to assist various consensus mechanisms. This will allow for a more native way to implement new features which don’t naturally fit into the current concept of transactions.
This functionality supports the time frame prior the final enforcement in which the blockchain will allow both legacy and deterministic Masternodes to exist at the same time, treating them equally.
This functionality supports the new network roles of the Deterministic Masternodes system. Three roles are included. First, the 'Owner' can manage the collateral, as well as customize the masternode and rewards payout addresses separately. Second, a 'BLS Key' can be specified for the 'Service Operator' as well as a percentage of reward payment and address for the optional 3rd party manager of the Masternode. Third, an address can be specified to define who has the voting rights for the Masternode for proposals.
Changes to display the distinction between Legacy and Deterministic Masternodes. New menu actions for each Deterministic Masternode to display info, change or revoke service, change the voting key, or delete the Masternode.
New functionality added to leverage the characteristics of the Deterministic Masternodes, and provide a highly performance optimized list of existing Deterministic Masternodes, from which a consensus pool can be randomly selected. A new generalized Masternode model to accept Legacy and Deterministic Masternodes is also included.
In a future 6.x wallet release PIVX will introduce a brand-new SHIELD staking feature. It will allow an individual to stake shielded coins and receive the staking rewards directly to a shield address. This feature will protect users' data, uphold their financial data protection, and increase the shielded coins' percentage in the PIVX network, further strengthening the SHIELD protocol.
It allows the creation of staking pools where users don’t need to find a block to get rewarded. The pool operator collects all the rewards, subtracts his fee, and then redistributes the remaining part across all stakers, percentually based on the amount of delegated coins. This prevents centralization which might happen once PIVX price goes up, and ensures further network decentralization, allowing the small stakers/investors to receive staking rewards on a daily basis to their mobile wallets for a daily spending, while their staking coins are being safely stored on a hardware of offline wallet.
Improve the security and decentralization of the sporks through the use of multiple signatories. Simply put: This will provide better protection of the network against potential internal attacks or mistakes.