Page History

...

...

More details on initial research: 

Problem

Integrations with different tools from Blockchain ecosystem required additional changes in Iroha 1.0 and Mikhail Boldyrevwith Andrei Lebedevhad to build more levels of abstractions to support them.

Data Model solution is an attempt to make Iroha "backend" more extensible without need to change already existing parts.

The idea behind DM or HL Transact is to decouple business logic from the blockchain. It will allow to run Iroha with a subset of ISIs required for a specific deployment, or solely with Burrow EVM, or WASM as business logic layer, for example.

Solution

A data model (further referred to as DM) is a business model abstraction. It may provide interfaces to execute some commands and query some state. A DM implementation is a module that can be attached to an Iroha node. In that case, the set of commands delivered to a DM module is strictly determined by the ledger, which enables to build extensible blockchain applications.

...

It also has no Iroha API inside, but it can be added if needed.

Decisions

• Use protobuf schema for Commands and Queries payloads  Use some schema for Commands and Queries payloadsdescriptions
• Commands and Queries implementation should align to appropriate interfaces (rollback_block, load_persistent, etc.) in available SKDs?
• Executor makes a decision to proceed with command/query or not

...

• No strict requirements to environment is powerful yet dangerous solution
• Solution did not align well with Iroha 2.0 in it's current form

Assumptions

• Clients and Iroha use gRPC or another protocol with Protobuf 
• Custom commands and queries has no obvious API for Iroha

Risks

• Protobuf will not be enough for 3rd party applications and users `[9;7]`
• Powerful environments will require a lot of resources `[9;5]`

Additional Information

• https://docs.rs/transact/0.2.4/transact/#modules