/hlp-candidate

Digital Asset's proposed code contribution to the Linux Foundation's Hyperledger Project written in Java and Scala

Primary LanguageJavaApache License 2.0Apache-2.0

Notice regarding the Linux Foundation's Hyperledger project

HLP-Candidate is Digital Asset's proposed contribution to the Linux Foundation's Hyperledger project. We have made it available as open source to enable others to explore our architecture and design. Digital Asset's intention is to engage rigorously in the Linux Foundation's Hyperledger project as the community establishes itself, and decides on a code base. Once established, we will transition our development focus to the Hyperledger effort, and this code will be maintained as needed for Digital Asset's use.

While we invite contribution to the HLP-Candidate project, we believe that the broader blockchain community's focus should be the Hyperledger project.

This codebase has been renamed to "HLP-Cadidate" but parts of the code reference "hyperledger" as a result of the legacy usage of that term prior to the mark being transferred to the Linux Foundation. This codebase is one of 4 proposal codebases to the official Hyperledger project, and links to the others can be found in the official Linux Foundation repository. Hyperledger is a trademark of The Linux Foundation. Linux Foundation is a registered trademark of The Linux Foundation. Linux is a registered trademark of Linus Torvalds.

HLP-Candidate

HLP-Candidate is an enterprise ready blockchain server with a client API. HLP-Candidate has a modular architecture and configurable network architecture.

HLP-Candidate implements an append-only log of financial transactions designed to be replicated at multiple organizations without centralized control. Technology companies today are well aware of the benefits of having a data backbone, or Enterprise Service Bus, to coordinate data across services within the company. The goal of HLP-Candidate is to allow expansion of the data backbone concept to the multi-organization level.

HLP-Candidate is designed to be the lowest level communication and consensus layer and aims to upgrade components of today's global financial infrastructure, which consists of a complex patchwork of systems, protocols, and adapters. We are open sourcing this project with the belief that as a critical part of the new financial infrastructure, this part of the software stack should be commoditized, collaborated on and serve as the robust backbone on which applications can be developed.

What we are making available today is the most recent stable version of a combination of many man years of work across multiple startups: Digital Asset, Bits of Proof, Blockstack, and Hyperledger. However, it is still a work in progress and we are in the process of replacing several components, adding others, and integrating with other open source projects. This particularly relates to security, scalability, and privacy, and is outlined in the roadmap below.

HLP-Candidate was built with the requirements of enterprise architecture in mind by a team that has worked in financial institutions for decades. It has a highly modular design at both the code and runtime levels to allow for integrations with legacy systems. The networking rules are configurable to allow for distinct interoperable consensus groups, each with its own functional and nonfunctional requirements.

HLP-Candidate utilizes the same UTXO/script based transactional decision of Bitcoin and extends it with features required in financial services. While the public Bitcoin blockchain is not suitable for many uses within regulated financial infrastructure, much of its design and mature cryptography has been withstanding attacks in the wild, protecting tokens with a market cap in the billions of dollars. There has been a large amount of venture investment around Bitcoin and a huge body of development work done around it. By conforming to the UTXO model as a de facto standard there is a larger ecosystem of innovation to draw from.

Digital Asset has also started working on a prototype implementation of the Practical Byzantine Fault Tolerance consensus module as a replacement for Proof of Work. We are collaborating with many of the other members of the project on the consensus module to ensure there is a scalable, secure, Byzantine Fault Tolerant consensus protocol that can provide settlement finality for wholesale financial institutions.

Other major additions are:

Roadmap

After being submitted to the Linux Foundation’s Hyperledger project, the roadmap will be determined by the Technical Steering Committee and community of contributions. The code base that we are contributing is the latest stable version but we have many more improvements that we will be contributing shortly:

  • Enhanced privacy features
  • Integration with multiple Byzantine Fault Tolerant consensus implementations
  • JNA bindings to a consensus library derived from the Bitcoin consensus library. This will allow for security audit of the patchset defining the divergence from Bitcoin, which has a well understood set of consensus rules
  • Fixes following a 3rd party security audit and static code analysis
  • Support for some of the Elements Project feature set

Building and running

Prerequisites

Version numbers below indicate the versions used.

Optionally a JMS bus provider

Installing Prerequisites on OSX

  • brew update
  • brew tap homebrew/versions
  • brew install git
  • brew install maven
  • Download and install the latest Java 8 dmg file from Oracle
  • Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE 8 from Oracle, which is a zip file. Extract it and copy the local_policy.jar and US_export_policy.jar files to your your <java_runtime_home>/lib/security
  • brew install protobuf250
  • brew install procmail if the command lockfile is not available on your OSX version

Installing Prerequisites on Ubuntu Linux

  • add-apt-repository ppa:webupd8team/java
  • apt-get update
  • apt-get install git maven oracle-java8-installer oracle-java8-unlimited-jce-policy protobuf-compiler procmail

Building Steps

  • git clone ???
  • cd hyperledger
  • mvn clean package

The most important results of the build are

  • server/main/target/hyperledger-server-main-<version>-dist.tar.gz - for bitcoin-like network
  • server/pbft/target/hyperledger-server-pbft-<version>-dist.tar.gz - for PBFT network

Running

Setup

It is recommended to copy the resulted *.tar.gz file outside of the project directory and execute the below commands there. The below commands are illustrating running the bitcoin-like network, but the similar steps apply for the other one too.

  • tar zxf hyperledger-server-main-<version>-dist.tar.gz
  • cd hyperledger-server-main-<version>

Setup for server and client in two processes connected with ActiveMQ

  • Besides the above steps copy examples/jmsclient/target/hyperledger-examples-jmsclient-<version>.jar next to the extracted hyperledger-server-main-<version> directory
  • Copy from the extracted hyperledger-server-main-<version>/conf/activemq.xml to the conf directory of your ActiveMQ installation

Starting and stopping

  • ./start.sh conf/bitcoin1.conf
  • ./stop.sh

The start script accepts a config file parameter. Example config files are in the conf directory. If no parameter is provided then it defaults to the system property hyperledger.configurationFile if it is set, otherwise it defaults to conf/application.conf.

Only one instance can run from a directory. If you want to run multiple instances then you have to repeat the setup steps in another location. This is because working files are saved in this directory.

You can change the config files for your needs, details are described here. Also you can tune the conf/logback.xml file to adjust what and how to log.

Starting and stopping server and client in two processes connected with ActiveMQ

  • ./bin/activemq start from the directory of your ActiveMQ
  • ./start.sh conf/production_with_jms.conf from the extracted hyperledger-server-main-<version> directory
  • java -cp hyperledger-server-main-<version>/hyperledger-server-main-<version>-shaded.jar:hyperledger-examples-jmsclient-<version>.jar Main

It will print out that There are 5000000000 satoshis on the genesis address.

  • ./stop.sh from the extracted hyperledger-server-main-<version> directory
  • ./bin/activemq stop from the directory of your ActiveMQ

Working files

Database is saved into the data directory if LevelDB is configured for storage. (Memory data store is never persisted.) If you want a clean start then remove the entire data directory.

Logs are stored in the logs directory. The actual log file is rolled and compressed in every hour. Oldest ones are deleted if there are too many of them.

Start and stop scripts use PID.LOCK file. Do not remove it manually because then the stop script will not know which process to stop. If it is removed accidentally then you have to use kill to terminate the process.

Documentation

Contributing

How to contribute? Digital Asset's HLP-Candidate Mailing List