| Page properties | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||
|
Background
Different Iroha users requested possibility to receive information about things outside of a Iroha Queries scope, like list of rejected transactions or changes in their statuses.
Because storage of this information on the Blockchain may have a big cost another approaches were consideredIt's important to note that this decision and solution based on it will be marked as "unstable" for 2.0.0 version and may be changed in future releases prior to 3.0 breaking back-compatibility.
Action items
- Nikita Puzankov should collect comments, make final decision and move it to Architecture Decision Records Log.
...
- Vadim Reutskiy should ask mobile and frontend developers to comment this RFC
Problem
During requirements gathering about `Bridge` and `DEX` Iroha Modules and comments on Maintenance Endpoint RFC following needs were found:
...
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Solution
As a standardized format for such an events CloudEvents specification was proposed as CloudNative Computing Foundation incubating project with 1.0 version released.
| View file | ||||
|---|---|---|---|---|
|
Introduction
Blockchain as is provides information about transactions and blocks stored on it, while needs of `Bridge` and `DEX` modules to know information about "non-persistent" events are not covered out-of-the-box.
Because of that we had to decide what module and how should provide this information.
Methods and Materials
We made design prototypes and whiteboarding about possible solutions, formats and interaction protocols.
Non-functional requirements to have a two-way interactive communication session between client and peer with streams of changes from peer's side and acceptance confirmations from client's side.
As was also discussed any networking related problems, clients problems will make impossible to deliver these changes and it's client's responsibility to make additional actions to receive information missed.
We also remember that some information is "non-persistent" so it will be impossible to fully recover after such incidents.
Results
The following design looks the more promising from our's point of view.
Maintenance endpoint will provide API marked as "unstable" feature (for release 2.0.0) with an ability to:
...
- An ability to receive changes in submitted by client Transactions statuses
- An ability to receive changes in Blocks formed by Peers with information inside filtered based on Clients permissions
...
| View file | ||||
|---|---|---|---|---|
|
Decisions
- Iroha Network library will provide protocol for a two-way interactive communications session. Iroha Client library will provide Rust API for more high level functions, like "subscribe_to_block_changes" and "subscribe_to_transaction_changes"
- Iroha Events will align to CloudEvents schema version 1.0
- TCP and WebSocket API will be provided by Iroha Peer
- Functionality should be optional
Alternatives
Concerns
- Some clients may fail to work with low-level TCP API or with rust client library
Assumptions
- We have a two-way interactive communication session between client and peer with streams of changes from peer's side and acceptance confirmations from client's side
- Cloud Events will be marked as "unstable" for 2.0.0 version and may have breaking changes in future minor releases
- In case of network problems or client side errors changes will not be delivered
- Information about these events is not stored by Iroha Peers
Risks
- Cloud Events will increase resources consumption and decrease performance `[4;7]`
- Breaking changes in Events format will require additional updates in client libraries `[9;5]`