Page History

...

2 - Leader adds trigger execution recommendations to the created block

Leader also should add events emitted by the transaction execution and triggers.

3 - Validators receive the block and check if they agree with leader trigger execution recommendations

...

• Time-based
  • 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-based
  • At block
  • Each `n_blocks`
  • For complex use cases Trigger might register itself again to execute at another height
• Transaction-based
  
  • Before (transaction execution)
    
    • Only for System Level Triggers
    • Have the ability to check and fail or allow transaction
  • 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
• Triggers that are triggered by specific ISI call - ExecuteTrigger(Params)
  • Similar to smart contracts as they are in Ethereum blockchain
  • Execute as part of the transaction instructions execution
• Event-based
  • Triggered by events emitted from other triggers or transaction execution.

Persistent State

Complex Triggers (such as Swap triggers managing Liquidity Pools) might need to store data between their invocations. For this purpose Triggers will have following persistent storage:

...