Page Properties | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
|
...
More details on initial research:
View file | ||||
---|---|---|---|---|
|
Problem
Integrations with different tools from Blockchain ecosystem required additional changes in Iroha 1.0 and Михаил Болдыревwith Andrei Lebedevhad to build more levels of abstractions to support them.
...
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 payloadsUse 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]`
...