Skip to content

RIW2021_RFC_Optimistic ZKC(S)P #15

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions 3DM_RFC/RIW2021_RFC_Optimistic ZKC(S)P.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# RIW2021 | RFC: Optimistic ZKC(S)P

_Status:_ **draft**; **~~ready for review~~**; **~~ready to publish~~ **

_Area of Improvement:_ Data Delivery Metering

_Estimated Effort Needed:_ <?>

_Prerequisite(s):_ <?>

_Priority:_ <? P0, P1, P2>


### Abstract

In this RFC, we propose a way to rely on the ZKCP only for resolving a dispute when one of the parties decides to go rogue at the end, only incurring the cost of issuing the proofs in case of misbehavior.

Note: Watch the full recording with Davidad’s presentation as it is a very complete description (LINK HERE)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidad would you be ok in sharing presentation for this RFC?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just watched the recording of this talk on OZKCP. I’m happy to say I’m actually proud of it and would be happy for it to be published on YouTube or wherever as appropriate. (Btw big thanks to @daviddias for graciously letting me run almost 50% longer than the assigned slot!)


### **Proposal/Construction**

* On a payment channel:
* Agree on the query - both parties sign
* In case the query is simply retrieving a CID, then privacy can be maintained even for a dispute, by revealing only the hash of the query to the chain
* Agree on the prices
* Buyer deposits enough coins for query execution + bandwidth + overhead
* Seller executes query
* If seller aborts at this point, query times out and coins return to buyer
* Seller sends result, in encrypted chunks
* If seller aborts at this point, buyer goes to on-chain dispute resolution
* Buyer acknowledges receipt of encrypted chunks & pays per-chunk for bandwidth
* If buyer aborts at this point, seller is out of luck - reputation risk
* Possibly, buyer could also report the speed (timestamping the ACKs)
* If buyer starts reporting slower than it actually is, the seller will throttle to match
* Seller reveals decryption key
* If seller aborts, buyer can go on-chain and claim a slash against the seller (and seller can reveal decryption key, with a proof, to “appeal” the slash)
* Buyer verifies query satisfaction
* Buyer acknowledges receipt of decryption key
* If buyer aborts, seller goes to on-chain and makes a proof

**Impact**

TBWRITTEN

### Pros and Cons

TBWRITTEN

### **Implementation **notes**

TBWRITTEN

### **Evaluation**

TBWRITTEN

### Prior work

ZKCP, ZKCSP