FIP Proposal: ZKCP over payment channels for fair retrievals

[adlrocha]

Posting this FIP proposal here to open a discussion before pushing a PR. Would love the feedback! 🙏

---
fip:
title: Zero Knowledge Contingent Payment (ZKCP) over Payment Channels for fair retrievals.
author: @adlrocha
discussions-to: #73
status: Draft
type: Technical
category: Networking
created: 2020-02-22
spec-sections:

• Retrieval Market in Filecoin

Simple Summary

• Support for fair-exchanges of data in retrieval deals.
• Implementation of a Zero Knowledge Contingent Payment (ZKCP) protocol over Filecoin payment channels.
• Support for the coexistence of different retrieval exchange protocols in the network.

Abstract

Filecoin retrieval deals currently happen primarily offline. Clients send periodic payment vouchers over a payment channel to pay for the retrieval of blocks of data to a provider. The provider sends blocks until it requires payment. When the provider requires payment, it pauses the data transfer until the client sends its next payment. This setup produces a clear unbalance in the exchange: if the provider requests a payment before the blocks paid for are sent, it can escape with the payment voucher and redeem it without sending any data to the client; and the other way around, if the provider sends the blocks before the client sends its payment, the client is able to run with the blocks without having to pay for them.

The aim of this FIP is to remove this unbalance in retrieval deals implementing all the primitives required to run a Zero Knowledge Contingent Payment protocol over Filecoin payment channels. This opens the door to the coexistence of different retrieval exchange protocols in the retrieval market, and the implementation of fair exchange of data over retrieval deals.

Change Motivation

The unbalances in the current implementation of retrieval deals is vulnerable to unfair exchanges, where a client or a provider can take advantage of the other party. In the case of clients, they would be able to run with some blocks of data without paying the provider; while in the case of providers, they would be able to request a payment and run with the payment voucher without sending the corresponding blocks paid for.

A retrieval of data is currently conformed by the following steps:

• The client finds a provider of a given piece and sends a `RetrievalDealProposal. In this proposal a field defining the type of retrieval exchange to be used could be included.
• All the required operations to get ready for the retrieval are performed: setting up the payment channel, unsealing the corresponding sectors, etc.
• The provider monitors data transfer as it sends blocks over the protocol, until it requires payment.
• When the provider requires payment, it pauses the data transfer and sends a request for payment as an intermediate voucher. At this point, the client would be able to run with the blocks received up to that point without sending any payment in exchange for them.
• The client receives the request for payment.
• The client creates and stores a payment voucher off-chain.
• The client responds to the provider with a reference to the payment voucher, sent as an intermediate voucher (i.e., acknowledging receipt of a part of the data and channel or lane value). At this stage, if the voucher also pays for subsequent blocks of the exchange not sent already, the provider would be able stop the exchange and run with the payment voucher without sending the pending blocks.
• The provider validates the voucher sent by the client and saves it to be redeemed on-chain later
• The provider resumes sending data and requesting intermediate payments. Each of these additional interactions gives room for both parties to leverage this attack.

Specification

Add a parameter in the negotiation of the retrieval deal (for instance in the '
RetrievalDealProposal) to agree on the type of retrieval to be performed: mainly, pay-per-chunk or zkcp (at least for now).

When a retrieval deal of type zkcp is accepted by a provider, the provider performs the following steps before sending the data:
- It generates a symmetric key k, and uses k to encrypt the chunk of blocks to be sent in the retrieval, c = Enc_k (data).
- It computes a hash of the key, y = hash(k), and builds a Zero Knowledge Proof, v, that verifies E^-1_{hash-1(y)} == c, i.e. that the ciphertext c has indeed been encrypted using the key whose hash is y.

The provider then sends over the data channel the encrypted data, c along with the hash of the key, y, and the proof v, and requests a payment. In order for the provider to reveal the key, the client needs to send a payment voucher.

The client sends a payment voucher setting the field SecretPreimage = y in the voucher. For the provider to be able to redeem the payment it needs to reveal the key, k, for the client to be able to recover the data.

If the accepted retrieval is of type pay-per-chunk, client and provider run the current implementation of the retrieval exchange seamlessly.

The basic implementation of the zkcp retrieval assumes a single payment for all the blocks of data requested. To support an exchange with n partial payments, the provider needs to generate n different keys, encrypt each of the n set of blocks with a different key, build n proofs, and redeem the n vouchers to reveal the keys to the client.

Design Rationale

This proposal adds overheads to the current implementation of retrieval deals, and it may not suit the needs of every retrieval exchange. The rationale behind the proposal is to put in place all the constructions required to run a ZKCP protocol to perform fair-exchanges over Filecoin payment channels. This opens the door to the coexistence of several retrieval protocols so clients and providers can agree on the most suitable one to fulfill their needs in a retrieval deal.

There are already some proposals being discussed for alternative implementations of the ZKCP protocol with optimizations and modifications to circumvent some of its limitations. Having a basic implementation of ZKCP in Filecoin can open the door to the design and implementation of more retrieval exchange protocols for fair-exchange based in this basic construction. A few examples of the aforementioned alternative implementation of ZKCP retrievals can be found here:

• https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/DECENTRALIZED_DATA_DELIVERY_MARKETS.md#new-ideas-being-explored
• https://github.com/adlrocha/go-fil-markets/blob/3dm/docs/rfcs/notes.md

Backwards Compatibility

This proposal is backward compatible. What's more, one of its goal is to enable the coexistence of different retrieval exchange protocols over the Filecoin retrieval network.

Test Cases

TBD

Security Considerations

The main security considerations for this proposal involve:

• The zero-knowledge proof construction used for v in order to verify E^-1_{hash-1(y)} == c, not leaking any information about the data or the key.
• The payment vouchers only being redeemable by the revelation by the provider of the key used to encrypt the data.

Incentive Considerations

Supporting the coexistence of several retrieval exchange protocols and fair-exchanges of data based on a ZKCP protocol gives flexibility to the retrieval network and retrieval deals, as clients and applications are able to choose the retrieval scheme that better suit their needs.

Moreover, this paves the way for the design and implementation of new retrieval exchange protocols, and further innovations in the retrieval market.

Product Considerations

• Having the ability to perform fair exchanges of data in retrieval deals removes the need of any kind of reputation in retrieval deals and off-chain data exchanges/interactions.
• Making payment channels ZKCP-compatible opens a new space for the implementation of new coexisting retrieval deals. This would enable clients and applications to select the retrieval exchange protocol that best suit their needs (a client may choose a pay-per-chunk exchange for fast retrievals, and a zkcp fair retrieval for costly ones).

Implementation

TBD

Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

[kaitlin-beegle]

@adlrocha I'm auditing our existing FIPs repository and noticed that no action seems to have been taken on this issue. Can you please provide an update?

Specifically, was this issue perhaps addressed in a different repo, or were offline decisions made which affected the status of this topic? If not, we should revisit this proposal and flag for the community.

[adlrocha]

hey, @kaitlin-beegle. This FIP was proposed in the context of the 3DMs RFCs that we were exploring at ResNetLab at the beginning of the year. ZCKP was a basic primitive for many of the protocols we were exploring and thus the FIP.

There has not been much progress since as the team has been dragged to other priorities. If the community sees value in this proposal, by all means let's re-activate it, if not I guess we can freeze it for now.

[kaitlin-beegle]

Reached out to @adlrocha on Slack to ask about moving vs. closing this issue.