Hyperledger Iroha v1.0 beta-4 version
In this release following changes were made:
Faster throughput, pluggable state storage
There is less abstraction on state storage level, and validation is done with means of SQL queries. It has significantly improved the performance of Iroha peer and made it less error-prone (#1557).
State storage is plugged over ORM library titled as SOCI, which bundles a nice thread pool for faster interconnection with PostgreSQL; and makes it possible to switch to other supported SQL storage (how about using in-memory SQLite database for even faster throughput? #1505)
Stateful validation errors
All the stateful validation errors are printed in peer logs and response is sent to a client along with transaction status. Now it is a lot easier to check what went wrong with a rejected transaction (#1508)
Important note: this version of Iroha can disclose some personal data like account balance (if a transaction was statefully invalid —account can now get the reason). In the future version we will implement error codes (check them there)
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 #1485)
Transaction status streaming over RxCpp
Reactive extensions library in C++ is actively used in our architecture and now is in charge of transaction status processing (#1541)
Fixed critical bug with query signatures
Previously, in beta-3 there was an issue with invalid queries passing stateful validation. Signatures, attached to a query were not checked properly, and this was fixed in current release
Input fuzzing
Libfuzz checks the input in our client component (called Torii) and protobuf messages are mutated as well (#1531)
Blocks and proposals are not copied now (and their creation process is benchmarked)
A proposal is a candidate for becoming the next block in Iroha chain. The lifetime of these objects is important, this is why their creation and copying has to be minimized by means of C++ (#1542, #1567)
Creation is benchmarked by means of Google Benchmark library (#1539)
Check the size of signatures set
One of the bugs, that was revealed with help of fuzzing, was a possibly valid empty signature set attached to a transaction. This behavior was fixed in #1536.
Doxygen documentation
Code docs generation is added to the pipeline (for master and develop branches) and docs are uploaded to https://docs.iroha.tech on each commit
API changes
Transaction batch support
Transaction batch is a set of transactions, which are to be applied together. There are two kinds of batches:
- Ordered batch
- transactions will be applied strictly in the order they were received
- Atomic batch
- the order is still guaranteed
- failure of any transaction inside it leads to failure of the whole batch
Important note: this feature was not implemented completely in this release, however, interfaces and SDKs have already been changed for easier integration in the future. This does not affect backward compatibility.
Check the status of development here
Amount is passed as a string. Everywhere
Code became much simpler and it is easier to create transactions without SDKs now (#1555)
Proto files were split
Client API proto files now are stored in a shared model folder, whereas as Iroha peer messages are stored in schema folder (#1550)
GetAccountDetail is a bit more powerful now
Check our documentation page
GetPendingTransactions
In order to make scenarios related to transaction batches and multisignature transactions easier Iroha has API endpoint to get transactions of transactions batches which require signing by participating accounts (#1532)
Important note: this feature was not implemented completely in this release, however, interfaces and SDKs have already been changed for easier integration in the future. This does not affect backward compatibility.
Deleted account_id from Add/SubtractAssetQuantity commands
Finally, we have deleted account_id from a previously confusing API in #1511
Roles can have an empty set of permissions
Now users can create empty roles for use cases where such a role can serve a purpose of a tag or the least powerful role in the system (#1510)
Other
- Transaction status bus (#1575)
- Databases are purged and dropped after tests (#1406, #1584)
- Query execution can be mocked now (and tests are going to be much cleaner and easy to read) (#1579)
- Common objects factory (#1556)
- Builders are replaced with mocked Shared Model interfaces (#1563)
- WSV Query factories (instead of builders) (#1573)
- Refactor QueryProcessor interface (#1572)
- Block and proposal creation benchmarks (#1539)
- Proposal and block transactions validation (#1506)
- Add test cases for empty protobuf payload (#1502)
- Jenkins build status badge link (#1551)
- Shared Model build status is fixed (#1576)
- Java binding fix (#1507, #1569)
- Color diagnostics in Jenkins CI (#1515)
- Reuse Peer proto (#1522)
- Fix tests for createRole with the empty set of permissions (#1520)
- Improve Findgrpc.cmake (#1518)
- WSV (blockchain state) in PostgreSQL stores permissions as bit strings (#1499)
- CLI values now are cached for convenience purposes (#1496) by contributor uditha-atukorala
- Removed grantable permissions in queries (#1500)
- Refactored TransferAsset test (#1482)
- Fix indentation in a code of error message in IP validator (#1514, #1513)
- Fix type incompatibility on 32-bit platforms in keys manager (#1503)
- Python example fix (#1529)
- Bind operator in TemporaryWsv files (#1544)
Known issues
Windows build does not work at the moment, as well as JS bindings, due to their rough transition to new client libraries