Hyperledger Iroha v1.0 beta-1 version

Hotfix

• Fix build errors related to unused lambda captures with clang 7.0
• Fix independent build of shared model subproject

Hyperledger Iroha v1.0 beta version

After beta release, we are moving to the schema of time-based releases, and it is expected to release approximately every month.

In this release following changes were made:

Client libraries & shared model

Our long road, taking its start from a decision made back in October 2017 about using in Iroha daemon a set of shared model classes with invariants, validators, protobuf as a backbone, clear and intuitive validation output, used both on client side and on server side is coming to its end with a release of libraries for several platforms:

• Obviously, C++
• Java & Android in particular
• Python

Shared model name means that exactly the same Transaction, Query, etc. objects are used on client and peer side for the purpose of improved reliability and user-friendliness. We are approaching the end of complete migration to these classes (it appears that we will ship it in next release).

A shared model name is going to change to irohalib for a better consistency with UNIX naming style (as Iroha binary is named as irohad).

All libraries except C++ are generated using SWIG — which means that their maintenance is guaranteed by an effective CI pipeline that we are going to build in the future. So far, libraries are available in several external repositories (Maven, PIP, etc.) and their update is going to be automated in following releases as well.

Swift & Objective-C library is available is a preview state, since there are issues with tests, documentation, and Objective-C code.

NodeJS library is also available in a preview state, though it has tests and documentation for it.

Please, use our documentation related to client libraries on ReadTheDocs service, which is explained below:

Documentation

Previously, documentation for the project was discrete and was placed in several places, moreover, it was targeted only at developers.

We are changing the focus by telling more people in different languages about key features of Iroha, and the level of technical expertise required to read the docs is varied from integrators or explorers to blockchain developers.

Check out our new docs at iroha.readthedocs.io (being still translated and changed).
Please, contribute to the translation of docs here on POEditor.

Project distribution

One of SnapCraft maintainers, @ElOpio, has recently contributed with a setup of snap package or Iroha. Please stay tuned as we will publish information on how to use snap right after release.

As usual, anyone can download docker image and deploy Iroha in a container — check Getting Started section.

In the future, all builds are going to be stored at https://artifact.soramitsu.co.jp/ page.

Stateless validation

We have changed rules for our transaction, query, etc. schemas to be valid by unifying stateless validation rules. Please check Core Concepts page of ReadTheDocs, where it is explained what is exactly stateless validation, and how certain fields are validated.

Integration Test Framework

Acceptance tests are written using Integration Test framework, allowing to set up a context for a transaction pipeline in an easy way. This framework is capable of performing checks all along the pipeline and is reducing code duplication greatly. Readme file explaining ITF is going to be written soon, but for now, please explore the code — it is well documented and there are already tests written, and some of the tests are already reported (acceptance testing is now in progress).

Ansible deployment

Now, Ansible playbook improvements allow you to deploy Iroha easily on many physical machines or in many docker containers on a fixed amount of machines to simulate different network configurations. More information is available in README.md file of deploy/ansible folder.

Torii

Optimizations are now all along the code of our frontend gRPC component (named Torii). Moreover, clients now are not forced to pull the status of a transaction, but instead, they can use pull-based notification mechanism (gRPC Streaming). Check client libraries section for more examples and information.

Optimisations

Reduced amount of project dependencies

• Redis component was removed completely, and PostgreSQL indices are used instead
• Using platform-independent file operations for better portability (still no Windows, sorry)
• Removed legacy code (old tests, crypto files, old schema files)

Performance

• Added a queue at Ordering Gate — which means that proposals are now waiting in line to be sent to Ordering Service
• Improved performance of Ordering Service component 500 times after removing Proposal copying
• Initial performance testing for 4, 16, 28, 64 nodes

Other

• Improved line coverage (command executor, Yet Another Consensus)
• Removed nonstd::optional (we are using boost::optional now)
• Clang formatting as a CMake function
• Improved logging
• Tests (more negative test cases, a whole new system test)
• Fixed memory leaks in Torii component
• Secured private keys with a passphrase for a safe storage on HDD

Bugfixes

• Allow querying all account data
• Ninja build
• CLI improvements (still, it is better to write a new one, but we are supporting what we have at the moment)
• YAC peer order was fixed
• Startup of Ordering Service
• Fixed back pressure on fast proposal emitting

1.0 alpha

The release brings following features:

Client libraries

If you want to communicate with Iroha now via the programming language of your choice — you can generate the library using SWIG, or you can use ready-to-go examples and extend them:

Java

