You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Status
IN PROGRESS
Stakeholders
Makoto Takemiya Egor Ivkov Iurii Vinogradov Vladislav Markushin 
Outcome
Due date
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 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.
  • 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

  • Iroha provides HTTP API out-of-the-box
    • Need to define scope
    • Need to not duplicate peer to peer communications logic
  • Dedicated HTTP server module on Iorha2 not included in the core but have an ability to proxy all ISI and queries if needed.
  • Iroha Bridge module provides HTTP wrapper on top of Iroha API (on the Peer side)
    • Need to define scope
  • Iroha Bridge has an additional application as a proxy on top of Iroha API (as a standalone app or service mesh)
  • Every client is responsible for Adapters

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

  •  
  • No labels