Payment offloading using server-less computing

[byzan2]

In the spirit of reducing the time taken by a wallet to generate proofs (Zcash issue #1113), we propose building an implementation of the current protocol taking benefit of server less computing (Azure, AWS Lambda). The idea is to explore whether clients can benefit from the resources of a powerful server that is made available only when the client initiates a payment step.

We plan to implement several of the ideas proposed in (zerocash spv clients- https://docs.google.com/document/d1gF3_BTP7IwoLOIXoxDxAK1AEdY5QPVL0dXf4EQef3p0/) including:

1) Pre-computation: As the time to set-up a new connection can be high in server less computing, it would make sense to start the connection and start some computations at the earliest opportunity of the wallet launch. Some computations are only possible once the destination public key is available.

2) Trust in the sever: We will explore the case where we are willing to share the private key with the server as required in the second SNARK.

3) Multiple servers from different providers: We will explore the use of multiple servers from different providers to minimize the risk associated with weak randomness while choosing some of the parameters.

Note, we propose not to make any major protocol changes, rather explore parallelism and server less computing to speed up things.

[tromer]

@byzan2, the upcoming Sapling upgrade will drastically reduce resource consumption shielded transaction generation (and in particular, the zkSNARK proving). See https://blog.z.cash/cultivating-sapling-faster-zksnarks (as well as the protocol spec and other upcoming blog posts).

How does this affect your proposal? Will there still be a need for such proving-as-a-service?

[byzan2]

@romer, totally agree that a reduction in proving time from 37 sec to 7 sec in the upcoming Sapling upgrade is a drastic improvement and will be good enough to not require offloading for several scenarios. But we believe that for several other (some are mentioned below) scenarios, offloading the proving service will yield substantial benefits:

1) Regular small payments to several fixed addresses: In scenarios, where small fixed payments are regularly paid to the same set of addresses (lets say smart contracts), 7 sec may be a big drain on the device. Offloading will deliver a significant benefit as literally the whole pour transaction can be pre-computed.

2) In general, payments to existing “payees”, even when the amount is not known in advance may yield significant improvements.

In both the above scenarios, the spending key would have to be embedded in the code to derive real benefits. To minimize the security risks, we also plan to explore maintenance of multiple spending keys and employing strong server authentication and key exchange at the time of server initiation, before the server can access the spending key.

[tromer]

Regarding precomputation (or other benefits of hard-coding the key), do you have a specific technical approach for how this would indeed improve performance for the on-line part?

Regarding 7 seconds, I wonder if it really matters (or is even desirable) to make proving much cheaper than that. Transactions will be posted on the blockchain, and everybody syncing up this chain will bear the cost of the transaction (in bandwidth, storage and computation). This externalized cost is probably more than 7 seconds worth of sender's computation, and indeed, transaction fees are higher than 7 seconds worth of one-time computation.

[tromer]

The Zcash Foundation Grant Review committee has reviewed your pre-proposal, including the above discussion, to evaluate its potential and competitiveness relative to other proposals. Every pre-proposal was evaluated by at least 4 committee members .

The committee's opinion is that your pre-proposal is not a leading candidate for funding in this round, and the committee therefore does not invite you to submit a full proposal. This decision is advisory, and you can still choose to submit a full proposal by June 15th, following the detailed structure described in the Call for Proposals. Note that if the full proposal is substantially the same as discussion so far reflects, then it's unlikely to be chosen for funding; and if it isn't, then we encourage you to post a draft (or at least answer any open questions) as early as possible, to allow for community feedback. Regardless of your choice, we thank you for participation thus far.