You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Status
IN PROGRESS
Stakeholders
Outcome
Due date
Owner

Background

Whitepaper gave some information about Triggers and initial requirements about this functionality, but a lot of open questions comes into play when implementation details were discussed.

Problem

Triggers can be either based on time or on a confirmed transaction (event). This is very powerful and enables Turing complete computation for Iroha's smart contracts.

  • Trigger at timestamp
  • Trigger at blockchain
  • Trigger atcondition

For cases like Iroha Permissions Module it will be need to manage Triggers execution (before block/transaction/instruction or after block/transaction/instruction).

Order Book case

Users send bid and ask limit orders into the order book. Every order in the order book should be executed when counter order with the same price will be received. Speaking other word it should happen when bid meets ask at the same price. In this case limit order should be notified that there is a matching order and swap should be executed with resulting funds sent to the owners of both orders. Looks like this notification is reasonable to implement using triggers.

  1.  Challenging here is that there might be really a lot of orders in the order book and every order should have a trigger and every trigger should be checked somehow if price counter order exists or not.
  2. Another challenge is that after one order executed using a certain amount of funds of counter order, other orders having the same price cannot be executed on the same amount of the counter order funds. Other orders even for the same price should wait for new free fund amounts of counter orders.

Solution

Iroha Triggers should be stored on the Blockchain. Other parts are represented in form of open questions with some alternatives:

  • Where to store them?
    • Under World State View as a set of Iroha Special Instructions
    • Inside World State View under Peer entity as a set of Iroha Special Instructions
    • Inside "global" domain as Assets (which can be transformed into Iroha Special Instructions)
  • When to check Trigger execution conditions?
    • Every Instruction
    • Every Transaction
    • Every Block
  • How to execute them?
    • As additional set of instructions inside transaction
    • As a set of instructions outside transaction
    • As a new transaction
      • This option will prevent halting problem inside one round (cyclic triggers)

Additionally, we have some requirements according to "Impure" instructions (like I/O), if we will have them in Iroha:

  • Impure Triggers should be executed only once in the ledger
  • Impure Triggers should be not executed during validation phase 

Decisions

Alternatives

Concerns

Assumptions

Risks

Additional Information

  • No labels