Development UpdateFull blog post:
https://zcoin.io/language/en/zcoin-development-update-znodes-and-scaling-zerocoin/ZnodesOne of the key challenges with Zerocoin has been scalability both from a computational cost and also the space it occupies on the blockchain. Currently, the way Zcoin implements the Zerocoin protocol, the RSA accumulators (where people burn their minted coins) are not stored anywhere but recalculated every single time. Although this approach is conceptually the safest and easiest, it does add significant computation time when calculating a Zerocoin spend transaction. At current Zerocoin transaction volumes, these are not a problem, but as Zerocoin usage becomes higher and RSA accumulators store more coins, this isn’t an ideal solution from a scaling perspective and it was always our intention to improve on this.
We also currently store all Zerocoin spend proofs (25 kb each) on the blockchain which again, isn’t a problem currently, but as more transactions go through, it will lead to significant bloat on the blockchain. The original Zerocoin paper did foresee this and proposed the use of a distributed hash table or a separate blockchain that would reduce Zerocoin spend transactions on the blockchain to a mere 64 bytes.
A key point that arose in our experience is, as Zerocoin spend transactions are computationally intensive and do not attract fees (currently all mint transactions attract a fixed 0.1 XZC fee that are paid to miners while spend transactions are free), mining pools are incentivized to ignore Zerocoin transactions. A pool before submitting a block needs to spend time to verify the Zerocoin spend transactions and during this time, another pool might have found the block and submitted it. This means that pools will make more money by purposely ignoring Zerocoin spend transactions. One approach is to add a spend transaction fee on top of the mint fee to incentivize pools to process Zerocoin transactions. However, after consideration, we did not favor this as it would mean that whatever denomination of Zerocoin you minted, you would get back slightly less (for e.g. if you minted 1 Zerocoin, you would get 0.9 XZC back). This becomes more complicated when we do eventually change the Zerocoin fee structure to be variable and it no longer becomes certain how many coins you’ll get back from a Zerocoin spend transaction which may prove to be a privacy risk as well. It also doesn’t address the concern of mining pools spending resources verifying these Zerocoin spend transactions.
Our proposal to implement Znodes solves both of these problems by creating a group of incentivized nodes that are tasked to support Zerocoin transactions. By having nodes incentivized, we can also have higher requirements for nodes that allow them to process more Zerocoin transactions and mining pools no longer need to spend time to verify Zerocoin spend transactions.
- A fixed number of XZC is deposited into an address so that Znode holders have a ‘stake’ and makes Sybil attacks much more expensive.
- Znodes will earn a portion of the block reward.
- Znodes will be the only nodes that verify Zerocoin transactions allowing normal nodes to have low requirements and also removing the disincentive for mining pools to ignore Zerocoin spend tx.
- A high percentage of Znodes will have to come to the same result for the transactions to be processed and we are also exploring the use of peer reputation management systems to reject malicious nodes.
- Znodes will store the RSA accumulators allowing quick verification instead of having to recalculate every single time allowing much larger RSA accumulator sizes.
- Allows a secondary layer for Zerocoin proofs to be stored in the future (won’t be implemented in first iteration).
The use of incentivized nodes have been controversial in the past especially when used in providing anonymity through tumbling/mixing methods. This is because in such systems, those incentivized nodes can see at least part of the mixing taking place. With Znodes, this isn’t an issue since the use of zero knowledge proofs means there is no ‘mixing’ to see. The nodes are verifying are mathematical proofs to show that a person doing a Zerocoin spend transaction has indeed done a valid Zerocoin mint without revealing which mint it is. Furthermore, we aren’t at this time considering any governance system to be implemented in Znodes. There’s also the often misplaced concern that the Zcoins would be locked up and affect liquidity. Zcoins can always be transferred out immediately from Znodes and the only effect is that the node stops being recognized as a Znode and functions as a regular node.
It is our opinion that having an incentivized node structure allows higher performance nodes which will form a strong backbone of the Zcoin and the Zerocoin network. This allows a larger number of spend transactions to be processed in each block without choking mining pools or normal nodes, larger RSA accumulator sizes and a more resilient network. With Znodes, we are confident that our Zerocoin implementation will be the premier anonymity solution for cryptocurrencies.
This post lays out the general principles of our implementation but will be subject to tweaking and potential modifications as we develop and test it.
Immediate Development GoalsWe also haven’t forgotten the other aspects of our project as just as it is important to have technical advancements, it is also critical for it to be user friendly. Together with our ongoing code audit, we are also working on improving the user experience of our wallet and Zcoin in general in a few key aspects:
Initial Load TimesThis has been one of the biggest complaints for users where an initial startup of the wallet takes a very long time. This is primarily due to the highly computationally intensive nature of the initial Lyra2 algorithm and that the verification is not multi-threaded. This was significantly improved in our current algorithm Lyra2z. We will be beginning work shortly to make this verification multi-threaded and the next step is to upgrade Bitcoin core which will include support of pruning and make it easier to develop light wallets.
Own Block ExplorerWe are already in the final stages of testing our own block explorer that will reduce reliance on third party block explorers and will have additional features related to Zerocoin transactions.
Finishing up MTPMTP will be delayed slightly to be released on testnet in the first week of April. djm34 has already started on miner development and hopes to have something to show in approximately 2 weeks.
Ability to do Zerocoin spend transactions to a third party addressCurrently, Zerocoin spend transactions only can be redeemed to a new address that is owned by you. However we can easily add the feature for Zerocoin spends to be redeemed to third party addresses, allowing users to ‘teleport’ coins directly.
Language TranslationsWe are working on translating our Zcoin wallet into multiple languages (in particular for our large Chinese community).
