Hyperledger Iroha (Blockchain Framework) Tutorial with Multi Signature & Decentralized Exchange in Multi Peers Set-up (Part 2)

Cross Border Asset/Currency Transfer with Enterprise Blockchain.

In this blog we try to explain Hyperledger Iroha’s two great features which are multi signature and decentralized exchange which will help us to develop a trustworthy decentralized finance system. This blog is the second part of our series named as “Hyperledger Iroha (Blockchain Framework) Tutorial with Multi Signature & Decentralized Exchange in Multi Peers Set-up”. To understand all the concept properly and to deploy the demo code, you have to follow the part 1 of this series. The link of part 1 is given below:

Hyperledger Iroha (Blockchain Framework) Tutorial with Multi Signature & Decentralized Exchange in…

Decentralized Exchange

Decentralized exchange is one of the most promising features of Hyperledger Iroha which will solve many of today’s real world problems. Decentralized exchange provides an ability to transfer assets between accounts in exchange for other assets. An example will be buyer & asset seller will agree into a shared agreement where asset ownership will transfer from seller to buyer accounts where token ownership will transfer from buyer to seller accounts automatically.

In a traditional system there will always be trust issues with this kind of business exchange like the seller may take the money and don’t provide the asset or the buyer may take the asset but not pay the bill. Iroha brings trust into this type of scenario where transactions will be successfully committed from both sides simultaneously.

In practice, this decentralized exchange may play a bigger role in opening a market of true decentralization by giving an asset its true value. We can take an example of cross border currency exchange. The way we choose the exchange rate between two currencies is not a totally decentralized system, moreover some big players always win in this exchange system instead of a currency’s true value. In the Iroha system, it will give the user a true power to fix the exchange rate according to that currency’s true value. We will see a real example of this in the hands-on demo section.

Decentralized Exchange Example

Now less discuss about Iroha’s decentralized exchange and how we can implement the system.

Hands-on Demo

From projects root directory, run the following command to clear the previous setup:

bash network.sh down

From projects root directory, run the following command to start the network:

bash network.sh up

You can also change the start up timing according to your machine by modifying the ‘network.sh’ file.

From projects root directory, run the following command for decentralized-exchanged example:

python3 python_sdk/decentralized-exchanged.py

Explanation

At first we have to initialize our peers/nodes with respective IP addresses and corresponding ports and after that we have to feed those values into ‘IrohaGrpc’.

Here we have one admin and two users where each account holder will recreate/create their cryptographic keys. In the real scenario, each account holder will use their own wallet to sign transactions.

Now it is time for the admin to initialize some transactions so that other users can perform their operations. Here admin performs 8 initialization operations and those are:

1. Admin creates ‘scoin’ asset at ‘test’ domain with precision=2
2. Admin creates ‘ncoin’ asset at ‘test’ domain with precision=2
3. Admin adds ‘10000’ ammount of scoin asset where asset id is ‘scoin#test’
4. Admin adds ‘20000’ ammount of ncoin asset where asset id is ‘ncoin#test’
5. Admin creates new account where account_name= ‘satoshi’, domain_id= ‘test’ with account holder public key
6. Admin creates new account where account_name= ‘nakamoto’, domain_id= ‘test’ with account holder public key
7. Admin transfers ‘10000’ amount of ‘scoin’ from admin’s account to ‘satoshi’ account
8. Admin transfers ‘20000’ amount of ‘ncoin’ from admin’s account to ‘nakamoto’ account

In Iroha, we can send several transactions at once as a batch which is known as Batch of transactions. There are 2 types of batch named as Atomic batch and Ordered batch. An atomic batch will only work if all the transactions within the batch are signed by its authority and all the transactions will pass the verification process. In Iroha system, one party needs to create an atomic exchange branch by fixing the exchange rate and transferable amount where to complete the transactions, the atomic exchange branch needs the consensus from both parties.

In our case, Satoshi creates a decentralized atomic exchange branch by initializing two transactions. In one transaction, ‘100’ amount of ‘scoin’ will be transferred from ‘satoshi’ account to ‘nakamoto’ account where in other transaction ‘200’ amount of ‘ncoin’ will be transferred from ‘nakamoto’ account to ‘satoshi’ account. Here Satoshi indirectly initializes an exchange rate which means 1 ‘scoin’ is equivalent to 2 ‘ncoin’. After the creation of the exchange batch, Satoshi gives his consent by signing his part of the transaction where ‘100’ amount of ‘scoin’ will be transferred from ‘satoshi’ account to ‘nakamoto’ account. Finally Satoshi sends the atomic batch of transactions to Iroha Peer.

Now it is time for Nakomoto to accept the atomic batch of transactions. Nakamoto can find pending transactions from peer or Satoshi may pass that via a messaging channel (Like the example of multi signature). Transactions that do not receive the required number of signatures will be considered as pending transactions where the Iroha system will trigger a transaction automatically when the transaction will collect the required number of signatures.

