September 18, 2019 Knowledge Center

Exploring the Monetha Platform: Verifiable Data layer

Here we introduce our approach to data verification and how we use Verifiable Data layer so that entities could evaluate the trustworthiness of one another.

Overview

The Verifiable Data layer of Monetha’s Platform is designed in a way which enables blockchain network participants to evaluate the trustworthiness of one another by securely accessing context-relevant information.

Verifiable Data layer provides the following key elements and possibilities:

  • – Digital Identity – a collection of data points about an entity (person, object, organization, etc.) stored in a secure and censorship-resistant manner. The identity is not tied to a single vendor and allows its owners to transfer and use their reputation capital across many platforms;
  • – Exchange of contextually relevant data with many requestors (applications, platforms, etc.);
  • – Ownership of data and control of access to it;
  • – Monetization of reputation capital;
  • – Utilities for third party developers to build custom applications for specific use cases.

Example of a problem

Susan wants to initiate a value exchange action with John. But Susan is not certain if her expectations are going to be met as she does not have enough information about John.

Susan would very likely be looking for the following information:

– Hard facts: proof of identity, proof of payments, credit score;
– Proof of historical performance (preferrably with similar people like her);
– Recommendations from a social circle (the ones she knows);
– Comparisons with alternatives;
– Guarantee that action will be executed by John as expected.

Access to the relevant information and guarantee of proper action as described above becomes even more important when:

– The cost of the transaction is close to the person’s psychological limits (e.g. with the monthly income of $1000, a transaction for $100 or $9000 would lead to a completely different decision-making process);
– Emotion is tied to a transaction (e.g. hiring a nanny, buying a pet, renting your car/flat, selling something of sentimental value, getting a mortgage, choosing a roommate, etc.)

Current reputation solutions often provide an average score while personalized expectations are not taken into account. With the Monetha’s Verifiable Data layer we can personalize reputation, increase the sense of trustworthiness and security by having the information described above available upon request.

Verifiable Data layer design

We aim to create a generalized solution for the problem described above and allow network participants to use it as a foundation for trustful communication.

The development is driven by the following principles:

– Open-source project;
– Reputation contracts are upgradable;
– Censorship resistance: Digital Identity owners control write permissions and access to their private data;
– Misuse is easily detectable;
– User and developer-friendly;
– Improvements are driven by the community via proposals, bug bounty, and other means.

Actors

Digital Identity owner

An entity that has an incentive to establish a censorship-resistant representation of trustworthiness or an intent to share the same profile between multiple parties. 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.

Types of Digital Identity owners:

– Person;
– Item;
– Entity;
– Organization;
– Service provider.

Digital Identities can be linked to represent a specific relation with other objects (depending on the implementation it can also be treated as registered facts), e.g.:

– A person owns items;
– People are working for a company or service provider.

Information is stored in a public or private manner on the behalf of Facts Providers. Allowed actions are defined in the Digital Identity and can vary based on the context of Identity’s usage. In addition to that, the Identity’s owner grants access per each data point stored on the Digital Identity and Identity’s logic defines possible behavior and state transition.

Facts Provider

Third parties can provide simple facts (e.g. the number of deals or claims made, signed files of accomplishment, etc.) about the Digital Identity owner in a permissionless manner from the content perspective.

Data can be provided as public or private based on the purpose and nature of the data.

Smart Facts Provider

Third parties also can act as Smart Facts Providers. In this case, they can provide complex/combined inputs and/or extended insights (e.g. the probability of a claim, estimated deal duration) by applying mathematical models to their data and/or the Digital Identity’s data (both public and private) for the Identity’s owner.

Smart Facts Providers can act in pull or push mode. Data can be provided as public or private based on the Digital Identity owner’s settings. In addition, Smart Facts Providers might not store information in the Digital Identity.

Requestor

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).

Implementation

The implementation is designed to be flexible and give its users a possibility to decide on how to store information: a) on-chain or off-chain; b) in a public or private manner.

How exactly specific information is going to be stored is left for the users to decide, as it involves financial and security aspects which are best known by the users themselves and different options can be used depending on the context.

Bootstrap Verifiable Data layer: https://github.com/monetha/go-verifiable-data#bootstrap-reputation-layer
Build Go SDK: https://github.com/monetha/go-verifiable-data#building-the-source

Digital Identity owners

Anyone with an incentive to have transferable reputation can create a Digital Identity.
The Digital Identity can implement different business logic to meet the needs of a specific use case to ensure certain behavior between parties.

Source: https://github.com/monetha/reputation-contracts#passport

Facts Providers

Registered:
– A well-known and trusted source (e.g. governmental services, applications, a person);
– Such Facts Provider will also have their Digital Identity linked to the registry.

Unknown/Anonymous:
– Anybody can provide additional information about the Digital Identity’s Owner;
– All data inputs (stored via the Verifiable Data layer) are signed by Facts Providers (anonymous or known).

Source: https://github.com/monetha/reputation-contracts#fact-provider-registry

Storage Types

On-chain (Ethereum) storage:
– Transactions data;
– Event logs;
– Blockchain storage.

Off-chain storage:
– Data from a single Facts Provider is stored as a linked list off-chain;
– Only the hash is stored on-chain and the rest of the information is appended to the list.

Public and private data

Public data:
– intended for non-sensitive data (reputation profile, reviews, feedback, public insights, etc.);
– All storage types are applicable for storing public data.

Source (Go SDK): https://github.com/monetha/go-verifiable-data#usage
Source (JS SDK): https://github.com/monetha/js-verifiable-data#usage

Private data:
– intended for sensitive information (address, birth date, personal score, etc.). We have prepared an implementation design document describing the private data exchange protocol;
– Off-chain storage is used to save encrypted data. Only the hash is stored on-chain and the rest of the information is stored off-chain.

Source (Go SDK): https://github.com/monetha/go-verifiable-data#private-data

Support for permissioned blockchains

Quorum

Quorum™ is an enterprise-focused version of Ethereum. It’s ideal for any application requiring high speed and high throughput processing of private transactions within a permissioned group of known participants. Check our Repositories to learn more.

Repositories

Reputation smart contracts: https://github.com/monetha/reputation-contracts
Verifiable Data Golang SDK: https://github.com/monetha/go-verifiable-data
Verifiable Data JavaScript SDK: https://github.com/monetha/js-verifiable-data

Forking the Verifiable Data layer

Our implementation can be forked or similar ones can be built.

The solutions are in favor of our implementation:

– Provide a valuable and useful solution;
– Partnerships with Facts Providers;
– Grow a strong development community to build context-specific solutions on top of Monetha’s Platform.

If you’d like to explore collaboration opportunities with us or simply ask a question, we’d love to hear from you. Feel free to shoot us an email at [email protected].

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

There's more for you to read