Abstract
Iroha Special Instructions processing requires to have a permissions based security model + a way to store some "triggers" on the block chain.
Whitepaper and Iroha v1 documentation were researched. The proposal is to use already existing Iroha Special Instructions + Assets mechanisms for Permissions implementation.
Introduction
Whitepaper gave some information about https://github.com/hyperledger/iroha/blob/iroha2-dev/iroha_2_whitepaper.md#251-event-listeners, and the need to trigger them based on time, block or "condition".
https://github.com/hyperledger/iroha/blob/iroha2-dev/iroha_2_whitepaper.md#211-data-permissions require protection of data from read and write cases.
https://iroha.readthedocs.io/en/master/concepts_architecture/glossary.html#permission gives a Permission definition:
A named rule that gives the privilege to perform a command. Permission cannot be granted to an account directly, instead, account has roles, which are collections of permissions. Although, there is an exception, see Grantable Permission.
and Grant-able Permission:
Only grantable permission is given to anaccountdirectly. An account that holds grantable permission is allowed to perform some particular action on behalf of another account. For example, if accounta@domain1gives the accountb@domain2a permission that it can transfer assets — thenb@domain2can transfer assets ofa@domain1to anyone.
As you can see permissions were a first-level entities in Iroha v1 while they can be easily implemented by Iroha Special Instructions.
pub mod isi { ... enum Instruction { Add(...), Register(...), ... Check(permissions::isi::CheckInstruction), } } pub mod permissions::isi { pub struct CheckInstruction<C, O> { condition: C, object: O, } }
Signature of `Instruction::execute` method provides an ability to return error result which for `Check` variant will prevent execution of Instructions for which account has no permissions. Each OOB Instruction and Query will include `Check` instructions in it:
impl Register { fn execute(...) -> Result<...> { Check{|account| account.asset("role") == ADMIN }.execute(...)?; ... } }
In this example you can see that we do not need to add permission related attributes to the `Account` and can use assets instead.
The same can be done with custom permissions, storing them in assets components of the account.
This whole concept can be used for event listeners `Instruction::Listener` can be executed for their configuration, but additionally to storing them in assets components of the account we need to find a way to store global Listeners (Domain level, Peer level) and define cases where we need time based listeners.