3 ms·

There is nothing preventing memory usage from being brought into the ~250MB range. The performance issues stem from a legacy codebase built by academics and a

There is nothing preventing memory usage from being brought into the ~250MB range. The performance issues stem from a legacy codebase built by academics and a focus on safety and enterprise features. >So it's plausible that monero transactions could practically end up with a larger anonymity set in absolute terms than zcash (especially for current monero, which has CT and a minimum mixin size). No, it isn't. There will always be a transaction graph between accounts, which limits the total number of possible routes between two participants in a trade.

davidsarah 10y ago
To correct a minor point, none of the current Zcash code comes from the Zerocash academic prototype. All of the code that had come from the prototype was rewritten before launch (mainly in https://github.com/zcash/zcash/pull/625 https://github.com/zcash/zcash/pull/625 ). Much of the performance issue comes from a single design decision made in Zerocash: to use SHA-256 for the Merkle tree, PRF, and note commitment hashes. We'll be changing this for the Sapling update. -- Daira Hopwood (Zcash developer)
- indolering 10y ago
  My apologies, I had assumed the codebase was legacy due to some lamentations about not being able to use Rust. I hope my portrayal of the performance issues was appropriate.
  - daira 10y ago
    The legacy codebase issue we are lamenting there is just that the code inherited from Bitcoin is in C++. It's of course possible to interface between C++ and Rust, and that's what we're intending to do in future. It would have been risky to try to do that in the code we wrote before launch. Yes, your portrayal of the performance issues was fine.