Hyperledger Indy - Anon Solutions Inc

HYPERLEDGER INDY ARCHITECTURE

research pic

Hyperledger Indy is a next-generation Blockchain platform for securely managing personal information, and connecting applications in a secure and privacy-preserving manner.  If you are not familiar with Indy you can read an overview here.

Indy supports a Layered Architecture - you don't need to know Blockchain fundamentals, or even the nuts and bolts of hooking up an Indy Agent, in order to build Indy-enabled applications.  Indy Agents can easily "Indy-enable" an existing application to enable it to issue Credentials and to receive and understand Proofs.

Indy provides a 3-layer software model (plus Layer 0, the Ledger itself), including:

  • a base Software Development Kit (SDK) for interacting with the Ledger and managing Credentials and Proofs
  • an Agent Protocol to support secure connections and data exchange between applications
  • Application Frameworks for building applications on specific technology platforms or for specific lines of business

LAYER 0 - THE LEDGER

An Indy network is a Distributed Ledger (or Blockchain), maintained by a set of Nodes, and based on a Byzantine Fault Tolerant Protocol (BFTP) called Indy Plenum.

Whew!

Sovrin is an implementation of a public Indy network.  That's probably all you need to know!  If you are building Indy-aware applications they will probably connect with Sovrin, or an equivalent public network.  If you are building your own environment for development, proof-of-concept, etc., there are distributions available (such as the VON Network, developed by the BC Government) that can be deployed quickly and easily using Docker.

LAYER 1 - INDY-SDK

The Indy Software Development Kit (or SDK) provides the main application interface on top of an Indy Ledger.  The Indy SDK is built using Rust and provides language bindings for Python, Java, Nodejs, C# and other languages.  The Indy SDK is a modular framework, and includes the following core modules:

  • Ledger - Provides an interface to read and write objects to the Indy Ledger, including DIDs, Schemas and Credential Definitions.  Transactions must be signed by a DID with the appropriate permissions in order to be accepted by the Ledger.
  • DID - Provides functions for creation and storage of DIDs.
  • Anoncreds - Provides the core capabilities to create, receive and validate Credentials and Proofs.  Anoncreds operations must have access to an existing, authenticated Wallet in order to access the user's credentials.
  • Wallet - Provides basic wallet storage operations.  Entities including DIDs, Credential Definitions, Verifiable Credentials are stored in a user's private, encrypted wallet.  Custom entities can be stored using the wallet's "non-secrets" interface.  The application does not typically interact directly with the Wallet, except when using the "non-secrets" interface (Credential storage and retrieval is handled through Anoncreds functions).

Indy uses the cryptographic functions from Hyperledger Ursa, which is a shared library across Hyperledger projects (and available for use outside of Hyperledger as well).

The Indy SDK has a plugin architecture, and supports plugins for different Payment types and Wallet storage methods.

LAYER 2 - INDY AGENTS

Indy Agents provide the capability for applications to establish secure connections with each other and exchange secure messages.  Indy Agents have the capability to define custom Messages and Message Protocols (or "Message Families") to support higher level business functions.  Two core Message Protocols are Credential Exchange and Proof Exchange (or Presentation Echange), which give Agents the capability to exchange Verified Credentials and Proofs in a secure manner.

The Indy SDK includes a "V1" Agent called VCX.  This is based on a custom Agent protocol developed by Evernym and supported by Evernym applications.  This Agent has been released as open source within the Indy SDK.

Interoperable Agent protocols have been developed through the HIPE process (or Hyperledger Indy Project Enhancements) and there are a number of "V2" Agents in active development.  (VCX is also in the process of being upgraded to support the interoperable "V2" protocols.)  A popular Python-based Agent is Indy-Catalyst, developed by the BC Government.

LAYER 3 - APPLICATION FRAMEWORKS

Indy Application frameworks provide (a) reusable implementations that are focussed on a specific business problem, or (b) frameworks that provide abstracts on (and generic implementations of) higher-level Indy-based functionality.

The BC Government Verifiable Organizations Network (or VON) is a framework for building networks to find, issue, store and share trustworthy data about organizations.  VON includes generic modules for implementing Credential Registries (public stores of Verifiable Credentials) and an Agent framework to easily add Issuers to the network.

Dyango Indy Community is a Python/Django-based application framework, built in collaboration with a UBC Blockchain research project studying the potential for using Indy to share health data for research purposes.  This framework is currently based on VCX and provides a sample user interface and a Docker-based development platform.  There are some demo applications available, and the framework is currently being upgraded to support the BC Government's Indy-Catalyst Agent.

DEVELOPING WITH HYERLEDGER INDY

Ultimately, Indy developers will work exclusively in Layer 3, using established frameworks.  However, Hyperledger Indy is a relatively new platform, and each layer is in active development.  In the table below, "Maturity" defines the level of maturity of the software components that make up the layer, and "Developer Engagement" defines the level of engagement Indy developers should expect to have with the respective software components:

Indy Layer Maturity Developer Engagement Items in Development
Layer 3 - Frameworks Low High
Layer 2 - Agents Medium Medium Agents and Protocols are in active development
Layer 1 - SDK High Low "V2" Schemas, Proof Requests
Layer 0 - Ledger High Low

As an Indy Developer, ultimately you will be working on and with higher-level Application Frameworks.  Given the relative maturity of each layer, you will likely be reviewing code for (and possibly contributing to) Layers 1 and 2, even if your primary focus is the use or development of a Layer 3 Application Framework.

Stay tuned - Anon Solutions is going to publish an introductory set of video tutorials that provide a technical overview of each layer, along with tutorials and pointers to sample code and related documentation that is available online.  There is also an associated Docker-based development environment that you can use to get up and running quickly.


footer line

Copyright 2019 Anon Solutions Inc. All rights reserved.