Using SWIG, the team of maintainers made it possible to generate a transaction, a query, and check the status of the transaction on running peer. In order to check it (and extend the code for your needs) please go to example/java folder.

Python

A similar example was made for python as well. In order to check it (and extend the code for your needs) please go to example/python folder.

Other (supported with SWIG)

Check CMakeFile and SWIG documentation. In future, we can extend this on-demand or would be happy to see such contribution from the community.

ed25519 library with SHA3 hashing

The ed25519 digital signature algorithm is described in RFC8032. The implementation provides a modularized implementation of this algorithm.

Originally Ed25519 consists of three modules:

• the digital signature algorithm itself
• SHA512 hash function
• random number generator, to generate keypairs

This repository offers at least two different C implementations for every module. Every implementation is tested and can be replaced with other at link-time. New implementations can be added as well. Test cases match RFC8032.

Other improvements and features

• a know-your-customer solution for account information. Check API page for more detail
• documentation updates, new contribution guidelines
• bug fixes and improvements

v0.95 preview-2

This release brings following features:

Hot join of peer to the network

Now, to join the peer to the network, a member of peer network should execute AddPeer command, passing the resolvable address of the peer in the network, and its public key. This peer should already have the same genesis block in the chain.

Iroha is compatible with macOS

We want to provide an ability for developers to test and build their code in an environment, which is convenient for them. That is why each pull request to develop is checked for the compatibility with darwin.

Transaction responses

To understand the status of the transaction in Iroha, a client should retrieve it from the node, which was used to send it. Check Status endpoint and use the hash of the transaction. There are 7 states in total, related to stateless, stateful validation, consensus and external transport.

Ordering gate

Now, the responsibility of the ordering gate is to decide on how to relay the transaction to ordering service. It used to be tightly coupled, but now the ordering service is another pluggable component in the system.

Static analysis tool

Technical debt of the project codebase is checked with sonarqube, available at sonar.soramitsu.co.jp.

Improved initialization pipeline

Peer variable is removed from main class since peer can be missing from the ledger when a node is started. API of main class is improved with virtual functions for every component, allowing testing the peer with ease.

Cryptographic checks

Now, Iroha does validation of payload signatures and signatures of the block made by peer. Temporarily we are using the ed25519 library with SHA2-512 hashing, but we are working on the SHA3 implementation for improved reliability.

Improved representation of asset amount

It is now greater, as the size of it is uint256. Is also supports custom operations — check iroha/libs/amount.

RBAC permission model, supporting grant command

Iroha is using now role-based access control model, which helps to create custom roles in the system, limited to the operations, which are available to them. Some of the permissions can be granted to other users, check API description for more details.

Integration test for transaction pipeline

This test is used to check the whole pipeline of a transaction, starting with an external endpoint (Iroha API). This test is going to be reused soon for extensive API testing when we will finish with the shared library for creation of transactions and queries.

Implementation of block index storage, based on Redis

Redis storage is used for indexing data, related to retrieval of a collection of transactions. Check the irohad/ametsuchi/impl/mutable_storage_impl.cpp.

Improved implementation of Yet Another Consensus

Consensus module does not require peer IP address now which was used for identification in network messages. Peer public key is now used for identification when vote message is received.

Provisioning of the system via Ansible Playbook

Now, the system can be easily provisioned with Ansible. This feature will help to write scripts for effective system and performance tests.

Other improvements

Fixed build for ARMv7, macOS platform

Several improvements in iroha-cli (C++ command-line interface)

Documentation for release

Available at http://hyperledger.github.io/iroha-api

v0.95 preview

Overview

Version 0.95 preview brings following highlights:

• YAC Consensus
• Observable-based interaction
• Transport agnostic architecture design
• Permission system for transactions and queries
• Separate validation stages: stateless, stateful, chain

New commands

• add asset
• add peer
• add signatory
• assign master key
• create asset
• create account
• create domain
• remove signatory
• set account permissions
• set account quorum
• transfer asset

New queries

• get account
• get signatories
• get account transactions
• get account asset transactions
• get account assets

Known issues

• No valid cryptography
• No recovery after critical errors
• Consensus guarantee only CFT
• No block loader

How to run

Preconditions

Docker and Docker Compose are installed

Running the system

https://github.com/hyperledger/iroha/wiki/How-to-start-Iroha https://github.com/hyperledger/iroha/wiki/How-to-use-Iroha-client

v0.75

Feature

• Data format is protocol buffer
• Local datastorage is level DB
• No support smart contract

Application

• Simple Currency
• Currency with tax
• Multi asset transfer