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

Compare with Current View Page History

« Previous Version 13 Next »

Status
IN PROGRESS
Stakeholders
Makoto Takemiya Egor Ivkov Iurii Vinogradov Vladislav Markushin 
Outcome
Due date
Owner
Nikita Puzankov 

Problem

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.

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 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?

Solution

Requirements from Iurii Vinogradov

  • 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 Iroha2
  • The deadline is the middle of August.

Which can be rephrased as:

  • Iroha should provide HTTP API for:
    • Iroha Special Instructions Submission
    • Iroha Queries Execution 
    • Iroha Cloud Events Consumption
  • Iroha's Rust HTTP client library for Substrate's Off-chain Workers should be developed
  • Iroha's JS client library should be developed

Decisions

  • Iroha HTTP module `iroha::modules::http` will provide additional HTTP Endpoints on top of existing Torii Endpoints, developed as a part of bridge and DEX features from the business point of view.
  • JS library will use HTTP Endpoints and will not depend on Iroha codebase
  • Rust HTTP Client will be implemented as a separate `no-std` crate
  • Cloud Events will be implemented via HTTP instead of WebSocket because of Substrate's restrictions

Alternatives

  • 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 Iroha 2 not included in the core but have an ability to proxy all ISI and queries if needed.
  • 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 HTTP Adapters

Concerns

  • Any change in `iroha_network` algorithms and Iroha entities format will break clients
  • HTTP implementation of Cloud Events may be very slow and impact the throughput of the whole ledger

Assumptions

  • Bridge clients will use Substrate's Off-chain Workers with an ability to communicate over HTTP only
  • JS client has additional restrictions
  • All clients will use scale encoding

Risks

  • Backward compatibility breakage `[7; 9]`
  • Performance regress `[8; 5]`
  • Scale encoding will be hard to implement for non-rust clients `[3;5]`

Action items

  • No labels