Pipeline triggers: re-evaluate the necessity and safety

[s8sato]

In my view, the only clearly useful programmable execution systems currently identified are the following three:

• smart contract (integrated with by-call trigger and custom instruction)
• data trigger
• time trigger

I am skeptical about providing other types of triggers:

• pipeline trigger: Without careful design, this could easily become a breeding ground for bugs. It appears to have been added in PR #2157 by bypassing the original architecture decision, justified merely by the existence of corresponding events and filters, without sufficient discussion. The peculiarity of the pipeline trigger concept lies in the fact that triggers are supposed to accompany block validation, whereas pipeline events, as the name suggests, occur throughout the entire pipeline, including but not limited to block validation.

  • transaction event

    • hash: Precomputing and specifying a hash is not realistic. Even if possible, this can be substituted by including the original transaction hash in a data event (#5250).

    • block height: Unless combined with other conditions, this induces an infinite loop within the same block.

    • status

      • queued and expired: Are there actual use cases? If triggers are induced by these statuses, at what block position should they be ordered?
      • approved and rejected: If you want to inject another transaction after a transaction is committed, you can simply use a smart contract and have it call another smart contract at the end of its logic.

  • block event: Generally, if you want to process something per block, a time trigger can be used. Still, assuming you want to process something in the “next” block, let us consider the following...

    • height: There may be use cases where one wants to perform some processing at a specific block height, but what is the difference in use from a time trigger?

    • status

      • created: What is the difference in use from a time trigger? Only the leader node would induce additional transactions, and reaching consensus on this would require additional gossip.
      • rejected: This variant is unused.
      • approved, committed, applied: What is the difference in use from a time trigger?

• trigger completed trigger: This event can be integrated as a type of pipeline event. If you want to chain programs, you can simply call the next smart contract at the end of the logic.

[s8sato]

If there is a use case that truly requires automation, one option is to introduce an off-chain worker that subscribes to pipeline events and converts them into certain transactions. In fact, in some other blockchains, even the functionality equivalent to data or time triggers is realized by having an off-chain worker call a smart contract. However, since Iroha has the concept of permissions, care must be taken when switching the execution principal.