Technical AMA w/ Zcash engineers Dec 8, 2017 noon PST

The Electrum server is a caching service that indexes UTXOs by public addresses, so it can answer API calls like “getBalance(any_bitcoin_address)” and “getUTXOset(any_bitcoin_address)” without rescaning the entire blockchain.

It is used by the Electrum Client to show the UI. The actual transactions on the client use the regular SPV stuff and get the SPV-level security.

4 Likes

I think it’s hard to quantify how much harder. The two main reasons it’s hard are performance issues of shielded payments, and the fact that transparent addresses are almost identical to bitcoin, so if you have experience with that adding Zcash t-addrs is easier.

2 Likes

It’s very speculative at the moment, and like I said, we need to see first if PoS works well in practice. Of course it would be awesome to avoid the heavy energy consumption of PoW.

3 Likes

Performance improvements are important. Have you guys considered disallowing txs with parents in the same mined block so you can do parallel shared-nothing tx validation, or is this not compatible with the way z-addresses are implemented?

2 Likes

This is pretty cool. Thanks for sharing!

1 Like

There are lots of possibilities! Not sure if any of them can really achieve “practically unlimited”. :slight_smile: Evaluating which one offers the best balance of consistent-low-latency, finality, capacity, practicality, reliability, assurance, simplicity, decentralization, etc. is the next step.

Possibilities include using new ZKP techniques such as zk-STARKS to compress large numbers of transactions (e.g. 1M transactions) into a single proof (e.g. a 1-MB string), and then recursively compress a million such proofs into a 1-MB string, and then have global network consensus on that. This would yield a capacity of up to a trillion transactions per consensus-period. But there are a whole lot of questions about whether it would be possible at all or whether it would come with other trade-offs that are unacceptable.

Other possibilities include Bitcoin-NG or SPECTRE, some new invention that I haven’t understood yet (like Algorand), or “copy whatever Casper/PoS/sharding protocol Ethereum has launched, as long as it works”.

8 Likes

In order to achieve this for shielded addresses (for which balances and other details are encrypted) you would need to forfeit a viewing key to the remote server, making it getBalance(viewing_key). In a UTXO-based model the server must perform some kind of “scanning” over the blockchain using this viewing key.

The authority to modify (i.e. increment) the balance of an address is given to anyone who has that address, as they are authorized to make payments to it. I don’t immediately see how you can avoid the scanning without breaking some privacy guarantee. (Maybe some kind of homomorphic encryption idea would help here.)

4 Likes

We have studied something similar: an online/offline split-node setup for making shielded transactions (#2542). My goal for this is to be able to have an offline node (or a Qubes VM with no networking) contain the keys, and generate transactions interactively using the online node (moving data in between via USB drives or clipboard buffers). I was only imagining this to be for specific spending operations, but you could probably extend this more generally to the entire node…

3 Likes

P.S. Oh yeah, and like you originally asked, Lightning Network / BOLT is also a good possibility. The Lightning Network folks have just performed their 1.0 spec and multiple implementation interop tests, so that’s very encouraging. On the other hand, I haven’t seen any evidence of UX testing yet, like whether users will find the workflow and economics of Lightning Network off-putting. Fortunately, others are likely to run those experiments for us within the next few months so we can learn from them. Lightning Network and BOLT are nicely decoupled from the underlying consensus protocol, so in principle the Zcash dev team — or someone else — can implement and deploy Lightning Network atop Zcash even while simultaneously upgrading the Zcash network/consensus protocol.

5 Likes

Regarding BIP-44-like derivation, we have a draft design for this (not yet written up) which would enable derivation of multiple z-keys (across different circuits) from a single master key, rooted in the same seed as regular BIP-32 HD wallets. I would be interested to see what you have come up with, to see if our design fits your use cases, and where the interesting differences are! :smiley:

4 Likes

Hey this was super fun! Thanks for all the great questions, and I’m excited to see what happens next, such as with Alexey’s Cosmos hub. Happy holidays everybody! :slight_smile::heart:

8 Likes

Hmm, that’s a good point. I hadn’t thought of this.

So, for this model to work the user has to hand their viewing_key to the service. Not ideal.

I wonder if there’s a way the service can stream all shielded transactions to the user and the user can then check them against their viewing key. Probably too much data/processing.

I wonder if the user can send the service multiple viewkeys to hide theirs? But the server will be able to figure out the users key because all the matched transactions will correspond to only one key. I wonder if the client can generate “decoy” viewkeys.

I need to think about this. Thanks for your help :slight_smile:

1 Like

An interesting project to watch involving LN is “CHIPS,” which is being worked on by the team that created Komodo

You may be interested in delegated detection, a feature that isn’t going to be in Sapling but is nonetheless quite interesting.

3 Likes

This is great. Let me send you what I have as soon as I get home tonight.

Even if there are rough edges, there’s an opportunity to turn this into a self-hosted solution for individuals, where a mobile wallet connects to the privately run service (at home, on a VPS etc) to generate proofs.

3 Likes

I haven’t thought about this for transparent transactions. As far as shielded transactions go:

  • You can’t have a child transaction in the same block as a parent transaction, because the child’s anchor needs to include the parent’s note commitments, and that only happens after blocks are mined.
  • Within a transaction, you can have multiple proofs chained together (later anchors derived from earlier commitments). However, the proofs themselves don’t depend on the validity of other proofs in the transaction (the anchor is sufficient via the Merkle path), and thus can be validated completely independently. But this would only give you a speed-up linear in the number of cores.

A more promising verification speed-up is probabilistic batch verification, where you could run a single slower validation for all proofs in a block, which would speed up overall block validation for blocks with many shielded Sprout transactions. We have an implementation of this (#2106), but it needs further development and testing before we would consider merging it, and we would likely run it in addition to regular verification.

1 Like

Since you mentioned btcd, what do you think of building a Zcash node on top of btcsuite? Is it interesting/worthwhile/too difficult?

Another question, have you looked at atomicswap project? Would it be possible to add Zcash support and bridge Zcash with currently supported networks? And how does it compare with zbxcat?

The AMA is technically over now. Thanks everyone for the questions and to the engineers for answering! :relaxed:

3 Likes

I’ll start with the main drawback: when used for the Sprout circuit, you reveal your spending keys to the proving service. This is obviously not an issue if you are sending from a t-address (since the spending keys are just dummy values), and thus could be used to do mobile payments to z-addresses, but it severely limits the use-cases for sending from a z-address. There are still use-cases though! The most obvious one to me is exchanges - when they want to make a shielded payment, they could spin up a temporary powerful node, use it for payment offloading, and then shut it down. In that situation, it doesn’t matter that the spending keys are sent to the proving service, because both the client and proving service are controlled by the same entity.

In Sapling, you will be able to do payment offloading without revealing your spending keys. As @nathan-at-least referred to, hardware wallets are the most likely user of this.

3 Likes