Encrypting Data

Vana uses a patented non-custodial encryption technique to encrypt personal data. Data does not leave the user's browser unencrypted. A user's file is symmetrically encrypted with their encryption key, and if the encryption key is shared with another party, the key is encrypted with that party's public key so only the intended reciepient can decrypt the key and the data.

The steps are as follows:

1. The user uploads a decrypted file (F).

2. They are prompted to sign a fixed message with their wallets, creating a unique signature that can only be recreated by signing that same message using that same wallet.

3. The generated signature is used as the encryption key (EK) to encrypt the file F using a symmetric encryption technique, creating an encrypted file EF.

4. The encryption key EK is then encrypted with the trusted party's public key, making an encrypted encryption key (EEK).

5. The encrypted file EF and encrypted encryption key EEK can be safely shared with the intended receipient.

Decrypting Data

Once the data has been encrypted, it can be decrypted by either a dApp or trusted party.

Decryption by dApp

1. The dApp prompts the user to sign the same fixed message, to retreive the same EK as above

2. The EK is used to decrypt the encrypted file EF and retreive F

Decryption by Trusted Party

1. The trusted party receives the encrypted file EF and the encrypted encryption key EEK

2. They decrypt the EEK using their private key, to retreive the encryption key EK

3. The EK is used to decrypt the encrypted file EF and retreive F

Code Samples

Data DAOs can use the encryption technique described above to efficiently encrypt large files (up to several gigabytes in size) in the browser.

If the encryption key EK needs to be shared with a trusted party, it can be encrypted with their public key. To generate a new public/private keypair, see the instructions here.

import * as openpgp from "openpgp";

const encryptionKey = "0x0a34ab7..."; // This is a secret (EK)
const publicKeyBase64 = "LS0tL..."; // Trusted party's public key, base64 encoded
const publicKey = await openpgp.readKey({
  armoredKey: atob(publicKeyBase64),
});
const encryptedEncryptionKey = await openpgp.encrypt({
  message: await openpgp.createMessage({ text: encryptionKey }),
  encryptionKeys: publicKey,
  format: "armored",
});
// encryptedEncryptionKey (EEK) is safe to share with the trusted party 

The trusted party can now receive and decrypt EEK, resulting in EK which can then be used to decrypt the user file F. A Python code example of this is shown here.

Data Storage

In the Vana network, data is stored encrypted off-chain in a storage solution of the user's choice, providing flexibility and control over their data. This approach allows data contributors to utilize familiar platforms such as Dropbox, Google Drive, or decentralized options like IPFS.

Vana's system only requires two key pieces of information: a URL pointing to the data's location and an optional identifier that changes when the data is modified (e.g., an ETAG or last modified date). This ensures data at a particular location has not changed since it was uploaded there.

By keeping data off-chain but accessible through these identifiers, Vana maintains a balance between data privacy, user control, and cost efficiency.

Adding Data

To make data discoverable in the Vana network, it must be written onchain using the Data Registry contract. The data contributor first uploads an encrypted file to a storage provider of their choice, then writes a pointer to that file (URL) and an optional content integrity hash to the registry.

Vana uses a Proof of Contributionsystem to validate data submitted to the network. "Valid" means something different in each DLP, because different DLPs value data differently.

Data Attestation

Anyone can submit data to the Vana network. However, for data to be considered valid, it must be attested for by a trusted party, i.e. Validators in a DLP. These trusted parties issue a "certificate" to prove that this data is, in fact, authentic, high-quality, unique, and has whatever other properties DLPs value in its data contributions.

Data attestations live offchain, and a URL to a data's attestation is written onchain alongside the data itself.

Attestation Schema

The attestation of a data point must follow a spec. Each attestation has fields that are shared across all attestations and also allow DLPs to insert unique fields.

An example of when this would be useful: consider a ChatGPT DLP that accepts GDPR exports from chatgpt.com. Say the DLP considers the export to be high quality when the number of conversations in the export exceeds 10. This DLP can insert numberOfConversations: xxx right in the attestation when Proof of Contribution is run.