Iroha Weekly Updates 9 #irohaweekly

Nikolay Yushkevich <nikolai@...>

Want to know what we’ve recently done? Here is our weekly update for W28 🔥:

Binary Testing Framework. This is a test framework that helps testing client libraries (now particularly in Python) if they produce valid transactions and queries (if permissions and other business rules were met) (fix)

“On-demand” ordering service implementation. In August, Ordering Service of Iroha is going to be Byzantine Fault-Tolerant, and this code introduces new behavior of peers — where they would ask each other for a proposal

#HelpWanted we need someone with skills of animating algorithms, especially in distributed systems. This would help us to explain Ordering Service component behavior to a broader audience 

As we have decided to improve existing interface a bit, our users are able to query account information in a flexible way (check description here

Pluggable storage with SOCI library. It also bundles a nice thread pool for faster interconnection with PostgreSQL

Retrieval of pending transactions from Iroha. When a transaction is sent and it requires more signatures — accounts can query Iroha peers in order to get such transactions 

Transaction status streaming was rewritten completely with RxCpp (if you don’t know what is this check

Synchronization of expired blocks, which was a small yet annoying bug in process of peer synchronization

Validation of transaction batches. Soon we would have a ready-to-use solution for transaction batch processing, that would check if all involved parties have signed the batch

Fuzzing Iroha input. Now, libfuzz checks the input in a client module (called Torii). What is awesome is that our protobuf messages are mutated as well. Isn’t this an awesome thing? 

Blocks are not directly copied now in C++ (and a move is a bit faster)

Our proto schema files have been prettified finally

Check the size of signatures set
Concurrent fix for abstract cache
Increase precision lifetime in insertAsset

P.S. Stay tuned for progress in — these optimizations are expected to deliver a faster throughput