Iris Update: Milestone 2

Published in

Ideal Labs

8 min readDec 14, 2022

This is the second installment in Iris’ journey through our grant funded by the web3 foundation. See here for part one, as this builds on it. This is a semi-technical high-level overview.

Background

Iris is a decentralized network, built with substrate and IPFS, that provides infrastructure for creating, owning, and exchanging secret data. It uses ‘data asset classes’ to represent off-chain data (in IPFS) in an on-chain context. Iris enables fractional ownership of digital assets, programmable data access rules, moderation without censorship, and the mechanisms needed for creators to be rewarded for the value their data creates.

Important Links

Website: https://idealabs.network/

Technical documentation: https://ideal-lab5.github.io/

Iris Protocol Paper: https://github.com/ideal-lab5/whitepaper/blob/main/IRIS_PROTOCOL_DRAFT_0.0.1.pdf

Repositories:

Iris node implementation: https://github.com/ideal-lab5/iris
Iris UI implementation: https://github.com/ideal-lab5/ui
Contracts: https://github.com/ideal-lab5/contracts

Docker

Iris Node: https://hub.docker.com/repository/docker/ideallabs/iris
Iris UI: https://hub.docker.com/repository/docker/ideallabs/iris-ui

Milestone Two Overview

The completion of our second milestone is a fairly large technological restructuring of the Iris blockchain. With this release, secure data encryption and data asset class creation is accomplished through the use of gateway nodes while data reencryption is handled by proxy nodes. This milestone introduces our implementation of the ‘iris protocol’ which we developed as part of this work (you can read the full paper here). The protocol uses threshold proxy reencryption (as implemented in the umbral_pre library) along with ECDH to encrypt data and share secrets. To learn more about these libraries, see https://docs.rs/umbral-pre/latest/umbral_pre/ and https://cryptobook.nakov.com/asymmetric-key-ciphers/ecdh-key-exchange respectively. The details of our implementation or elaborated on in the protocol paper.

In previous iterations of Iris, we attempted to realize the storage layer by embedding IPFS, implemented as rust-ipfs, into the blockchain runtime. This allowed offchain workers to easily interact with IPFS by issuing commands to IPFS in a similar way as HTTP calls are made. However, this presented several difficulties, with the most notable being that the rust-ipfs project is not feature-complete and has not yet implemented several key features. And so, we made the shift to use external IPFS instances. With this, we not only have the flexibility to use nearly any IPFS implementation we want, but we are also able to ensure content delivery is functional and available to all users of the network. That is, we have shifted to use the paradigm that data is encrypted and then can be added to any IPFS node.

Secure Encrypted Data Ingestion

This milestone enables a paradigm where a data owner is able to encrypt their data once and then delegate decryption rights to other users in the futures based on a set of automated conditions (via a Rule Executor contract).

Gateway nodes bridge the gap between the offchain existence of data and the onchain representation of data.

Our data ingestion design relies on two new types of nodes: the proxy node, to enable the TPRE system, and the gateway node, which facilitates secure data ingestion and data asset class creation. Both types of nodes are required to be validator nodes prior to taking on one of these roles. In the diagram below, RPC represents the RPC endpoints exposed by an Iris node and OCW is the node’s offchain worker.

In the figure above, you see a high level overview of how data encryption and ingestion functions. A potential ‘data owner’ invokes an RPC endpoint, iris_encrypt exposed by Iris to encrypt their data. Specifically, the endpoint accepts a signed message, signature, and signer account id, along with the plaintext to be encrypted and a proxy node’s account id. In the present version of the network, any node who declares themselves as a proxy must accept any and all requests sent to it (in the next iteration of Iris, this will not be economically viable). The endpoint will verify the signature to recover the account id, then generate new keys, encrypt the plaintext, submit an unsigned transaction to submit encryption artifacts on-chain and finally, it returns the ciphertext to the caller. This process is more finely detailed in the Iris protocol whitepaper. After adding the ciphertext to an IPFS node that’s reachable by a gateway node, the data owner then calls an extrinsic to request that a gateway node verify the existence of their data and create a new data asset class on their behalf.

