Hyperledger Iroha Developer Update – Week of May 23-30, 2025
Hello Iroha community! It’s time for this week’s developer update – and it’s been a busy one. We’ve got fresh features, squashed bugs, and insightful community contributions to share. Let’s dive in!
New Features & Enhancements
Dynamic WASM Fuel: A new feature was merged to make WASM smart contract “fuel” dynamic – essentially allowing configurable execution limits for WASM scripts. This gives developers more flexibility in tuning how long smart contracts can run, improving both security and performance of Iroha’s trigger system (no more one-size-fits-all gas limit!).
Multi-Architecture Docker Images: Iroha can now be built as a multi-architecture Docker image. The team merged PR #5435 (“build: multi-arch docker image”) enabling container builds for multiple CPU architectures (e.g. x86_64 and ARM). This enhancement makes it easier to deploy Iroha on diverse platforms without custom builds.
Environment-Only Configuration: A recent addition allows running iroha configured entirely via environment variables (no config file needed). This was introduced in PR #5394 and includes new tests to ensure smooth operation. It simplifies deployment automation – just set your env vars and go!
Test Network Modularity: The test framework got a refactor to enhance modularity of the test network setup. This internal improvement (PR #5424) makes it easier for developers to plug in custom network topologies and components in tests, paving the way for more extensible testing scenarios.
Performance Optimizations: Thanks to a community contribution by 0x009922, public keys are now stored in a more compact format. This optimization reduces memory overhead and potentially speeds up cryptographic operations. Every byte counts, and this change helps Iroha run leaner.
Metrics and Monitoring: (Earlier in the cycle) the team added commit time metrics for blocks (PR #5380). This provides insight into how long it takes for transactions to commit, aiding performance tuning and monitoring. (This was merged just before this week, but worth a shout-out for those tracking Iroha’s observability improvements.)
Bug Fixes & Improvements
Trigger Execution Fix: A critical fix was merged to the trigger system’s execution logic (PR #5430). Triggers (Iroha’s version of smart contracts) will now execute per-transaction with a depth limit. This change (a breaking update marked with
!) resolves issues where triggers could fire too often or even recursively. It closes longstanding bugs like “Trigger that fires too often” and ensures more predictable trigger behavior going forward.CI Pipeline Stability: The team gave some love to the CI/CD pipeline:
- A typo in a Docker tag was fixed in the CI scripts, which should resolve minor deployment pipeline hiccups.
- The nightly build workflow was tweaked to include the WASM module’s
Cargo.lockand allow trivial numeric casts. This fixed a nagging lint error that was breaking pre-merge checks. The issue “pr.yml: pre_build fails with outdated lint checks” was promptly closed after this fix. - An attempt to cache Rust artifacts for the WASM workspace (to speed up builds) was marked high-priority (PR #5444) but ultimately closed without merging – the team opted for the above Cargo.lock solution instead, simplifying the approach.
Documentation Updates: Documentation got a polish: an issue to “correct the term ‘smart contract’ in docs was closed. Iroha 2 uses the term “trigger” for its smart-contract-like feature, so this change aligns the terminology and clears up confusion for developers reading the docs. Also, various minor doc warnings were fixed (no more stray warnings during doc generation).
Miscellaneous Fixes: Additional bug fixes include resolving a bug where an “Expired transaction” event appeared after commit (now fixed), and addressing some flakiness in integration tests. Continuous integration workflow was reorganized to be more robust, and the labeler config was fixed so GitHub properly tags PRs. All in all, a bunch of pesky issues have been chased down and resolved.
Pull Requests Merged (May 23–30)
This week saw a flurry of PR merges: 🚀
- #5448 – build: Include WASM
Cargo.lockand allow trivial numeric casts (merged May 29) – Fixed CI lint failures and ensured reproducible builds for WASM. - #5447 – ci: Fix typo in tag (merged May 27) – Minor but important CI fix for Docker image tagging.
- #5445 – perf: Store public keys in compact format (merged May 26) – Community-contributed optimization improving memory usage.
- #5435 – build: Multi-arch docker image (merged May 26) – Added support for building multi-architecture Docker images of Iroha.
- #5430 – fix(triggers)!: Per-transaction trigger execution with depth limit (merged May 27) – Major fix to trigger handling (addresses trigger misbehavior, introduces a breaking change in trigger execution flow).
- #5421 – feat(wasm): Dynamic fuel in executor (merged May 27) – New feature for configurable WASM execution fuel limits. (Plus a few dependabot PRs were closed after being superseded by other updates.)
Issue Activity (Opened & Closed)
The Iroha repository was active with issue reports and discussions this week:
New Issues/Open Discussions:
A series of issues were opened as part of a “Trigger Safety” initiative for the upcoming 2.0 release candidate. For example:
- “Data triggers should inherit origin authorities (Trigger Safety 2-B)” – ensuring that triggers execute with the permissions of the original invoker for security.
- “Event subscription permissions (Trigger Safety 2-A)”– defining proper permission checks for event triggers.
- “Quota-based economic deterrence (Trigger Safety 3)” – proposing limits or costs on trigger usage to prevent abuse.
- These issues (all tagged for 2.0.0-rc.x milestone) signal that the team is focused on hardening trigger functionality before the next release. There’s active discussion around how to best implement these enhancements to balance flexibility with security.
- Another notable new issue is “Ensure every execution path goes through the executor” – a bug report making sure that all transaction processing uses the unified executor logic. This is being discussed to prevent any bypass of validation/execution steps.
Closed Issues:
Many issues were resolved this week, including:
- #5443 CI Lint Heisenbug – The transient lint failure in PR builds was fixed by PR #5448, and this issue is now closed.
- #5363 “Smart contract” terminology – Documentation updated (as noted above) to use the correct terms.
- #5232 Trigger firing too often – Addressed by the trigger execution fix (PR #5430).
- #4937 Per-transaction triggers – Also resolved by the new trigger execution model.
- #4687 Multi-arch Docker support – Fulfilled by the multi-arch image feature (PR #5435).
- #4429 Trigger queue bug – A bug where a trigger’s execution queue could get cleared on a new block (potentially skipping some executions) was fixed, and the issue was closed.
It’s great to see a lot of older tickets finally getting closed out as Iroha 2.0 matures!
Notable Community Contributions
This week highlighted the power of our open-source community:
- External PRs: A special shout-out to 0x009922 – their PR optimizing public key storage (#5445) was merged, improving Iroha’s performance. Community contributions like this are incredibly valuable, so thank you!
- Issue Reports: Community members also helped by reporting issues: for instance, user mversic opened the trigger-related bugs (#5232, #4937) that spurred improvements in trigger handling, and nxsaken requested multi-architecture Docker support (#4687) which is now implemented. Erigara identified the trigger queue issue (#4429) which has been fixed. These reports lead directly to a better Iroha – keep them coming!
- Engagement: It’s not all code – community members are chiming in on discussions around new features and design choices. It’s awesome to see ideas and feedback flowing in the open. If you have thoughts on “trigger safety” proposals or other improvements, don’t hesitate to join the conversation on GitHub.
Roadmap & Outlook
The development momentum suggests the Iroha 2.0 release candidate is getting polished for prime time. Recent fixes and enhancements (especially around triggers, security, and deployment flexibility) are strong indicators of an upcoming RC3 or final release. The team’s focus on trigger safety (with issues like 2-A, 2-B, 3) shows a commitment to making Iroha’s smart contract system robust and secure before launch.
On the horizon, there are hints of features like transaction fee research and other economic mechanisms (as seen in the “Quota-based deterrence” discussion). These could be potential roadmap items once the core 2.0 features stabilize. And with multi-arch support and easier config, Iroha is becoming more dev-ops friendly – a strategic move to encourage wider adoption.
That’s a wrap for this week’s update. 🎉 Kudos to everyone who contributed, whether by coding, reviewing, or giving feedback. The Hyperledger Iroha community is what makes this project special.
Stay tuned for next week’s update, and as always, happy coding! 🚢👩💻👨💻