2.0.3-SNAPSHOT

• Reworked tests
• Enabled billing rule (#92)
• Added parallel execution of registration and status waiting (#91)

2.0.2-SNAPSHOT

• Refactored rest response (#83)

2.0.1-SNAPSHOT

• Added Lykke KYC Rule

• Added whitelist assets exception

• Removed 100 XOR limit rule

2.0.0-SNAPSHOT: Pre-Release 2.0.0 (#68)

• Fixed required accounts list (#38)

• Restricted brvs to the domains provided (#39)

• Changed index to name (#40)

• Removed auto registration of new brvs instance (#41)

• Brvs synchronization, added pregenerated keys (#43)

• Refactored signatures setting, fixed config (#45)

• BRVS as a lightweightnode node (#44)

• Added REST proxying Iroha transactions and queries

• Added mongo block storage

• Added proxying Iroha and brvs transactions list API

• Added env variables resolving in example spring context (#46)

• Refactored laucnhing to contain env variables (#47)

• Repaired pending tx queries (#48)

• Fixed integration test (#49)

• Updated gitignore and added log message (#50)

• Feature/whitelists (#52)

• added whitelisting rules

• Fix bitcoin withdrawal account (#53)

• Fix bitcoin withdrawal account

• Feature/billing (#51)

• Added customizable endpoint port (#55)

• Jenkins integration (#54)

• Updated logs to be the same format as notary (#58)

• Refactored verdicts format (#59)

• Changed PENDING to UNKNOWN (#60)

• Fixed batches singing (#61)

• Added brvs status subscription to unlock accounts properly (#62)

• Made default brvs config conform to d3 infrastructure (#63)

• Fix of removal and batches appearance (#64)

• Updated Iroha version dependencies (#65)

• Refactored configs and keys (#66)

• Copyright (#69)

• Changed keypair (#70)

• Added lykke domain (#71)

• Refactored queries (#72)

• Super major bug fix (#74)

• Added rule to forbid deleting brvs keys (#73)

• Added keys amount restriction rule (#75)

• Feature/listener (#77)

• Fixed signatory management (#78)

• Fixed user quorum processing, added rule (#79)

• Added a rule for limit of 100 XOR transfer by default

Initial release 0.1

Business Rules Validation Service is a standalone service used to validate user's Iroha transactions before arriving to an Iroha peer via shared signatories. This means that BRVS keys set is a part of each user signatories.

Hyperledger Iroha is the ledger, which is used for voting (via multisignature accounts) and decentralized data storage. Iroha Java Library is used to interact with Iroha peers.

This release has the following features:

Rules and validators

Rule is a sort of a business restriction description. Validator is an entity capable to apply some logic of the rules combinations.
BRVS has several rules hardcoded for demonstrations but a one is free to add rules implementations freely.
All the service components (like Rules) configurations are expected to be expressed via Spring XML configuration.

Safe and consistent rule verdict outcome

BRVS implements a mechanism to form queues of transactions for each user account and 'consume' them for checking on time to prevent inconsistent Iroha state from the business logic perspective. BRVS waits for user keys first to be attached to transactions first. Moreover, it provides a user blocking mechanism based on transactions results observing to restrict a user from sending multiple transactions at a moment.

Registration of user accounts

BRVS instance is able to scan a specified Iroha account details for a list of existing accounts to register on startup.
BRVS registers any new accounts created in Iroha if theirs domains conform to the preconfigured ones.
Additionally BRVS can register an account via REST API.

Verdict storage

BRVS stores its decisions about every user transaction (based on Rules and Validators) that can be queried through REST API.

REST API

BRVS provides REST API for both registering users manually and querying verdict records. Examples of API calls can be found in README.