Overview
The main goal of the project is to create a documented Iroha (1.x) package for the Cactus project, which demonstrates the interoperability between Iroha and Cactus. The project also includes 3 documented examples of integration between Iroha and Cactus, and 2 documented examples of integration between Iroha and Fabric. The documentation will benefit the community so that people can understand this project.
...
| Mentor | Mentor | Mentee |
|---|---|---|
Peter Somogyvari PDT (UTC-7) | Grzegorz Baz CEST (UTC+2) | Han Xu EST (UTC-5) |
...
| Category | Index | Current implementation and issue | Expected improvements | Difficulty level |
|---|---|---|---|---|
| Iroha connector plugin | 1 | Currently the parameters are hardcoded, meaning that we can only support new parameters if we recompile the code of the connector and then publish a brand new release of it. This | Parameters should be more generic in the future so that parameter changes can be done dynamically. | 3/5 |
| 2 | Call Engine is not implemented. (made the transaction rejected within the ledger, and thus rejected in the test case. ) | Implement Call Engine command and test it. | ||
| 3 | setSettingValue is not implemented. (returned http 405 Error in plugin-ledger-connector-iroha.ts) | Implement SetSettingValue command and test it. | ||
| 4 | removePeer is not fully tested. A valid Iroha testnet needs to be constructed to test this command. | Able to manipulate Iroha testnet (>= 3 Iroha nodes are recommended). Then, construct Iroha test within the test case to test removePeer. | 4/5 | |
| 5 | fetchCommits is not implemented. Inside the plugin-ledger-connector-iroha.ts, but unable to test it due to its unique characteristic of streaming responses. | fetchCommits could be implemented as something similar to Besu connector's WatchBlockV1. | 3/5 | |
| 6 | getPendingTransaction is not fully tested. There is an issue with producing a pending transaction, the code will get stuck and fail the test suite. It seems like Iroha ledger itself is struggling to generate the pending transaction. (https://jira.hyperledger.org/browse/IR-1010) | Able to produce a pending transaction in the test case. Able to validate the pending transaction via getPendingTrasaction query. | 4/5 | |
| Iroha-Javascript library | 1 | Utilized iroha-helpers-ts because the original Iroha Javascript library gives “undefined” as output. It could be upgraded to match the most recent Javascript library. Its output could be further optimized to suit test cases better. | Construct our own iroha-helper-ts library (outputs tx status and tx hash) based on the Iroha Javascript library. | 3/5 |
| Iroha docker container | 1 | The test cases rely on a modified Iroha v1.2.0 all-in-one (AIO) docker image. However, version 1.2.0 is outdated. | Upgrade the Iroha version the latest version to improve functionality and performance. | 2/5 |
| 2 | Embedded Iroha Python SDK inside the Iroha AIO docker image. Although the current healthcheck mechanism works fine, it makes the docker image ~100MB larger. | Once the Iroha team introduces the grpc healthcheck/ make metrics page an option in a release version (e.g., v1.2.2), implement healthcheck mechanism through grpc healthcheck or curl the metric page. `curl http://127.0.0.1:8080/metrics` | 2/5 | |
| 3 | Each Iroha docker container relies on a corresponding Postgres database container to store information. | Replace the Postgres database docker container with RocksDB, which needs just one folder (a docker volume) to keep data between different runs of image.) | 3/5 | |
| Documentation | 1 | For docs/source/support/iroha.md, the test link is not guaranteed to be valid. | Once the current Iroha connector plugin PR gets merged/released, update the test link to be a valid link. | 1/5 |
...