Versions Compared

Old Version 10

changes.mady.by.user Nikita Puzankov

Saved on

compared with

New Version 11

changes.mady.by.user Egor Ivkov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page properties
label


Status
Status
colourYellow
titleIn progress
Stakeholders

Makoto Takemiya

 Egor Ivkov Andrei Lebedev Mikhail Boldyrev 

Bogdan Mingela Pavel Golovkin

Outcome
Due date
11 2020
Owner
Nikita Puzankov 

Egor Ivkov


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.

The design of Iroha Triggers mainly takes inspiration from:

  1. Database triggers - Oracle example
  2. Substrate weight and fee handling use cases in `pre-dispatch` and `post-dispatch` stages of transaction processing

Problem

Iroha Special Instructions can not provide the fully fledged toolbox for all possible use cases because they lack an ability to react on changes in Iroha state. Iroha Triggers provide this functionality and in addition to Iroha Special Instructions give users full-scale functionality for almost any business scenario.

...

Because we depend on triggers a lot, we will have tight coupling between transactions processing and their execution. Every Iroha Special Instruction that changes Iroha state (domain related instructions category from Set of OOB ISIs) can Trigger, so we need to check Iroha Triggers that depend on conditions every instruction, Iroha Triggers that depend on blockchain every block and Iroha Triggers that depend on timestamp every block also. 

...

It is suggested to:

  • Store Triggers under Peer entity
  • Have three the following Triggers categories:
    • Time-based
    • Block number-basedInstruction
    • Transaction-based (can have a condition of whether they need to execute, similar to Oracle `when` condition)
    • Triggers that are triggered by specific ISI call - ExecuteTrigger(Params)
  • Have an ability to configure trigger order for Transaction Based triggers:
    • Before (instruction or block)transaction execution) - have the ability to check and fail or allow transaction
    • After (instruction or blocktransaction execution)
  • Triggers will be build on top of Iroha Special Instructions and WASM
    • For instruction-based Triggers condition will be of `Instruction::Execute(Query)` type
    • All changes are declared as a set of Iroha Special Instructions or WASM

Decisions

Alternatives

  • Store Triggers as Assets - to much complexity and runtime dependent code
  • Execute Triggers sending new set of transactions - require networking communications, can end up in missing triggers

...