Versions Compared

Old Version 6

changes.mady.by.user Iurii Vinogradov

Saved on

compared with

New Version Current

changes.mady.by.user Nikita Puzankov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page properties
label


Status
Status
colourYellow
titleIn progress
Stakeholders
Makoto Takemiya Egor Ivkov Iurii Vinogradov Vladislav Markushin 
Outcome

Jira
serverHyperledger JIRA
serverId6326cb0b-65b2-38fd-a82c-67a89277103b
keyIR-885

Due date
24 Jul
Owner
Nikita Puzankov 


Background

Previous assumptions about Iroha Network and Web API in general were usage of iroha-client with encapsulation of underlying (plain TCP) protocols.
New needs from dependent projects require discussion of these assumptions and decision how to work with iroha network.

Abstract

Iroha Bridge module provides an ability to connect different blockchains together and needs an ability to communicate between both sides via web interface.

Current Iroha approach is a proprietary TCP based protocol encapsulated inside `iroha_network` crate. `iroha_client` crate uses `iroha_network` inside and should be  used itself by other applications including another other blockchain solutions like `Polkadot`.

It turns out that `Substrate's` off chain workers provides only HTTP (more high level) API for communications with external resources (like Iroha Peer).

In this discussion we should make a decision - will this situation impact our current solution?

Introduction

To make a decision we should formalize the problem, allocate and analyze possible solutions.

Requirements

  • We need Http compatible interface on Iroha side
  • We need and Http compatible client library which can support all Iroha user ISI, Query, streams.
  • HTTP client library should be implemented in Rust for use from substrate.
  • We need JS compatible library to interact with Iroha
  • The deadline is the middle of August.

Problem

Clients with only high level networking support (HTTP/WebSocket) need to do additional development for Iroha Bridge integration and may even have some runtime specific restrictions which will make it impossible.

High level solutions

...

  • Need to define scope
  • Need to not duplicate peer to peer communications logic

...

  • Need to define scope

...

Protocol

Also, we need to define protocol for HTTP messages. We have the next proposal:

  • JSON RPC - seems like a clearly define protocol able to generate code for multiple platforms.

Action items

  •  

Requirements from Iurii Vinogradov

  • HTTP compatible Iroha Peer API
  • HTTP client library for Instructions, Queries, Events
  • Rust client library (for Substrate's Off-chain workers)
  • JS Client library

Problem

Different clients environments have different restrictions - the strictest one is Substrate's Off-chain worker runtime which only supports HTTP 1.

Also DevOps team and Client side developers prefer to use JSON as a client-peer communication format. Some scenarios require to have an ability to combine Instructions API with Events API (send transaction and start consuming updates on it).

Solution

As a solution we propose this high-level design. HTTP and WebSocket protocols will be used for communication between Clients and Iroha Peers.

Iroha should provide HTTP API.

  • Endpoints:
    • Iroha Special Instructions
    • Iroha Queries 
    • Iroha Events (under consideration - needed for Substrate)
  • MIME type of the HTTP API will be `application/json`
  • Clients build their own functionality or use 3rd party clients to establish HTTP connection, sign and construct transactions
  • JSON RPC or RESTfull approach should be discussed

Additionally Iroha should provide WebSocket API.

  • Endpoints:
    • Iroha Events
    • Iroha Special Instructions (under consideration - was requested by client-side developers)
    • Iroha Queries (under consideration - was requested by client-side developers)
  • JSON RPC can be used as high level protocol over WebSocket

Decisions

  • Iroha will provide HTTP and WebSocket API for clients
  • JSON format for messages encoding/decoding will be used

Alternatives

  • Stay with TCP and use middle ware for protocol and messages transformations - not user friendly
  • Use HTTP 2.0 - will not work with Substrate

Concerns

  • WebSocket connections should have configuration options to prevent bad performance of Iroha peers under high load

Assumptions

  • Bridge clients will use Substrate's Off-chain Workers with an ability to communicate over HTTP only

Risks

  • Performance regress `[8; 5]`

Action items