Background
It'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.
Abstract
During requirements gathering about `Bridge` and `DEX` Iroha Modules and comments on Maintenance Endpoint RFC following needs were found:
- An ability for Clients to watch for Transactions and Block changes in almost real-time manner.
- A security mechanism to filter changes and do not share information that client has no permissions to obtain.
These needs were addressed as additional requirements for Maintenance Endpoint and following issues were created:
As a standardized format for such an events CloudEvents specification was proposed as CloudNative Computing Foundation incubating project with 1.0 version released.
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:
- Connect Consumer (Iroha Client) to the Source (Iroha Peer) providing signed filter criteria
- Criteria gives Iroha Peer information about types of Events needed
- Signature gives Iroha Peer information about the client to check permissions
That way we will address all requirements:
- 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
Some implementation details - 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".