...
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.
...
- Database triggers - Oracle example
- Substrate weight and fee handling use cases in `pre-dispatch` and `post-dispatch` stages of transaction processing
- Smart contracts in other blockchains
Problem
Currently we can submit transactions that can modify global state if they pass validation. These transactions can contain `Query`s inside of them, allowing them limited capability to execute logic on-chain.
Transactions can include:
- Iroha Special Instrucions
- (Unclear if needed and not yet implemented) WASM blobs
Independently of their content type they will have limited capability as they will only be able to execute the contained logic once.
Though as it is established in blockchain space current use cases require a more sophisticated functionality to efficiently support DeFi:
| Use Case | Needs * |
|---|---|
Swaps | |
Periodic Reward Distribution | |
Customizable and modifiable transaction fees | |
| Stable coins |
*- Algorithms for all of these use cases need to be on chain for transparency and safety guarantees, which are provided by consensus.
Other use cases for permissioned blockchains might include:
| Use Case | Needs | Comments |
|---|---|---|
| Transaction Metadata Validation | ||
Permission Management | We can let all permissions be customizable and upgradeable during runtime if we use Triggers. |
Solution
To execute arbitrary logic on-chain for unrestricted number of times other popular blockchains have Smart Contracts. Our solution for introducing smart contract functionality is called Triggers.
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 impure (I/O to 3rd party systems) Instructions and Triggers will not be supported by Iroha 2 - Iroha Events can be used to receive information by Cloud Events Consumers.
...
Peer can be a place to store Iroha Triggers. We can register new Triggers by Register<Peer, Trigger> Iroha Special Instruction.
...
- Store Triggers under Peer entity
- Provide a Store (key-value) for each trigger - way to keep data between executions.
- Have the following Triggers categories:
- Time-based
- Block number-based
- 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 (transaction execution) - have the ability to check and fail or allow transaction
- After (transaction 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
Triggers can be subdivided into the following categories and uses cases:
Time and Block Based
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
...