Versions Compared

Key

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

...

By wake up condition:

  • 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)

  • Block number-basedbased  - (System Level and User Level )
    • At block
    • Each `n_blocks`
    • For complex use cases Trigger might register itself again to execute at another height
  • Transaction-based (Only System Level)
    • Before (transaction execution)
      • Only for System Level TriggersBefore each
      • Have the ability to check and fail or allow transaction
      • Have access to all transaction data
      • Example: Transaction metadata validation, prohibiting particular instructions, permissions based on instruction inspection
    • After (transaction execution)
      • After each
      • After transaction that triggered a change in WSV that meets arbitrary condition - this is the most general option
      • In both cases they have access to transaction contents and at least read access to WSV
      • Have the ability to check and fail or allow transaction - if System Level
      • Have access to all transaction data and WSV diff after execution
      • Example: Transaction fees, 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
  • Event-based - (System Level and User Level )
    • Triggered by events emitted from other triggers or transaction execution.

...