Peer-to-Peer Data Sharing

Background

Centralized platforms such as YouTube, Instagram, TikTok, and Patreon have been the backbone of the Creator Economy thus far. These platforms provide creators with avenues to generate revenue via advertising, sponsorships, and fan support. However, they come with inherent drawbacks, including platform dependency, revenue sharing, and limited content ownership.

On the other hand, the existing Web3 creator platform fails to achieve censorship-resistance and data value sharing, due to the lack of data confidentiality measurement on transparent blockchains. Such an issue makes a creator unwilling or unable to share a worthy plain file with a paid customer through blockchains.

A straightforward way is to create a peer-to-peer data-sharing application on the blockchain with cryptography-ensured confidentiality. Within such a use case, the process of data-sharing is completely processed via smart contracts, by which the transaction atomicity is achieved. To achieve confidentiality, the data shall be encrypted and stored on decentralized storage, and further be accessed by the paid customer after the FHE computation on the encrypted data.

A Multi-key FHE Solution

The general process of peer-to-peer data sharing is shown in the following figure. We discuss the process that is integrated with PADO's zkFHE network on the task level. It is important that the data provider does not use their own encryption key. Allowing the provider to use their secret key would involve them in the sharing process and create an additional dependency. On the other hand, we shall not allow a single third party with his public key to run the outsourced encryption, which breaks the data confidentiality. A decent approach is to let the data provider encrypt data with a couple of public keys from a certain group to minimize the trust assumption. This is where Multi-key FHE is applied.

Encrypt Data

Let's assume there is a dApp that provides the peer-to-peer data-sharing feature for its end-users.

The data provider uses the dApp and requires a group of public keys from the zkFHE network and uses that public key set to encrypt the data. Here we suggest a hybrid encryption shall be applied, i.e., use a secret key K to encrypt the data content with a symmetric encryption algorithm and use different public keys to encrypt the shares of K with (zk)FHE algorithms.

The data provider then stores all the ciphertexts into a storage system, which can be either a storage blockchain or a centralized storage service.

Share Encrypted Data

A data consumer uses the dApp and sends some crypto assets to the dApp contract. In addition, the data consumer shall also send his public key to the dApp contract for decrypting the shared result which can only be accessed by himself. The dApp contract shall assign the computation task with the consumer's public key, to the computation network and requires FHE computation for the encrypted data-sharing.

After the computation execution, the result will be a new ciphertext that encrypts the data with the consumer's public key. The data consumer can receive that result and decrypt it locally to recover the plain data.