Status
IN PROGRESS
Stakeholders
Outcome
Due date
Owner

Background

In some cases, we need to propagate the Iroha Special Instruction's result as an argument to the next Iroha Special Instruction building a pipeline from several instructions. 

Example

In DEX we need to check the conversion amount in the pool for a token to be exchanged. Then we need to send this value to the ISI which will send exchanged funds to the user. Last ISI should send exactly the same amount as defined by the conversion rate query. So query should somehow set this information as an argument to the next ISI.

Problem

Transaction's processing in Iroha 2.0 is a sequential execution of Iroha Special Instructions on World State View. Current signature looks like this: WorldStateView --execute(ISI_arguments..)→ WorldStateView.

All Iroha Special Instruction's arguments are provided by the incoming transaction and distributed across the ledger as is. The only way to work with current design to cover needs from the Abstract is to set calculation's results on the World State View in form of assets.

Solution

We send a composite Iroha Special Instruction to execute the following algorithm:

  1. Execute Iroha Query to find "conversion amount in the pool" and Add Parameter Asset with this amount to the Account.
  2. Execute Iroha Query to get this amount and send exchanged funds.
  3. Execute Iroha Query to get this amount and send them.
  4. Remove Parameter Asset with this amount from the account.

Because this is one Iroha Special Instruction we will prevent harm from "side" effects of other transactions and instructions. We will also have the same state across all peers with full history of values used for exchange.

Decisions

Current Iroha Special Instructions model can cover these cases by storing all calculations on the blockchain as assets.

Alternatives

  • An ability to pass arguments from one instruction inside transaction to another - can cause side effects and will bring up additional complexity
  • An additional temporary storage for transactions with direct access from instructions - additional public API to maintain and possible differences across the ledger

Concerns

  • Some users may not agree with concept of Iroha Special Instruction composition and would prefer more imperative style

Assumptions

  • Composite Iroha Special Instructions (If, Sequence, Pair) in combination with `Query` instruction will cover DEX cases.

Risks

  • Some cases are not listed and wouldn't be covered `[2;7]`
  • Additional out-of-the-box instructions would needed `[2;4]`
  • No labels