Iroha Decentralized Exchange

Here Nakamoto is querying pending transactions from peer with his valid credentials. The atomic batch of transactions, which was previously created by Satoshi are now in pending state as those got Satoshi’s signature for transferring of ‘100’ amount of ‘scoin’ from ‘satoshi’ account to ‘nakamoto’ account but do not get Nakamoto’s signature for transferring of ‘200’ amount of ‘ncoin’ from ‘nakamoto’ account to ‘satoshi’ account. This atomic batch of pending transactions that Nakamoto fetched from peer, already got Satoshi’s signature and only needed Nakamoto’s signature and so Nakamoto will delete Satoshi’s signature and will sign only his transaction with his private key. Finally Nakamoto sends the atomic batch of transactions to Iroha Peer. Now this atomic exchange batch of transactions receives all the required consensus and this batch will commit transactional changes into leger by Iroha automatic triggering system if it passes other verification processes.

Multi Signature Transactions

Multi Signature Transactions is one of the best key features of Hyperledger Iroha Blockchain framework. With this feature we can manage our funds, deeds, agreement, assets etc by a decentralized authorization system. Decentralized authorization system lets several people from the same business complete a third-party asset transfer by taking the consensus from required number authorities.

A use case scenario will be a fund assets that is held at one account which is managed by multiple managers who are dealing with investments and portfolio distributions. Every manager will act as a role of a signatory who can sign the transactions to give his/her consensus. Here Iroha uses a term named ‘Quorum’ which means a minimum number of signatures required to consider a transaction signed. Here one manager may confirm a deal by sending the original transaction and others managers’ then sign that transaction where Iroha will maintain the transaction sending so that the deal will not be completed until it receives the required number of confirmation, which is parametrized with the transaction quorum parameter. Transactions that do not receive the required number of signatures will be considered as pending transactions where the Iroha system will trigger a transaction automatically when the transaction will collect the required number of signatures.

Multi Signature Transactions

Hands-on Demo

From projects root directory, run the following command to clear the previous setup:

bash network.sh down

From projects root directory, run the following command to start the network:

bash network.sh up

You can also change the start up timing according to your machine by modifying the ‘network.sh’ file.

From projects root directory, run the following command for multi-signature example:

python3 python_sdk/multi-signature.py

Explanation

At first we have to initialize our peers/nodes with respective IP addresses and corresponding ports and after that we have to feed those values into ‘IrohaGrpc’.

Here we have one admin and three users where each account holder will recreate/create their cryptographic keys. In the real scenario, each account holder will use their own wallet to sign transactions.

Now it is time for the admin to initialize some transactions so that other users can perform their operations. Here admin performs 5 initialization operations and those are:

1. Admin creates ‘scoin’ asset at ‘test’ domain with precision=2

2. Admin adds ‘10000’ amount of scoin asset where asset id is ‘scoin#test’

3. Admin creates new account where account_name= ‘satoshi’, domain_id= ‘test’ with account holder public key

4. Admin creates new account where account_name= ‘nakamoto’, domain_id= ‘test’ with account holder public key

5. Admin transfers ‘10000’ amount of ‘scoin’ from admin’s account to ‘satoshi’ account

For multi signature transactions we have to add keys for signatory and set quorum. Signatory represents an entity that can confirm multi signature transactions (MST) for an account. Quorum number is a minimum amount of signatures required to consider a transaction signed. So our Satoshi_1 adds a new signatory with Satoshi_2’s public key and sets quorum number 2.
As our quorum number is 2, so from now any transaction from account_id=’satoshi@test’ needs at least 2 signatorys’ signatures (Signature with Satoshi_1’s private key & Signature with Satoshi_2’s private key) to consider as a valid transaction in Hyperledger Iroha.

To perform a multi signature transaction, a signatory has to initiate the transaction. Here Satoshi_1 initiates that ‘10’ amount of ‘scoin’ will be transferred from ‘satoshi’ account to ‘nakamoto’ account. After that Satoshi_1 signs the transaction with it’s private key and then Satoshi_1 can send the signed transaction into Iroha peer or can give it to other signatories and in this scenario, Satoshi_1 gives it to another signatory named as Satoshi_2. So Satoshi_2 can find pending transactions from peer if Satoshi_1 sent that on peer (Like the example of decentralized exchanged) or Satoshi_1 may pass that via a messaging channel to Satoshi_2. Finally Satoshi_2 signs the transaction with it’s private key and sends the transaction to Iroha Peer. The transaction will be completed and committed into ledgers on successful verification performed by Iroha system.

Summary

In this blog we try to explain Hyperledger Iroha’s two great features which are multi signature and decentralized exchange. This blog is written only for learning purposes and we hope that this blog will be helpful for you and also expect your valuable reviews so that we all can have a chance to learn from you.