2022 Q3 Hyperledger Iroha
Created by Victor Gridnevsky, last modified on Oct 13, 2022
Project Health
Iroha 1 is no longer actively maintained, and no major releases are planned at this time. However, Iroha 1 still receives regular contributions from outside the core development team, Grzegorz Bazior contributing himself, and organizing contributions from his students. The Iroha 2 team is doing bug triage for both projects and implements security fixes for Iroha 1.
Iroha 2 is ramping up production. All developers are now fully onboarded and at maximum productivity. We have implemented a crude delineation of responsibilities, and implemented all processes for long-term development. We are following a timed release cadence, with a Long-term supported release planned at critical stability milestones. Iroha 2 repository is well organised, with branch protection rules enforced for all main branches ( iroha2-stable , iroha2-dev , iroha2-lts , iroha2-staging ) as well as a common CI/CD pipeline with thorough testing/linting and API verification systems.
Work is underway to bring the supporting libraries up to feature parity with the Rust library. Particular efforts are made to improve the Iroha Python library to be available for testing and automation. Additionally, a Hyperledger Cactus plugin is developed based on the Iroha typescript library. Additional tooling is made for improving the UX, and the Blockchain explorer is nearing the minimum viable product state. Finally, Iroha Kotlin is going to be used as a basis for a public test network, where we will analyse real-world usage statistics and use the data-driven optimisation approaches to further improve Iroha 2.
Questions/Issues for the TSC
We have a few issues in relation to Hyperledger Ursa. For example, due to its release cadence and relative lull in development activity, we had had to hold back a few dependencies in order to remain binary compatible with the Errors returned from Ursa methods. Our automated auditing tools have identified several deprecations as well as unmaintained libraries which cannot be simply “version bumped” into Ursa.
Ry Jones suggested that we take over some of the maintenance burden, particularly ensuring that the code quality of Ursa is up to the same high standards that we ensure for Iroha 2 (linting, reviews, release timing, auditing, fresh dependencies, dependency pruning, automated feature flag coherence testing, property-based testing, fuzzing, functional testing, coverage, modularity).
We would also like to involve more people in the development of Iroha v2, particularly interns and community members. We would like to plan and discuss a few key issues with David Boswell and design a new internship programme that would involve Iroha 2.
Releases
Last release reported here ”at May 26, 2022.
Timed releases:
v2.0.0-pre-rc.4(internal)v2.0.0-pre-rc.5(internal)v2.0.0-pre-rc.6 (LTS)v2.0.0-pre-rc.7(internal, TBR)
Overall Activity in the Past Quarter
Iroha v1
Merged Grzegorz Bazior ’s PRs:
- #2494 : Update documentation: AddPeer with
syncing_nodeoption - #2475 : Many documentation changes, corrections, etc.
Iroha v2
Performance enhancements
We have made several changes to both how we measure performance and how we improve it.
We now use profiling as a mandatory step: if something causes a performance regression of more than 10% in throughput and/or latency, we don’t allow it to be merged.
Based off of that we triggered a series of simplifications and optimisations which led to increased performance in the iroha2-staging branch. It is our best bet to increase throughput.
WASM dynamic linkage
Dynamic linkage of WASM binaries allows us to
- Save space on-chain, since smartcontracts are stored in binary
- Disallow direct allocations and direct memory manipulations enhancing security
- Allow manipulation of opaque objects only, enforcing invariants, netting even more security
- Increase the number of available methods and functions
New functionality
- Additional tooling (genesis block builder GUI)
- Sorting / filtering / pagination of queries, as well as several additional query types (block headers)
Improvements
- Better permission validation system
- Trigger improvements (scope, performance, strong typing)
- Better deployment scheme (fully static linkage, much smaller Docker container)
- Kura API improvements
- Iroha-Python currently works correctly with Iroha 2
- Run-time modular permission validation
- Simplified Expression subsystem
- Stability, performance improvements, bug fixes, actor system improvements
- Technical debt reduction
- Testing coverage improvements
- Introduction of other testing methods (property-based testing, fuzzing, failure point testing)
- Better UX (more readable error messages, tutorial, on-peer documentation)
Current Plans
- Resolve Ursa issues by possibly hiring a new developer, who will address the security issues in it.
- Improve the contributing process for community members by tracking PRs with a bot.
- Involve more community members by producing more content related to Iroha v2 (blog posts, video demo, tutorial content).
- Record a detailed demonstration video on Hyperledger Iroha use with CLI.
- Integrate examples into the documentation, so the users have fresh examples easily available and tested. Integrate language-specific guides into articles with a custom code component.
Maintainer Diversity
As of writing the Iroha 2 core development team consists of:
- 8 Rust developers + 1 tech lead
- 1 front-end developer
- 2 full-time QA engineers (functional and load testing/benchmarking)
- 1 full-time technical writer
- 1 full-time DevOps
- 1 community manager, who also handles front-end, back-end, DevOps and writing tasks as needed
Currently, the maintainer team consists of the Soramitsu employees. Gregorz Bazior (Yonix Digital Systems, AGH University of Science and Technology ) is interested in Iroha 2 and maintains Iroha 1.
Contributor Diversity
A new intern working on reimplementing iroha-swarm as a plugin to Kagami (Iroha 2’s example generation program).
We have had several contributions ( #2264 , #2285 , #2326 ) from Omkar Mohanty (intern) , Tejas (intern), who has shown interest, but has not contributed code directl y and Ritik Bhandari who contributed the code that was part of PR#2125 (add query for FindAssetDefinitionById ).
On the Python side of Iroha, we’ve had valuable input about ergonomics of the Iroha 2 Python library from Gregorz Bazior (Yonix Digital Systems, AGH University of Science and Technology) .
Reviewed By
- 🔲 Angelo De Caro
- ✅ Arnaud J Le Hors
- ✅ Artem Barger
- 🔲 Arun S M
- ✅ Bobbi Muscara
- ✅ Danno Ferrin
- ✅ David Enyeart
- 🔲 Grace Hartley
- ✅ Jim Zhang
- ✅ Kamlesh Nagware
- ✅ Nathan George
- ✅ Peter Somogyvari
- ✅ Tracy Kuhrt
- ✅ Troy Ronda
Submission date
18-Aug-2022, added the review section at 1-Sep-2022
Comments:
| Victor Gridnevsky : If this is ready for review by the TSC, please add the TSC as reviewers to the bottom of the web page similar to what you see in the template. Posted by tkuhrt at Aug 23, 2022 18:00 |
| Tracy Kuhrt excuse me, I've added the review section. Posted by vgridnevsky at Sep 01, 2022 10:56 |
| I am not sure how a release candidate (rc) is marked as a long-term support (LTS) version. Can you explain how that works? From wikipedia :
Posted by tkuhrt at Sep 01, 2022 15:27 |
| The versions that were previously marked as release candidate and currently marked as LTS will be supported for a longer period of time. I am ready to discuss further versioning details and we can address those thoroughly on a TSC meeting. Posted by vgridnevsky at Sep 06, 2022 11:03 |
| For maintainer diversity the report is not asking about the maintainer's skillsets, it is asking about their corporate affiliations. Can you add in some verbiage about the affiliations? Posted by shemnon at Sep 07, 2022 16:21 |
| I will address this question soon. Posted by vgridnevsky at Sep 09, 2022 06:16 |
| Rereading this report, it occurs to me that the " Questions/Issues for the TSC" don't really seem to be questions. Indeed every one of them appears to already include a solution or at least a direction to follow. Am I missing something here?
Posted by lehors at Sep 22, 2022 12:25 |
| Certainly, with Ursa we have a result we want in mind, but there are open questions about the whole process. Ursa is a cryptographic library, so it needs to be very reliable for the security reasons. Moreover, Iroha relies on it heavily. Involving more people in Ursa development would've helped then. With all the discussions we had, we understand the answer to why Ursa is in its current state, but we are not sure on how to effeciently improve both projects in parallel. Sadly, yesterday's Ursa meeting only included me and Aleksandr. Involving more people with cryptographic knowledge would've been great. Posted by vgridnevsky at Oct 13, 2022 09:34 |
| Victor Gridnevsky – I'm sorry to hear that yesterday's Ursa meeting only included you and Aleksandr. As we discussed on our call, I think we can do much more to drive participation in Ursa's community calls and with Ursa in general if we start talking more about the project to the community. We have seen increases in meeting attendance and activity around other projects and labs when those groups share what they're doing with the community. Very little has been done in the past though to talk about what Ursa is, why it is important and how people can get involved, so people don't know much about the project. There are a number of things we can do to help with this, including working with you and others involved in the project on meetups, workshops, blog posts and more. This presentation has a range of suggestions about how to raise your profile and invite more people to get involved and we're happy to help with any of these ideas. https://docs.google.com/presentation/d/13nji_R-op77ERT-AV3-CbOOZwAOjtvq33RRGnjpL3Gc/edit?usp=sharing Posted by davidwboswell at Oct 13, 2022 15:36 |