Iris Milestone 1 Update

Published in

Ideal Labs

7 min readJun 27, 2022

Overview

Iris is a decentralized data exchange protocol that enables a secure data ownership, access management, and delivery layer for Web 3.0 applications. It is infrastructure for the decentralized web. By building a cryptographically verifiable relationship between storage and ownership, Iris provides a data exchange which enables the transfer and monetization of access to and ownership of data across chains, smart contracts and participants in the network or connected through a relay chain. Iris provides security, reputation, and governance on top of storage, enabling data ownership, monetization, access management, capabilities to define unique business logic for data access and authorization, as well as smart contract support for content delivery. It applies DeFi concepts to data to represent off-chain assets in an on-chain context by representing data as a unique asset class with access to the underlying data controlled by ownership of assets minted from the asset class.

As we approach the finish line to completing our first milestone of our followup grant proposal, as funded by the web3 foundation, we want to take some time to reflect on the deliverables that we’ve completed, and to discuss what this means for the future direction of Iris.

A shift in our approach to storage

As part of this deliverable, we’ve decided to abandon our previous integration with rust-ipfs. Our integration, which is an updated verison of the offchain::ipfs repository, is still available here for those who are interested. We made this choice due to several reasons. Firstly, rust-ipfs is still very much in development and is not feature complete, so we will replace it with go-ipfs. Secondly, again due to it being in development as well as substrate’s core runtime facing frequent changes, syncing our fork of substrate with the substrate master created massive maintenance overheads with minimal benefit. With that said, as part of this milestone we’ve also modified the iris node, moving it out of our substrate fork and into it’s own dedicated repository with dependencies coming from the latest substrate version. This not only allows us to benefit from a fast build and test times, but also from being able to seamlessly upgrade our substrate dependencies as the library matures. In the near term, we intend to integrate with external storage systems for cold storage, exploring both centralized and decentralized data storage solutions. In the long term, we intend to construct our own integrated storage layer to complement the data exchange layer that we are currently building out.

Data spaces

With this milestone, we introduce the concept of the ‘data space’. The dataspace forms the basis for both organization of data as well as moderation (in the future). With this addition, we also stipulate that all data in Iris must exist within the context of a dataspace, however, there is no limit to the number of spaces a data owner can associate their data with. The idea behind dataspaces is very much the same as the idea behind data assets that were introduced as part of the original iris proposal, where an asset class represents ownership of an “real” off-chain asset and assets minted from the class represent on-chain access to the off-chain asset.

Under the hood, the ‘data space’ is an asset class which is mapped to a set of configuration items that determine the inclusion and moderation policies of the space. In general, the owner of a dataspace can mint assets and distribute or sell them to other addresses in the network, which then allows those addresses to associate data asset classes that they own with the dataspace.

The idea behind this is that it allows for dapp developers and builders to define cryptographically unique ‘groups’ that they can associate their data with, providing a way for users to associate disparate datasets with one another in a verifiable way. To elaborate on this through an example, imagine there’s a decentralized video streaming app, say dstream, that wants to use Iris to manage their users’ data. The app developers create their own dataspace, which allows them to do some cool things. First, the developers can stipulate that only data associated with their dataspace is available on the ‘dstream’ app. This implies that users who want to upload data “to the app” (keep in mind, however, that this does not imply that the user can only associate their data with dstream, they can associate with any number of dataspaces they want) must own an asset that allows them to do so, so dstream can either:

provide free access to users (i.e. a faucet)
allow users to purchase dataspace access tokens (on an ‘access exchange’)
allow users to trade their access to other addresses in the network

Dataspaces also form the basis for moderation, or curation, within the Iris network. This is not currently implemented and probably won’t be for some time. Our intention is that each data space may have a set of rules associated with it which limits not only the type of data that can be associated with the space, but also with the contents of the data. We intend to accomplish this through the execution of machine learning models, Bayesian filters, and more.

Contract Based data authorization scheme

The final major delivery as part of this milestone is the introduction of a new mechanism that provides data owners the capability to define unique authorization and access models for their data. We maintain that the minimal requirements for data authorization is the ownership of at least one asset minted from a the data asset class, and this is defined within the runtime itself. We have developed a rule-based system through which a data owner can specify any number of rules that determine if data is accessible or not by a consumer. We call these ‘composable access rules’, and they’re executed by a ‘rule executor’.

Rule Executor

A rule executor is a smart contract that instantiates each composable access rule and exposes an ‘execute’ function that’s responsible for executing each composable access rule and then reporting that result on-chain. For an example, take a look at the example rule executor here which runs a ‘single use rule’. To accomplish this, a data owner registers the rule executor’s address with their asset class, via a new module we introduce called the iris-ejection module.

Composable Access Rules

Composable access rules (a.k.a. CARs) are contracts deployed to the iris blockchain that allow data owners to determine unique sets of rules that data consumers must follow. They are called ‘composable’ in the sense that you can aggregate multiple rules via a rule executor, such as limiting the number of times an asset can be used to fetch data while also stipulating that an asset be used before a given date or within some specific time frame. Each composable access rule must must implement the ComposableAccessRule trait, meaning the contract implements an ‘execute’ function that returns a boolean value:

fn execute(&mut self, asset_id: u32, consumer: ink_env::AccountId) -> bool

By allowing a rule executor to aggregate many CARs, unique authorization mechanisms can be achieved. This also provides the freedom for data owners to deploy their own unique CARs to the network and to share them with others.

The limited use rule

The first rule that we developed as part of this delivery is the limited use rule. This rule stipulates that any given address is only able to retrieve data associated with some given asset a predefined number of times. For example, you may stipulate that data can only be retrieved a single time from the network, and any subsequent attempts result in authorization not being granted.

Deployment and Execution Process

The basic process to allow data consumers to gain access through a rule executor is to:

ensure each composable access rule that you want to use is deployed on chain
develop your rule executor to pass the code hash of each CAR you want to execute and to instantiate each one within the constructor
develop the rule executor’s execute function execute(asset_id) so that it calls the execute function of each composable access rule, passing the assetId and caller to each rule, and use the Iris chain extension to submit results back on-chain.
deploy the rule executor to the Iris blockchain
Either from the iris-ui or the polkadotjs ui, from the irisEjection pallet invoke the registerRule extrinsic to register the rule executor’s contract address with your asset id.

asset class and rule executor association model

This process is elaborated on in the demonstration video below:

Iris Milestone 1 demo

Next Steps

Implementation of proxy nodes: enabling hot storage in the Iris network
Creation of an offchain client: enabling data owners and consumers to run light clients and to interact with Iris through browser-only application and mobile devices
Enabling a light client: we’re working on running Iris as a light client, giving data owners and consumers the flexibility to communicate with iris via browsers and mobile devices.

You can read more about our upcoming features by taking a look at our grant proposal here: https://github.com/w3f/Grants-Program/blob/master/applications/iris_followup.md