...
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 1 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.
...
Communication channel: Telegram/ RocketChat/ Public Channels/ Emails/ Microsoft Teams
Project reporepository:
https://github.com/hyperledger/cactus (main)
https://github.com/hyperledger/iroha
Project pull requests:
https://github.com/hyperledger/cactus/pull/1183
https://github.com/hyperledger/cactus/pull/1169
Practical presentation of completed project (not the same presentation as on project site) - how to use result of the internship:
View file | ||||
---|---|---|---|---|
|
Project Plan
Schedule | Task | Deliverable |
---|---|---|
Week 1 - Week 3 Jun 1 - Jun 18 Jun 18: 1st Quarter Evaluation |
|
|
Week 3 - Week 6 Jun 19 - July 9 July 9: Midterm Quarter Evaluation |
|
|
Week 6 - Week 10 July 10 - July 30 July 30: 3rd Quarter Evaluation |
|
|
Week 10 July 31 - Aug 10 Aug 20-31: Final Evaluation |
|
|
...
Week | Task | Weekly Slide |
---|---|---|
1 (Jun 1 - Jun 6) |
| |
2 (Jun 7 - Jun 13) |
| |
3 (Jun 14 - Jun 20) |
| |
4 (Jun 21- Jun 27) |
| |
5 (Jun 28- July 4) |
| |
6 (July 5 - July 11) |
| |
7 (July 12 - July 18) |
| |
8 (July 19 - July 25) |
| W8 Slide.pdf |
9 (July 26 - Aug 1) |
| |
10 (Aug 2 - Aug 8) |
| |
11 (Aug 9 - Aug 15) |
| |
12 (Aug 16 - Aug 20) |
|
Process
- Communication and updates:
- Telegram/ RocketChat/ Public Channels/ Emails/ Microsoft Teams are used as tools.
- Weekly check-in meetings between mentors and the mentee.
...
Category | Index | Current implementation and issue | Expected improvements | Difficulty level level * | Priority * | Github Issue Link | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Iroha connector plugin | 1 | gRPC TLS option is not implemented. Currently, only able to pass in TLS parameters( TLS Cert/ TLS Key/ TLS Port) to iroha test ledger, but those parameters are immediately discarded. | Implement gRPC TLS support for Iroha test ledger. (Refer to Cactus PR #1190 as an example. ) | 3/5 | 1 | Link | ||||||
2 1 (important) | Currently the parameters are hardcoded ( i.e., we can only support new parameters if we recompile the code of the connector and then publish a brand new release of it.) | Parameters should be more generic in the future so that parameter changes can be done dynamically. | 3/5 | 2 | Link | |||||||
3 | fetchCommits is not implemented. It is 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 | 4 | Link | |||||||
4 | 4a. | 2 (will be important once full support for smart contract) | There is no implementation for smart contract (InvokeContractV1Request). 4b. InvokeContractV1 is not implemented due to the lack of smart contract. 4c. On top of this, Call Engine is not implemented. (because it tries to call Call Engine calls smart contract) ( CurrentlyFor Call Engine, we intentionally reject the transaction within the ledger, and thus able to test then validate the rejection in the test case. ) | 4a. Implement Call Engine command and test it. | 4 | smart contract once Iroha fully supports smart contract. 4b. Implement InvokeContractV1 for Iroha connector once Iroha fully support smart contract. 4c. Given smart contract is supported by Iroha, implement Call Engine and test it. | 3/5 | 5 ( will be important once Iroha fully supports smart contract) | ||||
53 | setSettingValue is not implemented . (Currently only can because this command can only be called inside genesis.block )file. ( Currently, always return Current connector implementation returns HTTP 405 Error in plugin-ledger-connector-iroha.ts) | Implement SetSettingValue command and When Iroha is able to run SetSettingValue outside of genesis.block, implement and test it. When Iroha supports SetSettingValue...., implement | 5 | (It is being said that the Iroha team plans to support running SetSettingValue outside of genesis.block.) | 2/5 | 7 | Link | |||||
64 | removePeer is not fully tested. A valid Iroha testnet needs to be constructed to test this command removePeer. | Able to manipulate Iroha testnet ( An Iroha testnet usually composes of >= 3 Iroha nodes). Then, construct Iroha test within the test case to test removePeer. | 4/55 | 6 | 5 (important) | fetchCommits is not implemented. Put it 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 | 3 | Link | ||
7 | 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) In other words, it seems to be an issue with Iroha ledger itself instead of the Iroha Javascript library. | Able to produce a pending transaction in the test case. Able to validate the pending transaction via getPendingTrasaction query. | 4/5 | 6 | 5 | Link | |||||
8 | Prometheus exporter metrics integration | 7 (important) | The grpc tls option is not implemented. Currently, only able to pass in tls parameters(tls cert/ tls key/ tls port) to iroha test ledger, but tls is not supported. | Implement grpc tls support for Iroha test ledger. | 3/5 | 1 | 8 | Prometheus metrics | Add prometheus exporter to the Iroha connector plugin. | 2/5 | 6 | Link5 |
Iroha-Javascript library | 1 | 1a. Utilized iroha-helpers-ts because since the original Iroha Javascript library gives “undefined” as output. However, iroha-helper-ts is based on a an old Iroha Javascript library (12/23/2020 release), which does not support some new features. 1b. Due to this, currently, one argument for compareAndSetAccountDetail, check_empty, is not dealt with inside the plugin-ledger-connector-iroha.ts file. The run-transaction test case also fail to use this argument. | 1a. Build Construct our own iroha-helper-ts library (outputs tx status and tx hash) based on the Iroha Javascript library, so that it could be upgraded to match the most recent Javascript library . Its version. Moreover, our own iroha-helper-ts's output could be further optimized to suit test cases better. 1b. After developing our own iroha-helper-ts library, correct compareAndSetAccountDetail's arguments. Also, correct the test case accordingly. | 3/5 | 3 | 2 | ||||||
Iroha docker container | 1 | The test cases rely on a modified Iroha v1.2.0 all-in-one (AIO) docker image. However, Iroha version 1.2.0 is outdated. | Upgrade the Iroha version to the latest version to improve its functionality and performance. | 2/5 | 6 | Link | ||||||
2 | Embedded An Iroha Python SDK is embedded inside the Iroha AIO docker image for docker healthcheck. Although the current this healthcheck mechanism works fine, it makes the docker image ~100MB larger. | Once the Iroha team introduces the grpc gRPC healthcheck/ make Iroha metrics page an option in a stable release version (e.g., v1.2.2), implement healthcheck mechanism through grpc gRPC healthcheck or curl the metric page. `curl http://127.0.0.1:8080/metrics` | 2/5 | 6 | Link | |||||||
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 | 6 | Link | |||||||
Documentation | 1 | For docs/source/support/iroha.md, the link to the transaction 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 | 6 | Link |
*For the difficulty level, 1 means the easiest, 5 means the most challenging.
*For the priority listing, 1 means the most important, 7 means the least important. Important ones have been marked as red.