Hi! I recently created a proof-of-concept in https://free2z.cash. I’m considering how this thing might scale. The current design is that each page gets its own zaddress. I’m thinking that this idea might not scale very well compared to using a single address for donations/payments and parsing the memo to determine the behavior of the payment.
Let’s say I have 10 transactions to 1,000,000 addresses. Would this be a lot worse for the performance of the node than 10,000,000 transactions to a single address?
Do I have to run some tests myself or does anyone have an idea?
I don’t know all the technical details, but the wallet.dat file does not scale very well. I don’t know if some of the problems are inherited from Bitcoin or if there are some problems unique to shielded transactions. Zcash mining pools with a lot of transactions typically rotate out their wallet.dat files every so often, otherwise the wallet.dat file grows to 100s of MB and the the node ultimately grinds to a halt.
Another anecdote: Due to a bug in a script, I once accidentally sent someone 15,000 shielded transactions. My node was rendered inoperable.
Also take a look at diversified addresses (different addresses with same spending key). That way, you don’t have to trial decrypt every shielded transaction in the world with each and every one of the spending keys you have in your wallet. You can have one spending key for an unlimited number of addresses.
The node only needs to send when the total balance accumulates to a certain point. A lot of small payments come in. So, there might be 500 coming in to 1 going out. I wonder if this is pertinent to your 15,000 send case. In my case, maybe 8,000 sends a year…
Your comment gives me a lot to think about. I think the most scalable design would be to just keep the wallet(s) small and disposable. This would mean maintaining all app state offchain - so, once transaction state is sync’d to the traditional database, the wallet.dat could effectively be discarded … that could definitely scale but then I essentially have to implement a sort of metawallet in traditional database …
Do you have any more information about how to implement “diversified addresses”? I’m mostly interacting with the node via the RPC interface.
Ah, yes! Now I remember you from one of the first Bay Area ZEC meetups years ago!
I don’t think zcashd has RPC calls for diversified addresses. (We added the RPC calls to ycashd back in 2019, and I use diversified addresses in some of my personal projects.)
Does any one here know whether there’s support for diversified addresses in librustzcash?
Awesome, thanks for the feedback. I know what I need to do now. BTW, also thanks for ZIP 321: Payment Request URIs which will make everything possible!