2020-08-25 RFC: Triggers discussion meeting notes

RFC overview

@Nikita Puzankov

• @Ales Zivkovic  How we are going to handle the external values?

  • @Yuriy Vinogradov We can separate triggers and off-chain functionality to put the data into the blockstore and use it in triggers.

  • Even if we will remove triggers from the system, the problem will consist

  • @Ales Zivkovic I am asking because of the previously existing components. Anton Khvorov can provide the details

  • @Yuriy Vinogradov We can use bridges as off-chain information receivers. By making their generic, we can use them for different uses. 

• @武宮誠 Are triggers consumed when used?

  • Triggers are stored in the "peer" entity. There are special instructions for registration of triggers

  • @武宮誠 For many use cases, there should be triggers with one-time usage. There is a potential exploit when the trigger can be used indefinitely and use too many resources. We should provide the possibility to use permissions

  • We can add additional trigger which will unregister existing triggers

  • @武宮誠 It is fine to have one additional trigger, but how you will force people to create triggers?

 Discussion

@武宮誠

• There should be one additional use case for the 1-time trigger in the public network

• The use case can be taken from the Sora voting system

@Nikita Puzankov

• The idea of triggers is very near to Iroha special instructions

  • Trigger is the structure which is a composition of 2 entities:

    • Condition

    • Transaction for execution (set of ISIs)

• Evgeniy: We can use additional parameters for the triggers to store "enabled" state, and perform garbage collection after they are disabled

  • We need to write down the scenario to comments

• @武宮誠 : Few words about the syntax for conditions: will it be like a batch

  • It will be like ISI DSL approach

  • @武宮誠 Let's create a list of examples

  • @武宮誠 We need to also consider the possibility of a chain of executions triggered one by one

  • It is one of our open questions – should triggers be able to be executed by other triggers?

    • Current proposal – do not fire any triggers as a result of transactions, which executed by triggers.

    • We need to have comments to add such possibility

    • There should be also the possibility to execute the trigger by explicit ISI

    • There is a possibility – to have some 

    • @武宮誠 : It is quite a hard question, for Turing-completeness we need to think about allowing triggering triggers from other triggers

    • @武宮誠 We just probably need to wait for another block to execute trigger from another trigger, which will give us possibility to handle the situation

• @Yuriy Vinogradov We may need to have loops in triggers

  • @Nikita Puzankov There is no possibility to have an infinite loop in the ISI, as it is counter-effective for execution

  • @Yuriy Vinogradov The particular use case – distribution of tokens, which can take millions of executions of the trigger.

  • Evgeniy Zhukov: Probably we can use some safe recursion with formal verification

  • @Nikita Puzankov We need to have requirements and model for verification

  • @武宮誠 For initial release we can limit complexity by limiting that Triggers cannot trigger triggers, then we can go deeper into the research of languages and safety

  • @Ales Zivkovic There is not about requirements, there is a non-functional security requirements. We need to develop protection from the hacker.

  • @Nikita Puzankov Yes, we can start with the limited functionality and then add additional security protection to caver extended functionality.