Verifiable Data Layer: Design

Monetha platform Verifiable Data Layer is designed in a way that enables users and companies to securely exchange and manage their data.

Verifiable Data Layer enables to:

• handle private data: encryptions, exchange/transfer;
• verify source of the data prior exchange of data;
• granular access to stored data and it's exchange;
• agility of stored data structures;

Design

We have created a decentralization and cryptography driven design in order to achieve the following:

• censorship resistance for all network participants. Owner of his digital identity controls write permission and access to private data stored
• transparency making any kind of miss-use easily detectable
• upgradeable logic of smart contracts ensuring transparent execution
• usage of the verifiable data layer is user and developer friendly

We will cover platform actors in scope of the using the platform, data structure in order to better understand how EVM is used in order to ensure some of the vital qualities of the platform, and data exchange in order to understand how reading of data is handled.

Actors

Passport owner

An entity that has an incentive to establish a censorship resistant representation of trustworthiness. Depending on the use case, the motivation can differ: get access to services (loan, rent a house, etc.), prove the credibility of previous deals, monetize valuable information, enforce certain behavior, and so on. He is the one who is handling the Passport aka data storage.

Types of Passports:

• Person - employee, application user
• Item - collectibles, assets, properties
• Legal entity

Key features:

• Passport storage can contain either public or private data that is provided on behalf of Facts Providers.
• Passport owner controls access to private data points via approving read requests.
• Private data stored off-chain

Fact provider

A third party that is willing to provide some information about a Passport in a permissionless manner from the content perspective.

Key features:

• Provided data can be either stored as public or sensitive data.
• Fact provider can be a Data requester at the same time in case if he is providing smart/aggregated insights on already existing data in the passport.

Data requester

Anyone who has an incentive to get access to public or private facts (e.g. extended reviews, if above certain age, if in the country) or calculated insights by Smart Facts Providers (e.g. a social score calculated based on public and private facts).

Key features:

• Can drive Passport owners incentive to share private data by staking amount of tokens when requesting data
• Can start a dispute in case if data could not be decrypted

Data structure

We use smart contracts in order to ensure trust in logic execution between platform users. This as well allows us to achieve level of interoperability between network participants due to the fact that there is a clear interface in order to operate with verifiable data layer.

The main idea behind our implementation is that the Passport is the data storage owned by users. However all passports share the same contract that handles the logic aka PassportLogic.

All the methods of the PassportLogic contract are executed in the context of the Passport contract using its storage.

To store the data a general key-value storage structure is used which could be described with the following pseudo-code

    // factProviderAddress - address of a fact provider
    // dataPointKey - byte32 representation of the data point key
    // dataPointValue - value of a supported data type
    mapping(factProviderAddress => mapping(dataPointKey, dataPointValue))

Implemented model:

                          ╔═══════════════════╗
      deploys             ║                   ║
┌─────passport────────────║  PassportFactory  ║
│                         ║                   ║
│                         ╚═══════════════════╝
│                                   │
│                           uses registry to
│                          bind it to passport
│                                   │
│                                   ▼
│                   ╔═══════════════════════════════╗
│                   ║     PassportLogicRegistry     ║
│                   ║  ┌─────────────────────────┐  ║
│                   ║  │    versions mapping     │──╬────────────────────┬─────────────────────┐
│                   ║  └─────────────────────────┘  ║                    │                     │
│                   ║  ┌─────────────────────────┐  ║                  v0.1                  v0.2
│          ┌────────╬─▶│ current passport logic  │──╬───┐                │                     │
│          │        ║  └─────────────────────────┘  ║   │                │                     │
│          │        ╚═══════════════════════════════╝   │      ╔═══════════════════╗ ╔═══════════════════╗
│    gets current                                       │      ║                   ║ ║                   ║
│      passport                                         └──────║   PassportLogic   ║ ║  PassportLogicV2  ║
│        logic                                                 ║                   ║ ║                   ║
│          │                                                   ╚═══════════════════╝ ╚═══════════════════╝
│          │                                                             ▲
│  ╔═══════╩══════╗                                                      │
│  ║   Passport   ║                   delegate call                      │
├─▶║  (owner 1)   ║─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│  ╚═══════╦══════╝                                                      │
│          │                                                             │
│          │                                                             │
│  ╔═══════╩══════╗                                                      │
│  ║   Passport   ║                   delegate call                      │
├─▶║  (owner 2)   ║─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
│  ╚═══════╦══════╝                                                      │
│          │
│         ...                                                            │
│          │
│  ╔══════════════╗                                                      │
│  ║   Passport   ║                   delegate call
└─▶║  (owner N)   ║─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
   ╚══════════════╝