It should be interesting to note that the gateway nodes generate asset ids using a unique prime number they are assigned when they become a gateway and multiplying it by a monotonically increasing integer sequence whose value is the number of times they’ve tried to create an asset class. For example, the first gateway to join will generate asset ids {2, 4, 6, …}, the second will generate {3, 6, 9, …}, the third {5, 10, 15, …} and so on.

And we are halfway done! The original account that created the encrypted data now owns a data asset class that proves their ownership of the data. Now, we can move on to the next phase: exchanging secret data.

Secure Data Ejection

The whole point of that complicated ingestion process is to enable this even more complicated data exchange process, which is really three processes: authorization through a rule executor, reencryption, and finally decryption. As was illustrated in the previous milestone, data ejection still starts with a rule executor contract (though to be clear, the ‘Authorization’ module technically allows a data owner to register any address, including individual nodes).

Fig 2. Data Authorization, Reencryption, and Decryption

As was elaborated on in the first part of this series, a data owner must register any account id to who will have the authority to authorize other nodes to access their data. This could potentially be yourself or another node, but to make the process non-interactive, predictable, and transparent, we have exposed functionality that allows smart contracts on Iris to be able to submit extrinsics that allow or deny access to callers (through the chain extension). We refer to contracts such as these as ‘rule executors’. So the first step is for the data owner to register such a contract and for the data consumer to request access to data by calling some function in the contract that calls into Iris to authorize the user.

If the consumer is authorized, a new request will be encoded onchain to reencrypt the data for the consumer. The proxy node (defined on ingestion) generates new key fragments (see the Iris protocol paper) and distributes them to three randomly-chosen validator nodes (note: the number ‘three’ here is arbitrary, and we used three only because our testnet is small. This number could potentially scale with the number of validators available.). Once key fragments are distributed, each selected validator generates a new capsule fragment and encodes it on chain. Finally, the consumer can gather two (again, arbitrary) capsule fragments, and the reencryption key, and finally decrypt the data and download it.

And with this, the data has been successfully exchanged from the original data owner to a data consumer who met all of the rules set by the owner.

Testnet Setup

Since the TPRE system requires at least 3 validator nodes to be available (to accept key fragments), we created a testnet in order to test and demonstrate this version of Iris. The quickest way to get a node running and connected to the testnet is to follow the setup guide here: https://ideal-lab5.github.io/quickstart/quick_setup.html.

If you want to spin up your own testnet, the easiest way is to use three separate machines, virtual or physical. Our testnet’s validators are running on AWS EC2 instances (see an ec2 setup guide here). When creating the network, it’s advised that you also setup a private IPFS network rather than bootstrapping to a public or otherwise hosted one. Calling ipfs get xxx can take a long time in a public network which can cause the validator running the OCW to potentially go offline or be booted from the validator set. In the diagram above, you see a high-level sketch of what this looks like, where each IPFS node uses a private swarm.key to build a private network.

User Interface

We also provide a minimalist user interface as part of this milestone. You can find the UI at https://github.com/ideal-lab5/ui. It provides capabilities to make interacting with Iris easier, such a keypair generation, signing message, calling RPCs and subscribing to state queries that make it a much easier experience that using the polkadotjs UI. For further details, read how Iris handles data ingestion and ejection through our UI. A limitation of the iris UI is that it does not support the deployment or invocation of smart contracts. For that functionality, we currently defer to the polkadotjs UI.

The Iris UI provides functionality to call the iris_encryptRPC endpoint and ingest data into the network. Currently, it specifies the Bob node as the default gateway node and proxy node.

It also provides functionality to search for asset classes by id, register rule executors, and generate a keypair (needed for reencryption and decryption). For data owners, searching for assets provides capabilities to register a rule executor address. For data consumer, registered addresses are shown and copy-able when available.

Search assets and configure a rule executor address

Currently, the UI doesn’t support the execution of smart contracts. For this, we defer to the polkadotjs ui to deploy and execute contracts.

Execute rule executor contract in polkadotjs ui

Once a rule executor has notified Iris that an account is authorized to access data, the process outlined above beings, and once sufficiently many capsule fragments are available (2 in the testnet), the data consume can call the decrypt RPC endpoint and download the plaintext.