Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ZIP: Delegated Proving T (DPT) Protocol #104
Roughly, there is a light wallet, a proving service, and some way to interact with the blockchain.
a. JAXX-like: light wallet is written in JS and may not have sufficient RAM for proving. It relies on a third party service for learning about UTXOs, block headers, relaying transactions. It uses a public proving service.
Note for a or c where there is a web service, it may or may not charge a fee for the service. Protocols should accommodate that if possible.
Two Protocol Categories
(Note: Let's exclude DPZ category from the topical meeting until the DPT case is well covered.)
a. Delegated Proving T (DPT) - a light wallet sends from t-addr to z-addr via proving service.
Assume light wallet has full blockchain view, but not the proving service.
#. light wallet hands proving service everything necessary to generate a proof sending from t-addr (controlled by light wallet) to z-addr, including:
#. proving service generates proof, hands back to light wallet.
referenced this issue
Feb 6, 2017
Notes from discussion:
Can give prover H_sig directly so it won't need randomseed and joinsplitpubkey..
If we do it in a way that we're giving the prover all data of dummy notes, including a_sk the same code could be used for the DPZ (assuming sender trusts Prover with his a_sk,e.g. when it's address containing only this note)
Should there be separate binaries for the client/server? Should it be part of zcashd?
Give prover less data using circuit change?
Questions about boundaries..
I often refer to the C++ class called
In zcash/zcash#1113 (comment) I have listed what zcash/zcash#2120 currently sends over the wire for proving. The information set is sufficient for both DPT, and DPZ where the prover is given the spending key. More importantly, it ensures that the proving service does not select any of the random values (for either regular Note components or dummy Note values), so they have zero ability to influence the resulting transaction other than providing an invalid proof (per the discussion in the topical meeting).
@nathan-at-least re: your original DPT sketch:
I am confused about point 3. If the light wallet hands the proving service everything necessary to generate a proof, it can already derive the output commitment. More specifically, I don't see a way to validate the server's response other than verifying the proof. If the client sends insufficient information such that it requires the server to choose values and compute commitments, then the server can return those values and the client can verify that the commitment provided by the server is equal to what they calculate with the server's randomness and their own note pre-images. However, that doesn't constrain the proof on-the-wire - IIUC, given a commitment and a proof, there is no way to validate that the proof took that commitment as input without actually validating the proof, which could contain random data for all we know.
Comment from @ebfull in dev chat:
One takeaway of the above discussion is that the API should enable sending multiple requests for proofs at once to the proving service. In particular, it is doable and desirable to be able to send most or all
The next logical question is, should the wire format enable encoding of the chaining (to make the proving service's job easier) at the expense of providing more contextual information (that the proving service could figure out on its own eventually anyway)? There are three possible formats for a request:
The third form doesn't seem to be necessary, because it can be expressed as multiple messages of the second form. In order to check that it will either get paid or produce proofs that are useless to the client, the proving service only needs to check that all of the anchors in messages of the second form are dependent on the first anchor (and that it is paid by the first JoinSplit). The third form doesn't help it to do that any more easily.
There's actually an extra degree of freedom in the second form: the list can either be constrained to be all from the same transaction, or a grab bag of multiple transactions. The third form simply makes this distinction concrete.
What I'm trying to reason about here is whether a client or server might want to request proofs from separate transactions or not, and how the server's desire to enforce payment might restrict that ability. From a ZIP level, we could just say "the wire format is a list of JoinSplit inputs" and leave any higher-level considerations to specific implementations, but is that unambiguous enough? Conversely, if we specify e.g. that all JoinSplits in a request must be chained, is that too restricting?