Page History

...

• Time-based - (System Level and User Level )
  
  • At timestamp
  • Each `duration`
  • For complex use cases Trigger might register itself again to execute at another timestamp
  • Time based Triggers seem to be difficult task for synchronization between peers. The following approach is suggested:

    • Recommendations to execute them should be added by the leader to the block (even if there are no transactions - leader should generate a block with trigger execution recommendations for them)

    • They are best effort - Iroha does not guarantee them to be executed at exact time. But it guarantees execution at closest possible time if network is operational.

    • If a leader does not produce a block with appropriate time based triggers in the defined time period after those trigger's selected timestamps - view change happens - similar to how if leader does not produce block for ordinary transactions

    • Next leader in this case will need to include the previous time based trigger in a block (when a view change happens it will be given a new time window to do this)

  • Example: Periodic rewards, scheduled batch processing
• Block number-based  - (System Level and User Level )
  
  • At block
  • Each `n_blocks`
  • For complex use cases Trigger might register itself again to execute at another height
  • Example: Per block rewards, scheduled batch processing
    
• Transaction-based (Only System Level) - primarily for private blockchains
  
  • Before (transaction execution)
    
    • Before each
    • Have the ability to check and fail or allow transaction
    • Have access to all transaction data
    • Allows introducing additional permission level for private blockchains
    • Example: Transaction metadata validation, prohibiting particular instructions, permissions based on instruction inspection
  • After (transaction execution)
    • After each
    • Have the ability to check and fail or allow transaction
    • Have access to all transaction data and WSV diff after execution
    • Allows introducing additional permission level for private blockchains
    • Example: Transaction fees, permissions Permissions based on changes to WSV
• Triggers that are triggered by specific ISI call - ExecuteTrigger(Params) - (System Level and User Level )
  
  • Similar to smart contracts as they are in Ethereum blockchain
  • Execute as part of the transaction instructions execution
  • For System Level - only admin can call the Trigger or through democracy pallet
  • Example: Swap with liquidity pool, locking funds (for bridges or stable coins for example)
• Event-based - (System Level and User Level )
  
  • Triggered by events emitted from other triggers or transaction execution.
  • The triggers react to the events emitted in the previous block as shown in the `Execution` section.
  • If leader does not supply the needed trigger execution recommendations based on events from previous block -
    the block will be rejected and the next leader will have to do this.
  • Example: Reacting to currency flow, reacting to system events (events from system level triggers), keeping metadata in sync

...

Triggers can also communicate by defining and emitting event events at their execution.

Execution Limits

...

It might be good to provide Triggers with a way to `Unregister` themselves. Especially for public blockchain use cases.

Outside of Triggers Scope

The following topics are proposed not to be handled with Triggers but instead considered separately. Both of the topics need a separate RFC, but they are mentioned here in the context of their relation to Triggers.

Instruction and Query Permissions

We considered moving our permission check into Triggers (for them to be runtime upgradeable), but this does not seem like a good idea due to the following reason.

If Triggers are used to check instructions' permissions during transaction execution, then how should Trigger permissions be checked.
If it is decided to:

1. Handle transaction permission checks and trigger permission checks separately - this will create inconsistency.
2. Use triggers to check execution of other triggers - this introduces a lot of complexity into the design.

Instead it is proposed to have Permissions as a WASM system which is not a Trigger, but a separate part of the system. This will allow us to upgrade them at runtime, without the complexity that might be there with Triggers.

Network Fees

We also considered using Triggers for handling network fees (transaction and trigger fees), but again there is a following issue.

If transaction based Triggers are used to calculate transaction fees, how should we calculate Trigger execution fees.
Here again there might arise either consistency or complexity problems.

Instead it is proposed to have either a highly configurable system where fee configuration can be done at runtime, or again do it through a separate WASM system (if fee handling logic might be changed at runtime).

Implementation Considerations

...