Page History

...

Whitepaper and Iroha v1 documentation were researched. The proposal is to use already existing Iroha Special Instructions + Assets mechanisms for Permissions implementation. 

Problem

The White Paper requires protection of data from unauthorized read and write access.

...

As you can see permissions were a first-level entities in Iroha 1 while they can be easily implemented by Iroha Special Instructions + Assets.

Solution

Permissions can be implemented as Iroha 2 Module and stored as assets under account that "owns" them. Then all out-of-the-box Iroha Special Instructions and Iroha Queries will trigger execution of permission check.

Permission check is an execution of `FindAssetsByAccountIdAndAssetDefinitionId` Iroha Query result and check that set of assets is not empty (containing permission needed).

Additionally to solving the problem it brings interesting advantages:

• we do not need to worry about Genesis Block and Network Setup problems (manual initial state configuration vs disabled state during genesis block commit) - we can place permissions module related entities (domains, asset definitions, triggers) commit after basic entities (root account, etc.) commit
• usage of Iroha Queries as a declarative API gives an ability for performance improvements (caches, batch executions, etc.)
• Iroha modules and users can "deploy" own permissions and checks without a need to compile them or to restart Iroha Peers
• private blockchains that do not need permissions module can remove it from the Genesis Block
  • `+` growth in performance
  • `-` additional client-side security checks needed

and had a strict hardcoded verification logic. Iroha1 was mainly planned to be used as a private blockchain and this system would work there. Yet Iroha2 is planned to be used in both private and public blockchains and therefore needs some degree of customization on how permissions are checked to implement some more complex cases.

Solution

Decisions

• Store permissions as Iroha Assets
• Check permissions by Iroha Triggers
• Place initial configuration inside additional Permissions Iroha Module and apply it from the Genesis Block

...

1. Use Iroha 1 approach with roles and grantable permissions and do hardcoded permissions checks inside instructions
   1. Pros:
   1. `+` Out-of-the-Box permissions grouping by roles
   2.  `-` hardcoded permissions checks and additional low-level logic
   1. 
      
      1. Tested in already running blockchains like bakong and byacco
   2. Cons:
      
      1. Hardcoded permission model - not possible to suit to different types of blockchains
2. Use Iroha Special Instructions as scripting for checking permissions + Assets mechanisms to store. With two options: implement permission checks as triggers, or simply another part of validation pipeline.
   1. Pros:
      
      1. Customizable permissions check logic
      2. Can be changed at runtime and stored in file
   2. `+` customizable permissions check logic
   3. `+` can be changed at runtime and stored in file
   Use assets, but do hardcoded permissions checks inside instructions
   1. `+` less client-side actions needed
   2. `-` no ability to clean genesis block  processing and configuration
3. Use WASM permission check functions so that they can be fully customized and written in any programming language (at runtime can be swapped)

Concerns

• Additional requirements to Iroha Special Instructions, Queries and Triggers will slow down development
• Additional high-level functionality would be needed to simulate "Roles"

...