Contracts that are used

• PassportLogic contract defines upgradable behavior of Passport contract, assuming that each version will follow the storage structure of the previous one, but having the chance to add new behavior and/or state variables. Once the PassportLogic contract is created, it is registered in PassportLogicRegistry so that its logic could be reused later in all the passports that use this registry. Passport owner might decide to use different registry if the logic which is maintained and developed by Monetha does not meet owner's requirementes.
• PassportLogicRegistry contract contains versioned registry of passport logic. It allows to add new versions of passport logic and set one of the available versions as current, which will be used by all the passports. The registry simplifies the upgrade of the passport logic, leaving it be transparent, and at the same time it does not restrict the passport owner in choosing a registry of passport logic.
• Passport is a contract owned by the passport owner. It behaves like proxy that delegates calls (using delegatecall) to current passport logic implementation which is currently set in the PassportLogicRegistry. Passport uses delegatecall to resolve the requested behaviors, the upgradable passport logic contract's state will be stored in the passport contract itself. Passport owner:
  • is allowed to change the registry of passport logic;
  • is allowed to destroy passport;
  • is allowed to transfer ownership to the new owner. The new owner need to confirm that by claiming ownership;
• PassportFactory contract allows anyone to deploy a new Reputation passport. To deploy a reputation passport one should call the passport factory's createPassport() method. During this call the passport factory deploys a new passport and binds it to the existing PassportLogicRegistry contract. It also emits PassportCreated(address indexed passport, address indexed owner) event that allows you to get the address of the deployed passport. After the passport contract is deployed, the same account who called the passport factory's createPassport() method should additionally call the passport's claimOwnership() method to finalize the ownership transfer of the passport.
• FactProviderRegistry contract behaves like a naming system for the known fact providers. It associates various information (like name, passport address, website) with the fact provider address.

Data exchange

Passport is used as the main storage of all the data points provided by multiple fact providers and allows it's owner to share this information either in a passive way (aka public data exchange) or in an active way (aka private data exchange).

Exchanging data implies interaction. This is where the 3 actors described above interact. Fact provider write data into Passport while Data requesters either initialize private data reading or just read the public data from the Passport.

Public data

Public data exchange is a censorship resistant way of providing information into a Passport. We use term public data to specify that this information is not encrypted thus is readable by anyone who has access to the underlying blockchain.

Supported data types for public exchange:

• EVM Storage
  • Address
  • Uint
  • Int
  • Boolean
  • String
  • Bytes array
  • IPFS address
• Transaction Data
  • Bytes array

Each data type has a method for reading, modifying or deleting. While reading operation can be done by anyone. Modification and deletion operations are limited to a fact provider who initialized the data point. The whole list of currently supported methods available for each data type is defined in IPassportLogic.

Private data

Private data exchange enables actors to store and read encrypted data. In order to ensure the security of the data exchange all data is stored off-chain as a result sensitive data has only single supported data type - IPFS address.

Anyone can request private data from the passport of user. This is achieved by running an interactive protocol between the passport owner and the data requester.

How it works:

1. The data requester initiates retrieval of private data from a passport by calling propose command. When executing this command, the data requester specifies which fact provider data he wants to read, encrypts exchange key with the passport owner's public key and transfers to the passport the funds that he is willing to pay for the private data.

2. The passport owner receives an event from the Ethereum blockchain or directly from the data requester for the data exchange proposition. If he is satisfied with the proposal, he executes the accept command. When executing this command, the passport owner encrypts the data encryption key with the exchange key of data requester and transfers the same amount of funds as the data requester to the passport as a guarantee of the validity of the data encryption key.

   The passport owner has 24 hours to accept private data exchange. 24 hours after the exchange proposition, the data requester can close the proposition and return staked funds back by calling timeout command.

3. The data requester receives an event from the Ethereum blockchain or directly from the passport owner about accepted private data exchange. It decrypts the data access key using exchange key and reads private data using read command. After that finish command is called, which returns all staked funds to the passport owner.

   During the first 24 hours, the finish command can only be called by the data requester, after 24 hours anyone can call this command.

4. If it is not possible to decrypt the data, the data requester calls the dispute command, revealing the exchange key. The Ethereum contract code identifies the cheater and transfers all staked funds to the party who behaved honestly. The data requester has 24 hours to open a dispute, otherwise the exchange is considered valid and the passport owner can get all staked funds.

This is how it looks in the state diagram:

At any time, the status command can be used to get detailed information about the private data exchange.

The following exchange has an academic proof - Private-data-exchange-protocol-proof.pdf