...
Though as it is established in blockchain space current use cases require a more sophisticated functionality to efficiently support DeFi:
| Use Case | Needs * |
|---|---|
Swaps | Executed when Triggered by user activates; Does several additional state validations; Manages liquidity; |
Periodic Reward Distribution | Executed periodically; Distributes to all users satisfying certain condition; |
Customizable and modifiable transaction fees | Executed for each transaction; Have ability to disallow transaction execution; |
| Stable coins contracts | Executed periodically or triggered by user; Possibly check external conditions provided by oracle contracts; |
| Oracle smart contracts | Triggered by user; Aggregate data from external world; Provide data to other contracts |
*- Algorithms for all of these use cases need to be on chain for transparency and safety guarantees, which are provided by consensus.
...
| Use Case | Needs | Comments |
|---|---|---|
| Transaction Metadata Validation | Executed for each transaction; Have ability to disallow transaction execution; | |
| Transaction Set Instructions Validation for Account, Domain and Asset Definition metadata | Executed for each transaction; Have ability to disallow transaction execution; Have access to transaction ISI contents; | |
Permission Management | Executed for each transaction; Have ability to disallow transaction execution; Have access to transaction ISI contents; | We can let all permissions be customizable and upgradeable upgrade-able during runtime if we use Triggers. |
...
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.
Triggers execution, in contrast to transaction execution, depends on condition.This is how triggers are described in the whitepaper:
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 (every 5 minutes or after one hour)
- Trigger at blockchain (new block, reach of some height, etc.)
- Trigger at condition (new account, transfer of an asset, etc.)
Also, for cases like Iroha Permissions Module we will need to be able to manage Triggers execution order - for example to execute them before block/transaction/instruction or after.
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.
...
or
...
after
...
.
...
Impure Triggers and Instructions
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.
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
- Provide a Store (key-value) for each trigger - way to keep data between executions.
- Provide a possibility to create technical accounts for Triggers where they might keep transferred funds.
- 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
...