Assuring ease of use really isn’t possible if the chain is not sufficiently scalable. It goes without saying that we all learned a lesson about scalability crises in the past year. The chain spam attacker could just as easily have been Zcash having a miraculous adoption period - pragmatically speaking the sort of data packing into the blockchain would look nearly similar.
If scalability weaknesses aren’t resolved proactively with technical solutions, then we risk suffering another all wallets are sync broken again sorry type of nightmare situation, if Zcash were to catch a wave of viral adoption in the future.
I also think that lumping these kinds of improvements under the banner of “scalability” might be misleading us into thinking they’re only necessary for a future scenario where we see massive adoption and need massive transaction throughput. They are necessary for that, but they’re also essential for making our SDKs usable by developers and for giving our wallets a UX that’s competitive against centralized payment processors, even when the chain is not being overloaded.
For example, because of the need for a background process to do scanning, it’s currently impractical to write e-commerce store plugins that run their own light wallet; instead we need to trust our viewing keys to a service like ZGo. We’ve also seen projects like ZBay try to develop on Zcash’s memo field who couldn’t because transactions weren’t performant enough. Getting Zcash support into somewhere that it’s not—such as into a browser plugin or into a hardware wallet’s companion desktop app—basically requires coding an entire new light client. These are the problems we need to solve to make Zcash usable for developers, and they’re problems even when the chain has a low load.
Let’s look at Zcash’s competitors in the area of SDKs:
PayPal: A developer just has to create their account, do some KYC, grab their API token, and then they can pip install or npm install a common PayPal library to begin making and processing payments through fast API calls.
Bitcoin, ETH: A developer just has to use a library to generate account keys and addresses, make API calls to some service provider to access blockchain information, and then generate and sign transactions.
In contrast, a Zcash developer has to implement a Zcash light client, which currently needs to maintain local state, handle reorgs, and do heavyweight processing. In a lot of cases they can use an SDK, but detecting transactions requires a linear scan, in contrast to the fast API calls our competitors provide. It’s possible to eliminate these roadblocks through protocol changes without giving up too much privacy.
In my opinion, great UX for Zcash cannot come from an approach of “let’s develop SDKs and wallets with great UX around the protocol we have”, it needs to come from an approach of “let’s develop the protocol around the great UX that we want our SDKs and wallets to have.”
I haven’t fully digested the zkCoins protocol, but the problem they’ve left unsolved is how to transmit the transaction data privately off-chain. If the data is sent directly between wallets, for example through a TLS connection, the metadata leaks information about who is paying who, it’s possible to find out who owns an address, and other problems.
Zcash currently achieves metadata-resistant privacy by being a broadcast network: everyone downloads every transaction, so you can’t tell where the transactions are going (with the caveat that the light wallet protocol currently leaks information). I’ve written a blog post that goes into more detail about why any private money system needs to solve the transaction-sending/detection problem in a scalable way and describes some of the options for doing so.
I see, but zkcoins doesn’t even have addresses, right? Basically the coins are identified by the proof data that is exchanged. Am I wrong or could this happen even completely out of band, e.g. through a messenger like Signal? If so, I’d say having any secure communication channel to the recipient is the user’s task.
Yep, if you already have a secure channel to your recipient, like a Signal contact, you can definitely use that. There’s still metadata leakage, but it’s less obvious you’re sending a transaction if it’s to someone you regularly message anyway. There’s a proposal for sending transactions that way in Zcash, too: https://github.com/zcash/zips/pull/420; in this design the recipient still has to post a transaction to the chain to make sure they really got the funds. I’m gonna have to dig into zkCoins more to see how they prevent double spends without needing the recipient to wait for something to be posted to the chain.
I think they do need to post something to the chain, something that invalidates the sender’s coins. These small commitments are then summed up on the chain once a month if i understand it correctly. In the end the chain only needs to store one month’s commitments and something constant.