Skip to content

A library and proxy server for interacting with Hyperledger Indy Node ledger instances

License

Notifications You must be signed in to change notification settings

hyperledger/indy-vdr

Indy-VDR (Verifiable Data Registry)

Unit Tests Python Package

Introduction

This library is derived from Hyperledger Indy SDK for the more limited use case of connecting to an Indy Node blockchain ledger. It is written in Rust and currently includes a Python wrapper and a standalone proxy server.

This library is still in development and there are currently no standard release packages.

Features

Indy-VDR can be used to connect to one or more Indy Node ledger pools given sets of genesis transactions. Methods are provided to construct ledger requests and send them to the validators, collecting the results and ensuring that there is a consensus between the nodes.

Building from Source

First, you must have Rust installed. For development, we recommend VS Code with the RLS plugin.

The library and proxy server can be built by running cargo build in the root directory. To build only the library, use cargo build --lib. You can add --release to produce smaller, faster binaries but with less information available for debugging purposes.

This should compile and place the shared library and indy-vdr-proxy executable in the target/debug subdirectory. The library will be named as libindy_vdr.so on Linux, libindy_vdr.dll on Windows, and libindy_vdr.dylib on Mac OS.

Wrappers

The Python wrapper is located in wrappers/python/indy_vdr. In order for the wrapper to locate the shared library, the latter may be placed in a system shared library directory like /usr/local/lib. Otherwise, the location of the shared library must be added to the appropriate environment variable for your platform: PATH for Windows, LD_LIBRARY_PATH for Linux or DYLD_LIBRARY_PATH for Mac OS.

At a later stage it should be possible to install a precompiled 'wheel' package for your platform using pip install indy_vdr, but at the moment it is necessary to build the library from source.

Proxy Server

The indy-vdr-proxy executable can be used to provide a simple REST API for interacting with one or more Indy ledgers. Command line options can be inspected by running indy-vdr-proxy --help.

To start the proxy server for a single ledger use the following command:

indy-vdr-proxy -p <PORT> (-g <OPTIONAL_PATH_TO_GENESIS_FILE>)

To start the proxy server with the standard configuration of indy ledgers use the following command: indy-vdr-proxy -p <PORT> -- --multiple-ledgers This will get the ledger configuration from https://github.com/IDunion/indy-did-networks

A custom ledger configuration can be provided either by specifying a Github repo or a local folder:

indy-vdr-proxy -p <PORT> -g <GITHUB_URL or PATH_TO_FOLDER> -- --multiple-ledgers

The structure needs to be as follows <NAMESPACE>/OPTIONAL<SUB_NAMESPACE>/pool_transactions_genesis.json, e.g. /sovrin/staging/pool_transactions_genesis.json

Responses can be formatted in either HTML or JSON formats. HTML formatting is selected when the text/html content type is requested according to the Accept header (as sent by web browsers) or the request query string is set to ?html. JSON formatting is selected otherwise, and may be explicitly selected by using the query string ?raw. For most ledger requests, JSON responses include information regarding which nodes were contacted is returned in the X-Requests header.

Sending prepared requests to the ledger is performed by delivering a POST request to the {LEDGER}/submit endpoint, where the body of the request is the JSON-formatted payload. Additional endpoints are provided as shortcuts for ledger read transactions:

  • / Return configured ledgers
  • {LEDGER}/ Basic status information about the server and the ledger pool
  • {LEDGER}/genesis Return the current set of genesis transactions
  • {LEDGER}/taa Fetch the current ledger Transaction Author Agreement
  • {LEDGER}/aml Fetch the current ledger Acceptance Methods List (for the TAA)
  • {LEDGER}/nym/{DID} Fetch the NYM transaction associated with an unqualified DID. Can be used with timestamp or seq_no query parameters to fetch specific versions
  • {LEDGER}/attrib/{DID}/endpoint Fetch the registered endpoint for an unqualified DID
  • {LEDGER}/schema/{SCHEMA_ID} Fetch a schema by its identifier
  • {LEDGER}/cred_def/{CRED_DEF_ID} Fetch a credential definition by its identifier
  • {LEDGER}/rev_reg/{REV_REG_ID} Fetch a revocation registry by its identifier
  • {LEDGER}/rev_reg_def/{REV_REG_ID} Fetch a revocation registry definition by its registry identifier
  • {LEDGER}/rev_reg_delta/{REV_REG_ID} Fetch a revocation registry delta by its registry identifier
  • {LEDGER}/auth Fetch all AUTH rules for the ledger
  • {LEDGER}/auth/{TXN_TYPE}/{ADD|EDIT} Fetch the AUTH rule for a specific transaction type and action
  • {LEDGER}/txn/{SUBLEDGER}/{SEQ_NO} Fetch a specific transaction by subledger identifier (0-2, or one of pool, domain, or config) and sequence number.

If the proxy server is used with a single ledger, the {LEDGER} part of the path must be omitted.

DID:Indy Resolver

Indy VDR contains a DID Resolver to resolve DIDs and dereference DID Urls to ledger objects from configured ledgers according to the did:indy specification.

GET /1.0/identifiers/{DID or DID_URL}

Connecting to a Ledger

Whether using the library or the proxy server, you will need a genesis.txn file containing the set of pool genesis transactions. You can run a local pool in Docker using VON-Network or follow the Indy-SDK instructions.

However the library is used, the RUST_LOG environment variable may be set in order to adjust the volume of logging messages produced. Acceptable values are error, warn, info, debug, and trace. The RUST_BACKTRACE environment variable may also be set to full for extended output in the case of fatal errors.

How to Contribute

  • Join us on the Hyperledger Discord. Guidance at chat.hyperledger.org.
  • Developer certificate of origin (DCO) are required in all Hyperledger repositories, so to get your pull requests accepted, you must certify your commits by signing off on each commit. More information can be found in Signing Commits article.