Page tree
Skip to end of metadata
Go to start of metadata

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-stableiroha2-deviroha2-ltsiroha2-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_node option
  • #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 directly 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

Submission date

18-Aug-2022, added the review section at 1-Sep-2022

  • No labels

9 Comments

  1. 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.

    1. Tracy Kuhrtexcuse me, I've added the review section.

  2. 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:

    Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. The term is typically reserved for open-source software, where it describes a software edition that is supported for months or years longer than the software's standard edition.

    1. 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.

  3. 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?

    1. I will address this question soon.

  4. 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?


    1. 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.

      1. 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